16.4 怎么避免 Agent 之间扯皮

概念：AI 团队也会”开会开到天黑”

多 Agent 系统最大的挑战不是技术选型，而是协调——让多个 AI 不打架、不推诿、不重复劳动。这听起来像管理学问题，但它确实是 2026 年多 Agent 生产环境中最常见的故障来源。

生活比喻：想象一个五人乐队，没有指挥，没有总谱，每个人只看得见自己的乐器。鼓手觉得吉他手节奏快了，吉他手觉得鼓手慢了，贝斯手不知道该跟谁——结果不是音乐，是噪音。多 Agent 系统没有协调机制时，情况一模一样。

2025 年的一项工程实践分析指出，AutoGen 的 GroupChat（群聊模式）最高频的生产故障就是”无限辩论”——Agent 陷入递归循环讨论，不断消耗 token 直到系统设置的 max_rounds 硬性切断，而此时还没有任何有效产出 ¹。

教学：四种典型故障与解决方案

故障一：无限辩论——“你说的不对""你才不对”

两个 Agent 对一个问题争论不休，永远不收敛。这在辩论模式中尤其常见：Agent A 提出一个观点，Agent B 反对，Agent A 再反驳 B 的反对，Agent B 再反驳 A 的反驳……循环往复。

为什么会发生？ LLM 本质上没有”认输”机制——它被训练成每次回复都要有实质内容。当两个 Agent 被设定为”坚持己见”的角色时，它们就把对话变成了永动机：每次回复都在之前的回复上做增量，但永远到达不了终点。

解决方案（三层防御）：

第一层：设置最大辩论轮次。通常 3-5 轮足够。超过上限，强制终止并由裁判 Agent 做最终裁决——裁判不看双方的历史辩论，只看双方最后一轮的立场和证据，独立判断。

第二层：收敛检测。不等到轮次上限才停——每轮之后检查双方立场是否已经趋同。如果连续两轮的核心主张相似度超过 80%，直接判定为已收敛，合成最终答案。这是在 2025 年 CortexDebate 研究中提出的”稀疏辩论”策略 ²。

第三层：成本熔断。设置单次任务的 token 预算上限——比如 5000 token。一旦超过，无论辩论是否收敛，都强制终止并返回当前最优结果。这是生产环境的底线保障。

故障二：总管瓶颈——“老板看不完所有周报”

层级模式的核心是总管 Agent 负责调度，但它面临一个致命问题：下属 Agent 的汇报越来越长，总管的上下文窗口被塞满，导致它”忘记”之前的决策或者”看漏”关键信息。

2025 年报告的一个真实故障案例：CrewAI 层级模式下，总管 Agent 压缩下属汇报时丢失了参数精度——本该是 UPDATE（修改记录）的操作被错误推断为 DELETE（删除记录），造成了生产数据丢失 ³。

解决方案：

• 摘要而非全文：下属 Agent 的汇报只包含结论、置信度和关键证据，不包含完整推理过程。总管需要细节时再主动查询。
• 结构化汇报模板：强制下属用固定 JSON 格式汇报（任务ID、状态、结论、置信度、需要总管决策的事项），总管一眼就能看完所有下属的状态。
• 分级管理：如果团队超过 5 个 Agent，增加一个”小组长”层级——组长汇总组内结果后向总管汇报，减轻总管的直接沟通负担。

故障三：责任推诿——“这是你的问题”

Agent A 说”这不在我的职责范围内”，Agent B 也说”这不在我的职责范围内”——任务就在两个 Agent 之间被踢来踢去。或者更糟：两个 Agent 都认为”这是我的活”，产生冲突输出。

根本原因：角色边界模糊。 如果两个 Agent 的 system prompt（系统提示词）都写着”你是一个能干的 AI 助手，什么都能做”，它们就不会自动产生分工——反而会因为职责重叠而打架或推诿。

解决方案：

