Subagent 与多 Agent：任务拆分、通信与结果汇总

给一个 Agent 增加“再启动几个 Agent”的能力很容易。难的是判断哪些工作值得拆、每个子任务应该看到什么、结果用什么协议返回，以及主 Agent 怎样发现重复、冲突和遗漏。

多 Agent 常被描述成一群角色开会。真实系统里更有用的视角是并行计算与上下文隔离：把可以独立推进的分支放进不同 Context，让它们各自产生证据，再由一个明确的 Owner 合并。拆分失败时，系统只是用更多 Token 制造更多互相矛盾的中间结论。

这篇文章以一次跨服务 API 迁移为例，讨论 Subagent、Agent-as-Tool、Handoff 和 Agent Team 的边界。研究依据包括 Anthropic 公开的 Research 多 Agent 架构、OpenAI Agents SDK 的 handoff 语义，以及 Claude Code 等产品公开的 Subagent 机制。产品实现会更新，文章关注较稳定的任务图、权限和通信问题。

Subagent 从拆分、隔离执行到证据汇总的协作路径

一、先判断问题能不能并行

任务只有同时满足“分支相对独立”和“结果可以汇总”时，才适合并行 Subagent。

假设要把订单 API 从 v1 迁移到 v2。可以并行调查服务端调用者、Web 前端影响、移动端兼容和文档示例，因为四个分支读取的文件不同，输出都能归一成“调用位置、旧行为、新约束、风险、证据”。调查结束后，再由主 Agent 形成迁移计划。

实现阶段未必适合照样并行。后端接口尚未确定时，前端和客户端同时改代码会围绕不同假设工作。多个 Agent 修改同一个 Schema 或同一组公共文件，还会产生合并冲突。此时应先完成接口契约，再把互不重叠的实现分支并行化。

可以用四个问题判断：

子任务之间是否需要频繁读取彼此的最新结果？
子任务是否会修改同一资源？
每个子任务能否写出独立验收条件？
合并结果是否比重新执行更便宜？

前两项越强，多 Agent 越不划算；后两项越清楚，拆分越安全。

Anthropic 的 Research 系统使用 orchestrator-worker 模式，让 Lead Agent 创建并行研究分支。官方文章也明确给出限制：多 Agent 更适合广度优先、可并行、信息超过单个 Context 的高价值任务；共享上下文多、依赖关系强的领域并不适合。其内部研究评测中的 90.2% 提升和约 15 倍聊天 Token 消耗，只能说明那套研究任务与配置下的取舍，不能外推为所有任务都应使用多 Agent。

判断并行性可以借用任务图。把子任务画成节点，数据、文件和决策依赖画成边。如果图大部分是宽层，多个节点只依赖同一个稳定输入，适合并行；如果图接近一条链，或每个节点都依赖上一步的开放结论，多 Agent 只会增加等待和同步。

还要区分“工具并行”和“推理并行”。同时读取十个独立文件，通常只需一个 Agent 并发调用工具；让十个 Agent 各读一个文件，会重复加载目标、规则和工具说明。只有分支需要各自规划、搜索多轮信息或维护局部 Context 时，独立 Agent 才有意义。先把能用普通并发完成的工作留给代码和工具层，再决定是否增加模型循环。

一个简单估算是比较关键路径。串行耗时近似各分支耗时之和；并行耗时接近最慢分支加协调与合并成本。如果最慢分支占了总工作量的八成，即使其他任务全部并行，收益也有限。协调器还会消耗额外模型调用，所以“可拆”不等于“值得拆”。

二、四种协作方式不要混用

“调用另一个 Agent”可能对应四种完全不同的控制权关系。

方式	谁保留控制权	子 Agent 得到什么	适合场景
Subagent	主 Agent	一个有边界的子任务与独立 Context	调查、验证、局部实现
Agent-as-Tool	调用方 Agent	像工具一样的输入，返回结构化结果	专项能力服务
Handoff	被转交的 Agent	会话或任务控制权	路由到专业处理者
Agent Team	团队协议决定	独立任务、邮箱或共享状态	多个长期自治成员

