什么时候才需要 Subagent？
教学案例：登录超时根因不明时，可以让一个只读 Subagent 查调用链，另一个只读 Subagent 检查失败测试；但两个 Agent 同时改同一文件，通常只会制造冲突。
Subagent 的价值来自任务可独立拆分、上下文需要隔离，或并行能明显缩短等待。主 Agent 仍负责授权、预算、冲突处理和最终验证。
多 Agent 会增加用量和汇总成本，所以先把单 Agent 跑好，再用同一任务比较是否真的更快、更稳。
主 Agent 需要决定拆什么、给多少上下文、如何避免资源冲突、何时汇总、如何处理结论分歧。协调成本可能超过并行收益。
什么时候并行调查，什么时候必须回到一个主任务？
登录超时任务先拆成三个互不写文件的调查分支；主 Agent 等证据汇合后只修改一次，再由独立复核者（Reviewer）检查改动对比和测试。
三个分支都不能修改文件，也不能扩大任务范围。
固定失败用例、运行命令与错误时间。
定位客户端超时、服务端配置与相关文件。
列出必须通过的测试和公开 API 约束。
证据不一致时不拼接答案；先补查，再只修改批准的两个文件。
未通过则返回主任务，不能由子任务自行宣布完成。
先画依赖，再决定并行
把任务写成节点和依赖：调用链调查与测试失败分析可以并行；修改方案必须等待两者结果；写代码只能由主 Agent 执行。这个有向依赖图就是简化的 DAG。
每个子任务需要明确输入快照、可用工具、输出格式、完成标准和停止条件。隔离上下文可以减少噪声，也意味着主 Agent 必须主动提供必要背景。
官方事实查看这一结论的依据与边界＋
Anthropic 文档公开说明 Claude Code 的自定义 Subagent、独立上下文与工具配置；这是 Claude Code 产品案例。
ANCreate custom subagents官方文档 · 核验 2026-07-14汇总不是拼接，而是验证
多个 Agent 结论冲突时，汇总器要比较证据、来源和任务条件，必要时请求独立 Reviewer 找反例。多数票不能替代事实。
衡量多 Agent 要同时看实际等待时间、总成本、工具冲突、结论质量和汇总负担。并行更快但成本更高，也可能不符合产品目标。
官方事实查看这一结论的依据与边界＋
Anthropic 建议从简单可组合模式出发，只有复杂性带来可证明收益时再增加 Agent 编排。
ANBuilding effective agents官方工程文章 · 核验 2026-07-14只有三类瓶颈值得先考虑多 Agent
第一，当前上下文被某个子任务污染，需要隔离；第二，多个子任务相互独立，可以真正并行；第三，工具和领域差异足够大，专业化能显著减少误选。其他情况下，先把单 Agent 的上下文、工具和指令做好。
是否采用多 Agent 是实验结论，不是架构审美。用同一任务比较单 Agent 与多 Agent 的质量、墙钟时间、总 Token、失败点和人工汇总成本，达不到预先门槛就不增加复杂度。
独立研究查看这一结论的依据与边界＋
Google Research 的实验显示，多 Agent 在其可并行任务上可能增益明显，在严格串行任务上反而下降 39%–70%；这些数字只适用于该研究任务与架构。
GOTowards a science of scaling agent systems官方研究 · 核验 2026-07-14有术语没听懂？在这里用人话再看一遍5 个词＋
- Subagent
- 在主任务下承担明确子任务、拥有受限上下文和工具的 Agent 实例。
- Orchestrator
- 负责拆分任务、调度依赖、分配资源并汇总结果的编排者。
- DAG
- 用节点和有向依赖表示哪些任务可并行、哪些必须按顺序完成。
- 输出契约
- 对子任务返回格式、证据、完成标准和失败语义的约定。
- 墙钟时间
- 从用户开始等待到整体任务结束的实际时间，与所有 Agent 消耗时间之和不同。
本章依据与证据边界3 条补充结论 · 12 份原始材料＋
下面补充本章的其他依据，并说明每份材料能证明什么、不能证明什么。
- [4]
Anthropic 将上下文隔离、可并行任务和有效专业化列为多 Agent 的三类主要收益，并披露其测试中多 Agent 通常使用 3–10 倍 Token；该数字只适用于其测试设置。
官方事实CLBuilding multi-agent systems: When and how to use them官方工程文章 · 核验 2026-07-14 - [5]
Claude Code 官方把 Dynamic Workflows 描述为动态编排、并行 Subagent、独立复核和可恢复进度的产品能力，并明确提醒用量会显著增加。
官方事实CLIntroducing dynamic workflows in Claude Code官方工程文章 · 核验 2026-07-14 - [6]
本站的 DAG、只读调查和 Reviewer 流程是跨产品教学推演。
本站推演ANCreate custom subagents官方文档 · 核验 2026-07-14
查看全部一手材料与源码证据 12 条
这份材料区分了由预定义代码路径控制的 Workflow 与由模型动态控制过程的 Agent，并强调先采用能工作的最简单方案。它还给出 Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer 等组合模式，以及何时值得承担 Agent 的延迟、成本和复合错误。
证据边界：官方经验与自测不能单独证明普遍收益，结论不得越过其样本、版本和适用范围。官方方法 · 核验 2026-07-23Effective context engineering for AI agentsAnthropic这份材料将 Context Engineering 定义为持续选择和维护推理时最合适的信息，而不只是改写一条 Prompt。它支持最小高信号上下文、按需检索、工具结果压缩、结构化笔记、Compaction 与 Subagent 隔离等长任务策略。
证据边界：官方经验与自测不能单独证明普遍收益，结论不得越过其样本、版本和适用范围。官方产品实现 · 核验 2026-07-11Hooks referenceAnthropic这份参考文档定义 Session、Prompt、Tool、Permission、Subagent、Compaction 等 Hook 事件及其输入输出协议。它还区分 command、HTTP、MCP tool、prompt 与 agent handler，并说明异步 Hook、阻断决策、超时和 Subagent Hook 的具体限制。
证据边界：官方文档不能单独证明未公开内部实现、长期可靠性或真实用户收益。官方产品实现 · 核验 2026-07-23Connect Claude Code to tools via MCPAnthropic这份文档说明 Claude Code 如何通过 MCP 连接外部工具、资源、提示与事件渠道，以及 local、project、user 等配置作用域。它支持讲清 MCP 是外部能力连接协议而不是 Agent 的推理核心或长期记忆，并覆盖认证、连接、超时和共享边界。
证据边界：官方文档不能单独证明未公开内部实现、长期可靠性或真实用户收益。官方产品实现 · 核验 2026-07-23Create custom subagentsAnthropic这份文档说明 Subagent 使用独立上下文完成委派任务并向主会话返回摘要，可分别配置模型、工具、权限、Skill、MCP、Memory、Hook 与 Worktree 隔离。它支持把 Subagent 的价值定位为上下文隔离、并行和专业化，而不是把增加 Agent 数量等同于自动提升结果质量。
证据边界：官方文档不能单独证明未公开内部实现、长期可靠性或真实用户收益。官方方法 · 核验 2026-07-23A practical guide to building agentsOpenAI这份指南面向产品与工程团队，给出 Agent 使用场景判断、Model/Tools/Instructions 基础结构、单 Agent 与多 Agent 编排和 Guardrail 设计。它支持从复杂决策、难维护规则和非结构化信息出发选择场景，并强调先强化单 Agent、从小范围真实用户验证开始。
证据边界：官方经验与自测不能单独证明普遍收益，结论不得越过其样本、版本和适用范围。官方产品实现 · 核验 2026-07-16Grok Build is Now Open SourcexAIxAI 官方说明本次公开的是 Grok Build 编码 Agent 与终端 TUI，并明确列出 Agent Loop、代码交互工具、终端 UI，以及 Skills、Plugins、Hooks、MCP Servers、Subagents 等扩展系统。它让课程可以用真实实现核对 Harness 责任，而不是让产品经理通读源码。
证据边界：官方公告没有说明 Grok Build 的服务端实现，也不能证明托管产品的完整架构、真实任务成功率或这些设计适用于所有 Agent。固定提交源码 · 核验 2026-07-23Grok Build repository map（固定提交）xAI固定提交 README 将公开范围界定为 grok CLI/TUI 与 Agent Runtime 的 Rust 源码快照，并标出 TUI、Agent Runtime、工具、Workspace、MCP、Sandbox 等主要 crate；仓库由 xAI 内部 monorepo 定期同步且不接受外部贡献。
证据边界：这个快照不是 Grok Build 服务端源码，也不能代表后续线上版本、内部 monorepo 的全部模块或每项功能的运行效果。固定提交源码 · 核验 2026-07-23Hermes Agent async delegation and turn finalizationNous Research这段源码说明后台 Subagent 的完成结果进入共享队列，并在 Agent 空闲时形成新的 Turn，而不是插进正在进行的工具序列；这样可以保持消息角色顺序与 Prompt Cache 稳定。这是 Hermes 的实现选择，不是行业统一协议。
证据边界：固定提交只能证明该版本的公开实现，不能代表现行私有产品、真实任务质量或行业统一架构。官方产品实现 · 核验 2026-07-23How we built our multi-agent research systemAnthropic这份生产案例披露 Orchestrator-Worker、独立上下文、并行搜索、恢复与评测方法，也明确多 Agent 的高 Token 成本和对串行、强共享上下文任务的限制。
证据边界：内部研究 Eval 的提升不能证明多 Agent 对所有任务都优于单 Agent。官方产品实现 · 核验 2026-07-23A harness for every task: dynamic workflows in Claude CodeClaude by Anthropic这份材料说明 Claude Code 如何让用户为长程、并行、结构化或对抗任务编写动态 Harness，并以多个独立上下文完成分解、验证和汇总。
证据边界：动态工作流不是默认更优；协调、Token、延迟和错误传播仍需针对任务测量。独立研究结论 · 核验 2026-07-14Towards a Science of Scaling Agent SystemsGoogle Research受控实验表明多 Agent 在可分解并行任务上可能显著提升，在严格串行任务上可能下降 39%–70%，工具密集任务还会承担额外协调成本。
证据边界：论文仍受基准、模型、配置和版本限制，不能当作所有生产任务的固定公式。