本阶段的核心命题 复杂任务如何拆解、委派、收敛——以及如何避免为了"多 Agent"而多 Agent。
本阶段的判别力比知识点重要：多 Agent 是这两年最容易被过度使用的架构，几乎所有"多 Agent 效果不好"的案例，都能追溯到"本来单 Agent 加好工具就够了"。
在讨论怎么做多 Agent 之前，先确认它是否必要：
三个都是"否"，才进入多 Agent 的讨论。
子 Agent 的第一价值是上下文隔离**，不是"模拟团队角色"** Anthropic 对子 Agent 价值的表述很直接：并行化 与 上下文管理——子 Agent 有自己独立的上下文窗口，只把相关信息回传给编排者，而不是整个上下文。这特别适合"要翻很多材料、但大部分没用"的任务。
"产品经理 Agent + 开发 Agent + 测试 Agent"这种按人类岗位切分的设计，如果不能对应到上下文隔离或并行加速这两个真实收益，通常只是把组织结构画成了架构图。
| 概念 | 是什么 | 何时需要 |
|---|---|---|
| Task Decomposition | 把大任务拆成子任务 | 任务步数多、跨领域 |
| Todo / Task List | 显式的待办清单，可勾选、可修订 | 长任务，需要用户看得见进度 |
| Task Graph / DAG | 带依赖关系的任务图 | 有并行机会、有明确依赖 |
| 动态重规划 | 执行中发现计划不对，改计划 | 环境不确定 |
把计划变成显式的、可见的、可修改的清单，带来三个收益：
本仓已有 Claude Code：从 Todos 到 Tasks 讲的就是这个演进：从"给模型看的清单"变成"系统可调度的任务"。
| 失败 | 现象 | 对策 |
|---|---|---|
| 过度规划 | 简单任务也列 8 步 | 按任务复杂度动态决定是否规划 |
| 计划僵化 | 第 2 步就发现方向不对，还照着走完 | 允许重规划，且重规划要留痕 |
| 计划与执行脱节 | 计划写得漂亮，执行完全没按它来 | 执行时把计划放在上下文末尾复述 |
| 不可验证的子任务 | "优化用户体验" | 每个子任务必须有可判定的完成条件 |
| 结构 | 形态 | 适用 | 主要风险 |
|---|---|---|---|
| Supervisor / 路由 | 一个上层 Agent 决定任务归谁 | 领域清晰、可分类 | 路由错误会放大 |
| Handoff（移交） | 控制权与会话状态整体交给另一个 Agent | 客服转专家这类场景 | 移交后原 Agent 不再接管，回不来 |
| Subagent（委派） | 主 Agent 派子任务，子 Agent 独立上下文，结果回传 | 信息筛选、并行调研 | 结果聚合与冲突处理 |
| Peer-to-peer / 协作图 | 多个 Agent 互相通信 | 少见，研究性质居多 | 不可观测、成本不可控 |
Handoff 与 Subagent 最容易被混用
- Handoff：像转接电话。转出去以后，原来那个人不再管这件事。OpenAI Agents SDK 把它做成了一等概念——handoff 本身就是一个工具，调用即移交并携带会话状态。
- Subagent：像派人去查资料。主 Agent 仍然掌控全局，子 Agent 只交回结果。
产品含义完全不同：Handoff 之后用户在和另一个角色对话（要有明确的交接感知）；Subagent 对用户通常是不可见的内部机制（但过程要可观察）。
Claude Code 的调度拆解提供了一个很有用的切分：
| 模式 | 子 Agent 起点 | 委派 Prompt 应包含什么 | 主要收益 |
|---|---|---|---|
| Fresh | 零上下文 | 完整目标、背景、输入、约束、验收与回传格式 | 隔离污染，适合独立研究和审查 |
| Fork | 继承父上下文 | 只写任务范围、具体动作和回传要求，避免重复背景 | 复用已有理解与缓存前缀 |
是否 Fork 的首要判据不是任务大小，而是：父会话已有上下文是否正是子任务需要的，以及子任务中间过程以后还需不需要回到主上下文。
三条委派纪律：
完整案例见 Claude Code：Fork 与 Fresh。
Context Firewall 是子 Agent 最核心的机制：子任务里产生的大量中间上下文（读了 30 个文件、试了 5 种方案、遇到 8 次报错）不回流到主 Agent，只回传结论。
设计要点：
| 要点 | 说明 |
|---|---|
| 回传什么 | 结论 + 依据 + 置信度 + 未完成项。不要回传原始过程 |
| 回传多长 | 要有上限。子 Agent 回传 5000 token 的"总结"，隔离就失效了 |
| 失败怎么回传 | "失败了"没有价值，要回传"试到哪一步、卡在什么、建议怎么办" |
| 过程去哪了 | 不进主上下文，但必须可观察——落到轨迹里供事后分析（阶段 10） |
隔离不等于丢弃 最常见的错误实现：子 Agent 的过程既不回传也不记录，出问题时完全是黑盒。隔离的是上下文，不是可观测性。
| 概念 | 说明 | 产品要定义 |
|---|---|---|
| 并行 | 无依赖的子任务同时跑 | 并发上限、成本上限 |
| 同步屏障（Barrier） | 等所有子任务都完成再进入下一步 | 什么时候真的需要等全部？ |
| 流水线（Pipeline） | 每个任务独立走完全部阶段，不互相等 | 默认应该是这个 |
| 结果聚合 | 把 N 份结果合成一份 | 冲突时怎么办 |
屏障是延迟浪费的主要来源 如果 5 个子任务里最慢的比最快的慢 3 倍，用屏障就等于浪费了快的那几个 2/3 的时间。只有当下一阶段真的需要"全部结果一起看"（去重、汇总、统计、早停判断）时，屏障才是必要的。
这一条不只是工程优化，它直接决定用户等待时长——是产品指标。
| 策略 | 适用 | 代价 |
|---|---|---|
| 多数表决 | 有客观答案 | 3 个都错时一致地错 |
| 加权（按 Agent 可信度） | 各 Agent 专长不同 | 权重要维护 |
| 交给判官 Agent | 复杂判断 | 多一层不确定性 |
| 升级人工 | 高风险动作 | 慢，但正确 |
长程任务里最有价值的三个"配角"：
| 角色 | 做什么 | 为什么有效 |
|---|---|---|
| Validator | 用确定性规则校验产物（格式、约束、业务规则） | 不依赖模型判断，最可靠 |
| Reviewer | 用独立上下文审查结论 | 没有被生成过程污染，能看出"自洽但错误" |
| Summarizer | 把长过程压成可交付的结论 | 隔离过程上下文（见第四节） |
Reviewer 必须有独立上下文和证据合同 让同一个 Agent 在同一段上下文里“再检查一遍”，等于让产生错误的机制去检查错误。换一个干净上下文，只给产物、判据和必要背景，审查才有意义。
更强的做法是对抗式审查：不问“这个对吗”，而要求“请找出问题；找不到才算通过”。同时规定 PASS 必须附原始证据、PARTIAL 只能用于环境阻塞，并让调用方随机复核若干证据。完整方法在阶段 10 展开，案例见 Claude Code：对抗式验证。
做法：让 Agent 对同一个任务反复执行多轮，每轮基于上一轮的产物继续推进，直到达到某个收敛条件。
适用：目标明确、有客观校验、单轮做不完的任务（大规模重构、批量修复、长文档生成）。
必须配的三件套：
没有收敛条件的重复执行是烧钱机器 "多跑几轮效果会更好"这个直觉在有校验信号时成立，在没有校验信号时不成立——没有信号的重复只是把同一个错误重写了 N 遍。
上多 Agent 之前，把这四项成本明确写进方案：
| 代价 | 表现 | 缓解 |
|---|---|---|
| 成本 | token 消耗是单 Agent 的数倍 | 并发上限、预算闸门、小模型做子任务 |
| 延迟 | 屏障 + 串行依赖 | 改流水线、减少屏障 |
| 错误放大 | 上游一个错误判断，下游全部基于它工作 | 每层加校验；关键节点人工确认 |
| 不可观测 | 出问题不知道是哪个 Agent 哪一步 | 统一 trace，子 Agent 过程必须落轨迹 |
一条产品评审用的硬问题 "这套多 Agent 方案，比单 Agent + 好工具，好在哪个可度量的指标上？"
如果答案是"结构更清晰""更像团队协作"，那就是没有收益。合格的答案形如："调研类任务上下文占用从 X 降到 Y，端到端时延从 A 降到 B，任务成功率从 M 升到 N"——而这需要阶段 10 的评测能力来支撑。
| 误区 | 纠正 |
|---|---|
| "多 Agent 更智能" | 它换来的是上下文隔离与并行，不是智力提升 |
| "按岗位拆分 Agent" | 拆分依据应是上下文隔离与并行机会 |
| "子 Agent 越多越好" | 每个都要评测、都要观测、都要成本 |
| "让它们自己商量" | 自由通信的多 Agent 成本与可观测性都失控 |
| "并行就快" | 屏障会吃掉大部分并行收益 |
| "反思/审查加上就更准" | 审查者必须有独立上下文和对抗立场 |
| "重复执行几轮效果更好" | 没有客观校验信号时不成立 |
| "隔离了就不用记录了" | 隔离的是上下文，可观测性一项都不能少 |
| "Fork Prompt 也要重写全部背景" | Fork 已继承父上下文，应只补任务范围和回传合同 |
| "可以让子 Agent 自己理解要做什么" | 主 Agent 先综合，再委派明确任务；不要委派理解 |
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| Building agents with the Claude Agent SDK | Anthropic，2025-09-29 | 子 Agent 的两个价值：并行化与上下文隔离 |
| Building Effective AI Agents（资源库版） | Anthropic | 单 Agent / 多 Agent / Workflow 的选型讨论 |
| Orchestration and handoffs | OpenAI Agents SDK 文档 | Handoff 作为一等概念的设计 |
| A Practical Guide to Building Agents | OpenAI | 单 Agent 优先、必要时再多 Agent 的论证 |
| LangChain Deep Agents 相关文档 | LangChain | 规划 + 子 Agent + 文件系统的组合形态 |
本仓已有资料：
建议按三种问题阅读 用 dsh 第 11 章比较 subagent / workflow / ralph，用 Codex 第 14 章看协作图与协议，用 Claude Code 第 12、13 章看 Fresh/Fork 上下文合同和验证问责。三组材料分别回答“怎么拆”“怎么协作”“怎么隔离并验证”。