第 10 章：什么时候真的需要多 Agent
本章目标：把多 Agent 从“听起来更高级”的幻觉里拽出来，讲清它真正解决什么问题、什么时候值得上、什么时候只是徒增复杂度。
本章对应总纲：docs/ebook-outline.md中“第 10 章正文写作提纲（2026-03-31 归档）”。
10.1 为什么多 Agent 很容易被神化
只要一提 multi-agent，很多人脑子里立刻冒出这些词：
- 分工协作
- 团队智能
- 并行加速
- 自主自治
- 像公司一样运作
听着都很爽。
问题是，很多时候这只是包装词。
因为你先得回答一个更基础的问题：
为什么一个 Agent 做不完，非要拆成多个？
如果这个问题答不出来，那所谓多 Agent 往往只是：
- 把简单问题拆复杂
- 把单次判断变成多轮传话
- 把可控系统变成更难调试的系统
所以多 Agent 不是默认更高级，而是默认更贵、更慢、更难控。
10.2 多 Agent 真正解决的，通常只有三类问题
工程上，多 Agent 值得存在，通常是因为单个执行单元在这三类场景里开始吃力。
10.2.1 任务可以天然拆成相对独立的子问题
比如：
- 一个负责代码搜索
- 一个负责架构判断
- 一个负责实现
- 一个负责测试验证
这些子问题之间虽然有关联，但不必共享完整上下文，也不必由同一个执行单元一步步全扛。
10.2.2 搜索空间太大，单线程探索成本过高
例如：
- 大仓库里要并行找多个线索
- 需要同时验证多个候选原因
- 要在多个模块、多个文件群里快速收集证据
这时多 Agent 的价值在于并行探索，而不是“更像人类团队”。
10.2.3 不同子任务需要不同能力边界
比如：
- 一个子 Agent 只读，不许写
- 一个子 Agent 专门做计划，不许改代码
- 一个子 Agent 专门做审查，不直接执行
这时拆成多个 Agent 的价值，是把权限和职责切开。
10.3 哪些情况根本不值得上多 Agent
这一刀也得切得狠一点。
10.3.1 问题本来就很小
一个文件里的小修补、一次简单解释、一个很清楚的单步任务，本来一个 Agent 就能搞定。
你硬拆成多 Agent，只会让事情更啰嗦。
10.3.2 子任务之间高度耦合
如果每个子任务都必须频繁共享上下文、反复同步状态，那拆分以后往往得不偿失。
你以为是在并行，实际是在制造沟通税。
10.3.3 没有明确分工边界
如果你只是让多个 Agent 都去“看看这个问题怎么修”，那这不是协作，这是重复劳动。
10.3.4 结果没有可靠汇总机制
多个 Agent 各说各话，最后没人整合、没人去重、没人裁决优先级，那系统只会产出更多噪音。
所以多 Agent 的前提不是“有多个 Agent”，而是：
你已经知道为什么要拆、怎么拆、拆完如何汇总。
10.4 多 Agent 的本质，不是团队隐喻，而是任务分解
大家很喜欢把多 Agent 讲成“像一个团队”。
这个比喻可以帮助入门，但也很容易带偏。
因为从系统设计角度看，多 Agent 更准确的理解是：
把一个复杂任务拆成多个执行单元，每个单元只拿自己真正需要的信息和能力。
重点不是“像人”，重点是：
- 降低单个执行单元负担
- 限制上下文规模
- 限制工具权限
- 提高并行收集信息的效率
- 让不同阶段使用不同策略
这是一种工程拆分，不是人格秀场。
10.5 多 Agent 一旦出现，系统就立刻多出三种新成本
10.5.1 协调成本
谁先做，谁后做，谁依赖谁，谁来汇总，谁来裁决冲突——这些问题在单 Agent 里几乎不存在，一拆分就全冒出来了。
10.5.2 上下文传递成本
子 Agent 不可能天然共享一切。
所以系统必须决定：
- 传哪些上下文
- 不传哪些上下文
- 结果怎么压缩回主会话
- 失败信息怎么回流
这本质上是在重做一遍信息治理。
10.5.3 一致性成本
不同 Agent 如果各自做出局部判断，最后很可能出现：
- 结论冲突
- 重复发现
- 优先级不一致
- 建议互相打架
所以只要一上多 Agent，最后就必须有一个整合层。没有整合层，多 Agent 通常只是噪音放大器。
10.6 一个好的多 Agent 系统，至少要把四件事设计清楚
10.6.1 分工
每个 Agent 负责什么，不负责什么，必须清楚。
最烂的设计就是职责重叠：
- 两个 Agent 都在搜代码
- 三个 Agent 都在做总体判断
- 没人真正负责收束结果
10.6.2 输入边界
每个 Agent 看到哪些信息，必须受控。
否则你要么给太少，Agent 瞎猜；要么给太多，又把单 Agent 的上下文问题原样复制了一遍。
10.6.3 工具边界
不同 Agent 应该拥有和自己任务相称的工具能力。
例如：
- 搜索 Agent 只给 Read / Grep / Glob
- 计划 Agent 不给写权限
- 审查 Agent 不直接改代码
- 实现 Agent 才允许编辑和验证
10.6.4 汇总机制
最后谁负责：
- 合并结果
- 去重
- 识别冲突
- 决定下一步动作
这件事一定得有人做，而且不能模糊。
10.7 并行和串行，不是一个味道
多 Agent 至少有两种常见组织方式。
10.7.1 并行型
适合：
- 独立搜索
- 独立审查
- 多角度收集证据
优点：
- 快
- 能扩大探索面
缺点：
- 汇总压力大
- 容易重复和冲突
10.7.2 串行型
适合：
- 前一步结论决定后一步输入
- 明确存在依赖链
- 需要逐层收敛
优点：
- 路径清楚
- 上下文衔接稳定
缺点：
- 慢
- 前面判断错了会连锁带偏
所以真正要问的不是“用多 Agent 吗”，而是：
当前任务更适合并行扩面，还是串行收敛？
10.8 主 Agent 和子 Agent 的关系，本质上是编排关系
在大多数现实系统里，多 Agent 并不是完全平权自治的乌托邦。
更常见的结构是：
- 一个主 Agent 负责理解目标、决定是否拆分、汇总结果
- 若干子 Agent 负责执行局部任务
也就是说，主 Agent 干的是 orchestration，不是亲自做完所有子任务。
这层关系为什么重要？因为它决定了谁来：
- 发任务
- 控边界
- 收结果
- 做最后判断
如果没有一个明确的编排者，多 Agent 很容易退化成一堆并列调用而已。
10.9 用 Claude Code 看一个现实中的多 Agent 样本
Claude Code 这种环境非常适合拿来理解“多 Agent 什么时候值得”。
这里也先把边界卡死：第 8 章讲的规划，主要解决单执行链里的路径组织；这一章开始讲的编排，解决的是多个执行单元之间的分发、边界控制、结果汇总和最后收敛。
从当前仓库就能看到，多 Agent 不是装饰，而是在明确场景下才上：
plugins/README.md里code-review明确写了 5 个并行 Sonnet Agent 做不同审查维度，说明当搜索面和审查维度都变大时，并行拆分是有现实收益的- 同一个文件里
feature-dev拆出code-explorer、code-architect、code-reviewer，说明多 Agent 的价值常常不是“更像团队”，而是把探索、设计、质量检查这几类任务切开 pr-review-toolkit又把 comments、tests、error handling、type design、simplification 拆成不同审查 Agent，说明当子任务天然可分时，拆分比让一个执行单元硬扛更清楚- 但仓库并没有把一切都做成多 Agent：大量能力仍然是单命令、单 Hook、单配置样板，这反而说明它没有把“多 Agent”当默认答案
它并不是默认逢事就拆，而是在一些明确场景下才会上子 Agent，例如：
- 广域代码探索
- 架构规划
- 独立审查
- 背景研究
- 分块验证
而且这些子 Agent 往往还会被明确限制：
- 读还是写
- 快速扫还是深度查
- 只研究还是允许实施
- 是否需要隔离环境
这说明现实里的多 Agent 不是“越多越智能”，而是在明确分工、明确边界、明确汇总责任下，用多个执行单元降低复杂任务成本。
10.10 什么时候你该警惕“伪多 Agent”
有几种味道，一闻就知道不太对。
第一种：名字很多，职责没有
系统里叫了一堆 reviewer、planner、expert、architect，但实际干的事都差不多。
第二种：拆了很多，结果没人收口
每个子 Agent 都输出一堆文字，最后主系统只是原样贴回来。
第三种：只是把 prompt 拆开，不是真正的执行分工
如果拆分后既没有权限边界差异，也没有上下文差异，也没有任务差异，那多半只是形式复杂化。
第四种：为了显得高级而上多 Agent
这是最差的动机。
系统设计不是看起来像公司组织图，而是看有没有减少真实复杂度。
10.11 本章小结
这一章真正想讲清的是：多 Agent 不是高级皮肤，而是一种有明显收益条件、也有明显额外成本的系统拆分方式。
你现在应该记住六件事：
- 多 Agent 只在单 Agent 开始吃力时才真正有意义。
- 它真正解决的是任务分解、并行探索和能力边界切分问题。
- 多 Agent 一旦引入，协调、上下文传递和一致性成本也会立刻上升。
- 好的多 Agent 设计必须明确分工、输入边界、工具边界和汇总机制。
- 主 Agent 和子 Agent 的关系，本质上是编排关系。
- “看起来像团队”不重要，能不能减少真实复杂度才重要。
下一章我们继续往下走，讲一个现实系统为什么不能永远活在自己的本地小世界里：它怎么接外部能力，为什么协议层会重要，以及 MCP 这种东西到底解决了什么麻烦。