摘要

Claude 现在拥有 Research 能力，可以跨网络、Google Workspace 和任何集成进行搜索，以完成复杂的任务。
　　这个多智能体系统从原型到生产的历程，教会了我们关于系统架构、工具设计和提示工程的重要经验。多智能体系统由多个智能体（LLM）组成，它们以循环的方式自主使用工具。我们的 Research 功能包含一个智能体，它会根据用户查询规划研究流程，然后使用工具创建并行智能体，同时搜索信息。多智能体系统在智能体的协调、评估和可靠性方面带来了新的挑战。
　　这篇文章分解了对我们有用的原则——我们希望您在构建自己的多智能体系统时会发现它们很有用。

Benefits of a multi-agent system

Research 工作涉及开放式问题，很难提前预测所需的步骤。你无法为探索复杂主题设定固定的路径，因为这个过程本质上是动态的，并且依赖于路径。人们在进行研究时，往往会根据研究过程中出现的线索，不断更新研究方法。
　　这种不可预测性使得人工智能 Agent 特别适合研究任务。研究需要能够灵活地随着调查的展开而调整方向或探索间接联系。模型必须自主运行多个回合，并根据中间发现决定后续方向。线性、一次性的流程无法处理这些任务。
　　Research 的本质在于压缩：从海量语料库中提炼洞察。子 Agent 通过与各自的上下文窗口并行运行，同时探索问题的不同方面，最终为 lead research Agent 提炼出最重要的 token，从而促进压缩。每个子 Agent 还提供关注点分离——不同的工具、提示和探索轨迹——从而减少路径依赖，并支持进行彻底、独立的调查。
　　一旦单体智能达到一定阈值，多 Agent 系统就成为提升性能的重要途径。例如，尽管在过去的十万年里，人类个体的智能水平不断提升，但在信息时代，由于集体智慧和协调能力的提升，人类社会的能力也呈指数级增长。即使是通用智能体，在单独运作时也会面临限制；而群体智能可以完成更多任务。
　　我们的内部评估表明，多 Agent 研究系统尤其擅长处理需要涉及同时追踪多个独立方向的广度优先查询。我们发现，以 Claude Opus 4 为主 Agent，并由 Claude Sonnet 4 为子 Agent 的多 Agent 系统，在内部研究评估中的表现比单 Agent Claude Opus 4 高出90.2%。例如，当被要求识别信息技术类S&P 500 公司的所有董事会成员时，多 Agent 系统通过将其分解为子 Agent 的任务找到了正确答案，而单 Agent 系统则因缓慢的顺序搜索而无法找到答案。
　　多 Agent 系统之所以有效，主要在于它们能够帮助消耗足够的 token 来解决问题。在我们的分析中，三个因素解释了BrowseComp评估（测试浏览 Agent 查找难以找到的信息的能力）中95%的性能差异。我们发现，token 使用本身就解释了80%的差异，工具调用次数和模型选择是另外两个解释因素。这一发现验证了我们的架构，该架构将工作分配给具有独立上下文窗口的 Agent ，从而增强了并行推理的能力。最新的Claude模型在 token 使用方面发挥了巨大的效率倍增器作用，因为升级到 Claude Sonnet 4 比将 Claude Sonnet 3.7 上的 token 预算翻倍带来的性能提升更大。多 Agent 架构可以有效地扩展超出单个 Agent 极限的任务的 token 使用量。
　　这些架构也存在一个缺点：在实践中，它们会快速消耗 token。根据我们的数据，Agent 通常比聊天交互多消耗 4 倍 token，而多 Agent 系统则比聊天多消耗 15 倍 token。为了实现经济可行性，多 Agent 系统需要执行那些价值足够高的任务，以抵消其性能提升带来的成本。此外，一些要求所有 Agent 共享相同上下文或 Agent 之间存在诸多依赖关系的领域，目前并不适合多 Agent 系统。例如，大多数编码任务中真正可并行化的任务比研究任务要少，而且 LLM Agent 目前还不擅长实时协调和委托其他 Agent 。我们发现，多 Agent 系统在执行那些需要大量并行化、处理超过单一上下文窗口的信息以及与众多复杂工具交互的有价值任务方面表现出色。

