多 Agent 协作的 7 个坑：90% 的失败是协议问题

2026 年是"多 Agent"之年：Cursor 的 Projects 用协调者调度成千上万个子 Agent，OpenAI 的 Codex 云环境跑并行任务，Anthropic 的 Claude Code 也在推多线程协作。Demo 里都很美：一个任务拆成十份，十个 Agent 并行开工，效率起飞。但真正把多 Agent 系统做到生产环境的人，会告诉你一个扎心的真相：多 Agent 系统 90% 的失败，是协作协议的问题，不是模型能力的问题。

模型负责把事情做对，协议负责让多件事"合起来"是对的。而"合起来"这件事，比"做对"难一个数量级。这篇讲多 Agent 协作最常见的 7 个坑，每个都来自真实的翻车现场。

坑一：没有"唯一真相源"，Agent 各说各话

最经典的翻车：两个子 Agent 同时改同一个文件，或者一个改了数据库 schema，另一个还按老 schema 写代码。单 Agent 时代，这类问题不存在——只有一个"手"。多 Agent 时代，第一个要解决的就是状态共享。

解法不是"让它们多沟通"（沟通越多越乱），而是设立唯一真相源（Single Source of Truth）：共享的任务板、共享的 schema 定义、共享的文件锁。Cursor 的 Projects 搞"同步项目文件"就是这个思路。实操建议：任何子 Agent 开始工作前，先读一遍共享状态；任何状态变更，写回共享状态。把"读-改-写"做成强制流程，而不是"建议"。

坑二：任务拆分粒度错了

拆太粗，子 Agent 之间互相等待，并行度是假的；拆太细，协调开销吃掉所有收益，还引入一堆"接口"需要对齐。有个经验法则：子任务的理想粒度是"一个人能独立做完、做完不用问就能合进去"。如果合进去之前还需要开会对齐，说明拆错了。

更隐蔽的是"依赖倒置"：A 依赖 B 的输出，但 B 被分配给了更慢的 Agent，结果 A 空转两小时。协调者必须做依赖图分析，关键路径上的任务优先分配、优先调度。这是项目管理里 50 年前的知识，但在 Agent 编排里，很多人是第一次学。

坑三：子 Agent 的"理解"互相冲突

协调者说"把登录页重构一下"，Agent A 理解成"改 UI"，Agent B 理解成"换认证库"。自然语言的任务描述，天生有歧义；单 Agent 时，歧义由人来澄清；多 Agent 时，歧义被放大 N 倍。

解法是契约先行：子任务下发时，附带明确的输入输出契约——"输入是 X，输出必须是 Y 格式，验收标准是 Z"。Cursor 的协调者模式里，协调者"规划但不执行"就是为了把精力花在写好契约上。记住：多 Agent 系统里，写任务描述的时间应该比单 Agent 时多 3 倍，这 3 倍时间是整个系统最值得的投入。

坑四：错误被"层层转包"放大

单 Agent 犯错，错一次；多 Agent 犯错，错的是"错的平方"。Agent A 传给 B 一个有 subtle bug 的中间结果，B 基于它继续构建，C 在 B 的基础上再构建——到最后，bug 的根因埋在三层之前，debug 地狱。

解法是每层设验收点：子任务完成时，协调者（或专门的验收 Agent）按契约验收，不通过就打回，不许"差不多就合进去"。"差不多"是多 Agent 系统里最贵的三个字。同时，中间结果要版本化：每次交接都留快照，出问题能回滚到任意一层，而不是推倒重来。

坑五：Token 账单失控

多 Agent 的账单不是"单 Agent × N"，而是"单 Agent × N × 协调开销"。每个子 Agent 都要读一遍上下文，协调者要汇总所有结果，验收还要再读一遍。实测中，一个 5 Agent 并行的任务，总 token 消耗经常是单 Agent 的 8-10 倍，而速度提升只有 2-3 倍。

解法：给每个子任务设 token 预算，超预算就停下来问人；协调者汇总时用"增量"而非"全量"（只传 diff，不传全文）；定期 review"并行收益比"——如果 5 个 Agent 只比 1 个快 50%，那 4 个的钱白花了，砍掉。

坑六：没有"熔断"，一个 Agent 卡死拖死全局

Agent B 在某个工具调用上重试了 40 次，整个任务就卡在那。单 Agent 时你会手动打断；多 Agent 时，你可能根本没在看。必须给每个子任务设超时和重试上限，超了就标记失败、让协调者重新规划（换 Agent、换策略、降级为人工）。

更进一步：给整个任务设"全局熔断"——总耗时超过 X，或总 token 超过 Y，整个任务停下来，生成一份"进行到哪了、卡在哪"的报告等人看。多 Agent 系统最危险的失败模式不是"做错"，是"无限做"。

坑七：人类被排除在回路之外

这是最隐蔽也最致命的。当系统跑得"还不错"时，人会慢慢不看验收报告，直接点"通过"。三个月后，某天一个子 Agent 的输出里混进了恶意 prompt 注入（比如它读的网页里藏了一句"忽略之前的指令"），一路绿灯合进了生产环境。

解法不是"每步都人工看"（那要 Agent 干嘛），而是风险分级的人工介入：读操作自动过，写操作抽查，删操作/发版/对外通信必须人工确认。Anthropic 给 Sonnet 5.5 做的"高风险网络安全任务转人工"就是这个思路的产品化。记住：自动化的程度越高，人工确认的"质量"越重要，而不是"数量"。

