多智能体不是为了制造更多 Agent，而是为了增加彼此隔离的执行边界。

先说结论

判断要不要使用多智能体，不应该先问：

这个任务复杂吗？

而应该问：

更好的提示词、工具搜索和上下文压缩，能不能在一个执行循环里解决它？

如果能，单智能体通常是更简单、成本更低的选择。

如果问题已经不再是“模型不知道怎么做”，而是下面这些执行层面的限制：

• 多个任务需要真正并发；
• 上下文需要隔离，而不是简单压缩；
• 不同任务需要不同工具、权限或行为规则；
• 一个长任务不能阻塞后续指令；
• 任务需要独立失败、重试和恢复；
• 需要一个执行者之外的角色进行独立验证；

那么多智能体才开始具有真正的工程价值。

一句话概括：

单智能体优化解决的是“一个执行循环怎样做得更好”，多智能体解决的是“一个执行循环不够用了以后，怎样增加多个相互独立的控制边界”。

一、先明确什么算多智能体

这里说的 Agent，不只是一次大模型调用，而是一个能够持续完成任务的执行单元：

接收目标
  ↓
理解当前状态
  ↓
选择工具或行动
  ↓
获取结果
  ↓
继续判断，直到任务完成

一个 Agent 通常包含：

• 大语言模型；
• 系统提示词；
• 工具集合；
• 上下文和任务状态；
• 一个持续执行的循环。

多智能体系统，则是多个相对独立的 Agent，通过代码、消息或任务调度机制进行协作。

关键不在于调用了多少次模型，也不在于写了多少个角色名称，而在于是否出现了多个独立的执行上下文和决策循环。

一个 Agent 连续调用搜索、文件、数据库工具
             ≠
          多智能体

这仍然是一个单智能体，只是工具比较多。

真正的多智能体更接近：

Router / 主智能体
  ├── Research Agent
  ├── Coding Agent
  ├── Verification Agent
  └── Data Agent

每个子智能体有自己的任务、上下文、工具和输出，主智能体负责拆分、协调和汇总。

二、单智能体优化能解决什么

在讨论多智能体之前，应该先充分使用单智能体的能力。

1. 更好的提示词

提示词可以改善：

• 任务步骤是否清楚；
• 输出格式是否稳定；
• Agent 是否会主动检查结果；
• 遇到不确定信息时是否会停下来；
• 是否会遵守权限和操作边界。

很多所谓“需要拆成多个 Agent”的问题，实际上只是系统提示词没有说清楚。

2. 工具搜索

当 Agent 拥有几十甚至上百个工具时，把所有工具定义都放进上下文，会占用大量 Token，也会增加误选工具的概率。

工具搜索可以让 Agent 根据当前任务按需发现工具。

适合解决的问题是：

工具太多，不知道怎么选

它不能自动解决：

两个长任务需要同时运行

3. 上下文压缩

当对话很长时，可以把历史消息压缩成摘要，或者按需检索过去的记录。

适合解决的问题是：

历史内容太多，无法全部保留

但它不能保证：

每个子任务都拥有完整、干净、互不干扰的上下文

4. 结构化输出和流程约束

通过 JSON Schema、固定的工具参数、状态机或检查清单，可以让单智能体的行为更稳定。

如果只是需要按步骤做事，不一定需要多个 Agent。

因此，多智能体之前的合理顺序通常是：

改提示词
  ↓
精简工具
  ↓
工具搜索
  ↓
上下文压缩或检索
  ↓
结构化输出和流程约束
  ↓
仍然无法满足时，再考虑多智能体

三、真正需要多智能体的五种情况

情况一：需要强上下文隔离，而不是简单压缩

上下文污染并不一定要求两个任务同时执行。

它指的是：

当前上下文里积累了大量对下一步推理无用的信息。

例如，一个客服 Agent 为了诊断技术问题，先查询了用户的完整订单历史：

用户问题
+ 订单详情
+ 历史购买记录
+ 物流记录
+ 售后记录
+ 技术诊断信息

这些信息可能都与用户有关，但大部分订单细节对“诊断技术问题”没有帮助。

可以把订单查询交给独立 Agent：

订单查询 Agent
  ↓
读取完整订单历史
  ↓
