多智能体系统（Multi-Agent System，MAS）是指多个 AI 智能体分工合作、并行运行，共同完成一项工作的机制。由负责统筹的智能体拆分任务，执行任务的智能体（子智能体）各自在独立的上下文中调研或撰写，最后由统筹者汇总结果。
不过，“智能体越多就越聪明”并不成立。Google Research 等机构在六类任务上做的实验显示，与单个智能体相比，在可以拆分的工作上最多好约 81%，在必须按顺序推进的工作上最多差 70%。本文先讲定义和五种模式，再结合这项实验以及 Anthropic、Cognition 等公开的资料，帮你判断哪些工作用得上、哪些工作反而适得其反。
多智能体＝分工并行运行的团队
— 不再让一个 AI 包办一切，而是由小型专家团队分担工作
每个智能体都有独立的上下文窗口，并行运行。
统筹者先检查结果再汇总——实验表明，有没有这样一个负责检查的统筹者，会大大影响错误扩散的程度。
目录
1. 什么是多智能体
多智能体系统（Multi-Agent System，MAS）是指多个 AI 智能体协作解决一项任务的机制。每个智能体都有自己的指令（提示词）、可用的工具和上下文，通过交换结果来达成整体目标。
作为基础的“单个智能体”，正如什么是 AI 智能体中所讲，会独自循环执行“思考→使用工具→查看结果”。多智能体最贴切的理解，就是在这个循环之上加入分工和并行。
与单智能体的区别
| 维度 | 单智能体 | 多智能体 |
|---|---|---|
| 结构 | 一个 AI 循环执行 | 多个 AI 协同工作 |
| 上下文 | 所有内容塞进一个窗口 | 按角色分开（无关信息不会混在一起） |
| 并行 | 基本按顺序处理 | 执行者可以同时推进 |
| 错误扩散 | 自身的错误会累积 | 没有检查者时，执行者的错误会直接进入最终结果 |
| 成本 | 较低（约为聊天的 4 倍） | 较高（约为聊天的 15 倍） |
| 擅长的工作 | 按顺序推进、后一步依赖前一步结果的工作 | 可拆成独立部分的调研、比较与验证 |
token 倍数来自 Anthropic 就自家调研功能公布的数值（How we built our multi-agent research system，2025 年 6 月 13 日）。详见第 6 节。
2. 为什么要让多个 AI 协作
出发点是“一个智能体能搞定，就用一个”。只有当你碰上单智能体在结构上难以跨越的三堵墙时，才需要多智能体。
单智能体难以跨越的三堵墙
举个效果的例子：Anthropic 公布，在 Claude 的调研功能（Research）中，由 Claude Opus 4 担任统筹者、Claude Sonnet 4 担任执行者的配置，在其内部调研评测中比 Opus 4 单独工作好 90.2%（同上）。同一篇文章还写道，仅凭所用 token 的数量，就能解释 80% 的性能波动（在名为 BrowseComp 的调研评测中）。也就是说，多智能体的优势大多来自“把独立的上下文并排运行，读到单个智能体装不下的信息量”。
3. 五种模式
多智能体的结构有几种“固定形态”。各产品的叫法不同，但大致可归为以下五种。对应第 4 节实验所用的分类（独立、集中、分散、混合）时，也一并标出。
3-1. 编排者–执行者型（最常用）
由一个统筹者（编排者）拆分任务，分配给多个执行者（子智能体）。每个执行者在独立的上下文中运行，把结果交回统筹者。在实验的分类中属于“集中型（Centralized）”。Anthropic 的调研功能、Claude Code 的子智能体，以及 OpenAI Agents SDK 中“把智能体当作工具调用”的方式（Agent.as_tool()）都属于这一类。
3-2. 移交型（handoff：负责人接力）
智能体之间以“接下来交给你”的方式转交对话的主导权。按照 OpenAI Agents SDK 的说明，接到移交的专业智能体会负责本轮剩余的部分。适合窗口类工作，比如把咨询从前台转给计费或技术支持。这个 SDK 的实验性前身 Swarm 已在代码仓库中注明“已被 Agents SDK 取代”，新项目应使用 Agents SDK。
3-3. 层级型（团队的团队）
在统筹者之下再设中间统筹者，其下再放执行者，形成树状结构。在 Claude Code 中，子智能体可以再调用自己的子智能体，默认最多 3 层（官方文档）；Cursor 也在 2026 年 2 月的 2.5 版中允许执行者再调用执行者。层数越多，token 和等待时间越多，所以要事先定好深度上限。
3-4. 对等型（辩论与共识）
不设统筹者，多个智能体以平等身份各抒己见，反复讨论直到达成一致。在实验的分类中属于“分散型（Decentralized）”。Multi-Agent Debate 的研究报告称，它能提升回答的事实性和推理质量。在需要对照多种视角的工作（如网络调研）中往往表现较好（第 4 节）。
3-5. 流水线型（固定顺序）
按照“调研 → 结构化 → 验证 → 输出”这样的固定顺序依次经过各个智能体。由程序而不是 AI 决定下一个运行哪个智能体，所以结果稳定，也容易查出在哪里出了问题。OpenAI Agents SDK 把把前一个输出作为下一个输入的“链式调用”，以及让生成者与评估者轮流工作的“评估循环”，介绍为用代码搭建的模式。
五种模式速览
4. 实验揭示的“有效的工作与无效的工作”
“哪种模式更强”会随工作的性质而反转。用数字说明这一点的，是 Google Research、Google DeepMind 等机构研究者的论文 Towards a Science of Scaling Agent Systems（最新版为 2026 年 4 月）。它用 GPT、Gemini、Claude 三个系列的模型，在 6 类任务、260 种组合上比较了单智能体加 4 种多智能体共 5 种配置（Google Research 博客的介绍发布于 2026 年 1 月，博客中的 180 种对应初版时的数字）。
出处：论文第 4.2 节。在代码修复和步骤规划上，测试的所有多智能体配置都不如单智能体，这里列出的是退步最小的一种（代码修复为 −2.1%～−14.9%，步骤规划为 −39.1%～−70.0%）。
可以读出三点。
- 只有可拆分的工作才明显有效：金融分析可以把收入、成本、市场等分开调研，最后再汇总，所以集中型比单智能体高出约 81%。
- 依赖顺序的工作会适得其反：在每一步决定下一步的规划任务上，所有配置都不如单智能体。拆分工作会让执行者之间的前提产生偏差，还要在沟通上耗费步数。
- 代码修复也没有提升：Anthropic 也写道，与调研相比，大多数编程任务中真正能并行的部分更少（该公司的文章），与这一结果相符。
有负责检查的统筹者，错误就不容易扩散
这篇论文还按配置测量了执行者的错误会在多大程度上扩散到最终结果（以单智能体为 1 的倍数）。
独立型（不商量也不检查）
17.2 倍
只是把执行者的结果并列，错误原样保留
分散型（平等辩论）
7.8 倍
讨论能纠正一部分错误，但没有负责检查的角色
混合型
5.1 倍
统筹者＋执行者之间的部分商量
集中型（统筹者检查）
4.4 倍
统筹者先检查执行者的结果再汇总
出处：论文表 5（Error Amp）。同一张表中，每个任务所需的交互轮数，单智能体平均 7.2 轮，集中型为 27.7 轮，混合型为 44.3 轮。
“单智能体已能解出 45% 以上，再加智能体往往反而有害”——论文报告称，在单智能体正确率已超过约 45% 的任务上，增加智能体往往会让成绩下降。先用一个智能体测量，看到这个数字再决定是否增加，这样的顺序也得到了实验的支持。
5. 实际产品中的用法
Anthropic 的调研功能：按问题难度调整执行者数量
Claude 的 Research 是典型的编排者–执行者型：统筹者拆分问题，执行者并行调研，统筹者汇总。公开设计中最有参考价值的一点，是在提示词里写明了按问题难度使用多少个执行者（该公司的文章）。
| 问题类型 | 执行者数量 | 工具调用次数 |
|---|---|---|
| 简单的事实核对 | 1 个（只有统筹者） | 3～10 次 |
| 直接比较 | 2～4 个 | 每个 10～15 次 |
| 复杂调研 | 有时超过 10 个 | 每个执行者的职责划分清楚 |
该公司写道，在有这些规则之前，早期版本出现过为一个简单问题启动 50 个执行者的失误。自己搭建时，最快的做法是把这张表原样写进提示词，作为“如何确定规模”的规则。另外，把搜索等工具改为并行调用后，复杂问题的调研时间最多缩短了 90%。
Claude Code 与 Codex 的子智能体
在 Claude Code 中，可以把调研、审查等工作交给子智能体。每个子智能体在自己的上下文中运行，只向父级返回摘要，因此父级的上下文不会被占满。默认最多可同时运行 20 个，嵌套最多 3 层。它与执行者之间边商量边推进的“智能体团队”有何不同，见Claude Code 子智能体与智能体团队的区别；与 Codex 对照的并行委托方法，见Codex 与 Claude Code 的并行子智能体。
Devin（Cognition）：从“别做”到“统领”
Cognition 在 2025 年 6 月发表了“Don't Build Multi-Agents”，指出并行的执行者在彼此不知道对方判断的情况下工作，会得出相互矛盾的结果。其两条原则是“共享上下文，而且要共享完整的工作过程，而不只是单条消息”和“行动中隐含着判断，判断相互矛盾就会带来糟糕的结果”。
而同一家公司在 2026 年 3 月推出了新功能：Devin 把大任务拆开，交给多个各自在独立虚拟机中运行的 Devin 并行处理。父级 Devin 关注进度，化解冲突并汇总结果。可以理解为它没有放弃并行，而是落在了“由父级承担执行者之间分歧”的形态上。这也与第 4 节“有负责检查的统筹者，错误不易扩散”相吻合。
Cursor：不等执行者也能继续
Cursor 在 2.5 版（2026 年 2 月 17 日）中让子智能体异步运行，父级无需等待即可继续工作。执行者还可以再调用执行者。Anthropic 也写道，统筹者等待执行者完成的同步执行方式会“造成瓶颈”，不让父级等待已成为各家共同的课题。
6. 成本：token 约为聊天的 15 倍
Anthropic 写道，智能体使用的 token 约为聊天的 4 倍，多智能体约为 15 倍（该公司的文章）。套用到自己的用途上，可以这样估算。
估算示例（倍数取自 Anthropic 调研功能的数值，因工作而异）
聊天一次需要 1 万 token 的问题 → 单个智能体约 4 万，多智能体约 15 万 token。
每天处理 100 件的话：聊天 100 万、单智能体 400 万、多智能体 1,500 万 token。再乘以所用模型官方价目表中的单价。
增加的不只是 token
把“会停下的上限”和“参考目标”分开设置
执行者再调用执行者、一旦陷入循环，费用就会一下子膨胀。用 Claude 搭建时，有两类机制不同的上限。
| 上限 | 在哪里设置 | 是否会停下 |
|---|---|---|
| 费用上限 | Claude Agent SDK 的 max_budget_usd（TypeScript 为 maxBudgetUsd） | 会（不再启动新执行者，并结束本次查询） |
| 嵌套深度 | 环境变量 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH（默认 3，设为 1 即不嵌套） | 会（最底层的执行者自己完成工作） |
| 同时运行的数量 | 环境变量 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS（默认 20） | 会（超出上限的执行者不会启动） |
| 任务预算 | Claude API 的 task_budget（测试版，最少 2 万 token） | 不会（模型根据剩余量分配节奏的参考值） |
出处：Agent SDK 的子智能体、Task budgets（2026 年 11 月 12 日确认）。上面 3 个会停下的上限适用于 TypeScript SDK v0.3.219、Python SDK v0.2.127 及以后的版本，更早的版本中有的没有、有的默认值不同。官方说明任务预算是“参考而非强制”，需要确实停下时，应与费用上限或 max_tokens 搭配使用。
7. 是否采用的判定表
把上面的资料归纳起来，判断基本取决于下面 5 个问题。从上往下回答，只要有一个落在“单智能体”一侧，就先用一个智能体来做。
| 问题 | 适合多智能体 | 适合单智能体 | 依据 |
|---|---|---|---|
| 能否把工作拆成独立的部分 | 能（按公司、按资料、按角度） | 后一步由前一步的结果决定 | 金融分析 +80.8%，步骤规划 −39.1%～−70.0% |
| 单智能体已经能解出多少 | 单智能体正确率低 | 单智能体已能解出约 45% 以上 | Google Research 等的论文 |
| 执行者是否需要共享同一上下文 | 各执行者手头的信息就够 | 不看同一上下文就会出现分歧（多数编程） | Anthropic、Cognition |
| 能否装进一个上下文 | 资料太多，单个智能体的上下文装不下 | 单个智能体的上下文装得下 | token 量解释了 80% 的性能波动 |
| 是否值得付出 15 倍的 token | 每件工作价值高（调研、审计、比较报告） | 大量定型处理、需要即时回复的窗口 | Anthropic 的约 15 倍 |
Anthropic 在其构建智能体的指南中也建议，从尽可能简单的方案开始，只在必要时增加复杂度。上手步骤和最小代码示例见如何构建多智能体系统，第一个单智能体的做法见如何构建 AI 智能体。
8. 设计要点与常见的失败类型
① 给执行者交代“目标、输出格式、可用工具、范围”
Anthropic 写道，给执行者的指示一旦含糊，执行者就会误解任务、与其他执行者重复同样的搜索，或漏掉需要的信息。要给每个执行者明确交代(1) 目标、(2) 返回的格式、(3) 可以使用的工具和信息来源、(4) 任务的范围。Claude Agent SDK 的子智能体收不到父级的对话，传给它的只有调用时的指令（官方文档），所以文件路径和已经做出的决定也要写进指令里。
② 指明要挖掘到多深
执行者不擅长自己决定“查到什么程度”。要像第 5 节的表那样写明规模的标准，同时设置推理深度。Claude 的 effort 可以按执行者分别指定，Agent SDK 的执行者定义中也可以从 low 选到 max。简单的执行者设得轻、负责验证的设得深，就能压住成本。
③ 让统筹者承担“检查”的工作
如第 4 节所示，统筹者先检查执行者结果再汇总的集中型，错误扩散远小于不检查的独立型（4.4 倍对 17.2 倍）。在统筹者的指令里加入找出执行者结果之间的矛盾、核实依据后再采用的步骤。
④ 了解失败的类型
加州大学伯克利分校等机构的研究者，从 7 个多智能体系统的 1,600 多份运行记录中，把失败归纳为3 大类、14 种类型（Why Do Multi-Agent LLM Systems Fail?）。复查设计时可以当作检查清单。
| 类别 | 会发生什么 | 对策 |
|---|---|---|
| 设计问题 | 不遵守角色或步骤的指示、重复同样的工作、不知道何时结束 | 在指令中写明角色、范围和结束条件 |
| 执行者之间的偏差 | 前提不一致、不传递必要的信息、无视其他执行者的意见 | 共享完整过程，由统筹者化解分歧 |
| 检查不足 | 中途结束、不检查、检查流于表面 | 设置负责检查的角色（统筹者或验证执行者） |
⑤ 一开始就搭好记录运行情况的机制
多智能体如果追踪不到发生了什么，就无从修复。从一开始就记录每个执行者的输入输出、耗时、token 和调用的工具。关于评估，Anthropic 写道，他们从贴近实际使用的约 20 个问题开始，把评分标准交给 AI 来打分。不必等待大型评估体系，先用少量问题观察变化，才是现实的做法。
9. 各模式在主要 SDK 中的写法
同一种模式，在各 SDK 中的叫法不同。选哪一个（原型速度、生产成熟度、token 用量）的比较交给AI 智能体框架比较，这里只说明第 3 节的各模式对应哪个组件。
| SDK | 编排者–执行者型 | 移交型、流水线型 |
|---|---|---|
| Claude Agent SDK | 用 agents 定义执行者，通过 Agent 工具调用（旧名 Task） | 没有专门组件，流水线由自己的代码依次调用 |
| OpenAI Agents SDK | 用 Agent.as_tool() 把执行者当作工具调用 | 用 handoff 转交主导权，链式和并行用代码搭建 |
| LangGraph | 从统筹者节点分支到执行者节点 | 用节点和边把顺序、分支、循环写成图 |
| Strands Agents（AWS） | 用 Agents as Tools 把执行者当作工具调用 | 用 Swarm 让执行者之间相互移交，用 Graph 或 Workflow 编排顺序 |
| Microsoft Agent Framework | 把多智能体协作的模式作为组件提供 | 以工作流的形式编排顺序 |
Microsoft 已将 AutoGen 的代码仓库归档，不再提供错误修复和安全修复（2026 年 11 月 12 日确认）。新项目被建议使用后继的 Microsoft Agent Framework。各 SDK 的最小代码示例见如何构建多智能体系统。
总结
- 多智能体是多个 AI 分工并行、共同完成一项工作的机制，能越过单智能体的几堵墙：上下文装不下、无法同时推进、做的人和查的人是同一个。
- 模式有编排者–执行者、移交、层级、对等、流水线五种，最常用的是编排者–执行者型。
- 是否有效取决于工作。在可拆分的金融分析上比单智能体高 +80.8%，在依赖顺序的规划上低 39.1%～70.0%，代码修复也没有提升。
- 设置负责检查的统筹者后，错误扩散从独立型的 17.2 倍降到 4.4 倍。
- token 约为聊天的 15 倍（单个智能体约 4 倍）。费用、深度、同时运行数量要用“会停下的上限”来设置。
- 判断的顺序：先用一个智能体做并测量，只把可拆分、且已证明一个智能体不够的部分交给执行者。
FAQ
Q1. 多智能体一定比“聪明的单智能体”更好吗？
不一定。Anthropic 的调研功能比单智能体好 90.2%，但那是在可以拆成独立部分的调研上。在 Google Research 等的实验中，依赖顺序的规划任务上，所有多智能体配置都不如单智能体。关键在于工作能否拆分。
Q2. 多智能体对编程有用吗？
让多个执行者分头写同一个修复，通常效果不好。实验中，在代码修复（SWE-bench Verified）上所有多智能体配置都低于单智能体（−2.1%～−14.9%）。反过来，把调研、审查、运行测试这类独立工作交给执行者，让父级的上下文保持空闲，是 Claude Code 子智能体的典型用法。
Q3. 能否从单智能体逐步过渡到多智能体？
可以。先用一个智能体做出来，测量正确率、token 和耗时；看清哪里上下文装不下、哪里可以并行之后，只把那部分交给执行者。一开始就全部按多智能体设计，就测不出到底是什么在起作用。
Q4. 智能体之间是否有标准通信协议？
在连接智能体与工具、数据的环节，MCP（Model Context Protocol）已成为事实标准。它源自 Anthropic，2025 年 12 月捐赠给 Linux Foundation 旗下的Agentic AI Foundation，并已被 OpenAI、Microsoft、AWS 等采用。智能体之间的通信则有源自 Google 的 A2A（Agent2Agent），同样已移交 Linux Foundation。IBM 发起的 ACP（Agent Communication Protocol）已于 2025 年 8 月并入 A2A。
Q5. 设置了任务预算，就能防止费用失控吗？
仅靠它不行。Claude API 的任务预算是让模型分配节奏的参考值，官方明确说明“不是强制的”。想确实停下，应设置 Agent SDK 的费用上限（max_budget_usd）以及嵌套深度、同时运行数量的上限（第 6 节的表）。
Q6. “子智能体”和“多智能体”是两回事吗？
子智能体是多智能体中编排者–执行者型所用的“执行者”。在 Claude Agent SDK 中，主智能体始终只有一个，只在需要时通过 Agent 工具调用执行者。执行者之间边直接商量边推进的形态（如 Claude Code 的智能体团队），则更接近对等型或混合型。