Architecture overview for Research

　　我们的 Research 系统采用具有 orchestrator-worker 模式的多 Agent 架构，其中主 Agent 协调流程，同时委托给并行操作的专门子 Agent。
　　当用户提交查询时，主 Agent 会进行分析，制定策略，并生成子 Agent 来同时探索不同方面。如上图所示，子 Agent 充当智能过滤器，通过迭代使用搜索工具收集信息（在本例中是2025年的AI Agent公司信息），然后将公司列表返回给主 Agent，以便其汇总最终答案。
　　传统使用检索增强生成 (RAG) 的方法采用静态检索。也就是说，它们会获取与输入查询最相似的一组词块，并使用这些词块生成响应。相比之下，我们的架构采用多步骤搜索，可以动态地查找相关信息，适应新的发现，并分析结果以生成高质量的答案。

Prompt engineering and evaluations for research agents

　　多 Agent 系统与单 Agent 系统存在关键区别，包括协调复杂性的快速增长。早期的 Agent 会犯一些错误，例如为了一个简单查询就生成 50 个子 Agent、在网络上无休止地搜索不存在的信息源，以及过度更新导致彼此分心。由于每个 Agent 都由一个 prompt 引导，因此提示工程是我们改进这些行为的主要手段。以下是我们总结的一些用于提示 Agent 的原则：

1. Think like your agents。要迭代 prompt，您必须了解其效果。为了做到这一点，我们使用控制台构建了模拟环境，并配备了系统中完全相同的提示和工具，然后观察 Agent 的逐步操作。这立即揭示了一些失败模式：Agent 在已有足够结果的情况下仍继续操作、使用过于冗长的搜索查询或选择了错误的工具。有效的提示依赖于构建 Agent 的精准心智模型，这可以使最有影响力的改变显而易见。
2. Teach the orchestrator how to delegate。在我们的系统中，首席 Agent 将查询分解为子任务，并将它们描述给子 Agent。每个子 Agent都需要一个目标、一个输出格式、关于使用工具和资源的指导，以及清晰的任务边界。如果没有详细的任务描述，Agent 就会重复工作、留下空白，或者找不到必要的信息。我们最初允许首席 Agent 给出一些简单、简短的指示，例如“研究半导体短缺问题”，但发现这些指示通常非常模糊，以至于子 Agent 会误解任务，或者执行与其他 Agent 完全相同的搜索。例如，一个子 Agent 探索了2021年的汽车芯片危机，而另外两个子 Agent 则重复调查当前的2025年供应链，缺乏有效的分工。
3. Scale effort to query complexity。Agent 难以判断不同任务的合理工作量，因此我们在提示中嵌入了调整规则。简单的事实调查只需 1 名 Agent 调用 3-10 个工具；直接比较可能需要 2-4 名子 Agent，每名子 Agent调用 10-15 个工具；而复杂的研究可能需要 10 名以上子 Agent，并明确划分职责。这些明确的指导原则有助于首席 Agent高效地分配资源，并避免在简单查询上投入过多资源——这在我们早期版本中是一种常见的失败模式。
4. Tool design and selection are critical。Agent 工具界面与人机界面同样重要。使用正确的工具至关重要——通常，这是绝对必要的。例如，一个 Agent 在网络上搜索只存在于 Slack 中的上下文，从一开始就注定要失败。由于 MCP 服务器允许模型访问外部工具，这个问题会变得更加严重，因为 Agent 会遇到一些描述质量参差不齐的、从未见过的工具。我们为 Agent 提供了明确的启发式方法：例如，首先检查所有可用的工具，将工具使用情况与用户意图相匹配，在网络上搜索广泛的外部探索，或者优先选择专用工具而非通用工具。糟糕的工具描述可能会让 Agent 走上完全错误的路径，因此每个工具都需要有明确的用途和清晰的描述。
5. Let agents improve themselves。我们发现，Claude 4 模型可以成为优秀的提示工程师。当给出提示和故障模式时，它们能够诊断 Agent 失败的原因并提出改进建议。我们甚至创建了一个工具测试Agent——当获得一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免故障。通过数十次工具测试，该 Agent 发现了关键的细微差别和错误。这种改进工具人体工程学的过程使未来使用新描述的智能体的任务完成时间缩短了 40%，因为他们能够避免大多数错误。
6. Start wide, then narrow down。搜索策略应效仿专家的人工研究：先探索全局，再深入细节。Agent 通常会默认生成输入过长、具体的查询，但结果却很少。我们通过鼓励 Agent 先从简短、宽泛的查询开始，评估可用的内容，然后逐步缩小范围来抵消这种倾向。
7. Guide the thinking process。 扩展思维模式（long thought）引导 Claude 在可见的思考过程中输出额外的 token，可以充当可控的便笺簿。首席 Agent 运用思维链来规划其方法，评估哪些工具适合该任务，确定查询的复杂性和子 Agent 数量，并定义每个子 Agent 的角色。我们的测试表明，扩展思维链可以提高指令遵循能力、推理能力和效率。子 Agent 也会进行规划，然后在工具结果之后运用交叉思维来评估质量、识别差距并优化下一个查询。这使得子 Agent 能够更有效地适应任何任务。
8. Parallel tool calling transforms speed and performance。复杂的研究任务自然需要探索众多来源。我们早期的 Agent 执行的是顺序搜索，速度非常慢。为了提高速度，我们引入了两种并行化方式：(1) 主 Agent 并行（而非串行）启动 3-5 个子 Agent；(2) 子 Agent并行使用 3 个或以上工具。这些改进将复杂查询的研究时间缩短了高达 90%，使研究团队能够在几分钟内完成更多工作，而不是几小时，同时覆盖比其他系统更多的信息。

