Multi-Agent 不是 Single Agent 的自然升级。把一个 Agent 复制三份，不会自动得到三倍能力；如果三个 Agent 读取同样的 Context、使用同样的 Tool、沿同一路径判断，系统通常只会增加 Token、延迟和冲突。
只有拆分带来的并行、隔离、权限边界或独立证据，明显高于委派、通信、等待和合并成本时，才应该引入多个 Agent。
术语来源与适用范围
Multi-Agent System 来自分布式人工智能与多智能体研究，传统研究对象可以是具有局部观察、独立目标和交互规则的软件实体。今天的 LLM Multi-Agent 常把多个配置不同的 LLM 执行单元组织成团队，两者有关联，但不能直接等同。
Anthropic 的多 Agent Research 系统采用 Lead Agent 与并行 Subagent，并明确指出多 Agent 会增加协调、评估、可靠性与 Token 成本。OpenAI Agents SDK 的编排文档则区分 Manager 调用 Agent-as-Tool 与 Handoff 两种常见模式。这些是产品实现和工程经验，不是跨框架统一定义。
本章的拆分条件、成本模型与决策树是 Playbook 的分析框架。它适用于有明确 Goal、Run、Artifact 和验收标准的执行系统，不意味着每个子任务都必须启动独立进程，也不要求使用某种 Agent 框架。
先问拆分解决了什么问题
值得拆分的原因通常只有四类：
| 拆分收益 | 成立条件 | 典型例子 | 主要代价 |
|---|---|---|---|
| 并行执行 | 子任务大部分时间无数据依赖 | 同时研究多个独立市场 | 峰值资源、合并等待 |
| Context 隔离 | 信息域不同，放在一起会挤占或污染 Context | 法务条款与代码实现分别分析 | 摘要失真、跨域遗漏 |
| 权限分离 | 不同动作必须使用不同身份或 Sandbox | 只读审计与生产变更分离 | 授权、审计与凭据管理 |
| 独立判断 | 需要避免执行者自我验证 | 实现者与安全 Reviewer 分离 | 重复读取、意见冲突 |
专业化本身不是第五类充分理由。只要通过 Skill、Tool 或模型路由就能让一个 Agent完成任务，就不必为“角色名称不同”建立独立 Agent。角色只有带来独立 Context、State、权限、生命周期或责任时，才成为系统边界。
并行的前提是依赖图允许并行
不要根据任务数量判断是否并行，要根据 Task Graph 判断。
代码块说明｜层级示意： 这段文本图按缩进和树枝符号阅读，用来展开“并行的前提是依赖图允许并行”中的父子关系与归属边界。它描述的是逻辑结构，不要求数据库或服务按同样层级拆分。
A 读取需求
├── B 检查前端影响
├── C 检查后端影响
└── D 检查数据迁移
↓
E 合并风险
B、C、D 只依赖 A，可以并行；E 依赖三者，只能等待。如果 C 必须读取 B 的接口设计，再把两者同时委派只会制造空等、返工和额外消息。
可用一个简化估算判断并行价值：
代码块说明｜关系式： 这段表达式把“并行的前提是依赖图允许并行”压缩成便于比较的组成关系。它是分析模型，不是可执行代码，也不是要求实现者采用的行业标准公式。
single_time = Σ task_time
multi_time = critical_path + delegation + queue + merge + rework
只有 multi_time 明显小于 single_time，延迟层面的拆分才成立。
Token 成本通常不会同样下降。多个 Agent 需要重复读取 Goal、共享约束和背景材料，还要生成委派与合并消息。因此多 Agent 更常交换的是更低的墙钟时间，而不是更低的总计算成本。
计算协调成本，而不是只看 Agent 数量
一次拆分至少增加五类成本：
- Delegation：把父任务转换为边界清楚、可验收的子任务。
- Context Transfer：选择哪些事实、约束和 Artifact 交给子 Agent。
- Synchronization：等待依赖、处理超时、取消和孤儿任务。
- Merge：去重、解决接口不一致、合并多个产物。
- Verification：验证局部结果，也验证组合结果。
可以给候选拆分建立简单评分，不追求跨团队统一数值：
| 维度 | 低收益 / 高成本信号 | 高收益 / 低成本信号 |
|---|---|---|
| 依赖耦合 | 子任务频繁互相等待 | 输入输出边界稳定 |
| 产物可合并性 | 都修改同一区域 | 产物可独立验证 |
| Context 重叠 | 大部分材料相同 | 各自只需局部材料 |
| 失败隔离 | 一个失败使全部失效 | 局部失败可以降级 |
| 权限边界 | 完全相同 | 明确不同 |
| 判断独立性 | 复制同一偏差 | 不同证据或评估方法 |
如果收益只来自“希望模型更聪明”，优先改进 Context、Skill、Tool 和 Evaluation。增加 Agent 数量不是能力缺口的通用修复。
Subagent 什么时候只是 Tool
Subagent 可以有两种完全不同的系统身份：
| 形态 | 调用关系 | 状态与生命周期 | 结果责任 |
|---|---|---|---|
| Agent-as-Tool | Parent 发起一次有界调用并等待结果 | 通常是嵌套或短生命周期 | Parent 解释、合并并对最终结果负责 |
| 持续参与者 | 拥有独立 Child Run，可等待、恢复和收发消息 | 有独立状态、预算、权限与终态 | 对委派产物负责，Root Owner 仍负责总目标 |
一个“翻译专家”接收文本并返回译文，更像 Agent-as-Tool。一个负责数小时研究、需要追问、维护自己的 Task、等待外部事件并持续提交 Artifact 的研究 Agent，是持续参与者。
名称不决定身份。即使 SDK 把 Handoff 表示成 Tool Call，控制权、Context 继承和完成责任仍可能发生转移。需要从运行语义判断，而不是从 API 名称判断。
不适合拆分的典型任务
- 下一步强依赖上一轮观察的探索任务。
- 多个 Agent 会同时修改同一小段文件或同一外部对象。
- 任务很短，启动与合并成本接近执行成本。
- 没有可机器检查或人工验收的局部产物。
- 所有 Agent 使用相同 Context、模型、Skill 和证据，只做重复投票。
- Root Agent 本身已经成为信息瓶颈，却继续增加 Worker。
示例：并行调查三家候选供应商
目标是从三家互不关联的候选供应商中选择一家进入现场评估。每家供应商需要调查相同维度，包括资质、交付能力、公开风险、客户案例与报价条件。
这个任务适合按调查对象拆分：三家供应商的信息来源彼此独立，可以同时推进；每个 Child Run 使用同一份调查标准，产出结构一致且带来源引用的候选档案。
代码块说明｜层级示意： 这段文本图按缩进和树枝符号阅读，用来展开“示例：并行调查三家候选供应商”中的父子关系与归属边界。它描述的是逻辑结构，不要求数据库或服务按同样层级拆分。
Root Owner
├── 调查供应商 A → supplier-a.json + evidence_refs
├── 调查供应商 B → supplier-b.json + evidence_refs
└── 调查供应商 C → supplier-c.json + evidence_refs
↓
Root 统一校验来源、比较差异并形成候选结论
Root 不把三份调查结论直接拼接成报告，而要先检查来源时间、证据完整性和指标口径，再对关键差异进行交叉验证。最终推荐仍由 Root Owner 根据统一标准作出，Child Agent 只对各自的供应商档案负责。
这里的并行收益来自调查对象独立，而不是把同一个判断重复三次。如果三家供应商的数据必须在同一个受限系统中顺序查询，或者关键资料只有一个 Agent 能访问，拆分收益就会明显下降。
为什么完整 Pull Request 通常不应按技术层拆开验收
一个包含 API、前端和数据库迁移的 Pull Request，其可合并性是整体属性。接口兼容、迁移顺序、前端行为与集成测试之间存在跨层依赖。默认做法应该是由一个明确 Owner 从变更意图、代码差异到完整测试回归进行端到端验证。
当代码库很大时，可以让 Subagent 作为有界的证据收集 Tool，例如运行特定平台测试或检查一组迁移脚本；但这些局部结果不能替代完整审查，也不应把最终验收责任分散给多个 Reviewer。最终 Owner 必须重新查看整体 Diff、组合测试与跨层不变量，再判断是否可以合并。
本章检查
- 拆分是否对应并行、Context、权限或独立判断中的至少一项真实收益。
- Task Graph 是否证明子任务可以独立推进，而不只是名字不同。
- 每个 Child Run 是否有边界清楚、可验证的 Artifact。
- 是否估算了 Delegation、Context Transfer、等待、Merge 和 Rework。
- Agent-as-Tool 与持续参与者是否采用了不同生命周期语义。
- Root Owner 是否仍然对总目标和组合验证负责。