• 明确的能力边界声明：每个 Agent 的 system prompt 不仅要写”你能做什么”，更要写”你不能做什么”和”遇到不属于你职责范围的任务时，明确声明并建议转交给哪个 Agent”。2026 年的 Agent 安全标准草案也强调了这一点——Agent 必须有清晰的能力边界 ⁴。
• 失败处理流程：定义”当某个 Agent 无法完成任务时怎么办”——是升级给总管、转交给其他 Agent、还是降级为人工处理？
• 任务交接协议：Agent A 转交任务给 Agent B 时，必须附带”为什么我处理不了""我尝试了什么""建议 B 从哪个方向入手”。这让信息不丢失，也让总管可以审计转交是否合理。

故障四：重复劳动——“我们都搜了同样的东西”

Agent A 搜索了”2026 年 AI 芯片融资数据”，Agent B 也搜索了同样的关键词——浪费了两次 API 调用费用，还得到了可能不一致的结果。

这在层级模式中尤其常见：总管把一个大任务拆成几个子任务分给下属，但子任务之间有重叠区域，两个下属各自去搜了相同的资料。

解决方案：共享记忆（Shared Memory）。

不是让 Agent 之间互相读对方的脑子，而是维护一个所有 Agent 都能看到的”已完成任务清单”。Google ADK（Agent Development Kit）在 2025 年底提出了一个分层的上下文架构：工作上下文（当前任务）→ 会话层（持久事件日志）→ 记忆层（可向量检索的长期记忆）→ 制品层（大文件只存引用不塞进窗口）⁵。

具体实现：

• 每个 Agent 执行任务前，先查共享清单——“有没有人已经做过类似的？”
• 任务完成后，写入共享清单——“我完成了 X，中间结果是 Y，来源是 Z”
• 用 Redis 或向量数据库做共享存储，加锁机制保证并发一致性

故障五：共享状态被覆盖——“我写的东西被覆盖了”

多个 Agent 同时读写共享状态（比如同一个文档、同一个数据库），Agent B 的写入可能悄无声息地覆盖 Agent A 的结果——经典的”最后写入者胜”（Last Writer Wins）问题。没有报错，没有警告，数据就丢了。

解决方案：提议-验证-提交（Propose-Validate-Commit）三阶段协议。

• 提议阶段：Agent 声明”我要修改 X”
• 验证阶段：协调器检查 X 当前版本是否与 Agent 上次读取时一致——如果不一致，说明有人抢先改了，拒绝修改并通知 Agent 重新读取最新版本
• 提交阶段：验证通过后才能写入

这本质上是把数据库的乐观锁（Optimistic Locking）思想搬到了 Agent 协作中——不需要中央锁，但能检测和防止冲突。

关联

• 16.3 多 Agent 架构模式深入 — 不同架构模式下的协调策略（流水线的错误传播 vs 层级的调度故障）
• 16.5 Agent 间通信 — 共享内存、消息队列等通信实现方式
• 16.6 多 Agent 的挑战 — 通信开销、错误传播、幻觉放大等系统性挑战
• 概念-MultiAgent — 协调机制对比表（顺序/并行/投票/层级/辩论）
• 第14章 · Agent 是怎么工作的 — 先理解单个 Agent 的 ReAct 循环，协调是建立在单 Agent 能力之上的
• 第15章 · Agent 之间的通信协议 — MCP 和 A2A 标准让 Agent 之间的协调有统一的”语言”

---

← 上一节：16.3 多 Agent 架构模式深入 ｜ 下一节：16.5 Agent 间通信 →

注释

1. CloudGeometry, “From Solo Act to Orchestra: Why Multi-Agent Systems Need Real Architecture”, 2025, https://www.cloudgeometry.com/blog/from-solo-act-to-orchestra-why-multi-agent-systems-demand-real-architecture ↩

2. Sun et al., “CortexDebate: Debating Sparsely and Equally for Multi-Agent Debate”, ACL 2025, https://arxiv.org/abs/2507.03928 ↩

3. OneStarDao, “Why Multi-Agent Orchestration Collapses”, 2025, https://dev.to/onestardao/-ep-6-why-multi-agent-orchestration-collapses-deadlocks-infinite-loops-and-memory-overwrites-1e52 ↩

4. Google, “Architecting efficient context-aware multi-agent framework for production”, 2025, https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/ ↩

5. Google ADK, “Context Architecture for Multi-Agent Systems”, 2025 ↩