Subagent 通常有自己的模型循环、Context 和工具，但生命周期属于父任务。它完成后返回结果，主 Agent 继续决策。父任务可以限制它只能读文件、最多调用十次工具、不能再创建子 Agent。

Agent-as-Tool 更接近函数调用。调用方知道自己需要某项专业结果，例如“分析 SQL 执行计划”或“检查这份变更的安全风险”，工具内部是否用模型循环对调用方透明。控制权没有转移。

Handoff 会把后续对话交给另一个 Agent。OpenAI Agents SDK 的 Handoffs 文档把 handoff 暴露成模型可调用的工具，并允许定义输入 Schema 与过滤后的历史。客服分流适合这种模式：退款 Agent 接管用户会话后，原分流 Agent 不必逐轮中转。

Agent Team 再多一层。成员可能有独立会话、共享任务图、点对点消息和较长生命周期。只有任务确实需要成员互相协调时才值得引入。多数应用使用主 Agent 加有限 Subagent 已经足够。

四种方式也对应不同恢复单元。Agent-as-Tool 失败时，调用方把它当一次工具调用处理；Subagent 失败时，父任务可以重试该分支或接管；Handoff 失败会影响会话所有权，需要明确谁重新接待用户；Agent Team 则要恢复成员、任务图和消息状态。设计时若只看调用接口，不看所有权和恢复，后面很容易把一次 Handoff 当作普通函数重试，导致两个 Agent 同时回复用户。

系统里还常见一种“评审 Agent”。它不承担任务分支，而是在产物边界做检查，例如验证补丁是否越界、报告是否缺证据。评审是控制环节，不应和执行者共享同一目标描述后互相讨论。给它固定检查项、只读权限和独立证据，效果通常比增加一个泛化“批评者角色”更稳定。

三、任务拆分要写成契约

一句“调查前端影响”不是合格的委派。子 Agent 不知道搜索范围、需要多少证据、何时停止，也不知道主 Agent怎样使用结果。一个任务契约至少包含目标、范围、输入引用、允许工具、禁止动作、输出 Schema、预算和完成条件。

task_id: api-v2/web-impact
objective: 找出 Web 项目中所有订单 v1 API 调用并评估迁移影响
scope:
  include: [apps/web, packages/order-client]
  exclude: [apps/admin, generated]
tools: [search, read_file, run_readonly_command]
constraints:
  - 不修改文件
  - 每个结论必须给出文件和行号
output_schema:
  findings:
    - location: string
      current_behavior: string
      v2_impact: string
      evidence: string[]
  gaps: string[]
  confidence: high | medium | low
budget:
  max_tool_calls: 18
  deadline_seconds: 240

范围最好按信息源、组件或假设拆，而不是给不同 Agent 相同问题。三个 Agent 都“研究 API 迁移”只会重复搜索。可以让一个负责调用面，一个负责数据契约，一个负责发布兼容；三者的交集和空白都容易检查。

任务契约还要声明依赖。implement-web 依赖 approve-api-schema，调度器就不能为了追求并发提前启动。把依赖留给模型临时判断，会出现子 Agent 围绕过期假设工作。

从自然语言计划变成可执行任务图

协调者可以提出任务图，但运行时要校验它。每个节点包含输入版本、依赖、产物类型、读写资源、预算和 Owner。创建图时检查循环依赖、写集合重叠和没有消费者的产物。模型生成的“先 A 再 B”如果没有被转成依赖边，调度器无法保证顺序。

{
  "id": "implement-web",
  "depends_on": ["approve-schema", "publish-client"],
  "reads": ["brief@3", "openapi@a81f"],
  "writes": ["apps/web/**"],
  "acceptance": ["web-tests", "no-v1-endpoint"],
  "owner": "web-agent",
  "budget": {"tool_calls": 24, "tokens": 60000}
}

动态拆分仍然允许，但要作为图变更处理。Subagent 发现生成代码里还有一处调用，可以请求新增节点，并说明新证据、依赖和预算。根协调器批准后递增图版本。这样可以追溯为什么任务从四个分支变成六个，也能防止子 Agent 因局部困难无限派生后代。

