怎么判断是否要使用多agent架构

怎么判断是否要使用多agent架构

使用龙虾的人越来越多，龙虾在使用时间长了之后，历史会话信息有些多的时候会导致token消耗增加，同时返回结果也不如以前。那我们是否就必须每个人都需要使用多agent架构呢？今天这里就展开跟大家说说，笔者对Claude的一个多agent的技术分享比较认同，所以今天我们的建议跟这个比较契合，而且在文章后面也会给出这个技术分享的翻译，供大家参阅。

多智能体系统设计建议概览

在开始之前，我们提供关于多智能体系统设计的核心建议，帮助大家快速建立系统性认知。

核心原则

适用场景

在多智能体架构在以下三种场景中能够持续产生正向收益的话，你的系统就是适合多agent的，如果不是建议使用单agent：

1. 上下文保护场景
   • 当单一任务流程中存在多个独立子任务，且各子任务产生大量中间数据
   • 当上下文污染明显影响模型推理质量时
   • 典型案例：客户支持系统同时处理订单查询和技术诊断
2. 并行化场景
   • 当任务可分解为多个相互独立的子任务
   • 当响应时间要求严格，串行处理无法满足需求时
   • 典型案例：调研任务同时调研不同方向的时候
3. 专业化场景
   • 当不同子任务需要截然不同的工具集或领域知识
   • 当通用智能体在特定任务上的工具选择准确率不足时
   • 典型案例：全栈开发系统分设前端、后端智能体

关键考量因素

在决定采用多智能体架构前，请审慎评估以下因素：

决策检查清单

在转向多智能体架构前，请确认以下条件：

• ☐ 已验证单智能体方案确实无法满足需求
• ☐ 能够清晰识别出上下文保护、并行化或专业化的具体需求
• ☐ 已评估并接受额外的Token成本和系统复杂度
• ☐ 具备相应的监控、日志和调试基础设施
• ☐ 团队对多智能体协调机制有充分理解

建议：若以上任一条件不满足，请优先考虑优化现有单智能体方案。

翻译：Building multi-agent systems: When and how to use them

原文作者：Cara Phillips（Paul Chen、Andy Schumeister、Brad Abrams 和 Theo Chu 参与贡献）

尽管单智能体系统能够有效处理大多数企业工作流程，但多智能体架构可以为您的组织释放额外价值。本文将帮助您了解何时以及如何使用它们。

多智能体系统（Multi-agent System）是一种架构，其中多个大语言模型实例在各自独立的对话上下文中运行，并通过代码进行协调。虽然存在多种协调模式（如智能体群集、基于能力的系统和消息总线架构），但本文重点介绍编排者-子智能体模式（Orchestrator-Subagent Pattern）：这是一种层级模型，由主智能体生成并管理针对特定子任务的专业子智能体。该模式提供了一种简洁明了的协调方式，是多智能体系统新手团队的理想起点。我们将在下一篇文章中详细探讨其他模式。（译者注：这个是典型的sub-agent方式的多agent，还有multi-agent方式的多agent。）

目前，多智能体系统常常被应用于单智能体本可表现更佳的场景，尽管随着模型能力的提升，这一判断标准也在不断演进。在 Anthropic，我们曾见证团队耗费数月构建精密复杂的多智能体架构，最终却发现通过改进单智能体的提示词便能实现同等效果。（译者注：所以通常建议大家还是先从单agent模式起步。）

在构建多智能体系统并与生产环境部署团队协作的过程中，我们总结出三种多智能体方案持续优于单智能体的情形：上下文污染导致性能下降时、任务可并行执行时、以及专业化能提升工具选择或任务聚焦度时。在这三种情形之外，协调成本通常会超出收益。

本文将分享如何识别单智能体的局限性、辨别多智能体系统发挥优势的三种场景，以及如何规避常见的实施误区。

1. 从单智能体起步的理由

一个设计精良、配备适当工具的单智能体，其能力远超许多开发者的预期。

多智能体系统会引入额外开销。每增加一个智能体，就意味着多一个潜在的故障点、多一套需要维护的提示词，以及多一个不可预测行为的来源。

我们观察到，不少团队构建了精心设计的多智能体系统——分别设置规划智能体、执行智能体、审核智能体和迭代智能体——最终却发现每次交接都会造成上下文丢失，花费在协调上的 Token 反而比实际执行更多。根据我们的测试，在完成同等任务时，多智能体实现通常消耗的 Token 是单智能体方案的 3 至 10 倍。这些开销源于跨智能体的上下文复制、智能体间的协调消息，以及交接时的结果摘要。

2. 多智能体系统的决策框架

多智能体架构只有在能够解决单智能体无法克服的特定约束时才能体现价值。这意味着，多智能体架构应当保留给那些收益明确、足以证明额外成本合理性的场景。

