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