任务图与计划文本承担不同职责。文本解释策略和风险，任务图约束可调度关系。把整个计划只存成 Markdown，界面看起来清楚，运行时却无法查询“哪些节点因为 schema 未批准而阻塞”；只存 DAG 又会丢掉为何这样拆的背景。两者应通过 plan revision 关联。

拆分粒度怎样控制

任务太大，Subagent 仍会 Context 膨胀，父 Agent 也无法判断它是否完整。任务太小，启动模型、传递背景和汇总结果的成本超过实际工作。

一个实用粒度是：子任务能在独立 Context 中完成，产物可以单独验收，并且结果明显小于其读取的信息。代码搜索读取几十个文件，返回十条有证据的调用点，压缩比很高；把一个两行配置修改交给 Subagent，通常没有收益。

设置最大深度与最大扇出。允许每个 Agent 无限递归委派，会让任务树指数增长。第一版可以只允许主 Agent 创建子任务，Subagent 不得继续派生。真的出现稳定的二级分工后，再开放一层，并把总预算绑定到根任务。

预算分配不能简单平均。未知程度高、搜索空间大的分支需要更多预算；格式化文档或运行固定测试只需很少。协调器可以先给每个分支小额度，收到有价值证据后再追加。已经连续两次返回相同发现的分支不应继续消耗根预算。

取消也沿任务图传播。根任务取消时，尚未开始的节点直接取消，运行节点收到停止信号，已完成产物保留供审计。某个上游节点失败时，只取消真正依赖它的后代，其他独立调查仍可完成并返回部分结果。把失败广播成全局终止，会浪费已经接近完成的有效分支。

四、Context 隔离既是收益也是风险

Subagent 往往通过额外 Context 产生收益。它可以读取大量局部材料，只把压缩后的证据返回主 Agent，避免中间噪声污染主窗口。

父 Agent 不应把完整对话复制给每个子任务。委派 Context 分三部分：稳定目标与约束、该分支需要的输入引用、输出契约。其余信息按需读取。这样既省 Token，也减少无关指令冲突。

隔离也会造成信息缺口。主 Agent 已经知道 v2 接口取消某字段，但没有把事实放进子任务，前端 Agent 可能仍按旧约束分析。维护一份版本化的任务 Brief，可以在不复制全部历史的情况下同步重要事实；Brief 更新后，把受影响的子任务标记为过期或重新验证。

权限应随子任务缩小。调查 Agent 只需要搜索与读取；测试 Agent 可以运行受限命令；负责提交的 Agent 也不该自动得到部署权限。OWASP 对 Excessive Agency 的建议包括减少可用扩展、缩小扩展功能和权限，并为高影响动作保留独立批准。多 Agent 系统还要防止权限经委派扩散。

共享 Brief 不是共享聊天记录

共享 Brief 保存会影响多个分支的稳定事实，例如目标、术语、接口决议、禁止修改范围和已经确认的风险。每条事实带来源与 revision。成员读取某个 revision 开始工作，提交产物时注明基于哪个版本。

Brief 更新不代表所有任务都要重跑。运行时根据事实的影响范围标记节点：尚未开始的节点读取最新版；进行中的节点收到变更通知并判断是否仍成立；已完成节点只有在相关输入变化时才变为 STALE。例如文案示例变化不会让后端实现失效，OpenAPI 响应字段变化则会影响客户端和文档两个分支。

共享工作区也需要隔离。代码任务可以为每个写分支创建 Worktree，限定可修改路径，最后由集成 Owner 合并。两个 Agent 即使改不同文件，也可能同时修改锁文件、生成代码或公共配置。运行时在调度前比较写集合，对已知冲突资源设置串行锁；合并时仍以测试和最终 Diff 为准，不能因为 Git 自动合并成功就认为语义没有冲突。

隔离环境里产生的依赖缓存、构建产物和凭证要有生命周期。任务结束后清理 Worktree 和短期凭证，保留补丁、测试结果与必要日志。直接让所有 Agent 操作同一目录，速度看似更快，一次误覆盖就很难说明哪个分支产生了当前文件。