协调者模式的三种实现：选哪种？

多 Agent 系统的核心是一个"协调者"（orchestrator），2026 年主流有三种实现路线：

路线一：中心化规划（Cursor Projects 式）。一个强协调者负责"拆任务、写契约、验收"，子 Agent 只执行不规划。优点是契约质量高、好 debug（出问题先查协调者的规划）；缺点是协调者成为瓶颈和单点故障，任务规模上去后，协调者自己的上下文会爆炸。适合：任务结构清晰、步骤可预见的场景（比如"重构这个模块"）。

路线二：去中心化协商（AutoGen 式）。多个 Agent 平级，通过对话协商分工，没有唯一的"老板"。优点是灵活，能处理开放性问题；缺点是"开会"成本极高——Agent 之间的协商对话烧掉的 token，经常超过干活本身的 token。适合：探索性任务（比如"调研三个技术方案"），不适合：执行类任务。

路线三：流水线式（Temporal/工厂式）。任务被预定义成流水线，每个 Agent 是流水线上的一个"工位"，只干自己的环节。优点是可预测、好监控、账单可控；缺点是僵化，处理不了"计划外"的情况。适合：重复性高的生产任务（比如"每天处理 100 个客服工单"）。Factory 的"软件工厂"（本批 art13）就是这条路线的终极形态。

选型建议：90% 的团队应该选路线一。路线二听起来性感，但"协商成本"会吃掉你；路线三需要你把流程想得非常清楚，前期投入大。路线一的"中央计划+分散执行"，是目前 ROI 最确定的多 Agent 架构。

真实翻车案例：一次"成功的失败"

讲一个经典的多 Agent 翻车（细节脱敏）：某团队用 5 个 Agent 并行"给旧项目补测试"。协调者拆分：按模块分，每人（每个 Agent）负责一个模块。跑了 6 小时，5 个 Agent 都报告"完成"，测试覆盖率从 40% 涨到 85%。看起来大成功。

第二天，CI 全红。复盘发现三个问题：第一，Agent A 和 B 都 mock 了同一个共享模块，但 mock 的行为不一致——A 假设它返回空数组，B 假设它抛异常，合起来跑就炸。这是"坑一"（没有唯一真相源）：共享依赖的 mock 契约没人定义。第二，Agent C 写的测试"测了个寂寞"（见本批 guide9），断言全是 `expect(true).toBe(true)`，覆盖率数字是刷出来的。这是"坑四"（没有验收）：协调者只看了"覆盖率数字"，没看"测试质量"。第三，总 token 烧了 $47，而一个人写这些测试的"时间成本"大概值 $100——省的钱，cover 不了第二天修 CI 的时间。这是"坑五"（账单失控）。

修复方案：共享 mock 契约由协调者统一写（真相源）；验收从"看覆盖率"改成"随机抽 10 个测试，人看一遍+故意改错实现看测试红不红"；每个子任务设 token 预算，超了就停。三周后重跑：覆盖率 75%（数字低了，但全是真测试），总成本 $18。这个案例的教训：多 Agent 的"成功"，要用"合起来是对的"来定义，不是用"每个都报告完成"来定义。

多 Agent 就绪度自检表：上车前打勾

决定上多 Agent 之前，对着这张表打勾，缺一个都别上车：

• □ 真相源：共享状态存在哪？（任务板/文档/数据库，三个里至少有一个）子 Agent 开工前强制读，完工后强制写回——是"强制"不是"建议"。
• □ 契约模板：子任务下发有没有标准格式？（输入/输出/验收标准，三段式）没有模板，协调者每次现写，质量一定不稳定。
• □ 验收机制：谁验收？按什么标准？不通过怎么办？（打回/换 Agent/转人工，三选一必须有）
• □ 熔断配置：单任务超时多久？重试几次？全局熔断线在哪？（没设=默认"无限跑"，这是最危险的配置）
• □ 预算上限：单任务 token 预算多少？超了谁决策？（没预算的多 Agent，等于没刹车的车）
• □ 人工介入点：哪些操作必须人工确认？（删/发版/对外通信，三类至少覆盖）确认的人是谁？他休假了怎么办？（别笑，真出过事）
• □ 回滚方案：中间结果版本化了吗？出问题能回滚到第 N 步吗？（不能回滚的多 Agent，debug 成本是单 Agent 的 10 倍）

7 个勾全打上，你的多 Agent 系统才算"生产就绪"。很多团队上了 3 个就敢跑——然后在第 4 个上翻车。记住：多 Agent 的复杂度是乘法，不是加法。5 个 Agent 不是"5 倍的单 Agent"，是"5 个 Agent × 它们之间的交互"，后者才是 complexity 的大头。

一句话总结

多 Agent 不是"多个单 Agent"，而是一个分布式系统——而分布式系统的课，计算机行业上了 40 年：一致性、契约、超时、熔断、回滚，每一条都是血换来的。2026 年大家忙着把 Agent 拆成十个并行跑，却忘了先把这 40 年的作业抄一遍。我的建议是：上多 Agent 之前，先问自己三个问题——真相源在哪？契约写清楚了吗？熔断设了吗？三个都答得上来，再谈并行。否则你得到的不是 10 倍效率，是 10 倍的 debug 地狱。