Anthropic 发布新文章，解释 Claude 是如何构建智能体研究系统的
本文翻译自 anthropic blog
我们的 Research 功能使用多个 Claude 代理来更有效地探索复杂的主题。我们分享了工程挑战以及我们从构建该系统中吸取的经验教训。
Claude 现在拥有研究功能，使其能够在 Web、Google Workspace 和任何集成中进行搜索以完成复杂的任务。
这个多智能体系统从原型到生产的旅程教会了我们关于系统架构、工具设计和提示工程的重要课程。多代理系统由多个代理（LLM 在循环中自主使用工具）组成。我们的 Research 功能涉及一个代理，该代理根据用户查询规划研究流程，然后使用工具创建同时搜索信息的并行代理。具有多个代理的系统在代理协调、评估和可靠性方面带来了新的挑战。
这篇文章分解了对我们有用的原则——我们希望您在构建自己的多智能体系统时会发现它们很有用。
多代理系统的优势
研究工作涉及开放式问题，很难提前预测所需的步骤。您不能硬编码用于探索复杂主题的固定路径，因为该过程本质上是动态的并且依赖于路径。当人们进行研究时，他们倾向于根据发现不断更新他们的方法，并遵循调查过程中出现的线索。
这种不可预测性使 AI 代理特别适合研究任务。研究需要随着调查的展开而灵活地调整或探索切线联系。该模型必须自主运行多个回合，并根据中间结果决定要追求的方向。线性的一次性管道无法处理这些任务。
搜索的本质是压缩：从庞大的语料库中提炼洞察。子代理通过与自己的上下文窗口并行作来促进压缩，在为首席研究代理压缩最重要的标记之前同时探索问题的不同方面。每个子代理还提供关注点分离（不同的工具、提示和探索轨迹），从而减少路径依赖性并实现彻底、独立的调查。
一旦智能达到阈值，多代理系统就成为扩展性能的重要方式。例如，尽管人类个体在过去 100,000 年中变得更加聪明，但由于我们的集体智慧和协调能力，人类社会在信息时代的能力呈指数级增长。即使是一般智能的代理在作为个体作时也会面临限制;代理组可以完成更多工作。
我们的内部评估表明，多智能体研究系统尤其擅长涉及同时追求多个独立方向的广度优先查询。我们发现，在我们的内部研究评估中，以 Claude Opus 4 为主要代理和 Claude Sonnet 4 子代理的多代理系统的性能比单代理 Claude Opus 4 高出 90.2%。例如，当被要求识别信息技术标准普尔 500 指数中公司的所有董事会成员时，多智能体系统通过将其分解为子智能体的任务来找到正确答案，而单智能体系统通过缓慢的顺序搜索无法找到答案。
多代理系统之所以有效，主要是因为它们有助于花费足够的代币来解决问题。在我们的分析中，三个因素解释了 BrowseComp 评估（测试浏览代理查找难以找到的信息的能力）中 95% 的性能差异。我们发现，令牌使用本身可以解释 80% 的方差，工具调用次数和模型选择是另外两个解释因素。这一发现验证了我们的架构，该架构在具有单独上下文窗口的代理之间分配工作，以增加更多并行推理能力。最新的 Claude 模型在代币使用方面起到了很大的效率乘数的作用，因为升级到 Claude Sonnet 4 比在 Claude Sonnet 3.7 上将代币预算翻倍要提高性能。多代理架构可以有效地扩展超出单个代理限制的任务的令牌使用。
有一个缺点：在实践中，这些架构会快速烧毁代币。根据我们的数据，代理通常比聊天交互多使用约 4× 个令牌，而多代理系统使用的令牌比聊天多约 15× 个。为了经济可行性，多代理系统需要任务价值足够高的任务，以支付更高的性能。此外，一些要求所有代理共享相同上下文或涉及代理之间许多依赖关系的域不适合当今的多代理系统。例如，与研究相比，大多数编码任务涉及的真正可并行化的任务更少，而且 LLM 代理还不擅长实时协调和委派给其他代理。我们发现，多智能体系统擅长处理有价值的任务，这些任务涉及大量并行化、超出单个上下文窗口的信息以及与众多复杂工具的接口。
Research 的体系结构概述
我们的研究系统使用具有编排器-工作程序模式的多代理架构，其中领导代理协调流程，同时委派给并行运行的专用子代理。
当用户提交查询时，Lead Agent 会对其进行分析，制定策略，并生成子代理以同时探索不同的方面。如上图所示，子代理充当智能过滤器，以迭代方式使用搜索工具收集信息，在本例中为 2025 年的 AI 代理公司，然后将公司列表返回给牵头代理，以便其编译最终答案。
使用 Retrieval Augmented Generation （RAG） 的传统方法使用静态检索。也就是说，它们获取一些与输入查询最相似的块，并使用这些块生成响应。相比之下，我们的架构使用多步骤搜索，动态查找相关信息，适应新发现，并分析结果以形成高质量的答案。
为研究代理提供及时的工程设计和评估
多智能体系统与单智能体系统存在关键区别，包括协调复杂性的快速增长。早期的代理会犯一些错误，例如为简单查询生成 50 个子代理，无休止地在 Web 上搜索不存在的来源，以及通过过多的更新分散彼此的注意力。由于每个代理都由提示引导，因此提示工程是我们改进这些行为的主要杠杆。以下是我们学到的提示代理的一些原则：
像您的代理一样思考。 要迭代提示，您必须了解它们的效果。为了帮助我们做到这一点，我们使用控制台使用系统中的确切提示和工具构建了模拟，然后观察代理逐步工作。这立即揭示了失败模式：代理在已经获得足够结果时继续、使用过于冗长的搜索查询或选择不正确的工具。有效的提示依赖于开发一个准确的代理心智模型，这可以使最具影响力的变化显而易见。
教编排器如何委派。在我们的系统中，Lead Agent 将查询分解为 subtask 并向 subagent 描述它们。每个子代理都需要一个目标、一个输出格式、关于要使用的工具和来源的指导，以及明确的任务边界。如果没有详细的任务描述，代理会重复工作、留下空白或找不到必要的信息。我们一开始允许牵头代理给出简单、简短的指示，例如“研究半导体短缺”，但发现这些指示通常非常模糊，以至于子代理误解了任务或执行与其他代理完全相同的搜索。例如，一个子代理探讨了 2021 年的汽车芯片危机，而其他 2 个子代理则重复了调查当前 2025 年供应链的工作，而没有进行有效的分工。
扩展工作量以降低查询复杂性。 代理很难判断不同任务的适当努力，因此我们在提示中嵌入了缩放规则。简单的事实调查只需要 1 个代理和 3-10 个工具调用，直接比较可能需要 2-4 个子代理，每个子代理 10-15 个调用，复杂的研究可能需要 10 多个职责明确划分的子代理。这些明确的指导方针有助于 Lead Agent 有效地分配资源，并防止对简单查询进行过度投资，这是我们早期版本中常见的失败模式。
工具设计和选择至关重要。 代理工具界面与人机界面一样重要。使用正确的工具是有效的 — 通常，这是绝对必要的。例如，代理在 Web 上搜索仅存在于 Slack 中的上下文从一开始就注定要失败。对于允许模型访问外部工具的 MCP 服务器，这个问题会变得更加复杂，因为代理会遇到看不见的工具，这些工具的描述质量参差不齐。我们给代理提供了明确的启发式方法：例如，首先检查所有可用的工具，将工具使用情况与用户意图相匹配，在 Web 上搜索广泛的外部探索，或者更喜欢专用工具而不是通用工具。错误的工具描述可能会使代理走上完全错误的道路，因此每个工具都需要不同的用途和清晰的描述。
让代理商自我提升。我们发现 Claude 4 模型可以成为出色的提示工程师。当收到提示和故障模式时，他们能够诊断代理失败的原因并提出改进建议。我们甚至创建了一个工具测试代理 — 当给定有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过对该工具进行数十次测试，该代理发现了关键的细微差别和错误。这一改进工具人体工程学的过程使使用新描述的未来代理的任务完成时间缩短了 40%，因为他们能够避免大多数错误。
从宽处开始，然后缩小范围。搜索策略应反映专家的人类研究：在深入研究细节之前先探索前景。代理通常默认使用过长的特定查询，返回的结果很少。我们通过提示代理从简短、广泛的查询开始，评估可用的内容，然后逐渐缩小关注点来抵消这种趋势。
引导思考过程。 扩展思维模式，引导 Claude 在可见的思考过程中输出额外的标记，可以作为一个可控的便签本。Lead Agent 使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子代理数量，并定义每个子代理的角色。我们的测试表明，扩展思维可以提高指令遵循、推理和效率。子代理还会在工具结果后进行规划，然后使用交错思维来评估质量、识别差距并优化他们的下一个查询。这使得子代理更有效地适应任何任务。
并行工具调用可转换速度和性能。复杂的研究任务自然涉及探索许多来源。我们早期的代理执行顺序搜索，这非常缓慢。为了提高速度，我们引入了两种并行化：（1） lead 代理并行启动 3-5 个子代理，而不是串行启动;（2） 子代理并行使用 3+ 工具。对于复杂查询，这些更改将 Research 时间缩短了 90%，使 Research 能够在几分钟而不是几小时内完成更多工作，同时比其他系统涵盖更多的信息。
我们的提示策略侧重于灌输良好的启发式方法，而不是僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码在我们的提示中——例如将困难的问题分解为更小的任务，仔细评估来源的质量，根据新信息调整搜索方法，以及识别何时关注深度（详细调查一个主题）与广度（同时探索多个主题）。我们还通过设置明确的护栏来主动缓解意外的副作用，以防止代理程序失控。最后，我们专注于具有可观察性和测试用例的快速迭代循环。
有效评估药物
良好的评估对于构建可靠的 AI 应用程序至关重要，代理也不例外。然而，评估多代理系统带来了独特的挑战。传统评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 以生成输出 Z。但是多代理系统不是这样工作的。即使起点相同，代理也可能采用完全不同的有效路径来实现他们的目标。一个代理可能会搜索 3 个来源，而另一个代理可能会搜索 10 个，或者他们可能会使用不同的工具来查找相同的答案。因为我们并不总是知道什么是正确的步骤，所以我们通常不能只检查代理人是否遵循了我们事先规定的“正确”步骤。相反，我们需要灵活的评估方法，以判断代理人是否取得了正确的结果，同时也遵循合理的流程。
立即开始使用小样本进行评估。在早期代理开发中，变化往往会产生巨大的影响，因为有大量唾手可得的成果。及时调整可能会将成功率从 30% 提高到 80%。对于如此大的 effect 大小，您只需几个测试用例即可发现更改。我们从一组大约 20 个查询开始，这些查询代表真实的使用模式。测试这些查询通常可以让我们清楚地看到更改的影响。我们经常听到 AI 开发团队延迟创建 eval，因为他们认为只有具有数百个测试用例的大型 eval 才有用。但是，最好从几个示例立即开始小规模测试，而不是等到可以构建更全面的评估时再推迟。
LLM 作为评委的评估量表如果做得好。研究成果很难以编程方式进行评估，因为它们是自由格式的文本，很少有一个正确的答案。LLM 非常适合对输出进行评分。我们使用了一名法学硕士评委，根据评分标准中的标准评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有请求的方面？）、来源质量（它是否使用了第一手来源而不是低质量的第二手来源？）和工具效率（它是否使用了正确的工具合理次数？我们尝试了多名裁判来评估每个组成部分，但发现单个 LLM 调用和单个提示输出 0.0-1.0 的分数和通过-失败等级是最一致的，并且与人工判断最一致。当评估测试用例确实有明确的答案时，这种方法特别有效，我们可以使用 LLM 判断来简单地检查答案是否正确（即，它是否准确地列出了研发预算前 3 名的制药公司？使用 LLM 作为评委使我们能够大规模评估数百项输出。
人工评估可以捕捉到自动化遗漏的内容。人员测试代理发现 evals 遗漏的边缘情况。这些包括对异常查询的幻觉答案、系统故障或微妙的源选择偏差。在我们的案例中，人工测试人员注意到，我们的早期代理始终选择经过 SEO 优化的内容农场，而不是权威但排名较低的来源，如学术 PDF 或个人博客。在我们的提示中添加源质量启发式方法有助于解决此问题。即使在自动评估的世界中，手动测试仍然是必不可少的。
多智能体系统具有紧急行为，这些行为在没有特定编程的情况下出现。例如，对 Lead Agent 的微小更改可能会不可预知地改变 Subagent 的行为方式。成功需要了解交互模式，而不仅仅是单个座席的行为。因此，对这些代理的最佳提示不仅仅是严格的指示，而是定义分工、解决问题的方法和工作预算的协作框架。要做到这一点，需要仔细的提示和工具设计、可靠的启发式方法、可观察性和紧密的反馈循环。 有关来自我们系统的提示的示例，请参阅我们的说明书中的开源提示。
生产可靠性和工程挑战
在传统软件中，错误可能会破坏功能、降低性能或导致中断。在代理系统中，微小的变化会级联成大的行为变化，这使得为必须在长时间运行的进程中保持状态的复杂代理编写代码变得非常困难。
代理是有状态的，并且错误是复合的。 代理可以长时间运行，在许多工具调用中保持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。如果没有有效的缓解措施，轻微的系统故障可能会对代理造成灾难性的影响。当错误发生时，我们不能从头开始重新启动：重新启动成本高昂且让用户感到沮丧。相反，我们构建了可以从 Agent 发生错误时所在的位置恢复的系统。我们还使用模型的智能来优雅地处理问题：例如，让代理知道工具何时出现故障并让它适应效果非常好。我们将基于 Claude 构建的 AI 代理的适应性与重试逻辑和常规检查点等确定性保护措施相结合。
调试受益于新方法。 代理会做出动态决策，并且在运行之间是不确定的，即使具有相同的提示也是如此。这使得调试更加困难。例如，用户会报告代理“没有找到明显的信息”，但我们不明白为什么。代理是否使用了错误的搜索查询？选择糟糕的来源？击中工具故障？通过添加完整的生产跟踪，我们可以诊断代理失败的原因并系统地修复问题。除了标准可观察性之外，我们还监控座席决策模式和交互结构，所有这些都无需监控单个对话的内容，以保护用户隐私。这种高级可观测性帮助我们诊断根本原因、发现意外行为并修复常见故障。
部署需要仔细协调。代理系统是提示、工具和执行逻辑的高度状态 Web，它们几乎连续运行。这意味着，无论何时我们部署更新，代理都可能在其进程中的任何位置。因此，我们需要防止我们善意的代码更改破坏现有代理。我们不能同时将每个代理更新到新版本。相反，我们使用 rainbow 部署来避免中断正在运行的代理，方法是逐渐将流量从旧版本转移到新版本，同时保持两者同时运行。
同步执行会产生瓶颈。目前，我们的 Lead Agent 会同步执行 subagent，等待每组 subagent 完成后再继续。这简化了协调，但在代理之间的信息流中造成了瓶颈。例如，Lead Agent 无法引导 subagent，subagent 无法协调，并且在等待单个 subagent 完成搜索时，整个系统可能会被阻止。异步执行将启用额外的并行性：代理同时工作并在需要时创建新的子代理。但是这种异步性增加了结果协调、状态一致性和跨子代理的错误传播方面的挑战。由于模型可以处理更长、更复杂的研究任务，我们预计性能提升将证明复杂性是合理的。
结论
在构建 AI 代理时，最后一英里往往成为旅程的大部分。在开发人员计算机上工作的代码库需要大量的工程设计才能成为可靠的生产系统。代理系统中错误的复合性质意味着传统软件的小问题可能会完全使代理脱轨。一步失败可能会导致代理探索完全不同的轨迹，从而导致不可预测的结果。由于本文中描述的所有原因，原型和生产之间的差距通常比预期的要大。
尽管存在这些挑战，但事实证明，多智能体系统对于开放式研究任务很有价值。用户表示，Claude 帮助他们找到了他们没有考虑过的商机，浏览了复杂的医疗保健选项，解决了棘手的技术错误，并通过发现他们无法单独找到的研究联系来节省长达数天的工作时间。多智能体研究系统可以通过仔细的工程设计、全面的测试、注重细节的提示和工具设计、强大的作实践以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的密切合作，可靠地大规模运行。我们已经看到这些系统改变了人们解决复杂问题的方式。
附录
以下是多代理系统的一些其他杂项提示。
在许多回合中改变状态的代理体的最终状态评估。 评估在多轮次对话中修改持久状态的座席面临独特的挑战。与只读研究任务不同，每个作都可以改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现，成功集中在最终状态评估而不是逐向分析上。与其判断代理是否遵循特定的过程，不如评估它是否达到了正确的最终状态。这种方法承认代理可能会找到通往相同目标的替代路径，同时仍然确保他们提供预期的结果。对于复杂的工作流，将评估分解为应该发生特定状态更改的离散检查点，而不是尝试验证每个中间步骤。
长期对话管理。 生产代理经常参与跨越数百个回合的对话，需要仔细的上下文管理策略。随着对话的扩展，标准上下文窗口变得不够用，需要智能压缩和记忆机制。我们实施了代理总结已完成的工作阶段并将基本信息存储在外部存储器中的模式，然后再继续执行新任务。当上下文限制接近时，代理可以生成具有干净上下文的新子代理，同时通过谨慎的交接保持连续性。此外，他们可以从内存中检索存储的上下文，例如研究计划，而不是在达到上下文限制时丢失以前的工作。这种分布式方法可以防止上下文溢出，同时保持扩展交互之间的对话连贯性。
子代理输出到文件系统，以最大限度地减少“电话游戏”。 直接子代理输出可以绕过主协调器以获得某些类型的结果，从而提高保真度和性能。与其要求子代理通过主代理传达所有内容，不如实施工件系统，其中专门的代理可以创建独立存在的输出。子代理调用工具将其工作存储在外部系统中，然后将轻量级引用传递回协调器。这可以防止在多阶段处理过程中丢失信息，并减少通过对话历史记录复制大型输出的令牌开销。该模式特别适用于结构化输出，如代码、报告或数据可视化，其中子代理的专用提示比通过总协调器进行筛选产生更好的结果。