五、通信协议要传事实，不传思维过程

让 Agent 在共享聊天室里不断更新进度，容易制造大量低价值消息。每条消息都进入 Context 后，成员开始阅读彼此的草稿、猜测和重复结论，协调开销迅速上升。

更稳定的通信分三类：

控制消息：创建、取消、超时、重新分配和依赖解除；
状态消息：已开始、阻塞、完成，以及预算使用；
产物消息：符合 Schema 的发现、补丁、测试或证据引用。

中间推理通常保留在各自 Trace，不进入共享上下文。只有会改变其他分支决策的事实才广播，例如“API v2 实际仍保留旧字段，但只读”。这类事实要附来源，并由协调者写入共享 Brief。

{
  "type": "finding",
  "task_id": "api-v2/web-impact",
  "claim": "Web 端有 6 处直接调用 v1，其中 2 处依赖 removed_field",
  "evidence": [
    {"path": "apps/web/src/order.ts", "line": 84},
    {"path": "packages/order-client/src/types.ts", "line": 31}
  ],
  "gaps": ["运行时动态拼接 URL 的调用未能静态确认"],
  "confidence": "medium"
}

通信需要去重和版本。子任务重试可能重复提交产物；共享 Brief 更新后，旧产物可能基于过期版本。消息应带 task_attempt、brief_revision 和唯一 ID，汇总器才能判断是重复、补充还是失效结果。

三种通信拓扑

Manager-worker 最容易控制：所有任务和产物经过协调者，成员之间不直接聊天。它适合分支较独立、最终结果由一个 Owner 负责的场景。缺点是协调者可能成为 Context 与吞吐瓶颈。

Blackboard 模式让成员读写一个结构化事实库。适合多个分支持续产生可复用证据，例如安全审计里一个分支发现的新入口会触发另一个分支检查权限。Blackboard 必须有 Schema、去重与来源，不能退化成公共聊天频道。

点对点通信适合确实存在局部协商的团队，例如接口实现者与测试者需要快速确认一个字段。它也最难治理，因为关键决议可能只存在于两名成员的消息里。采用点对点时，任何改变根任务的结论仍要提升为共享事实，由 Owner 确认。否则最终汇总器看不见局部达成的约定。

通信协议还要考虑不可信输出。一个 Subagent 读取网页后返回的文本可能包含 Prompt Injection，父 Agent 不能因为发送者是“内部 Agent”就当成系统指令。产物保留来源标签，结构化字段经过校验，引用内容继续按外部数据处理。信任绑定证据与权限，不绑定拟人化角色。

六、主 Agent 的工作是合并与查漏

协调者不能把子 Agent 的文本首尾相接。它需要执行四项检查：覆盖范围是否完整，证据是否支持结论，多个分支是否冲突，最终方案是否满足根任务约束。

先用任务矩阵查覆盖：每个预定分支都应有成功、明确无发现或已解释失败。一个 Subagent 超时不应被安静忽略。缺失项可以重试、降级为主 Agent 处理，或在最终结果中标明未知。

再按实体合并。两个分支都提到同一个 API、文件或风险时，把它们放到同一记录中比较证据。冲突不能靠多数投票解决。一个 Agent 说字段已删除，另一个说仍然存在，协调者应读取权威 Schema 或启动一个只针对冲突的验证任务。

最后把产物映射回根任务验收条件。迁移计划需要影响清单、依赖顺序、兼容策略、测试和回滚。子 Agent 可能分别交出高质量局部报告，却没有人负责最终可执行性。根任务 Owner 必须唯一。

结果汇总也需要预算

子 Agent 返回整份长报告会挤爆主 Context。输出 Schema 可以要求“结论不超过 N 条，每条必须附证据；大文件保存到产物库，只返回引用”。主 Agent 先读取摘要，在冲突或低置信度时再展开原始材料。

分层汇总适合大扇出任务。十个 Worker 先由两个中间汇总器按主题合并，再交给根 Agent。不过每多一层都会损失细节并增加错误归因。能够由程序完成的去重、排序、Schema 校验和覆盖统计，应交给代码，不必再开一个模型。

