单个 Agent 跑得挺好，一上多 Agent 协作，反而开始乱套：两个 Agent 抢着干同一件事，另一个关键步骤没人管；上一个 Agent 干完的成果，下一个根本没接住，重新理解一遍还理解错了；最后产出一堆互相矛盾的结果，谁都不知道该听谁的。这些不是个例，是多 Agent 协作里几乎必然遇到的坑。
Anthropic 红队之前实测过，45 个 Claude 协作找漏洞很强，80 个一起写代码却集体摆烂。人越多不一定越强，Agent 也一样。这篇把多 Agent 协作最常见的五个坑拆开，每个坑配一个可落地的解法。
坑一：任务拆分边界模糊
多 Agent 协作的第一步是拆任务，而大多数失败就死在第一步。边界模糊有两种典型表现：一是职责重叠，两个 Agent 都以为自己该做，做了双份还可能互相覆盖；二是职责遗漏，某个步骤谁都不认领，最后在结果里凭空消失。
解法是把任务拆成「单一职责 + 可验证产出」。每个 Agent 只负责一件事，并且这件事有一个明确、可检查的输出物。拆完之后，主 Agent 逐项核对产出有没有交齐，交齐了再往下走。这套核对思路，跟站里写的 质量门禁 是一条线——产出不达标，不放行到下一步。
坑二：上下文传递丢失
Agent 之间的协作，靠的是把上一个环节的成果传给下一个。传的过程中信息一定会衰减：A 把结论浓缩成一句话，B 只能基于这句话继续，A 当时看到的细节、做过的排除、踩过的坑，全没了。
解决的关键不是传更长的文本，而是传「结构化的交接物」。把结论、依据、已排除的选项、待确认的事项分开写，而不是写成一坨自然语言。每次交接都留痕，才能事后追溯到底哪一步把信息弄丢了。这个思路和 证据包、回放对照 完全一致：先留痕，再定位。
坑三：结果合并冲突
多个 Agent 对同一个问题给出不同答案，是常态不是意外。如果系统没有仲裁机制，就会随机采纳、或者干脆把所有答案混在一起，制造一个更乱的结论。
解法是设立明确的仲裁层：由主 Agent 或一个专门的评审 Agent 来裁决，裁决要有标准（比如数据一致性、来源可信度、逻辑自洽），而不是拍脑袋。拿不准的，交给 人工复核抽检。裁决结果本身也要记录，方便回查为什么选了 A 没选 B。
坑四：互相调用死循环
Agent 之间可以互相调用，这是多 Agent 的威力，也是最危险的地方。A 调 B、B 又调 A，如果中间没有层级约束和终止条件，token 会被烧穿，任务卡死在原地。
解法是给调用设层级和熔断：调用只能从上往下、不能同级无限互调；给每一次调用设最大步数和总预算，超了就停；检测到「同样的调用反复发生」就触发熔断，强制转人工。这套逻辑对应 失败升级规则——确定错的转人工，别让 Agent 在原地空转。
坑五：集体摆烂与责任稀释
Agent 一多，会出现一种微妙的现象：责任被稀释。每个 Agent 都默认「别人会兜底」，结果谁都没兜住。红队实测里 80 个 Claude 写代码集体摆烂，本质就是协作规模超过了协调能力，责任边界碎掉了。
解法是控制协作规模，同时给关键环节设单一负责人。不是 Agent 越多越好，而是「刚刚够」最好。当任务卡住或者连续失败，要有明确的 转人工队列，把还原好的调用链和原始产出交给人，而不是让一堆 Agent 继续互相推。
总结
多 Agent 协作的坑，归结起来就一句话：拆得清、传得准、裁得明、刹得住、责任到人。任务拆分要单一职责加可验证产出，上下文传递要结构化交接并留痕，结果合并要靠仲裁而非随机，互相调用要设层级和熔断，规模失控要能及时转人工。把这些机制建起来，多 Agent 协作才不是「越多人越乱」，而是真正可控制、可复盘的工程。
