随着业务场景不断深入，问题复杂度也在不断提升，与之匹配的大模型应用架构也在不断进化，从RAG到Agent，再到Multi Agent，系统复杂度不断提高。
借鉴人类社会和组织结构，多智能体系统的核心在于如何让 AI 能像团队一样协作，分解目标，合理分工、各司其职，从而高效解决复杂、开放式的大规模任务。
想要系统学习的读者，推荐本人新书：
近日，Anthropic团队发表了一篇新博文《How we built our multi-agent research system（我们如何构建多智能体研究系统）》，他们分享了其在开发deep research功能时总结的多智能体构建的经验。
在此之前，他们也分享过他们在Rag及Agent的建议。
Anthropic提出的Contextual RAG开源实现Open Contextual RAG来了
Anthropic发文分享“如何高效构建Agent”，从简单到复杂带你体会Agent应用架构的真谛
Anthropic 的 Research 系统采用“编排者-工作者（orchestrator-worker）”模式：主智能体负责整体规划和任务分解，多个子智能体并行执行具体子任务。
用户提交查询后，主智能体分析问题、制定策略，并生成多个子智能体，分别探索不同方向。子智能体像智能过滤器一样，利用搜索工具收集信息，最后将结果汇总给主智能体，由其整合成最终答案。
与传统的 RAG（检索增强生成）不同，Anthropic 的多智能体架构采用多步动态搜索，能根据中间发现不断调整策略，生成高质量答案。
在开发过程中，他们总结了8个多智能体系统的设计原则：
-
像智能体一样思考
用模拟和可视化工具观察智能体决策，及时发现和修正失败模式，理解提示词对行为的影响。 -
教会主控智能体如何分工
主智能体需为每个子智能体分配清晰目标、输出格式、工具指引和任务边界，避免重复或遗漏。 -
根据任务复杂度分配资源
在提示词中嵌入“规模规则”：简单任务用少量智能体和工具调用，复杂任务用更多资源，防止资源浪费或过度投入。 -
工具设计与选择至关重要
工具接口要像人机界面一样清晰，描述明确，避免误用。智能体需先评估所有可用工具，匹配用户意图选择最合适的工具。 -
让智能体自我改进
利用大模型自身能力优化提示词和工具描述，通过“工具测试智能体”不断发现和修正工具使用中的问题。 -
先广后深
搜索策略应先用宽泛查询探索全局，再逐步聚焦细节，避免一开始就陷入死胡同。 -
引导思考过程
通过“扩展思考模式”让智能体显式规划、评估和调整策略，提升适应性和推理能力。 -
并行工具调用极大提升效率
主智能体和子智能体都应并行调用工具，显著缩短研究时间，提升覆盖面和深度。
以及评测与工程化的6条实践经验：
-
结果导向评测：关注最终结果是否正确，而非过程是否完全按预设执行。 -
LLM 自动评测结合人工检查：用大模型自动打分，人工补充发现边界问题，快速迭代优化。 -
状态管理与错误恢复：智能体需持久化状态，优雅处理错误，不能简单重启。 -
灰度部署与升级：采用渐进式部署，避免影响正在运行的智能体。 -
长对话上下文管理：用摘要、外部记忆等机制防止上下文溢出。 -
子智能体直接产出结构化结果：如代码、报告等，减少信息损失和 Token 消耗。
该系统最终表现也十分出色，在内部评估中比最强大的单智能体模型（Claude Opus 4）高出 90.2%。它再一次证明：构建强大的 AI Agent 系统，不单单是算法和模型的胜利，更是工程化、系统化的胜利。
对于想要深入了解的读者，可以阅读原文翻译：
Claude 现在具备了研究能力，使其能够搜索网络、Google Workspace 以及任何集成应用，以完成复杂的任务。
这个多智能体系统从原型到生产的历程，让我们在系统架构、工具设计和提示工程方面学到了至关重要的经验。一个多智能体系统由多个智能体（在循环中自主使用工具的 LLM）协同工作。我们的“研究”功能包含一个主导智能体，它根据用户查询来规划研究流程，然后使用工具创建并行的子智能体，同时搜索信息。多智能体系统在智能体协调、评估和可靠性方面引入了新的挑战。
本文将详细分析对我们行之有效的原则——我们希望您在构建自己的多智能-体系统时会发现它们很有用。
多智能体系统的优势
研究工作涉及开放式问题，在这类问题中，很难预先预测所需的步骤。你无法为探索复杂主题硬编码一个固定的路径，因为这个过程本质上是动态且依赖于路径的。当人们进行研究时，他们倾向于根据新发现不断更新自己的方法，并跟进调查过程中出现的线索。
这种不可预测性使得 AI 智能体特别适合研究任务。研究工作要求在调查展开时能够灵活地调整方向或探索切题的关联信息。模型必须自主运行多轮，根据中间结果来决定追求哪个方向。线性的、一次性的处理流程无法胜任这些任务。
搜索的本质是压缩：从浩瀚的语料库中提炼出洞见。子智能体通过在各自的上下文窗口中并行操作来促进这种压缩，它们在为主要研究智能体浓缩最重要信息（token）之前，同时探索问题的不同方面。每个子智能体还提供了关注点分离（separation of concerns）——拥有不同的工具、提示和探索轨迹——这减少了路径依赖，并实现了彻底、独立的调查。
一旦智能达到某个阈值，多智能体系统就成为扩展性能的重要途径。例如，尽管在过去10万年中，个体人类的智力没有变得更聪明，但在信息时代，由于我们的集体智能和协调能力，人类社会的能变得指数级强大。即使是通用智能体，在作为个体行动时也面临限制；而智能体群体可以完成远超个体的工作。
我们的内部评估显示，多智能体研究系统在涉及同时进行多个独立方向探索的广度优先查询方面表现尤其出色。我们发现，在一个由 Claude Opus 4 担任主导智能体、Claude Sonnet 4 担任子智能体的多智能体系统中，其在我们内部研究评估上的表现比单智能体的 Claude Opus 4 高出 90.2%。例如，当被要求找出标普500信息技术行业中所有公司的董事会成员时，多智能体系统通过将任务分解给子智能体找到了正确答案，而单智能体系统则因缓慢的顺序搜索而未能找到答案。
多智能体系统之所以有效，主要是因为它们有助于投入足够的令牌（token）来解决问题。在我们的分析中，有三个因素解释了 BrowseComp 评估（测试浏览智能体定位难寻信息的能力）中 95% 的性能差异。我们发现，仅令牌使用量这一个因素就能解释 80% 的差异，另外两个解释性因素是工具调用次数和模型选择。这一发现验证了我们的架构，该架构将工作分配给具有独立上下文窗口的智能体，从而增加了并行推理的能力。最新的 Claude 模型在令牌使用效率上起到了巨大的放大作用，因为升级到 Claude Sonnet 4 带来的性能提升，比在 Claude Sonnet 3.7 上将令牌预算翻倍还要大。多智能体架构能有效地扩展令牌使用量，以应对超出单个智能体能力极限的任务。
但这里也有一个缺点：在实践中，这些架构会快速消耗令牌。我们的数据显示，智能体通常比聊天交互多用约 4 倍的令牌，而多智能体系统则比聊天多用约 15 倍的令牌。为了实现经济上的可行性，多智能体系统需要用于那些任务价值足够高，能够支付得起性能提升所带来的成本的场景。此外，一些要求所有智能体共享相同上下文或智能体之间存在许多依赖关系的领域，目前并不适合多智能体系统。例如，大多数编码任务中真正可并行的任务比研究要少，而且 LLM 智能体在与其他智能体进行实时协调和授权方面还不够出色。我们发现，多智能体系统在涉及大量并行化、信息量超过单个上下文窗口、以及与众多复杂工具交互的高价值任务中表现卓越。
“Research”功能架构概览
我们的Research系统采用了一种多智能体架构，遵循编排者-工作者模式（orchestrator-worker pattern），即一个主导智能体协调整个流程，同时将任务委派给并行的专用子智能体。
多智能体架构的运作流程：用户查询流经一个主导智能体，该智能体创建专门的子智能体以并行搜索不同方面的信息。
当用户提交查询时，主导智能体会分析它，制定策略，并生成子智能体以同时探索不同方面。如上图所示，子智能体充当智能过滤器，通过迭代使用搜索工具收集信息（此案例中是关于2025年的AI智能体公司），然后将公司列表返回给主导智能体，以便其汇总最终答案。
使用检索增强生成（RAG）的传统方法采用静态检索。也就是说，它们获取一组与输入查询最相似的文本块，并用这些文本块生成响应。相比之下，我们的架构使用多步搜索，动态地寻找相关信息，适应新发现，并分析结果以形成高质量的答案。
流程图展示了我们的多智能体研究系统的完整工作流。当用户提交查询时，系统会创建一个 LeadResearcher（主导研究员）智能体，进入一个迭代的研究过程。LeadResearcher 首先思考方法，并将其计划保存到内存（Memory）中以持久化上下文，因为如果上下文窗口超过20万个令牌，它将被截断，保留计划至关重要。然后，它创建专门的 Subagents（子智能体，这里展示了两个，但可以是任意数量），并分配具体的研究任务。每个 Subagent 独立执行网络搜索，使用交错思考（interleaved thinking）评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并决定是否需要更多研究——如果需要，它可以创建额外的子智能体或完善其策略。一旦收集到足够的信息，系统就会退出研究循环，并将所有发现传递给一个 CitationAgent（引文智能体），该智能体处理文档和研究报告，以确定引文的具体位置。这确保所有声明都正确地归因于其来源。最后，附带引文的最终研究结果会返回给用户。
研究智能体的提示工程与评估
多智能体系统与单智能体系统有关键区别，其中包括协调复杂性的迅速增长。早期的智能体曾犯过这样的错误：为简单查询生成 50 个子智能体，无休止地在网上搜索不存在的来源，以及用过多的更新相互干扰。由于每个智能体都由一个提示（prompt）引导，提示工程是我们改善这些行为的主要手段。以下是我们学到的一些关于提示智能体的原则：
-
像你的智能体一样思考。 为了迭代提示，你必须理解其效果。为了帮助我们做到这一点，我们使用我们的控制台，利用系统中的确切提示和工具进行模拟，然后一步步观察智能体的工作。这立刻暴露了失败模式：智能体在已经有足够结果时仍继续工作，使用过于冗长的搜索查询，或选择错误的工具。有效的提示依赖于建立一个准确的智能体心智模型，这能让最有影响力的改变变得显而易见。
-
教会编排者如何委派任务。 在我们的系统中，主导智能体将查询分解为子任务，并向子智能体描述它们。每个子智能体都需要一个目标、一个输出格式、关于使用哪些工具和来源的指导，以及明确的任务边界。没有详细的任务描述，智能体就会重复工作、留下空白，或找不到必要的信息。我们开始时允许主导智能体给出简单的、简短的指令，如“研究半导体短缺”，但发现这些指令常常模糊不清，导致子智能体误解任务或执行与其他智能体完全相同的搜索。例如，一个子智能体在研究2021年汽车芯片危机，而另外两个则在重复调查当前2025年的供应链，没有有效的分工。
-
根据查询的复杂度来调整投入。 智能体很难判断不同任务的适当投入量，所以我们在提示中嵌入了扩展规则。简单的事实查找只需要1个智能体进行3-10次工具调用，直接比较可能需要2-4个子智能体，每个进行10-15次调用，而复杂的研究可能需要超过10个子智能体，并有明确分工。这些明确的指导方针帮助主导智能体高效分配资源，并防止在简单查询上过度投入，这是我们早期版本中常见的失败模式。
-
工具的设计和选择至关重要。 智能体与工具的接口和人机界面一样关键。使用正确的工具是高效的——通常，这是绝对必要的。例如，一个在网上搜索只存在于 Slack 中的上下文的智能体从一开始就注定失败。通过让模型能够访问外部工具的 MCP 服务器，这个问题会更加复杂，因为智能体可能会遇到描述质量参差不齐的未知工具。我们给了智能体明确的启发式规则：例如，首先检查所有可用的工具，将工具使用与用户意图匹配，对于广泛的外部探索使用网络搜索，或者优先选择专用工具而非通用工具。糟糕的工具描述可能会让智能体走上完全错误的道路，所以每个工具都需要一个明确的用途和清晰的描述。
-
让智能体自我改进。 我们发现 Claude 4 模型可以成为出色的提示工程师。当给定一个提示和一个失败模式时，它们能够诊断出智能体失败的原因并提出改进建议。我们甚至创建了一个工具测试智能体——当给定一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过数十次测试该工具，这个智能体发现了关键的细微差别和错误。这个改进工具人机工程学的过程，使得未来使用新描述的智能体完成任务的时间减少了40%，因为它们能够避免大多数错误。
-
先广泛探索，再聚焦深入。 搜索策略应该模仿人类专家的研究方法：在深入研究具体细节之前，先探索整个领域。智能体通常默认使用过于冗长、具体的查询，结果返回很少。我们通过提示智能体从简短、宽泛的查询开始，评估可用的信息，然后逐步缩小焦点，来纠正这种倾向。
-
引导思考过程。 扩展思考模式（Extended thinking mode）引导 Claude 在一个可见的思考过程中输出额外的令牌，可以作为可控的草稿纸。主导智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂度和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思考改善了指令遵循、推理和效率。子智能体也会进行规划，然后在工具返回结果后使用交错思考（interleaved thinking）来评估质量、发现差距，并完善下一步的查询。这使得子智能体在适应任何任务时都更加有效。
-
并行工具调用改变了速度和性能。 复杂的研究任务自然涉及探索许多来源。我们早期的智能体是按顺序执行搜索的，速度慢得令人痛苦。为了提高速度，我们引入了两种并行化：（1）主导智能体并行启动3-5个子智能体，而不是串行启动；（2）子智能体并行使用3个以上的工具。这些改变将复杂查询的研究时间缩短了高达90%，使得“研究”功能能在几分钟内完成更多工作，而不是几小时，同时覆盖的信息比其他系统更多。
我们的提示策略侧重于灌输良好的启发式方法，而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的提示中——例如分解难题为小任务、仔细评估来源质量、根据新信息调整搜索方法、以及识别何时应注重深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外的副作用，以防止智能体失控。最后，我们专注于一个具有可观测性和测试用例的快速迭代循环。
对智能体进行有效评估
良好的评估对于构建可靠的 AI 应用至关重要，智能体也不例外。然而，评估多智能体系统带来了独特的挑战。传统评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 产生输出 Z。但多智能体系统并非如此运作。即使起点相同，智能体也可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个来源，而另一个可能搜索十个，或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么，所以我们通常不能仅仅检查智能体是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评估方法，既能判断智能体是否取得了正确的结果，又能判断其过程是否合理。
立即用小样本开始评估。在智能体开发的早期，改变往往会产生巨大的影响，因为有大量唾手可得的改进空间。一个提示的调整可能会将成功率从30%提升到80%。在这种效应规模下，只需几个测试用例就能发现变化。我们从大约20个代表真实使用模式的查询集开始。测试这些查询通常能让我们清楚地看到变化的影响。我们常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好是立即用几个例子开始小规模测试，而不是等到能够构建更全面的评估时再行动。
“LLM 即评委”的评估方法在做得好时可以扩展。 研究的输出很难用程序化方式评估，因为它们是自由格式的文本，很少有唯一的正确答案。LLM 自然适合对输出进行评分。我们使用了一个 LLM 评委，它根据一个评分标准来评估每个输出：事实准确性（声明是否与来源匹配？）、引文准确性（引用的来源是否与声明匹配？）、完整性（是否覆盖了所有被要求的内容？）、来源质量（是否使用了主要来源而非质量较低的次要来源？），以及工具效率（是否以合理的次数使用了正确的工具？）。我们曾尝试用多个评委来评估每个部分，但发现单一的 LLM 调用，使用单一提示，输出 0.0-1.0 的分数和一个通过/不通过的等级，结果最为一致，并与人类判断相符。当评估的测试用例确实有明确答案时，这种方法尤其有效，我们可以用 LLM 评委简单地检查答案是否正确（例如，它是否准确列出了研发预算最高的前3家制药公司？）。使用 LLM 作为评委，使我们能够规模化地评估数百个输出。
人工评估能捕捉到自动化遗漏的问题。 人工测试智能体能发现评估遗漏的边缘案例。这些包括对不寻常查询的幻觉性回答、系统故障或微妙的来源选择偏见。在我们的案例中，人类测试员注意到，我们早期的智能体总是选择经过 SEO 优化的内容农场，而不是像学术 PDF 或个人博客这样权威但排名较低的来源。在我们的提示中加入来源质量的启发式规则帮助解决了这个问题。即使在自动化评估的世界里，手动测试仍然至关重要。
多智能体系统具有涌现行为（emergent behaviors），这些行为是在没有特定编程的情况下产生的。例如，对主导智能体的微小改动可能会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体的行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义了分工、解决问题的方法和投入预算的协作框架。要做到这一点，依赖于仔细的提示和工具设计、可靠的启发式方法、可观测性以及紧密的反馈循环。
Cookbook提示示例：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents/prompts
生产可靠性与工程挑战
在传统软件中，一个 bug 可能会破坏一个功能、降低性能或导致服务中断。在智能体系统中，微小的变化会级联成巨大的行为变化，这使得为必须在长期运行过程中维持状态的复杂智能体编写代码变得异常困难。
智能体是有状态的，错误会累积。 智能体可以长时间运行，在多次工具调用中维持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。没有有效的缓解措施，微小的系统故障对智能体来说可能是灾难性的。当错误发生时，我们不能简单地从头开始：重新启动对用户来说既昂贵又令人沮丧。相反，我们构建了能够从错误发生时智能体所在位置恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让智能体知道某个工具正在失败并让其适应，效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障措施相结合。
调试工作受益于新方法。 智能体做出动态决策，并且即使使用相同的提示，每次运行的结果也可能不确定。这使得调试更加困难。例如，用户会报告智能体“找不到明显的信息”，但我们看不出原因。是智能体使用了糟糕的搜索查询？选择了差的来源？还是遇到了工具故障？添加完整的生产环境追踪让我们能够诊断智能体失败的原因，并系统地修复问题。除了标准的可观测性，我们还监控智能体的决策模式和交互结构——所有这些都在不监控单个对话内容的情况下进行，以维护用户隐私。这种高层次的可观测性帮助我们诊断根本原因，发现意外行为，并修复常见故障。
部署需要仔细协调。 智能体系统是由提示、工具和执行逻辑组成的高度有状态的网络，几乎连续运行。这意味着每当我们部署更新时，智能体可能处于其流程的任何位置。因此，我们需要防止我们出于好意的代码更改破坏现有的智能体。我们不能同时将所有智能体更新到新版本。相反，我们使用彩虹部署（rainbow deployments）来避免干扰正在运行的智能体，通过在保持新旧版本同时运行的情况下，逐步将流量从旧版本转移到新版本。
同步执行会造成瓶颈。 目前，我们的主导智能体是同步执行子智能体的，即等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈。例如，主导智能体无法引导子智能体，子智能体之间无法协调，并且整个系统可能因为等待单个子智能体完成搜索而被阻塞。异步执行将能实现额外的并行性：智能体可以并发工作，并在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性和跨子智能体的错误传播方面增加了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能的提升将证明这种复杂性是值得的。
结论
在构建 AI 智能体时，最后一英里往往占据了整个旅程的大部分。在开发人员机器上能工作的代码库，需要大量的工程努力才能成为可靠的生产系统。智能体系统中错误的复合性质意味着，对传统软件来说的小问题可能会让智能体完全脱轨。一个步骤的失败可能导致智能体探索完全不同的轨迹，从而导致不可预测的结果。出于本文所述的所有原因，原型与生产之间的差距往往比预期的要大。
尽管存在这些挑战，多智能体系统在开放式研究任务中已证明其价值。用户表示，Claude 帮助他们找到了未曾考虑过的商业机会，驾驭了复杂的医疗保健选项，解决了棘手的技术 bug，并通过发现他们自己找不到的研究联系，节省了长达数天的工作时间。通过精心的工程设计、全面的测试、注重细节的提示和工具设计、稳健的运营实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统可以在规模上可靠地运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。
一张 Clio 嵌入图，显示了当今人们使用“研究”功能最常见的方式。排名前列的用例类别是：开发跨专业领域的软件系统（10%），开发和优化专业及技术内容（8%），制定业务增长和收入生成策略（8%），协助学术研究和教育材料开发（7%），以及研究和核实关于人物、地点或组织的信息（5%）。
致谢
由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作反映了 Anthropic 多个团队的集体努力，他们使“研究”功能成为可能。特别感谢 Anthropic 应用工程团队，他们的奉献精神将这个复杂的多智能体系统带入了生产环境。我们也感谢早期用户的出色反馈。
附录
以下是关于多智能体系统的一些额外杂项技巧。
对在多轮交互中改变状态的智能体进行终态评估。 评估在多轮对话中修改持久状态的智能体带来了独特的挑战。与只读的研究任务不同，每个动作都会改变后续步骤的环境， tạo thành了传统评估方法难以处理的依赖关系。我们发现，专注于终态评估而不是逐轮分析取得了成功。与其判断智能体是否遵循了特定的过程，不如评估它是否达到了正确的最终状态。这种方法承认智能体可能会找到通往同一目标的不同路径，同时仍能确保它们交付预期的结果。对于复杂的工作流，将评估分解为应发生特定状态变化的离散检查点，而不是试图验证每个中间步骤。
长跨度对话管理。 生产环境中的智能体通常会进行跨越数百轮的对话，需要仔细的上下文管理策略。随着对话的延长，标准的上下文窗口变得不足，需要智能的压缩和记忆机制。我们实现了一些模式，其中智能体在进入新任务之前，会总结已完成的工作阶段并将基本信息存储在外部存储器中。当接近上下文限制时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接保持连续性。此外，它们可以从内存中检索存储的上下文（如研究计划），而不是在达到上下文限制时丢失先前的工作。这种分布式方法在保持扩展对话连贯性的同时，防止了上下文溢出。
将子智能体的输出保存到文件系统，以最大限度地减少“传话游戏”式的信息失真。 对于某些类型的结果，让子智能体直接输出可以绕过主协调器，从而提高保真度和性能。与其要求子智能体通过主导智能体来传达所有信息，不如实现一个工件（artifact）系统，让专门的智能体可以创建独立持久化的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级的引用传递回协调器。这可以防止在多阶段处理过程中的信息丢失，并减少因在对话历史中复制大型输出而产生的令牌开销。这种模式对于结构化输出（如代码、报告或数据可视化）尤其有效，因为子智能体的专门提示比通过通用协调器过滤产生的结果更好。
原文：https://www.anthropic.com/engineering/built-multi-agent-research-system
公众号回复“进群”入群讨论。
（文：AI工程化）