汇总可以分为机械合并、证据裁决和方案生成。机械合并按实体键去重，计算覆盖率并检查 Schema；证据裁决只处理冲突和低置信度；方案生成最后才把确认事实转成计划或答案。若一开始就把所有长报告塞给模型“综合一下”，模型可能用流畅叙述掩盖两个分支的矛盾。

对代码产物，补丁本身不是汇总结果。集成 Owner 要在干净基线按依赖顺序应用补丁，处理冲突，运行跨分支测试，再生成最终 Diff。子任务测试通过只能证明局部环境有效，无法证明组合后有效。对研究产物也类似：每个来源摘要准确，不代表最后的跨来源结论成立。

可以给每条最终结论建立 provenance：它来自哪些产物、哪些证据、哪一次裁决。用户追问“为什么认为移动端会受影响”时，系统能回到具体代码位置，而不是重新询问模型。Provenance 也帮助评测哪些子任务真正被采用，哪些只是昂贵噪声。

七、一次跨服务迁移怎样协作

根任务先固定 v2 Schema、仓库范围和完成条件。协调者创建四个只读调查任务：服务端调用、Web、移动端、文档与示例。它们并行读取各自代码，输出统一的影响记录。调度器限制总并发为四，每个任务有独立工具预算。

四份结果返回后，汇总器发现 Web 与服务端对 legacy_discount 是否保留存在冲突。它没有让两个 Agent 继续辩论，而是读取生成接口的 OpenAPI 文件，确认字段只在响应兼容层保留。共享 Brief 更新到 revision 3，受影响记录重新计算。

协调者据此生成依赖图：先发布兼容服务端，再更新公共客户端，随后让 Web 和移动端在独立 Worktree 修改，最后更新文档。两个实现 Agent 只获得各自目录写权限。公共客户端由单独任务修改并先合并，避免三个 Agent 同时碰同一文件。

每个实现分支返回 Diff、测试和未解决风险。主 Agent 在集成分支运行跨服务测试，发现移动端仍发送废弃枚举值，于是把失败日志和固定范围交回原任务修复。所有验证通过后，主 Agent 生成一个迁移结果，而不是四份报告。

这条路径里，并行只出现在依赖允许的位置。调查可以全并行，公共契约必须串行，互不重叠的实现再次并行，最终集成回到单一 Owner。

如果移动端调查任务超时，根任务不会假装覆盖完成。任务矩阵把移动端标为 MISSING，协调者先用剩余预算重试一次；仍失败时，由主 Agent 执行最小静态搜索，并在计划里保留“运行时动态调用未确认”的风险。部分结果可以交付，但必须让缺口可见。

如果 Web 实现与公共客户端补丁在锁文件上冲突，集成 Owner 不让两个 Agent 互相改对方分支。它先合并客户端、重新生成锁文件，再把新的基线和失败测试交给 Web 分支重放局部改动。协调协议处理的是资源所有权，不需要更多模型参与 Git 冲突讨论。

整个案例可记录为四个阶段：发现、决议、实现、集成。每个阶段都有不同并发度和验收器。静态固定“始终开四个 Agent”会在决议阶段制造冲突，在集成阶段掩盖唯一 Owner；根据任务图改变并发，才是编排器的工作。

八、失败模式比角色设计更重要

最常见失败是重复劳动。任务描述过宽、工具相同、没有范围字段时，所有 Agent 会沿同一路径搜索。检查不同分支的文件、URL 和结论重合度，可以量化是否真的形成分工。

第二类是空洞交接。Subagent 返回“可能需要关注兼容性”，没有文件、行号或实验。父 Agent 只能重新调查。把证据设为必填，并用程序拒绝缺字段结果，可以在边界处挡住这类输出。

第三类是协调风暴。Agent 频繁广播进度，主 Agent 不断重规划，任务图反复变化。限制控制消息类型，设置最小重规划间隔，并要求只有新证据才能触发任务调整。