提取订单状态、购买日期、物流状态
  ↓
客服 Agent 只接收必要摘要

这里引入多智能体的原因不是摘要本身，而是：

• 子任务需要独立阅读和筛选大量原始信息；
• 主任务不应该承担这些中间过程；
• 主上下文只接收经过加工的少量结果；
• 子任务的失败和重试不会污染主任务。

上下文压缩适合“历史太长”，上下文隔离适合“这部分工作本来就应该独立完成”。

还要区分两个不同问题：

问题	表现	主要原因
上下文污染	无关信息太多，干扰判断	信息没有按任务隔离
上下文丢失	重要条件不见了	截断、压缩、摘要不完整或交接失败

多智能体可以缓解上下文污染，但也可能引入新的上下文丢失。

因为子智能体交给主智能体的往往只是摘要。如果交接协议设计得不好，真正重要的约束可能在交接时消失。

所以多智能体不是自动解决记忆问题，而是把问题变成：

如何在独立上下文之间传递正确、完整又足够简洁的信息？

情况二：需要真正的并发执行

工具搜索只能帮助一个 Agent 选择一个工具，不能让一个执行循环变为多个执行循环。

假设要排查一次线上故障：

前端：请求参数、控制台、页面状态
后端：接口日志、异常堆栈、业务逻辑
网络：状态码、超时、代理、DNS
数据库：查询耗时、连接池、数据状态

这些调查可以在第一轮同时进行：

前端 Agent ─┐
后端 Agent ─┼─> 汇总 Agent
网络 Agent ─┤
数据库 Agent┘

但并发并不代表整个排障过程都可以并行。

更合理的流程是：

并行收集证据
  ↓
集中关联和判断
  ↓
按依赖顺序修复
  ↓
统一验证

例如，前端发现请求字段错误，后端接口却正常，网络也确认请求成功到达。最终仍需要一个汇总角色，把多个子任务的证据放在一起判断。

判断子任务是否适合并行，可以看四件事：

1. 信息是否相对独立；
2. 是否不共享可变状态；
3. 是否能独立产出阶段性结果；
4. 是否允许最后再统一汇总。

如果一个子任务必须等另一个子任务得出结论才能开始，就不适合机械地并行。

情况三：需要不同的工具、权限或行为规则

一个 Agent 也可以通过提示词切换多种角色，但长期运行时，角色之间可能发生冲突。

例如：

客服 Agent：耐心、委婉、安抚用户
安全审计 Agent：怀疑、严格、主动寻找漏洞
代码修改 Agent：拥有写文件权限
代码审查 Agent：只能读，不能修改

需要的不是四段更长的提示词，而是四种不同的边界：

• 不同的工具集合；
• 不同的文件或数据权限；
• 不同的上下文；
• 不同的输出约束；
• 不同的失败处理方式。

工具搜索解决的是“工具太多”，权限隔离解决的是“这个 Agent 根本不应该拥有这些工具”。

这是多智能体比提示词切换更可靠的地方之一。

情况四：长任务不能阻塞新指令

这是很多人在日常使用 AI 时最直观的痛点。

传统单会话可能是：

用户发出任务 A
  ↓
Agent 长时间执行任务 A
  ↓
用户想追加任务 B
  ↓
只能等待、打断，或者另开一个对话

如果所有任务都绑定在同一个会话和执行循环中，就会出现：

• 新任务无法立即开始；
• 新指令混入旧任务上下文；
• 打断旧任务后难以恢复；
• 两个任务互相污染；
• 一个长任务占用整个 Agent session。

Router-Worker 架构可以变成：

Router：继续接收和判断新消息
  ├── Worker A：后台执行任务 A
  └── Worker B：立即执行任务 B

这里引入多智能体的根本原因是：

一个执行生命周期无法同时满足持续接收新任务和后台执行长任务的需求。

即使把单 Agent 的提示词写得再好，也不会自动改变执行循环被一个长任务占用的事实。

情况五：需要独立失败、重试和恢复

上下文压缩不能解决：

任务 A 失败
任务 B 仍然需要继续
任务 C 稍后重试

如果所有任务共享一个会话和状态，可能出现：