我们的提示策略侧重于灌输良好的启发式方法，而非僵化的规则。我们研究了经验丰富的人类如何处理研究任务，并将这些策略融入到我们的提示中——例如将难题分解成更小的任务、仔细评估信息来源的质量、根据新信息调整搜索方法，以及识别何时关注深度（详细研究一个主题）而非广度（并行探索多个主题）。我们还通过设置明确的防护措施，主动缓解意外的副作用，以防止 Agent 失控。最后，我们专注于通过可观察性和测试用例实现快速迭代循环。

Effective evaluation of agents

良好的评估对于构建可靠的人工智能应用至关重要，Agent 也不例外。然而，评估多 Agent 系统面临着独特的挑战。传统的评估方法通常假设人工智能每次都遵循相同的步骤：给定输入 $X$，系统应该遵循路径 $Y$ 来产生输出 $Z$。但多 Agent 系统并非如此运作。即使起点相同，Agent 也可能采取完全不同的有效路径来实现其目标。一个 Agent 可能搜索三个来源，而另一个 Agent 搜索十个，或者它们可能使用不同的工具来找到相同的答案。由于我们并不总是知道正确的步骤是什么，我们通常不能仅仅检查 Agent 是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评估方法来判断 Agent 是否在遵循合理流程的同时实现了正确的结果。
　　Start evaluating immediately with small samples。在 Agent 开发的早期，由于有大量唾手可得的成果，因此更改往往会产生巨大影响。及时调整可能会将成功率从 30% 提高到 80%。由于效果如此之大，您只需几个测试用例即可发现变化。我们从一组大约 20 个代表真实使用模式的查询开始。测试这些查询通常使我们能够清楚地看到变化的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。但是，最好立即从几个示例开始进行小规模测试，而不是拖延到可以构建更全面的评估。
　　LLM-as-judge evaluation scales when done well。研究成果很难通过程序化方式进行评估，因为它们是自由格式的文本，很少有唯一正确答案。LLM 非常适合用于评分。我们使用了一位 LLM 评委，根据评分标准对每项成果进行评估：事实准确性（论断是否与来源相符？）、引用准确性（引用的来源是否与论断相符？）、完整性（是否涵盖了所有要求的方面？）、来源质量（是否使用了一手资料而非质量较低的二手资料？）以及工具效率（是否合理地使用了正确的工具？）。我们尝试使用多位评委来评估每个组成部分，但发现单次 LLM 调用，单个提示输出 0.0-1.0 之间的分数以及通过/不通过的等级，与人工判断最为一致。当评估测试用例确实有明确答案时，这种方法尤其有效，我们可以使用 LLM 评判器简单地检查答案是否正确（例如，它是否准确列出了研发预算排名前三的制药公司？）。使用 LLM 作为评判器使我们能够可扩展地评估数百个输出。
　　Human evaluation catches what automation misses。测试 Agent 的人员会发现评估工具遗漏的极端情况，例如对异常查询的虚假答案、系统故障或细微的来源选择偏差。在我们的案例中，人工测试人员注意到，我们早期的 Agent 始终会选择经过 SEO 优化的内容农场，而不是权威但排名较低的来源，例如学术 PDF 或个人博客。在提示中添加来源质量启发式方法有助于解决这个问题。即使在自动化评估盛行的时代，手动测试仍然至关重要。
　　多 Agent 系统具有涌现行为，这些行为无需特定编程即可产生。例如，对主 Agent 进行微小更改可能会不可预测地改变子 Agent 的行为。成功的关键在于理解交互模式，而不仅仅是单个 Agent 的行为。因此，对这些 Agent 来说，最好的提示不仅仅是严格的指令，而是定义分工、问题解决方法和工作量预算的协作框架。要做到这一点，依赖于精心的提示和工具设计、可靠的启发式算法、可观察性和紧密的反馈回路。 请参阅我们食谱中的开源提示，了解我们系统中的示例提示。