第四类是权限扩大。父 Agent 有部署权限，子 Agent 自动继承全部工具，任意研究分支便能触发生产动作。权限应该显式授予，默认不继承；凭证绑定任务、租户、资源和期限。

第五类是无人收口。所有成员都认为自己只负责局部，根任务长期处于“几乎完成”。任务图需要唯一 Owner、明确终态和剩余工作查询。Subagent 完成不等于根任务完成。

第六类是旧结果污染。共享 Brief 已升级，较慢的旧 attempt 最后才返回，汇总器若不检查 revision，会把过期结论重新写入事实库。产物要保留但标记为 stale，不能按到达时间覆盖新结果。

第七类是错误相关。多个 Agent 使用相同模型、相同 Prompt 和相同信息源时，它们可能以相同方式犯错。多份一致回答不等于独立证据。需要提高可信度时，应改变验证方法，例如一个分支读源码，一个分支运行测试，一个分支查权威 Schema，而不是复制三次相同提问。

第八类是成本失控。协调者在每个小问题上新增分支，子 Agent 又递归拆分，最终大部分 Token 花在复述 Brief 和产出进度消息。根预算、最大节点数、最大深度和单位证据成本必须由运行时执行，不能只写在 Prompt 里。

九、怎样评测多 Agent 是否值得

比较对象应包括单 Agent 基线，而不是只观察多 Agent 版本能否完成。使用相同任务、模型预算和验收标准，测结果质量、端到端延迟、Token、工具调用、重复工作、人工介入与失败恢复。

多 Agent 的预期收益通常是降低墙钟时间、扩大搜索覆盖或隔离 Context。若完成率相同、时间没有下降、成本明显上升，就没有理由保留复杂度。对强依赖代码任务，单 Agent 配合并行工具调用可能更便宜。

轨迹评测还要看任务图：拆分是否覆盖问题，依赖是否正确，是否产生大量取消任务，冲突如何解决，子任务结果有多少被最终答案采用。只看最终答案，会看不到系统用十五倍 Token 重复搜索后碰巧成功。

建议准备三类样本：天然可并行的广度任务、部分依赖的混合任务、强顺序任务。一个可靠协调器应该在第一类扩展，在第二类建立依赖，在第三类主动不拆。永远选择多 Agent 的路由器本身就是失败。

性能分析可以借用并行计算里的两个量。第一是关键路径长度，决定理论最短耗时；第二是并行效率，即实际节省时间与新增资源的比例。若四个 Agent 把 40 分钟任务降到 30 分钟，却把模型与工具成本增加四倍，效率很低。若研究任务从 40 分钟降到 12 分钟，同时覆盖率明显提升，对高价值场景可能值得。

评测时固定根任务预算比固定每个 Agent 预算更公平。否则多 Agent 方案天然得到更多总 Token。可以设置两组实验：等成本比较质量，等质量比较成本与延迟。再记录协调开销，包括 Brief 重复输入、未采用产物、冲突验证和取消分支。这样才能知道收益来自真正并行，还是来自单纯增加计算量。

线上还要观察分支分布。平均子任务数稳定，少数任务却派生上百个节点，通常意味着拆分策略在某类输入上失控。对节点数、深度、重试、stale 产物和采用率做分位数告警，比只看总 Token 更容易定位协调器问题。

十、从一个受控 Subagent 开始

第一版只增加一种能力：主 Agent 可以把只读调查交给一个 Subagent，输入与输出使用固定 Schema。先测它是否减少主 Context 噪声、是否稳定返回证据。有效后再开放并发和多个任务类型。

随后补任务 ID、预算、超时、取消、Trace 与覆盖检查。并发稳定后再考虑共享 Brief 和依赖图。Handoff、团队消息和递归委派应由真实需求推动，因为它们各自增加新的控制权和恢复问题。

落地顺序可以绑定可验证能力。第一阶段要求单个只读 Subagent 稳定返回有来源的结果；第二阶段允许两个独立分支并发，并证明取消、超时和预算生效；第三阶段加入 DAG 与 Worktree，验证依赖和写冲突；最后才考虑成员通信与动态重规划。每一阶段都保留单 Agent 路由，方便对照和降级。

