什么时候需要多 Agent
先回答：为什么一个 Agent 加多个 Skill 做不到？
一句话理解：先证明“一个 Agent 加多个 Skill 和工具做不到”，再考虑多 Agent；多 Agent 真正买到的是并行、上下文隔离和权限隔离，付出的是成本、信息损失与调试难度。
“我们要做一个销售分析 Agent 团队：数据 Agent 负责取数，分析 Agent 负责找原因，报告 Agent 负责写报告，审核 Agent 负责检查。”这类方案在需求评审里非常常见，因为它看起来像一个井然有序的组织架构图，很容易讲给老板听。
但 Agent 不是员工。人类团队分工，是因为一个人的时间和专业有限；而一个 Agent 可以按需加载不同的 Skill、调用不同的工具，并不会“累”。把一个流程硬拆成四个 Agent，往往换来的是四份 Token 账单、三次信息传递损耗，以及出错时没人说得清是哪个环节的问题。
这就是本模块被放在课程最后的原因：大多数场景一个 Agent 加多个 Skill 就够了。这一课给出判断方法。
先问：单 Agent 为什么做不到？
在提出多 Agent 方案之前，依次回答下面的问题。只要有一个问题能用更简单的方式解决，就先用简单的方式：
图 1 把这些问题画成一棵决策树：
前四个问题的答案指向的都不是多 Agent。相关内容分别在 Skill、Tool、Workflow 与 Subagent、混合架构 和 工具设计原则 中讲过。
OpenAI 在《A practical guide to building agents》中给出的建议与此一致：先最大化单个 Agent 的能力，多数情况下一个带工具的 Agent 就足够。它列出了两个值得拆分的信号：
- 逻辑过于复杂：指令里充满条件分支，模板越来越难以维护。
- 工具过载：问题不只是工具数量，而是工具之间是否相似、重叠。指南提到，有的实现能很好地管理超过 15 个定义清晰、互不重叠的工具，也有实现在不到 10 个相互重叠的工具上就表现吃力。先尝试改进工具命名、参数和描述，无效后再拆分。
多 Agent 真正能买到什么
排除以上情况之后，多 Agent 能带来四类单 Agent 难以获得的收益：
| 收益 | 机制 | 典型场景 |
|---|---|---|
| 并行加速 | 多个 Agent 同时处理相互独立的子任务 | 同时诊断 50 个页面的 SEO 问题；同时调研 5 家竞品 |
| 上下文隔离 | 探索性工作在独立上下文里完成，只把结论带回 | Coding Agent 让子 Agent 翻遍代码库，主线程只看摘要 |
| 权限与信任隔离 | 读取不可信内容的 Agent 没有写权限，有写权限的 Agent 不直接接触不可信内容 | 浏览网页的调研 Agent 与能发邮件的执行 Agent 分开，降低 Prompt 注入 风险 |
| 组织与系统边界 | 不同团队维护、独立部署、独立演进的 Agent 之间协作 | 企业内的采购 Agent 调用财务部门维护的报销 Agent，见 Agent 间协议概览 |
注意这张表里没有“专业分工”。“让分析 Agent 更专注于分析”这件事，通常用 Skill 就能做到，不需要一个独立的 Agent。
图 2 对比两种架构的形态、收益与代价：
公开的工程实践怎么说
多 Agent 是业界争议较多的话题，两种声音都值得了解。
支持的一方：Anthropic 的多 Agent 研究系统。 Anthropic 在 2025 年 6 月发布的工程文章中介绍，他们的 Research 功能采用编排者-执行者（orchestrator-worker）架构：一个主 Agent 制定研究计划，并行派出多个子 Agent 分头搜索。在其内部研究评测中，以 Claude Opus 4 为主 Agent、Claude Sonnet 4 为子 Agent 的多 Agent 系统，比单 Agent 的 Claude Opus 4 表现高出 90.2%。但文章同样坦白了代价与边界：
- 多 Agent 系统消耗的 Token 大约是普通聊天的 15 倍，只适合任务价值足以覆盖成本的场景。
- 在 BrowseComp 评测中，Token 用量本身就能解释约 80% 的表现差异，也就是说，多 Agent 有效的一个重要原因是它能在问题上投入更多 Token。
- 需要所有 Agent 共享同一份上下文、子任务之间依赖很多的领域并不适合多 Agent，文章特别提到大多数编码任务中真正可并行的部分比研究任务少。
谨慎的一方：Cognition 的《Don’t Build Multi-Agents》。 这篇 2025 年 6 月的文章提出两条原则：共享上下文，而且要共享完整的 Agent 轨迹，而不只是单条消息；行动隐含着决策，相互冲突的决策会带来糟糕的结果。它的例子是让两个子 Agent 分别做 Flappy Bird 游戏的背景和小鸟，结果一个做出了超级马里奥风格的背景，另一个的小鸟风格也对不上，主 Agent 很难把它们拼起来。作者建议多数情况下使用单线程的线性 Agent，超长任务再引入上下文压缩。
两边其实并不矛盾，可以合并成一条经验：以读为主、可以拆成独立子问题的广度任务，适合并行多 Agent；以写为主、步骤之间强依赖的任务，应保持单线程，由一个 Agent 拥有全部决策。
图 3 把这条经验画成两栏：
用三个场景练习判断
| 场景 | 是否需要多 Agent | 理由 |
|---|---|---|
| 全站 SEO 诊断：检查 50 个页面并出报告 | 适合 | 每个页面的诊断相互独立，可并行；各页面的原始 HTML 不必进入主上下文，只需汇总问题清单 |
| 客服工单处理：查订单、查支付、判断原因、创建工单 | 通常不需要 | 步骤强依赖，后一步的判断需要前面所有事实；单 Agent 加售后诊断 Skill 更可靠。若历史工单数量巨大，可把“历史工单检索与归纳”交给一个 Subagent |
| Coding Agent 修复一个跨模块 Bug | 主线程单 Agent，局部用 Subagent | 修改代码需要连续一致的决策；“在代码库里找出所有调用点”这类探索可以交给 Subagent，保护主上下文 |
| 销售周报：取数、分析、写报告、审核 | 通常不需要 | 这是一条固定流程，更适合 Workflow 加一个分析 Agent 节点；“审核”可以用程序校验加评估者模式实现 |
常见误区
- “多 Agent 更高级，效果一定更好。” 公开数据中效果提升往往伴随着数倍的 Token 投入。先问：同样的预算给单 Agent，效果会差多少？
- “按人类岗位拆 Agent。” 岗位分工解决的是人的精力与专业限制，Agent 的对应手段是 Skill 和工具，不是新 Agent。
- “多 Agent 能解决指令混乱。” 如果单个 Agent 的指令已经写不清楚，拆成多个 Agent 之后，协作规则只会更难写清楚。
- “先搭多 Agent 框架，以后好扩展。” 过早引入的架构复杂度会让每一次调试和评测都变贵。需要时再拆，比预先拆好更容易。
产品经理检查清单
评审一个多 Agent 方案时，逐条确认：
- 是否已经尝试过“单 Agent + Skill + 工具 + 更好的指令”，并有评测数据证明不够？
- 拆分的理由属于哪一类：并行、上下文隔离、权限隔离，还是组织边界？如果都不是，为什么要拆？
- 子任务之间是否真正独立？还是后一个 Agent 需要前一个 Agent 的全部上下文？
- 是否估算过多 Agent 方案的 Token 成本倍数？任务价值能否覆盖？
- 最终答案由哪个 Agent 负责？出错时如何定位是哪个环节？
- 同一份评测集上，单 Agent 与多 Agent 方案的质量、成本、延迟对比结果是什么？
练习
选一个你见过的“多 Agent 方案”（或使用本课开头的销售分析 Agent 团队，30–45 分钟）：
- 用决策树逐条检查，写下每个拆分出来的 Agent 能否用 Skill、工具或 Workflow 替代。
- 画出你认为最简单可行的架构。
- 如果你保留了多 Agent 的部分，写清它属于四类收益中的哪一类，并估算成本会是单 Agent 的几倍。
延伸阅读
- Anthropic：How we built our multi-agent research system
- Cognition：Don’t Build Multi-Agents
- OpenAI：A practical guide to building agents（PDF）
- Anthropic：Building effective agents
下一步
如果确实需要多个 Agent，它们之间怎么协作？下一课「协作模式」对比 Router、Manager / Worker、Supervisor、Handoff 与并行五种模式。