多 Agent 什么时候才值得

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

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

六项准入，至少满足一项

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

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

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

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

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

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

协调到什么程度算够：一次实测

Anthropic 的 Frontier Red Team 做过一组对照：让 45 个 agent 各拿一台虚拟机和一个共享论坛，去找 15 个开源项目里的漏洞并互相评审，另配一个仲裁 agent 定夺；对照组是让独立 agent 各自扫不同的代码区域。结果是协调 swarm 花 2700 万 token 找到 266 个漏洞，独立并行花 650 万找到 21 个 anthropic-multiagent-systems。

但这个数字不能读成「协调必胜」。当把协调组限定在与对照组相同的核心目录后，两种方法的单位 token 效率相当；两组只有 12 个漏洞重叠——协调 swarm 会把注意力投向自己认为最好挖的地方，还自己造工具、自发分工。结论是协调与蛮力互补：先用便宜的无协调并行扫确定性范围，再把 agent 放到没有人划定边界的地方。

同一组实验还测了提示词干预：告诉 agent 它们属于什么团队（核心编程、美术、测试），或者指定一个「CEO」层层派活，对最终结果几乎没有影响。协调质量是模型代际的属性——早期模型靠冲突后放弃，中间代际「解决」冲突的方式是各占文件不共享，只有最新代际做到高共享与高吞吐兼得。把协调能力寄望于提示词工程，等于把系统质量押在模型能力上赌。

先算清你买到了什么

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

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

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

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

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

还有一类和人类不同的失效方式：上下文、脚手架、模型相同或相似的 agent 是低方差的——动作空间再大，它们也倾向做同样的选择。一个 agent 判错，很可能所有 agent 一起判错，孤例问题直接变系统性失败。所以「多派几个 agent 互相审查」并不构成交叉验证：要么换上下文起点，要么换模型，要么拿外部证据兜底 anthropic-multiagent-systems。

什么时候把子 Agent 折回主循环

拆分的反面同样成立：已经拆出去的子 Agent，不一定该一直存在。Anthropic 在多个企业部署里看到同一个模式——每个团队、每类问题各配一个子 Agent，架构慢慢变成组织图的复制品；结局是一批互相重叠的子 Agent、被各团队的句子拼起来的系统提示，以及各自为政、只对子任务优化的评测。对比下来，配齐渐进披露的单一 Agent 在质量上胜过子 Agent 架构，有客户的单循环运行快了约一倍；工具定义超过三五十个之后，选择质量也会开始下降 anthropic-subagent-folding。

保留子 Agent 的条件只有三个：单循环因为上下文膨胀出现可测量的性能下降；多个任务确实需要可以随手丢弃的新上下文并行；单个 Agent 选不准工具，或系统提示里已经出现互相冲突的规则。三条都不满足，就把它折回去——提示词改成 Skill，接口调用改成工具，一次折一个，用端到端评测对比折前折后。对比时不能只看总分，要看哪些任务翻转了：有团队折叠一个子 Agent 之后延迟降了，但一个原本通过的流程坏了——主 Agent 拿着订单查询工具自己作答，不再问发货专家 anthropic-subagent-folding。

三个真实的失败方式

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，判断"完成"的标准一样吗？共享上下文被重复加载了几次？把其中一个砍掉，质量实际会掉多少？

三种已经跑通的协作形态

角色分离：Planner 把任务拆成可验证的子任务，Generator 每次实现一个，Evaluator 独立跑测试、对照需求验收。两条纪律：Evaluator 不能只重复 Generator 的判断（否则你付两份钱买同一份乐观）；主观标准先转成可检查的清单再交给它。这套开销只配得上复杂且价值足够高的任务。

扇出采集 + 对抗审查：Claude Code 团队把 code review 做成了这个模式 claude-code-team——先广泛撒网找候选问题（扇出产生人消费不了的信息量），再用多视角的对抗性审查逐个评估、过滤误报，最后由确定性 for-loop 保证同一套检查应用到每一项——「对 workflow 的信任来自确定性循环」。人只审过滤后真正值得注意的问题集。这个模式同样适用于性能排查、多方案研究：扇出的本质是花算力换覆盖面，但扇出去的信息量必须过滤回来，否则只是把噪音换了个产地。

看板当控制平面：编排系统不一定要建。OpenAI 内部的 Symphony 让每个 Linear open task 自动配一个 agent，崩溃自动重启；整个「编排系统」就是一份 spec 文档（含工具使用说明），由 agent 自己实现；再配一道 request_changes 门禁——分派新任务前必须先处理已有评审意见，防止 agent 堆积任务 openai-symphony。没有中央调度器，没有消息总线，部分团队的 landed PR 增了 500%。当你发现自己在给多 agent 写编排代码时，先看一眼手边的项目管理工具能不能直接当那个控制平面。