多 Agent 什么时候才值得

多 Agent 是成本不是默认；只有六项准入条件至少满足一项才考虑，而且拆分必须以差异化工程责任为判据。

多 Agent 是成本，不是默认值。每多一个 Agent，就多一份 token 开销、多一条延迟路径、多一个失败面，还多一层"谁对这件事负责"的模糊。只有六项准入条件至少满足一项时才值得付这个成本，而且拆分必须以差异化的工程责任为判据——不是因为角色听起来更专业。

六项准入，至少满足一项

• 子任务可明显并行；
• 上下文应当隔离；
• 工具或权限必须隔离；
• 由独立团队或服务部署；
• 单 Agent 上下文无法承载；
• 专业评审需要独立视角，且有可测收益。

注意最后一条的限定词"有可测收益"。为了看起来更严谨而加一个评审 Agent，是纯开销。另外要分清：多个 Tool 不等于多 Agent。同一个 Agent 挂十个工具，仍然是单一上下文、单一责任主体；你要的如果是隔离，加工具解决不了。

第一判断标准：有没有新信息进来

准入条件之外，书里把多 Agent 的价值收敛成一条判据：协作过程是否引入了单个 Agent 在生成时拿不到的新信息 ai-agent-book。

这张表顺带解释了学术与工程的分歧。学术设置多是"几个 Agent 看着同一段上下文互相讨论"，它不引入新信息；真正有效的工程系统几乎都带一条外部反馈环路——执行、渲染、工具验证。RLEF 那条线是同一件事的训练版本：让模型反复利用代码执行反馈迭代改进，效果远超独立多次采样再挑最好，因为每次迭代注入的是写代码那一刻并不存在的信号（编译错误、测试失败、运行时异常） ai-agent-book。

拿它对照自己加的那个 reviewer：它看到了 generator 看不到的东西吗？如果它手上只有同一份上下文，你买到的就是复述。

先算清你买到了什么

决定之前先算三笔账：额外 token（每个 Agent 都要重复加载共享上下文）、额外延迟（并行不等于同步返回，最慢的那个决定墙钟时间）、额外失败面（N 个 Agent 各自有超时、跑偏和工具故障）。

同时必须定义四件事，缺一条多 Agent 就会退化成多人同时改一个文件：谁是协调者、每个产出归谁所有、共享状态怎么读写、冲突怎么处理。

拆分判据：差异化的工程责任

多个 Agent 用相似上下文做相似判断，最后相互复述结论，是纯成本。拆分只在两种条件下有价值：角色对应稳定的工程责任（规划、实现、验收各自有长期归属），且不同角色对"完成"的判断标准不同——Planner 看任务是否可验证，Worker 看测试是否通过，Evaluator 看需求是否被满足。为角色拆分本身创建多个 Agent，是最常见的浪费。

Cognition 团队得出过同向结论：他们最初让多个独立 agent 各拿一份不完整的上下文并行干活，结果决策彼此冲突、拼不出一个连贯整体；给出的原则是共享完整上下文、由单一责任主体承接一个连续任务流 cognition-no-multi。换言之，先证明「一个 Agent 装不下」，再考虑拆。

三个真实的失败方式

Cursor 最初让 20 个 agent 扁平对等、通过共享文件自行协调，用锁防止抢占同一任务。结果是持锁太久或忘记释放，锁成了瓶颈，有效吞吐降到 2 到 3 个；更麻烦的是没有层级时 agent 变得过度规避风险，专挑小而安全的改动，没人承担难题，长时间空转没有实质进展。最后改成 Planner / Worker 流水线才跑起来 cursor-scaling-agents。

Anthropic 用 16 个 agent 编译 Linux 内核时踩到另一类问题：内核是一个巨型任务，每个 agent 撞同一个 bug、修完又互相覆盖，16 个 agent 没起作用。他们最后用 GCC 作"已知正确的 oracle"——随机用 GCC 编译大部分内核文件，只把剩余文件交给 Claude 的编译器；内核能跑说明问题不在 Claude 的子集，崩了就二分细化。独立测试可以天然并行，单体大任务不行 anthropic-c-compiler。

还有一类成本是隐蔽的。同一批 1266 道 BrowseComp 题，单 agent 配置的意外解率是 0.24%，多 agent 配置是 0.87%，高出 3.7 倍。多 agent 不改变模型倾向，但更高的 token 用量加上每轮多个并行搜索者，提高了"至少一个 agent 撞到泄漏材料或开始怀疑自己在被测"的概率——多 Agent 会放大你评估体系里已有的问题 anthropic-eval-awareness。

子 Agent 的运行时契约

准入成立后，运行时要立六条规矩，否则后台子 Agent 会退化成黑盒。Google Antigravity 团队就遇到过：父编排者进入休眠直到全部子 Agent 跑完整个轨迹，开发者对进度零可见性；子 Agent 之间无终止条件的互回消息还会烧掉大量 token googleai-subagent。

• 按任务收窄能力开关（写入、MCP、再派发子 Agent 分级授权），不默认全量。
• 反应式唤醒替代轮询：子 Agent 的消息直接投递进父会话上下文并触发唤醒，编排者不为等进度烧 token。
• 上报用结构化载荷（JSON，或 PROGRESS / ERROR / ABORT 前缀），禁止自由文本，只在里程碑边界上报。
• 显式 COMPLETE / TERMINATE 终止条件，防止无界乒乓对话。
• 父会话 ID 注入子 Agent 的初始任务，子 Agent 不得猜测消息接收者。
• 两级断路：软中止（广播 abort）与硬终止（强制 kill），单点致命失败时立即止损。

协调者怎么用

协调者负责任务分解、专家选择、状态与预算与权限、Gate、恢复和汇总；专家负责单一领域产出、自包含输入输出、独立工作区、领域级测试。

两条硬约束。协调者不能重复专家的核心工作，否则你付了两份钱买一份判断；专家的 Tool、数据和写入范围必须受限，防止多个 Agent 无约束修改同一业务对象。优先用 Manager-as-tools——把专家当作主 Agent 可调用的工具，比让协调者自己编排一整套消息协议更简单，也更容易调试。

写入范围受限还不够，因为文件层干净不等于逻辑一致。书里的例子很典型：Agent A 重新编排全书的图片编号，Agent B 同时在改某一章并引用原始编号的图片——两者改的是不同文件，文件层面看不出任何冲突，而 B 引用的编号在 A 重排之后全部失效 ai-agent-book。乐观锁能挡住同一个文件的写入冲突（读取时记下版本号，写入时比对，不一致就写失败、重读、重做），挡不住跨文件的语义冲突，后者要更高层的语义校验机制。主流做法因此是工作副本隔离：一个 Agent 一条分支或一个 worktree，并行修改互不干扰，把冲突集中推迟到最后的合并点处理。

三个问题自检：你拆出来的两个 Agent，判断"完成"的标准一样吗？共享上下文被重复加载了几次？把其中一个砍掉，质量实际会掉多少？