• 一个任务失败影响后续任务；
• 重试时带入错误上下文；
• 长任务中断后无法恢复；
• 一个工具异常污染整个会话；
• 无法单独停止某个任务。

独立 Worker 可以分别拥有：

• 会话；
• 工作目录；
• 任务状态；
• 超时和重试次数；
• 失败处理策略；
• 恢复入口。

这类问题属于任务生命周期和故障隔离，不是单纯的模型能力问题。

四、验证子智能体：一种容易落地的模式

Claude 的文章特别强调“验证子智能体”。

主智能体完成工作后，把产物和明确的验收标准交给验证 Agent：

主智能体完成代码修改
  ↓
验证 Agent 只接收：
    1. 修改后的产物
    2. 验收标准
    3. 测试工具
  ↓
运行完整测试并报告结果

这个模式有效，是因为验证通常不需要完整理解“工作是怎么一步步完成的”，只需要判断结果是否满足标准。

它适合：

• 运行测试和代码检查；
• 校验输出格式；
• 对照规则检查合规性；
• 验证事实和引用；
• 在交付前进行独立审查。

但验证 Agent 很容易出现“提前庆祝”问题：

运行了一两个测试都通过
  ↓
直接宣布全部成功

解决办法不是增加更多角色，而是把验收标准写具体：

• 运行完整测试套件；
• 列出全部失败项；
• 覆盖正常、边界和失败场景；
• 只有所有检查通过才标记 PASSED；
• 失败时返回明确证据，而不是笼统结论。

五、多智能体最容易犯的错：按角色拆，而不是按上下文拆

很多团队会这样设计：

规划 Agent
  ↓
编码 Agent
  ↓
测试 Agent
  ↓
审查 Agent

表面上分工明确，实际经常变成“电话游戏”：

规划 Agent 解释设计
  ↓
编码 Agent 重新理解
  ↓
测试 Agent 重新猜测需求
  ↓
审查 Agent 再次追问背景

每次交接都可能丢失上下文，协调消耗的 Token 甚至超过真正执行任务的 Token。

更合理的做法是按上下文边界拆分：

一个 Agent 负责一个功能及其测试
另一个 Agent 负责接口独立的另一个功能
独立验证 Agent 做黑盒验收

或者：

研究亚洲市场
研究欧洲市场
最后统一汇总

因此有一个很重要的原则：

按上下文边界拆分任务，而不是按职业角色拆分任务。

适合拆分的边界通常包括：

• 相互独立的研究路径；
• 接口清晰的独立组件；
• 只需要运行测试并报告结果的黑盒验证；
• 不需要共享可变状态的并行调查。

不适合拆分的边界包括：

• 同一个功能的规划、实现和测试；
• 需要频繁来回沟通的紧耦合模块；
• 必须持续同步理解的共享状态；
• 每个步骤都依赖上一步完整过程的顺序任务。

六、任务级多智能体与系统级多智能体

Claude 的文章和 DSH Super-Agent 的设计并不矛盾，它们关注的层次不同。

Claude：任务级架构

Claude 的文章主要回答：

一个任务内部，什么时候应该拆成多个 Agent？

重点是：

• 上下文隔离；
• 并行探索；
• 工具和提示词专业化；
• 独立验证；
• 防止按角色拆分导致的协调开销。

DSH Super-Agent：系统级架构

DeepSeek Harness（DSH）的 Super-Agent 设计进一步回答：

多个 Agent 如何组成一个长期运行、可恢复的系统？

它的核心结构可以概括为：

Router：长期运行，负责监听、判断和调度
Workers：按需创建，负责独立执行具体任务

DSH 关注的不只是一个任务，还包括：

• 外部事件如何进入系统；
• 哪些请求有权限触发工作；
• 任务如何排队和分配；
• Worker 如何获得独立上下文和执行环境；
• 多个任务如何并发；
• Worker 中断后如何恢复；
• 失败如何重试；
• 如何避免重复处理事件；
• 什么时候应该通知人；
• 如何避免 Agent 制造大量注意力噪声。

DSH 官方原型强调一个原则：

尽可能少地占用人的注意力，同时尽可能多地创造价值。

所以它的“自主”不是无条件自动执行，而是：

