我们如何构建多智能体研究系统¶
原文链接: English Original
Claude 现在具备 Research（研究）能力，可以跨网页、Google Workspace 及任何集成进行搜索，以完成复杂任务。这个多智能体系统从原型到生产的过程，教会了我们关于系统架构、工具设计和 prompt 工程的关键经验。
多智能体系统由多个智能体（LLM 在循环中自主使用工具）协同工作组成。我们的 Research 功能涉及一个智能体，它根据用户查询规划研究流程，然后使用工具创建并行智能体同时搜索信息。拥有多个智能体的系统在智能体协调、评估和可靠性方面引入了新的挑战。本文分享了适用于我们的原则——希望你在构建自己的多智能体系统时能从中受益。
多智能体系统的优势¶
研究工作涉及开放性问题，很难提前预测所需步骤。你无法为探索复杂主题硬编码固定路径，因为这个过程本质上是动态且路径依赖的。当人们进行研究时，往往会根据发现不断更新方法，追踪调查过程中出现的线索。
这种不可预测性使 AI 智能体特别适合研究任务。研究需要灵活性，能够随着调查的展开转向或探索相关的关联。模型必须自主运行许多轮次，根据中间发现做出关于 pursue 哪些方向的决策。线性的、一次性管道无法处理这些任务。
搜索的本质是压缩：从大量语料中提炼洞察。子智能体通过在自己的 context window 中并行操作来促进压缩，同时探索问题的不同方面，然后将最重要的 token 提炼给主导研究智能体。每个子智能体还提供了关注点分离——不同的工具、prompt 和探索轨迹——这减少了路径依赖，并使彻底的、独立的调查成为可能。
一旦智能达到一定阈值，多智能体系统就成为扩展性能的关键方式。例如，尽管单个人类在过去 100,000 年中变得更加聪明，但人类社会在信息时代的能力呈指数级增长，因为我们的集体智能和协调能力。即使是通用智能的智能体作为个体操作时也面临限制；智能体群体可以完成更多事情。
我们的内部评估表明，多智能体研究系统在需要同时 pursue 多个独立方向的广度优先查询中表现尤为出色。我们发现，以 Claude Opus 4 为主导智能体、Claude Sonnet 4 为子智能体的多智能体系统，表现优于单个智能体。
Research 架构概览¶
我们的 Research 系统使用编排器-工作者模式的多智能体架构，其中主导智能体协调整个流程，同时委派给专门的子智能体并行操作。
当用户提交查询时，主导智能体分析查询，制定策略，并生成子智能体同时探索不同方面。子智能体充当智能过滤器，通过迭代使用搜索工具收集信息，然后将发现返回给主导智能体以编译最终答案。
传统使用检索增强生成（RAG）的方法使用静态检索。即，它们获取一组与输入查询最相似的文本块，并使用这些文本块生成响应。相比之下，我们的架构使用多步搜索，动态查找相关信息，适应新发现，并分析结果以制定高质量的答案。
完整流程：当用户提交查询时，系统创建一个 LeadResearcher 智能体，进入迭代研究流程。LeadResearcher 首先思考方法并将计划保存到 Memory 中以持久化上下文（因为如果 context window 超过 200,000 token 就会被截断，保留计划很重要）。然后创建具有特定研究任务的专门子智能体（图中显示两个，但可以是任意数量）。每个子智能体独立执行网页搜索，使用 interleaved thinking 评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果并决定是否需要更多研究——如果是，它可以创建额外的子智能体或调整策略。一旦收集到足够信息，LeadResearcher 生成最终综合答案。
研究智能体的 prompt 工程与评估¶
多智能体系统与单智能体系统有关键差异，包括协调复杂度的快速增长。早期的智能体会犯以下错误：为简单查询生成 50 个子智能体、无休止地搜索不存在的来源、用过多的更新互相干扰。由于每个智能体都由 prompt 引导，prompt 工程是我们改善这些行为的主要手段。以下是我们学到的 prompt 原则：
像你的智能体一样思考。 要迭代 prompt，你必须理解它们的效果。为此，我们使用 Console 进行了模拟，使用系统中完全相同的 prompt 和工具，然后逐步观察智能体的工作。这立即揭示了失败模式：智能体在已有足够结果时仍继续运行、使用过于冗长的搜索查询、或选择错误的工具。有效的 prompt 依赖于对智能体建立准确的思维模型，这可以使最具影响力的改进变得显而易见。
教导编排器如何委派。 在我们的系统中，主导智能体将查询分解为子任务并描述给子智能体。每个子智能体需要一个目标、一个输出格式、关于使用哪些工具和来源的指导，以及清晰的任务边界。没有详细的任务描述，智能体会重复工作、留下空白，或无法找到必要信息。我们最初允许主导智能体给出简单、简短的指令如"研究半导体短缺"，但发现这些指令往往足够模糊，子智能体会误解任务或执行与其他智能体完全相同的搜索。例如，一个子智能体探索 2021 年汽车芯片危机，而另外 2 个重复调查当前 2025 年供应链的工作，没有有效的分工。
根据查询复杂度调整工作量。 智能体很难判断不同任务的适当工作量，因此我们在 prompt 中嵌入了缩放规则。简单的事实查找只需要 1 个智能体配合少量搜索；复杂的研究可能需要 5-10 个子智能体分批工作，每个子智能体在特定方向上进行多次搜索。
对工具使用设定明确边界。 我们学会了指定每种工具何时应该被使用、使用多少次，以及在什么条件下应该停止使用特定方法。没有这些边界，智能体有时会过度依赖单一策略。
我们的 prompt 策略侧重于灌输好的启发式方法，而不是僵化的规则。我们研究了熟练的人类如何处理研究任务，并在 prompt 中编码了这些策略——例如将困难问题分解为更小的任务、仔细评估来源质量、根据新信息调整搜索方法、以及识别何时应该注重深度（详细调查一个主题）vs. 广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外副作用，防止智能体失控。最后，我们专注于通过可观察性和测试用例实现快速迭代循环。
智能体的有效评估¶
好的评估对于构建可靠的 AI 应用至关重要，智能体也不例外。然而，评估多智能体系统带来了独特的挑战。传统评估通常假设 AI 每次遵循相同的步骤：给定输入 X，系统应遵循路径 Y 产生输出 Z。但多智能体系统不是这样工作的。即使起点相同，智能体可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个来源而另一个搜索十个，或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常不能只检查智能体是否遵循了预先规定的"正确"步骤。相反，我们需要灵活的评估方法，判断智能体是否达到了正确的结果，同时也遵循了合理的过程。
立即用小样本开始评估。 在智能体开发的早期，变更往往产生显著影响，因为存在大量低垂的果实。一个 prompt 微调可能会将成功率从 30% 提高到 80%。效果量如此之大，只需几个测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询开始。经常测试这些查询使我们能清楚看到变更的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有几百个测试用例的大规模评估才有用。然而，最好立即从几个示例开始小规模测试，而不是等到构建更全面的评估。
LLM-as-judge 评估在做好后可以扩展。 研究输出难以通过编程评估，因为它们是自由格式的文本，很少有唯一正确答案。LLM 自然适合对输出进行评分。我们使用了一个 LLM judge，根据 rubric 中的标准评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否匹配声明？）、完整性（是否覆盖了所有要求方面？）、来源质量（是否使用了主要来源而非较低质量的次要来源？）、以及工具效率（是否合理次数地使用了正确的工具？）。我们尝试了多个 judge 来评估每个组件，但发现单个 LLM 调用配合单个 prompt 输出 0.0-1.0 分数和通过/不通过等级是最一致的，且与人类判断最吻合。这种方法在评估测试用例确实有明确答案时特别有效，我们可以使用 LLM judge 简单地检查答案是否正确。使用 LLM 作为 judge 使我们能够大规模评估数百个输出。
人类评估能发现自动化遗漏的问题。 测试智能体的人员会发现评估遗漏的边缘情况。这些包括在异常查询上产生幻觉的答案、系统故障或微妙的来源选择偏差。在我们的案例中，人类测试人员注意到我们的早期智能体始终选择 SEO 优化的内容农场，而非权威但排名较低的来源（如学术论文或个人博客）。在 prompt 中添加来源质量启发式方法帮助解决了这个问题。即使在自动化评估的世界中，手动测试仍然必不可少。
多智能体系统具有涌现行为，这些行为不需要特定的编程。例如，对主导智能体的小幅更改可能不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是个体智能体行为。因此，这些智能体最好的 prompt 不仅是严格指令，而是定义分工、解决问题方法和工作量预算的协作框架。做好这一点依赖于精心设计的 prompt 和工具、可靠的启发式方法、可观察性和紧密的反馈循环。参见我们 Cookbook 中的开源 prompt 了解系统中的示例 prompt。
生产可靠性和工程挑战¶
在传统软件中，一个 bug 可能破坏功能、降低性能或导致宕机。在智能体系统中，微小的变更会级联成大的行为变化，这使编写必须在长时间运行过程中保持状态的复杂智能体的代码变得异常困难。
智能体是有状态的，错误会复合。 智能体可以长时间运行，在许多工具调用中保持状态。这意味着我们需要持久地执行代码并处理途中的错误。没有有效的缓解措施，小的系统故障对智能体可能是灾难性的。当错误发生时，我们不能从头重新开始：重启既昂贵又令用户沮丧。相反，我们构建了可以从错误发生位置恢复的系统。我们还利用模型的智能优雅地处理问题：例如，让智能体知道工具何时失败并让它适应的效果出奇地好。我们将基于 Claude 的 AI 智能体的适应性与确定性保障措施（如重试逻辑和定期检查点）结合起来。
调试需要新方法。 智能体做出动态决策，即使在 prompt 相同的情况下，运行之间也是非确定性的。这使得调试更困难。例如，用户报告智能体"找不到明显的信息"，但我们无法看到原因。是智能体使用了糟糕的搜索查询？选择了不良来源？遇到了工具故障？添加完整的生产跟踪使我们能够诊断智能体失败的原因并系统地修复问题。除了标准可观察性之外，我们还监控智能体决策模式和交互结构——所有这些都不监控个别对话的内容，以维护用户隐私。这种高层可观察性帮助我们诊断根本原因、发现意外行为和修复常见故障。
部署需要精心协调。 智能体系统是高度有状态的 prompt、工具和执行逻辑网络，几乎持续运行。这意味着每当我们部署更新时，智能体可能处于其流程的任何位置。因此我们需要防止善意的代码变更破坏正在运行的智能体。我们无法同时将每个智能体更新到新版本。相反，我们使用 rainbow deployments 避免中断正在运行的智能体，通过逐渐将流量从旧版本转移到新版本，同时保持两者同时运行。
同步执行造成瓶颈。 目前，我们的主导智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈。例如，主导智能体无法引导子智能体，子智能体无法协调，整个系统可能被等待单个子智能体完成搜索所阻塞。异步执行将启用额外的并行性：智能体并发工作，在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性和错误传播方面增加了挑战。随着模型能够处理更长更复杂的研究任务，我们预计性能收益将证明这种复杂性是值得的。
结论¶
在构建 AI 智能体时，最后一英里往往成为大部分的旅程。在开发者机器上运行的代码库需要大量工程才能成为可靠的生产系统。智能体系统中错误的复合性质意味着传统软件的小问题可能完全使智能体脱轨。一步失败可能导致智能体探索完全不同的轨迹，导致不可预测的结果。由于本文描述的所有原因，原型与生产之间的差距通常比预期的更大。
尽管存在这些挑战，多智能体系统已证明对开放式研究任务很有价值。用户表示 Claude 帮助他们发现了他们没有考虑过的商业机会、导航复杂的医疗保健选项、解决棘手的技术 bug，并通过揭示他们独自不会发现的研究联系节省了长达数天的工作。多智能体研究系统可以通过精心工程、全面测试、注重细节的 prompt 和工具设计、强大的运营实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队的紧密协作，可靠地大规模运行。
致谢¶
由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作反映了 Anthropic 多个团队的集体努力，是 Research 功能得以实现的原因。特别感谢 Anthropic 应用工程团队，他们的奉献使这个复杂的多智能体系统投入生产。我们也感谢早期用户的出色反馈。
附录¶
以下是一些多智能体系统的额外杂项技巧。
对跨多轮修改状态的智能体进行终态评估。 评估跨多轮对话修改持久状态的智能体提出了独特挑战。与只读研究任务不同，每个操作可以改变后续步骤的环境，创建了传统评估方法难以处理的依赖关系。我们发现专注于终态评估而非逐轮分析是成功的。与其判断智能体是否遵循了特定流程，不如评估它是否达到了正确的最终状态。这种方法承认智能体可能找到通往相同目标的替代路径，同时仍然确保它们交付了预期的结果。对于复杂工作流，将评估分解为离散的检查点，在特定状态变更应该发生的地方，而不是试图验证每个中间步骤。
长期对话管理。 生产智能体经常参与跨越数百轮的对话，需要仔细的上下文管理策略。随着对话延伸，标准 context window 变得不足，需要智能压缩和记忆机制。我们实现了这样的模式：智能体总结已完成的工作阶段，并将关键信息存储在外部记忆中，然后再继续新任务。当 context 限制接近时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接保持连续性。此外，它们可以从记忆中检索存储的上下文（如研究计划），而不是在达到 context 限制时丢失之前的工作。这种分布式方法防止了 context 溢出，同时保持了扩展交互中的对话连贯性。
子智能体输出到文件系统以最小化"传话游戏"。 直接子智能体输出可以绕过主协调器处理某些类型的结果，提高保真度和性能。与其要求子智能体通过主导智能体传达所有信息，不如实现工件系统，专门的智能体可以创建独立持久化的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传回给协调器。这防止了多阶段处理过程中的信息丢失，并减少了通过对话历史复制大输出的 token 开销。这种模式对于结构化输出（如代码、报告或数据可视化）特别有效，子智能体的专门 prompt 在这些情况下比通过通用协调器过滤产生更好的结果。