运行时的数据模型至少包括根任务、节点、依赖边、attempt、产物和消息。节点描述逻辑工作，attempt 表示一次执行；重试生成新 attempt，不覆盖旧产物。根任务完成由图验收器判断，而不是等待“所有节点 success”，因为有些分支可能被取消、替代或明确允许失败。

一个最小调度循环并不复杂。复杂的是边界检查：

for (const node of graph.readyNodes()) {
  if (!budget.canReserve(node.estimate)) continue
  if (!resources.canLock(node.writeSet)) continue

  const attempt = createAttempt(node, brief.revision)
  const capability = issueCapability(node.tools, node.scope)
  dispatch(attempt, capability)
}

onArtifact(artifact => {
  validateSchema(artifact)
  verifyEvidence(artifact)
  markStaleIfBriefChanged(artifact)
  graph.updateCoverage(artifact)
})

readyNodes() 只返回依赖已满足且输入版本有效的节点。预算要先预留，防止多个分支同时看到同一余额；写集合要先锁定，防止两个 Worktree 都认为自己拥有公共文件。产物返回后先做程序校验，再交给模型处理语义冲突。顺序反过来，协调 Agent 就会反复阅读本可直接拒绝的坏结果。

调度器还要决定失败策略。required 节点失败会阻塞根任务；optional 节点失败只降低覆盖率；fallback 节点在主路径失败后才启用。每类节点有独立最大 attempt 和超时。统一“失败就重试三次”会让确定性 Schema 错误白白消耗预算，也可能对有副作用的实现任务重复写入。

产物库保存逻辑结果与大对象引用。调查结果、补丁、测试报告和截图使用不同 Schema，但共享 provenance 字段：节点、attempt、Brief revision、输入哈希、工具版本与生成时间。协调器读摘要，验证器按需打开原始对象。这样既控制 Context，也保留追溯能力。

上线前做三类故障注入：在 Subagent 返回后、保存产物前终止 Worker；重复投递完成消息；在 Brief 更新时让旧 attempt 延迟返回。系统应避免重复计费和重复合并，正确标记旧产物，并让根 Owner 看见未覆盖项。多 Agent 的可靠性首先是分布式任务系统问题，其次才是 Prompt 问题。

一张决策表胜过默认多 Agent

路由器可以根据任务特征选择执行方式，而不是把“是否多 Agent”交给一次开放判断。

任务特征	首选方式	原因
多个独立读取，几乎无局部推理	单 Agent 并行工具	不重复加载 Context
多个独立搜索，每支都需多轮判断	并行 Subagent	隔离局部 Context，缩短关键路径
强依赖、频繁共享中间结果	单 Agent 或串行节点	同步成本高，假设容易过期
专业能力有稳定输入输出	Agent-as-Tool	调用契约清楚，控制权不转移
用户后续应由专业角色负责	Handoff	会话所有权明确转移
长期成员需要互相协商	Agent Team	只有此时才承担团队协议成本

路由决策进入 Trace，包含预估分支、关键路径、预算和不拆分原因。线上可以比较预估与实际：原本认为独立的分支是否频繁冲突，预估并行收益是否实现，多少产物被采用。路由器据此改进，比统计“调用了几个 Agent”更有意义。

还应保留降级路径。协调服务故障时，任务可以回到单 Agent；预算不足时，只启动最高价值分支；某类 Subagent 连续返回无证据结果时，暂时禁用该模板。多 Agent 是执行策略，不应成为完成任务的唯一入口。

设计评审可以沿着六个问题走：为什么要拆，分支是否独立，每个分支拥有哪些 Context 与权限，产物 Schema 是什么，冲突由谁裁决，根任务由谁验收。回答不了其中任何一项时，多开几个 Agent 只会把不清楚的责任复制几份。

Subagent 的价值来自受控隔离。多 Agent 的价值来自并行且可合并的工作。清楚的任务图、证据协议与唯一 Owner 可以直接决定协作是否缩短了路径，角色名称和拟人化对话不会替系统补齐这些条件。