自动感知
+ 权限约束
+ 任务调度
+ 独立执行
+ 故障恢复
+ 人类注意力管理

两篇文章的关系可以表示为：

Claude：为什么要把一个任务拆成多个执行单元？
DSH：拆开以后，怎样让这些执行单元长期稳定运行？

一个偏任务执行质量，一个偏系统运行可靠性。

七、一个实用的决策框架

遇到复杂任务时，可以依次问下面几个问题。

第一步：单 Agent 优化是否足够？

先检查：

• 提示词是否清楚；
• 工具是否可以精简；
• 是否需要工具搜索；
• 是否可以压缩或检索历史上下文；
• 是否可以用结构化输出约束结果。

如果这些手段已经能解决，就不需要多智能体。

第二步：子任务是否具有独立的上下文？

如果子任务必须持续共享当前状态、频繁来回沟通，或者每一步都依赖上一步的完整过程，优先放在同一个 Agent 中。

第三步：子任务是否可以真正并行？

只有能够独立观察、独立执行、独立报告，最后再统一汇总的任务，才适合并行。

第四步：是否需要不同的权限和工具边界？

如果某个步骤本就不应该拥有写权限、数据库权限或外部发送权限，使用独立执行单元通常比依赖提示词自我约束更可靠。

第五步：是否需要独立的生命周期？

如果任务需要：

• 长时间后台执行；
• 中途接收新任务；
• 单独停止；
• 单独重试；
• 中断后恢复；
• 独立计算资源；

就应该考虑独立 Worker，而不仅是一个普通函数调用。

第六步：是否存在低成本的独立验证点？

如果验证只需要产物和验收标准，不需要完整执行历史，就适合使用验证子智能体。

八、什么时候不应该使用多智能体

下面这些情况通常不值得拆分：

• 一个更强的提示词就能解决；
• 任务需要连续、密集、双向的上下文；
• 子任务之间频繁修改同一状态；
• 主要工作量是等待模型或工具返回；
• 拆分后仍然需要不断同步信息；
• 没有明确的任务边界和交付格式；
• 团队无法承担多个提示词、工具和权限的维护成本。

Claude 的文章提到，多智能体实现通常比单智能体消耗更多 Token，文中给出的工程观察范围是等价任务的 3 到 10 倍。这个数字不应被理解为普适定律，但它提醒我们：

多智能体会同时增加模型调用、上下文复制、消息传递和结果汇总的成本。

更常见的情况是，多智能体提高的是覆盖面和执行边界的灵活性，不一定降低总延迟。

并行可以减少等待时间，但更多 Agent、更多 Token 和更多协调，也可能让总计算时间变长。

九、最终判断

可以把核心判断压缩成下面几句话：

1. 多智能体不是模型能力的简单叠加。
2. 更好的提示词、工具搜索和上下文压缩，解决的是单个执行循环内部的问题。
3. 多智能体解决的是并发、上下文隔离、权限隔离、任务生命周期、故障恢复和非阻塞运行的问题。
4. 上下文隔离和上下文压缩不是一回事：前者拆开处理边界，后者压缩已有历史。
5. 上下文污染和上下文丢失也不是一回事：前者是无关信息太多，后者是重要信息不足或交接失败。
6. 应该按上下文边界拆分任务，尽量避免把同一功能的规划、实现、测试和审查拆成互相反复解释的角色。
7. 对单篇资料学习、短问答这类连续理解任务，单智能体通常已经足够；对长期运行、多任务并发和不同权限边界，才更需要多智能体。

最实用的判断仍然是一句话：

如果一个单智能体加上更好的提示词、工具搜索和上下文压缩就能解决问题，就先不要引入多个智能体；当问题变成多个独立执行生命周期如何并发、隔离、恢复和协作时，多智能体才有真正的必要。

参考资料

1. Cara Phillips et al. Building multi-agent systems: When and how to use them. Claude, 2026-01-23.
   https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them

2. DeepSeek Harness. Exploring Super-agent Design: Towards a More Autonomous Agent System.
   官方研究原型：https://github.com/deepseek-ai/dsh-superagent-prototype

3. DeepSeek Harness Team. dsh-superagent. GitHub, MIT License.
   https://github.com/deepseek-ai/dsh-superagent-prototype