第 18 章：多 Agent 一旦落地，真正难的是编排而不是数量
本章目标：讲清多 Agent 系统一旦真的上线，难点不在“有几个 Agent”，而在“主 Agent、子 Agent、Hook、工具扩展和外部能力之间到底怎么串起来”。
本章对应总纲：docs/ebook-outline.md中“第 18 章正文写作提纲（2026-03-31 归档）”。
18.1 为什么多 Agent 一落地，问题就从“值不值得上”变成“怎么编排”
前面已经讲过，多 Agent 不是默认更高级，而是有明确收益条件的一种系统拆分方式。
第 10 章讲的是什么时候值得上多 Agent；这一章只讲一旦上了以后，系统该怎么编排。
这里也先把边界卡死：这一章讲的是任务运行时编排，也就是主 Agent、子 Agent、Hook、工具和外部能力在一次真实任务里如何被组织起来；不是第 16 章那种“扩展如何被发现、接入和治理”的平台级编排。
但只要你真的决定上多 Agent，问题马上就变了。
这时最关键的已经不是：
- 要不要拆
- 拆几个
- 名字起得帅不帅
而是：
谁发任务，谁收结果，谁裁决冲突，谁决定下一步。
这就是编排问题。
如果这层没设计清楚，多 Agent 很快就会退化成：
- 一堆并列调用
- 一堆局部结论
- 一堆没人收口的文字
所以多 Agent 一旦进入真实系统，难点通常就不再是“并行”，而是“编排”。
18.2 编排真正解决的，通常是四类问题
18.2.1 任务分发
谁该干什么，必须有人决定。
不是所有任务都该广播给所有 Agent，也不是所有 Agent 都该自己抢活。
如果分发逻辑不清，系统很快就会出现：
- 重复劳动
- 角色越权
- 不该拿到上下文的 Agent 拿到了太多信息
18.2.2 结果汇总
多个 Agent 各自产出局部结果，这不等于系统已经有了答案。
还必须有人负责：
- 去重
- 识别冲突
- 判断证据强弱
- 合并成下一步可执行结论
18.2.3 状态推进
多 Agent 不是做完就算了，还要知道当前整体任务走到哪。
例如：
- 还在探索阶段
- 已经定位问题
- 正在实施修复
- 正在验证
- 正在等待授权
如果没有统一状态推进层，子 Agent 只会各自忙碌，但系统整体不会真正收敛。
18.2.4 边界控制
不同 Agent 拿什么上下文、拥有什么工具、能不能写、能不能联网，这些都不能靠运气。
编排层必须把这些边界显式管起来。
18.3 主 Agent 为什么几乎总会存在
很多人喜欢幻想一种完全平权自治的多 Agent 乌托邦：
- 大家自由讨论
- 大家彼此协商
- 自然得出结论
听着很美，工程上通常很烂。
因为只要任务存在目标、优先级、冲突裁决和结果收口，系统几乎总需要一个主导层。
这个主导层通常就是主 Agent，或者说 orchestrator。
它的职责通常包括：
- 理解用户目标
- 判断是否需要拆分
- 选择要调哪些子 Agent
- 给每个子 Agent 分配边界
- 汇总子结果
- 决定整体下一步
所以主 Agent 的本质不是“最聪明的那个”，而是：
负责保持全局收敛的那个。
18.4 子 Agent 真正该被怎样看待
子 Agent 不是迷你主系统，也不是会动的 prompt 贴纸。
更准确的理解是：
- 它是受限执行单元
- 它拿的是局部目标
- 它拿的是受控上下文
- 它输出的是局部证据、局部结论或局部动作结果
所以一个健康的子 Agent，通常不该：
- 自己重新定义全局目标
- 自己决定整个系统策略
- 自己持有不必要的高权限
- 自己直接收口最终答案
子 Agent 的价值，是局部推进，不是替代编排层。
18.5 多 Agent 编排最容易烂掉的几个地方
18.5.1 所有人都在做总体判断
如果每个 Agent 都被要求“看看整体怎么解决”，那不是分工，是复制噪音。
18.5.2 没有统一汇总人
多个 Agent 都产出观点，但没人负责收束，系统最后只会把所有结果原样摊给用户。
18.5.3 上下文发放失控
为了“保险”，把所有背景都发给所有子 Agent，结果上下文负担没减，保密边界也没了。
18.5.4 子 Agent 权限过宽
本来只是搜证据的子 Agent 却有写权限，本来只是审查的子 Agent 却能直接执行高风险动作。
18.5.5 编排层不保留失败信息
如果某个子 Agent 试过的失败路径没有被吸收进全局状态，后面其他 Agent 很可能还会重走一遍。
这类系统会非常吵，而且越来越吵。
18.6 Hook 和工具扩展为什么也会进入编排问题
很多人以为编排只发生在主 Agent 和子 Agent 之间。
其实一旦系统有 Hook、工具扩展、MCP 接入，这些东西都会进入编排世界。
因为现实里的执行链可能更像这样：
- 主 Agent 决定发任务
- 子 Agent 开始执行
- 某个工具调用前被 Hook 拦截
- 某个外部能力通过 MCP 暴露出来
- 工具结果再回流给子 Agent
- 子 Agent 结果再回流给主 Agent
- 主 Agent 再决定继续、停机还是请人确认
这说明编排不是“Agent 和 Agent 对话”这么窄，而是：
整个运行时里，各类执行单元、生命周期挂点和外部能力怎样被组织成一条可收敛的链。
18.7 串行编排和并行编排，到底差在哪
串行编排更适合
- 明确依赖链
- 前一步结果决定后一步输入
- 需要逐层收敛
优点是路径清楚，坏处是慢，而且前一步带偏了会层层传染。
并行编排更适合
- 多线索搜索
- 多角度审查
- 大空间证据收集
优点是扩面快，坏处是汇总难，冲突和重复都更常见。
所以编排层真正要回答的不是“并行是不是更先进”，而是：
当前阶段更需要扩面，还是更需要收敛？
这和前面讲规划时“何时前进、何时验证、何时回退”其实是一脉相承的。
18.8 用 Claude Code 看一个现实中的编排样本
Claude Code 很适合看这个问题，因为它的子 Agent 并不是自由漂浮的。
从当前仓库里几个地方就能看见这种编排味道不是抽象词，而是现实结构：
.claude/commands/CLAUDE.md里对/dedupe的描述明确写了“预检查 → Issue 摘要 → 5 个并行 Agent 搜索 → 过滤假阳性 → 发布评论”，这就是典型的主导层分发、并行搜证、统一收束- 同一个命令文档还限制可用工具，说明编排不只是决定顺序，还要决定边界
examples/settings/settings-strict.json把ask、deny、allowManagedHooksOnly、sandbox这些约束显式写成配置，说明运行时编排并不是想怎么调度就怎么调度，它始终被权限和策略层卡住.github/workflows/deploy-docs.yml又展示了另一种更传统的编排：build先执行，成功后deploy才能继续，这不是多 Agent，但它说明“谁先做、谁依赖谁、失败后是否继续”本来就是运行时组织问题
你能明显看到几层结构：
- 主会话理解目标
- 在需要时决定是否发子任务
- 子 Agent 拿到特定边界和工具集
- 子结果回到主会话收束
- 风险动作仍然留在更高层处理
而且 Hook、工具、权限、工作树隔离这些机制，也都不是孤立存在的，它们都在共同塑造编排链路。
这说明现实里的多 Agent 编排从来不是“几个模型互聊”，而是围绕收敛、边界和治理构造运行时秩序。
18.9 什么时候你的多 Agent 系统其实只是伪编排
有几种味道，一看就知道不对。
第一种：只是并列调用
主系统把同一个问题发给多个 Agent，然后原样贴回结果。这不是编排，这是转发。
第二种：没有全局状态推进
每个 Agent 都完成了局部任务，但整体任务位置没人维护。
第三种：没有明确的结束条件
多个 Agent 一直互相传结果，但没人决定什么时候收口、什么时候停、什么时候问人。
第四种：权限和上下文跟着感觉走
子 Agent 看到什么、能做什么，全靠调用方随手塞。这种系统迟早失控。
18.10 好编排的标准，不是更热闹，而是更可收敛
最后把标准压缩成一句话：
一个好的多 Agent 编排系统，不是让更多执行单元同时动起来，而是让整个任务能在更多执行单元参与时仍然保持可收敛、可治理、可解释。
所以真正的标准不是：
- Agent 数量多不多
- 对话看起来像不像团队
- 输出字数多不多
而是：
- 全局目标有没有被守住
- 结果有没有被有效收束
- 边界有没有被稳定控制
- 错误和失败信息有没有被吸收
- 系统有没有越来越接近终点
18.11 本章小结
这一章真正想讲清的是：多 Agent 真正难的不是数量，而是编排。编排负责任务分发、结果汇总、状态推进和边界控制，让主 Agent、子 Agent、Hook、工具扩展和外部能力能够被组织成一条可收敛的执行链。
你现在应该记住六件事：
- 多 Agent 一旦落地，核心问题会从“值不值得上”转成“怎么编排”。
- 编排至少要解决任务分发、结果汇总、状态推进和边界控制。
- 主 Agent 的本质是保持全局收敛，而不是单纯“更聪明”。
- 子 Agent 应该是受限执行单元，而不是迷你主系统。
- Hook、工具扩展和外部能力同样会进入编排问题。
- 好编排的标准不是更热闹，而是更可收敛。
下一章我们把全书收束到工程现实：部署、测试、评估、观测和长期维护。也就是一个 Agent 系统到底怎样才不只是能演示，而是真的能长期活着。