何时该用，何时该放弃

多智能体系统是一种让多个大语言模型实例在各自独立的对话上下文中运行、并通过代码协调配合的架构。每个智能体负责任务的特定切片——例如子智能体负责信息检索，编排者负责整体规划——这种分工既保护了上下文完整性，也支持并行作业和专业化分工，是单一智能体难以持续维持的能力组合。目前存在多种协调模式，包括智能体群、基于能力的系统和消息总线架构，但编排者-子智能体的层级模型是新团队最易上手的起点。

在考虑引入多智能体之前，应当充分挖掘单智能体的潜力。一个配备合适工具、经过精心设计的单智能体，往往能完成远超开发者预期的任务。多智能体系统引入了额外开销：每增加一个智能体，就意味着多一个潜在故障点、多一套需要维护的提示词、多一个产生意外行为的来源。Anthropic 观察到，一些团队为规划、执行、审查和迭代分别设置独立智能体，结果却因每次交接时上下文丢失而受损，协调本身消耗的 token 甚至多于实际执行。

第一个适合引入多智能体的场景是上下文污染。大语言模型的上下文窗口有限，随着上下文增长，响应质量会下降。当某个子任务产生的信息大量堆积在上下文中，却对后续子任务毫无用处时，上下文污染便会发生。以客户支持场景为例：若每次查询订单都向上下文追加数千个 token 的历史记录，智能体在诊断技术问题时的推理能力就会被稀释。子智能体方案让订单查询在独立上下文中完成，仅将 50 到 100 个 token 的精简摘要注入主智能体，使主上下文保持聚焦。

第二个适用场景是并行化。让多个智能体同时运行，可以覆盖单一智能体无法触及的更大搜索空间，在搜索和研究类任务中尤为有效。编排智能体分析查询后，同时派生多个子智能体从不同维度并行探索，各子智能体独立检索后返回提炼结果，最终由编排者汇总。Anthropic 研究团队在构建内部多智能体研究系统时已验证了这一模式的价值，并行化带来的效率提升在信息密集型任务中尤为显著。

第三个场景是专业化分工。当不同子任务需要截然不同的工具集或推理风格时，让专门的子智能体各司其职，能够改善工具选择的精准度和任务聚焦程度。值得注意的是，上下文隔离最有效的前提是：子任务产生的上下文体量较大（超过 1000 个 token），但其中大部分信息对主任务无关；子任务定义清晰，有明确的信息提取标准；以及需要过滤后才能使用的查找或检索操作。在不满足上述条件的情况下，协调成本通常会超过收益，此时应坚持使用单智能体方案。

要点

• 多智能体系统通常比单智能体消耗多 3 到 10 倍的 token，引入前应先充分优化单智能体
• 上下文污染、任务并行化、专业化分工是多智能体架构能持续带来正向回报的三种核心场景
• 编排者-子智能体的层级模式是新团队进入多智能体领域最易上手的起点
• 上下文隔离的关键在于子智能体只向主智能体返回精简摘要，而非完整的原始上下文
• 许多团队耗费数月搭建的复杂多智能体系统，最终被更好的单智能体提示词所替代