以下模式代表了我们持续观察到正向投资回报的情形。

2.1 上下文保护（Context Protection）

大语言模型的上下文窗口是有限的，随着上下文的增长，响应质量可能会下降。当智能体的上下文中积累了来自某一子任务的信息，而这些信息与后续子任务无关时，便会发生上下文污染（Context Pollution）。子智能体提供了隔离机制——每个子智能体都在专注于其特定任务的独立干净上下文中运行。

设想一个客户支持智能体，它需要在诊断技术问题的同时检索订单历史。如果每次订单查询都向上下文中添加数千个 Token，智能体对技术问题的推理能力就会下降。

单智能体方案：

智能体必须在维护 2000 多个无关订单历史 Token 的同时推理技术问题，这分散了注意力并降低了响应质量。

多智能体方案：

订单查询智能体处理完整的订单历史并提取摘要。主智能体仅接收其实际所需的 50-100 个 Token，使上下文保持聚焦。

上下文隔离在以下情况下最为有效：子任务产生大量上下文（超过 1000 个 Token）但其中大部分信息与主任务无关时；子任务定义清晰、具有明确的信息提取标准时；以及需要在使用前进行过滤的查询或检索操作时。（译者注：在龙虾使用过程中，一个会话多个主题来回切换，而且个别主题会产生大量的内容的时候，就会有这种问题存在。）

2.2 并行化（Parallelization）

并行运行多个智能体使您能够探索比单个智能体更大的搜索空间。这种模式在搜索和研究任务中已被证明特别有价值。

我们的研究特性（Research feature）采用了这种方法。主智能体分析查询请求，并生成多个子智能体以并行研究不同的维度。每个子智能体独立搜索，然后返回提炼后的发现。多智能体搜索相比单智能体方案展现出显著的准确性提升，因为它能够在更大的信息空间中进行探索。

核心实现是将问题分解为独立的维度，并发运行子智能体，然后综合结果。

这种覆盖范围的提升是有代价的。对于等效任务，多智能体系统消耗的token数量通常是单智能体方法的3到10倍。这是因为每个智能体都需要自己的上下文，智能体之间必须交换信息进行协调，而且当结果在智能体之间传递时，还必须进行总结。尽管与顺序执行所有工作相比，并行处理有助于减少总执行时间，但由于总计算量的大幅增加，多智能体系统所需的总体时间反而通常比单智能体系统更长。

并行处理的主要优势在于其全面性，而非速度。当您需要搜索广阔的信息空间或从多个角度探究一个复杂问题时，与在自身上下文限制内工作的单个智能体相比，并行智能体可以覆盖更广的范围。这种权衡是用更高的token使用量和通常更长的总执行时间，来换取更全面的结果。

（译者注：并行化在以下情况下最为有效：子任务真正独立、无共享状态需求时；任务量足够大、并行处理能带来显著时间节省时；以及结果可以无需复杂协调逻辑即可合并时。这种调研类收集信息并整理类任务比较适合采用这种模式。）

2.3 专业化（Specialization）

不同的任务有时受益于不同的工具集、系统提示词或专业领域。与其为单个智能体提供数十个工具的访问权限，不如让配备与其职责匹配的聚焦工具集的专业化智能体来提高可靠性。

2.3.1工具集专业化

当一个智能体拥有过多工具时，性能会下降。三个信号表明工具专业化会有所帮助：

1. 数量：拥有过多工具（通常超过 20 个）的智能体难以选择合适的工具。

2. 领域混淆：当工具跨越多个无关领域（数据库操作、API 调用、文件系统操作）时，智能体会混淆哪个领域适用于给定任务。

3. 性能下降：添加新工具会降低现有任务的性能，这表明智能体已达到其工具管理能力的极限。

2.3.2系统提示词专业化

不同的任务有时需要不同的角色、约束或指令，这些内容在合并时会发生冲突。客户支持智能体需要同理心和耐心；代码审查智能体需要精确和批判性。合规检查智能体需要严格遵守规则；头脑风暴智能体需要创造性的灵活性。当单个智能体必须在冲突的行为模式之间切换时，将其拆分为具有定制系统提示词的专业化智能体可以产生更一致的结果。

2.3.3领域专家专业化

某些任务受益于深度的领域背景，这可能会让通用智能体不堪重负。法律分析智能体可能需要关于判例法和监管框架的大量背景。医学研究智能体可能需要关于临床试验方法的专业知识。与其将所有领域背景加载到单个智能体中，不如让专业化智能体携带与其特定职责相关的聚焦专业知识。

示例：多平台集成。考虑一个集成系统，智能体需要跨 CRM、营销自动化和消息平台工作。每个平台都有 10-15 个相关的 API 端点。

拥有 40+ 工具的单智能体经常难以正确选择，容易混淆不同平台上的类似操作。拆分为具有聚焦工具集和定制提示词的专业化智能体可以解决选择错误。