Production reliability and engineering challenges

在传统软件中，错误可能会破坏功能、降低性能或导致中断。在 Agent 系统中，微小的变更会级联引发大规模的行为变更，这使得为必须在长期运行过程中维护状态的复杂 Agent 编写代码变得异常困难。
　　Agents are stateful and errors compound。Agent 可以长时间运行，在多次工具调用中保持状态。这意味着我们需要持久地执行代码并处理过程中的错误。如果没有有效的缓解措施，轻微的系统故障可能会对 Agent 造成灾难性的后果。发生错误时，我们不能从头开始重启：重启不仅成本高昂，还会让用户感到沮丧。因此，我们构建了能够从 AGent 发生错误时的位置恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让 Agent 知道工具何时发生故障，并让其进行调整，效果出奇地好。我们将基于 Claude 构建的 AI AGent 的适应性与重试逻辑和定期检查点等确定性保障措施相结合。
　　Debugging benefits from new approaches。Agent 会做出动态决策，即使提示完全相同，每次运行之间也存在不确定性。这让调试更加困难。例如，用户会报告 Agent“找不到明显的信息”，但我们却找不到原因。Agent 是否使用了错误的搜索查询？选择了错误的来源？还是遇到了工具故障？添加完整的生产跟踪功能使我们能够诊断 Agent 失败的原因并系统地解决问题。除了标准的可观察性之外，我们还监控 Agent 的决策模式和交互结构——所有这些都无需监控单个对话的内容，从而保护用户隐私。这种高级别的可观察性帮助我们诊断根本原因、发现意外行为并修复常见故障。
　　Deployment needs careful coordination。Agent 系统是高度状态化的网络，由提示、工具和执行逻辑组成，几乎持续运行。这意味着，每当我们部署更新时，Agent 都可能处于其进程的任何地方。因此，我们需要防止我们善意的代码更改破坏现有 AGent。我们无法同时将所有 Agent 更新到新版本。相反，我们使用彩虹部署来避免中断正在运行的Agent，方法是逐步将流量从旧版本转移到新版本，同时保持两个版本同时运行。
　　Synchronous execution creates bottlenecks。目前，我们的主 Agent 同步执行子 Agent，等待每组子 Agent完成后再继续执行。这简化了协调，但在 Agent 之间的信息流中造成了瓶颈。例如，主 Agetn 无法引导子 Agent，子 Agent 间无法协调，并且整个系统可能会在等待单个子 Agent 完成搜索时被阻塞。异步执行可以实现更高的并行性：Agent 可以并发工作并在需要时创建新的子 Agent。但是，这种异步性在结果协调、状态一致性以及子 Agent 之间的错误传播方面带来了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能提升将弥补复杂性的增加。

