多 Agent 是今天最容易被浪漫化的一部分。
只要看到多个角色、多个节点、多轮对话、互相协作，人们就会很自然地觉得这是一种更高级的系统，好像 Agent 只要从一个变成多个，能力就会自动上升。但从研究和工程实践看，这种直觉往往是错的。多 Agent 从来不是天然更强，它只是把系统从“一个会做事的智能体”变成“一个需要协调的组织”。
而组织一旦出现，问题就变了。
单 Agent 的核心问题，是模型、工具、状态和循环如何闭环；多 Agent 的核心问题，则变成任务如何拆、角色如何分、上下文如何交、谁来汇总、谁来最终负责、以及为了这种拆分到底付出了多少额外成本。换句话说，多 Agent 的本质不是“更多智能”，而是“更多协调”。
因此，本章第一条结论应该是：
多 Agent 的收益来自结构化分工，而不是来自数量本身。只要没有真正的结构化分工，增加 agent 数量通常不会增加能力，只会增加噪声。因为每多一个 agent，系统就会多出新的沟通、交接、路由、同步、评估和责任问题。一个本来可以在单线程里解决的问题，一旦被拆成多个角色，往往会出现六种典型代价：
- 重复思考
- 重复调用工具
- 上下文被切碎
- 状态交叉污染
- 责任边界变模糊
- 延迟与成本同时上升
所以，判断一个系统是否该上多 Agent，不能从“看起来很复杂”出发，而要从“是否存在真实可拆的角色差异”出发。
这里至少有三个判断标准。
第一，任务真的可以拆。
如果任务本质上是一个紧耦合的连续决策过程，每一步都强依赖上一轮隐含判断，把它强行拆给多个 Agent，往往只会让高价值上下文在交接中流失。很多任务表面上步骤很多，实际上并不适合多 Agent，因为它需要的是同一个主体持续维护全局语境，而不是把语境分发给多个局部角色。
第二，角色边界真的清楚。
多 Agent 只有在不同子任务需要不同上下文、不同工具面、不同权限或不同指令风格时才有意义。如果每个 Agent 都“什么都懂一点”，最后形成的不会是分工，而是角色重叠。角色一旦重叠，系统既拿不到并行收益，也得不到上下文隔离收益，反而还要承担额外的协调成本。
第三，交接逻辑真的稳定。
一个 Agent 把任务交给另一个 Agent，从来不只是发一句话。它意味着当前状态、目标、约束、已完成步骤、不能再做的事情、剩余预算、权限边界和失败历史，都可能要被显式传递。只要这一步没有被设计清楚，多 Agent 就会迅速退化成“电话游戏”：上游知道的事，下游只知道一部分；下游再继续传递时，又丢掉一层。
这也是为什么官方框架越来越强调 handoff 不是免费操作，而是带上下文裁剪、状态筛选和路由决策的显式协议。多 Agent 系统里，真正稀缺的不是“能不能再加一个 Agent”，而是“能不能在交接时不把信息和责任一起交乱”。
于是，本章真正要反对的，不是多 Agent 本身，而是“把复杂任务默认等同于需要更多 Agent”这种冲动。
研究和工程都在反复说明：很多任务其实并不需要多 Agent，而是需要更好的单 Agent 结构。例如更清晰的工具面、更好的状态管理、更稳的循环控制、更强的上下文压缩。只有当单 Agent 已经被以下问题卡住时，多 Agent 才开始显示价值：
- 单一上下文窗口承载不了所有角色信息
- 不同子任务需要完全不同的工具和权限
- 子任务彼此独立，能真正并行
- 需要把不同职责隔离到不同主体中
- 需要让用户在不同阶段直接与不同专家交互
这几个条件如果不成立，多 Agent 通常只是把问题换了个地方出现。
从工程角度看，多 Agent 最常见的两个收益，其实都非常现实，而不浪漫。
第一个收益，是上下文隔离。
当一个总控 Agent 需要处理极大的工具面、很长的历史和多类不同子任务时，让子 Agent 在自己的小上下文里各自完成局部任务，确实会更稳。很多 subagent 设计真正解决的不是“智能增强”，而是“避免主上下文被全部细节淹没”。但这也意味着另一个事实：多 Agent 的收益里很大一部分，其实来自“少让每个 Agent 看太多”，而不是“多让很多 Agent 一起想”。
第二个收益，是可并行的独立任务。
如果多个子任务在逻辑上真能独立，例如从多个系统并行抓取资料、对不同方案并行评估、对多个候选输出并行校验，那么 fan-out/fan-in 结构确实能减少 wall-clock 时间。但并行并不是白赚的。每一个并发分支都要占用模型调用、工具资源、状态管理和结果合流能力。一旦任务之间并不独立，或者最后汇总非常复杂，多 Agent 并行很可能只是把延迟从串行等待变成了合流等待。
所以，多 Agent 的“并行收益”有一个隐含前提：分支之间必须足够独立，合流点必须足够清楚。
这一点特别重要。因为很多团队会高估并行带来的收益，低估合流带来的成本。表面上看，四个 Agent 同时工作似乎更快；实际上，如果最终还要一个 manager 重新理解四份冗长输出、检查它们是否矛盾、补齐遗漏上下文、再做统一决策，那么总成本未必更低，甚至可能更高。
这就引出多 Agent 的第三个难点：责任扩散。
单 Agent 系统出问题时，虽然也很复杂，但至少能明确知道“这套系统的决策中心在哪里”。多 Agent 一旦引入 manager、worker、handoff、debate、subagent、router 等结构，责任就很容易在组织中扩散：是上游路由错了，还是下游 specialist 判错了；是交接信息不完整，还是汇总器丢掉了关键约束；是某个子 Agent 越权了，还是 coordinator 没有限权。Agent 一多，失败就不再是“结果错了”，而是“组织怎么一起把结果做错了”。
这也是为什么多 Agent 系统比单 Agent 更依赖 tracing、thread continuity、handoff logging 和 escalation path。没有这些机制，系统会迅速变成一个谁都做了一点、但没有人能说清最终为什么错了的分布式黑箱。
更麻烦的是，安全风险也会被多 Agent 放大。
单个 Agent 可能在本地看来是安全的，但多个 Agent 组合起来之后，危险任务可以被拆成若干个局部看起来无害的子步骤，再通过一连串 handoff 完成整体目标。局部 guardrail 可能在某一段起作用，却在 handoff 时失效；一个子 Agent 看不到全局意图，就可能配合完成本不该执行的链条。这说明，多 Agent 安全不能只看每个点上是否安全，还要看整条协作路径是否整体安全。
因此，真正成熟的多 Agent 设计，不是“增加角色”，而是“增加组织约束”。
这些约束至少包括：
- 谁可以创建或调用下游 Agent
- 哪些上下文可以被转交
- 哪些工具权限不能跟着交接一起传播
- 哪些决策必须回到中心 Agent 或人类审批
- 哪些结果必须在合流点重新验证
- 哪些 trace 和责任记录必须被保留
如果这些组织约束不存在，多 Agent 就不是组织化协作，而只是把单 Agent 的不稳定性放大成系统级不稳定性。
从这一点看，多 Agent 更像组织设计问题，而不是模型设计问题。
一个设计得好的多 Agent 系统，往往有非常克制的结构：少数真正必要的角色、清晰的路由原则、可审查的 handoff、严格的上下文裁剪、明确的最终汇总点，以及在复杂度上与任务规模相匹配的最小组织形态。它追求的是“刚好够用的分工”，不是“角色越多越显得聪明”。
所以，成熟的判断不是“能不能上多 Agent”，而是：
这个系统是否已经出现了明确的、可被结构化拆分的角色差异。如果没有，先把单 Agent 做强，通常更稳；如果有，再让多 Agent 去解决单 Agent 真的解决不了的那部分问题，例如上下文隔离、权限隔离、可并行子任务和明确的职责边界。只有在这种条件下，多 Agent 才是能力增益；否则，它更像复杂度增益。