这种模式模拟了有效的专业协作——拥有与其角色匹配工具的专家比试图在所有领域保持专业能力的通才协作更为高效。然而，专业化也引入了路由复杂性。编排者必须正确分类请求并委派给合适的智能体，错误的路由会导致糟糕的结果。维护多个专业智能体也增加了提示词维护的开销。专业化在领域边界清晰、路由决策明确时效果最佳。

3. 超越单智能体架构的信号

除了上述通用框架外，某些具体信号表明单智能体模式已经无法满足需求：

这些阈值将随着模型的改进而变化。当前的限制代表的是实践指南，而非根本性约束。（译者注：对于单agent的可以重复利用压缩技术，对上下文进行压缩管理，甚至起静默定时任务检查和压缩管理。）

4. 以上下文为中心的分解原则

在采用多智能体架构时，最重要的设计决策是如何在智能体之间划分工作。我们观察到团队经常错误地做出选择，导致协调开销抵消了多智能体设计的收益。

核心见解是在分解工作时采用以上下文为中心 (context-centric) 的视角，而非以问题为中心 (problem-centric) 的视角。

这一原则源于对多智能体系统故障模式的观察。当智能体按问题类型拆分时，它们会陷入“传声筒游戏”，信息在每次移交中不断降级。在一个按软件开发角色（规划者、执行者、测试者、审查者）专业化的实验中，子智能体在协调上花费的 Token 比在实际工作上花费的还要多。

有效的分解边界包括：

1 独立的研究路径：调查“亚洲市场趋势”与“欧洲市场趋势”可以并行进行，无需共享上下文。

2 具有清晰接口的独立组件：有了定义良好的 API 契约，前端和后端工作可以并行进行。

3 黑盒验证：一个仅需要运行测试并报告结果的验证器不需要实现上下文。

有问题的分解边界包括：

1 同一工作的顺序阶段：同一功能的规划、实现和测试共享过多的上下文。

2 紧耦合组件：需要不断来回沟通的组件属于同一个智能体。

3 需要共享状态的工作：需要频繁同步理解的智能体应该保持在一起。

5. 验证子智能体模式

一种在各领域始终表现良好的多智能体模式是验证子智能体。这是一个专门的智能体，其唯一职责是测试或验证主智能体的工作。

值得注意的是，更强大的编排者模型（如 Claude Opus 4.5）越来越能够直接评估子智能体的工作，而无需单独的验证步骤。然而，在使用能力较弱的编排者、验证需要专业工具或您希望在工作流中强制执行显式验证检查点时，验证子智能体仍然很有价值。

验证子智能体之所以成功，是因为它们避开了“传声筒游戏”问题。验证本质上只需要极少的上下文转移，因此验证器可以对系统进行黑盒测试，而无需了解其构建的完整历史。（译者注：异源大模型的验证agent模式是比较通用和有效的。）

。

5.1 实现方式

主智能体完成一个工作单元。在继续之前，它生成一个验证子智能体，并提供待验证的产物、明确的成功标准以及执行验证的工具。

验证器不需要理解产物为何被这样构建。它只需要确定产物是否符合指定的标准。

5.2 应用场景

验证子智能体对以下场景非常有效：

1 质量保证：运行测试套件、进行代码静态检查、根据 Schema 验证输出。

2 合规检查：验证文档是否符合政策要求，根据规则检查输出。

3 输出验证：在交付前确认生成的内符合规范。

4 事实核查：让独立智能体验证生成内容中的主张或引用。

5.3 “过早胜利”问题

验证子智能体最显著的故障模式是在没有彻底测试的情况下就将输出标记为通过。验证器运行一两个测试，观察到它们通过，然后就宣布成功。

缓解策略包括：

1 具体标准：指定“运行完整测试套件并报告所有失败”，而非“确保它能工作”。

2 全面检查：要求验证器测试多个场景和边缘情况。

3 负面测试：指示验证器尝试应该失败的输入，并确认它们确实失败。

4 明确指令：指令“在标记为通过之前，你必须运行完整的测试套件”至关重要。如果没有对全面验证的明确要求，验证智能体往往会走捷径。

6. 前进方向

多智能体系统功能强大，但并非普遍适用。在增加多个协调智能体的复杂性之前，请确认：

1. 存在真正的约束：多智能体能解决单智能体无法解决的问题，如上下文限制、并行化机会或专业化需求。

2. 分解遵循上下文，而非问题类型：按工作所需的上下文进行分组，而非按工作类型。

3. 存在清晰的验证点：子智能体可以在不需要完整上下文的情况下验证工作。

我们的建议:从能奏效的最简单方法开始，仅在有证据支持时才增加复杂性。

参考文献

[1] Anthropic, 2026年1月23日. Building multi-agent systems: When and how to use them. https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them