Conclusion

在构建人工智能 Agent 时，最后一英里往往占据了最重要的一步。在开发者机器上运行的代码库需要大量的工程设计才能成为可靠的生产系统。Agent 系统中错误的累积性意味着传统软件的一个小问题就可能彻底破坏 Agent。一步失败就可能导致 Agent 探索完全不同的轨迹，从而导致不可预测的结果。由于本文所述的所有原因，原型和生产之间的差距通常比预期的要大。
　　尽管面临诸多挑战，多 Agent 系统已被证明在开放式研究任务中具有重要价值。用户表示，Claude 帮助他们找到了未曾考虑过的商业机会，引导他们应对复杂的医疗保健方案，解决棘手的技术错误，并通过发现他们独自一人无法发现的研究关联，节省了长达数天的工作时间。多智能体研究系统能够通过精心的工程设计、全面的测试、注重细节的提示和工具设计、强大的操作实践，以及对当前智能体功能有深入理解的研究、产品和工程团队之间的紧密合作，实现大规模可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。

Appendix

以下是针对多 Agent 系统的一些额外的杂项提示。
　　End-state evaluation of agents that mutate state over many turns。评估在多轮对话中修改持久状态的 Agent 面临着独特的挑战。与只读研究任务不同，每个操作都可能改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现专注于最终状态评估而非逐轮分析是成功的。与其判断 Agent 是否遵循了特定的流程，不如评估其是否达到了正确的最终状态。这种方法承认 Agent 可能会找到实现同一目标的替代路径，同时仍能确保其交付预期结果。对于复杂的工作流，应将评估分解为应该发生特定状态变化的离散检查点，而不是试图验证每个中间步骤。
　　Long-horizon conversation management。生产 Agent 通常参与跨越数百轮的对话，需要谨慎的上下文管理策略。随着对话的延长，标准上下文窗口变得不足，需要智能压缩和记忆机制。我们实现了一些模式，Agent 会在执行新任务之前总结已完成的工作阶段，并将重要信息存储在外部存储器中。当上下文接近上限时，Agent 可以生成具有干净上下文的全新子 Agent，同时通过谨慎的交接保持对话的连续性。此外，它们可以从内存中检索存储的上下文（例如研究计划），而不会在达到上下文上限时丢失之前的工作。这种分布式方法可以防止上下文溢出，同时在扩展交互过程中保持对话的连贯性。
　　Subagent output to a filesystem to minimize the ‘game of telephone.’。直接子 Agent 输出可以绕过主协调器，从而提高某些类型结果的保真度和性能。与其要求子 Agent 通过主 Agent传达所有信息，不如实施工件系统，让专门的 Agent 可以创建独立持久的输出。子 Agent 调用工具将其工作存储在外部系统中，然后将轻量级引用传递回协调器。这可以防止在多阶段处理过程中丢失信息，并减少通过对话历史记录复制大量输出所带来的 token 开销。该模式尤其适用于结构化输出，例如代码、报告或数据可视化，在这些情况下，子 Agent 的专用提示比通过通用协调器进行筛选能产生更好的结果。