Claude 现在具备了研究能力,可以在网络、Google Workspace 和任何集成中进行搜索,从而完成复杂任务。
这一多智能体系统从原型到生产的旅程使我们获得了关于系统架构、工具设计和提示工程的重要经验。多智能体系统由多个智能体(LLMs 自主地在一个循环中使用工具)协同工作。我们的研究功能包含一个智能体,它根据用户的查询规划研究过程,然后利用工具创建并行的智能体,以同时搜索信息。多个智能体的系统引入了智能体协调、评估和可靠性的新挑战。
本文将分解我们成功的原则,希望您在构建自己的多智能体系统时能够找到实用的借鉴。
多智能体系统的优势
研究工作涉及开放性的问题,很难事先预测所需的步骤。您不能为复杂主题的探索硬编码固定的路径,因为这一过程本质上是动态和依赖路径的。当人们进行研究时,他们往往会根据发现不断更新自己的方法,追踪在调查过程中出现的线索。
这种不可预测性使得 AI 智能体特别适合研究任务。研究要求在调查展开过程中具备灵活性,可以随时调整方向或探索旁支关系。模型必须自主运行许多轮次,根据中间发现对追求的方向做出决策。线性一锤子买卖的流程无法处理这些任务。
搜索的本质是压缩:从大规模的信息中提炼出见解。子智能体通过各自的上下文窗口并行操作来促进压缩,同时探索问题的不同方面,然后将最重要的标记提炼给主研究智能体。每个子智能体也提供了关注点的分离——不同的工具、提示和探索路径——这减少了路径依赖,使彻底、独立的调查成为可能。
一旦智能达到一定阈值,多智能体系统就成为扩展性能的重要方式。例如,虽然个体人类在过去 10 万年中变得更加聪明,但人类社会在信息时代由于我们集体智力和协调能力变得 指数级 更加强大。即便是通常智能的智能体在运行时也面临限制;而智能体群体可以完成更多的事情。
我们的内部评估显示,尤其是在处理涉及同时追求多个独立方向的广度优先查询时,多智能体研究系统表现出色。我们发现以 Claude Opus 4 作为主智能体,Claude Sonnet 4 作为子智能体的多智能体系统在我们内部研究评估中优于单智能体 Claude Opus 4 高达 90.2%。例如,当被要求识别信息技术 S&P 500 中的所有董事会成员时,多智能体系统通过将任务分解给子智能体找到正确的答案,而单智能体系统则因慢速的顺序搜索未能找到答案。
多智能体系统的主要工作原理在于它们有效地花费足够的标记来解决问题。在我们的分析中,三个因素解释了 BrowseComp 评估中 95% 的性能差异(该评估测试浏览代理定位难以找到信息的能力)。我们发现,仅标记使用就解释了 80% 的差异,其余两者是工具调用的数量和模型选择。这一发现验证了我们将工作分配给具有不同上下文窗口的智能体的架构,以增加并行推理的能力。最新的 Claude 模型在标记使用上充当了大型效率倍增器,因为升级到 Claude Sonnet 4 的性能提升大于将 Claude Sonnet 3.7 的标记预算翻倍。多智能体架构有效地扩展了超出单个智能体能力的任务的标记使用。
但是也有一个缺点:在实践中,这些架构会迅速消耗标记。在我们的数据中,智能体的标记使用量通常是聊天交互的 4 倍,而多智能体系统的标记使用量是聊天的约 15 倍。为了经济可行性,多智能体系统需要在任务中其价值足够高,以支付提高的性能。此外,某些领域需要所有智能体共享相同的上下文或涉及智能体之间的许多依赖关系,这些领域今天并不适合多智能体系统。例如,大多数编码任务涉及的并行化任务实际上少于研究,而 LLM 智能体在实时协调和委派给其他智能体方面仍然表现不佳。我们发现,多智能体系统在需要大量并行化、超出单个上下文窗口的信息以及与许多复杂工具交互的有价值任务中表现出色。
研究架构概述
我们的研究系统采用了多智能体架构,采用协调者-工作者模式,其中主智能体协调过程,同时将任务委派给并行工作的专业子智能体。
多智能体架构的实际应用:用户查询通过主智能体流动,后者创建专业的子智能体以并行搜索不同方面。
当用户提交查询时,主智能体会分析该查询,制定策略,并生成子智能体以同时探索不同方面。如上图所示,子智能体通过迭代使用搜索工具来收集信息,在这种情况下是 2025 年的 AI 智能体公司,然后将公司列表返回给主智能体,以便其汇编出最终答案。
使用增强检索生成(RAG)的传统方法使用静态检索。也就是说,它们提取与输入查询最相似的一组块,并使用这些块生成回应。相反,我们的架构使用多步骤搜索,动态找到相关信息,适应新的发现,并分析结果以制定高质量答案。
流程图展示了我们多智能体研究系统的完整工作流程。当用户提交查询时,系统创建一个 LeadResearcher 智能体,进入一个迭代研究过程。LeadResearcher 首先考虑方法并将其计划保存到内存中,以保持上下文,因为如果上下文窗口超过 200,000 个标记,它将被截断,而保留计划非常重要。然后,它创建具有特定研究任务的专业子智能体(这里显示了两个,但可以是任意数量)。每个子智能体独立进行网页搜索,使用交错思维评估工具结果,并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果,并决定是否需要更多研究——如果需要,它可以创建额外的子智能体或精炼其策略。一旦收集到足够的信息,系统就退出研究循环,将所有发现传递给 CitationAgent,后者处理文档和研究报告,识别引文的特定位置。这确保了所有主张都正确归属其来源。最终的研究结果连同引文一起返回给用户。
研究智能体的提示工程与评估
多智能体系统与单智能体系统有关键区别,包括协调复杂性的快速增长。早期的智能体容易出现错误,例如为简单查询生成 50 个子智能体,无休止地在网络上寻找不存在的来源,或由于更新过于频繁而分散彼此的注意力。由于每个智能体都是由提示驱动的,提示工程成为改善这些行为的主要杠杆。以下是我们为提示智能体而学习的一些原则:
- 像你的智能体一样思考。 为了迭代提示,您必须理解它们的效果。为了帮助我们做到这一点,我们使用我们的控制台进行模拟,使用来自我们系统的确切提示和工具,然后逐步观察智能体的工作。这立即揭示了故障模式:智能体在结果已经足够时继续运行,使用冗长的搜索查询,或者选择不正确的工具。有效的提示依赖于建立对智能体的准确心理模型,这会使最重要的变化显而易见。
- 教会协调者如何委派。 在我们的系统中,主智能体将查询分解为子任务并向子智能体描述它们。每个子智能体需要一个目标、输出格式、工具和来源的使用指南以及明确的任务边界。没有详细的任务描述,智能体会重复工作、留下空白或无法找到必要的信息。我们从允许主智能体给予简单、简短的指令(例如“研究半导体短缺”)开始,但发现这些指令通常模糊到子智能体误解任务或执行与其他智能体相同的搜索。例如,一个子智能体探索了 2021 年的汽车芯片危机,而另外两个智能体重复调查当前 2025 年的供应链,而没能有效划分劳动。
- 根据查询复杂性调整努力规模。 智能体在判断不同任务的适当努力方面存在困难,因此我们在提示中嵌入了规模调整规则。简单的事实查找仅需要 1 个智能体和 3-10 次工具调用,直接比较可能需要 2-4 个子智能体,每个智能体进行 10-15 次调用,而复杂的研究可能需要超过 10 个子智能体并明确划分责任。这些明确的指导原则帮助主智能体有效地分配资源,防止在简单查询中投入过多,这在我们的早期版本中是常见的失败模式。
- 工具设计和选择至关重要。 智能体与工具的接口和人机之间的接口同样重要。使用正确的工具是高效的——往往是绝对必要的。例如,一个在网络上搜索只能在 Slack 中存在背景的智能体注定是失败的。借助MCP 服务器,模型可以访问外部工具,但这个问题会加剧,因为智能体会遇到质量描述各异的未见工具。我们为我们的智能体提供了明确的启发式规则:例如,首先检查所有可用工具,将工具使用与用户意图匹配,广泛搜索网络以进行外部探索,或优先选择专业工具而非通用工具。糟糕的工具描述可能使智能体走上完全错误的道路,因此每个工具都需要有明确的目的和清晰的描述。
- 让智能体自我改进。 我们发现,Claude 4 模型能够成为出色的提示工程师。当给定一个提示和一个失败模式时,它们能够诊断智能体失败的原因并建议改进。我们甚至创建了一个工具测试智能体——当给定一个有缺陷的 MCP 工具时,它尝试使用该工具,然后重写工具描述以避免失败。通过测试该工具数十次,该智能体找到了关键的细微差别和错误。这个改善工具人机交互的过程使未来使用新描述的智能体在任务完成时间上减少了 40%,因为它们能够避免大多数错误。
- 先广后细。 搜索策略应当类似于专家人类的研究:先探索全貌,再深入细节。智能体往往默认使用过长的特定查询,返回很少的结果。我们通过提示智能体先使用简短、广泛的查询,评估可获得的信息,以此来对抗这一趋势,然后逐步缩小焦点。
- 引导思维过程。 扩展思维模式可以使 Claude 输出额外的标记,形成可控的思考记录。主智能体使用思考来规划其方法,评估哪些工具适合任务,确定查询复杂性和子智能体数量,并定义每个子智能体的角色。我们的测试表明,扩展的思维改善了指令的遵循、推理能力和效率。子智能体也会进行思考,然后在工具结果后使用交错思维来评估质量、识别空白、并完善下一步查询。这使得子智能体在适应任何任务时更为有效。
- 并行调用工具提升速度和性能。 复杂的研究任务自然涉及探索许多来源。我们早期的智能体执行顺序搜索,导致效率极为缓慢。为了提高速度,我们引入了两种并行化:主智能体并行启动 3-5 个子智能体,而不是按顺序进行;子智能体并行使用 3 个以上的工具。这些变化将复杂查询的研究时间缩短了多达 90%,使研究能够在数分钟内完成比其他系统更多的工作。
我们的提示策略专注于灌输良好的启发式,而非固定规则。我们研究优秀人类如何处理研究任务,并将这些策略编码在我们的提示中——例如将困难的问题分解为更小的任务、仔细评估来源的质量、根据新信息调整搜索方法,以及识别何时应关注深度(深入探讨一个主题)与广度(并行探索多个主题)。我们还主动减轻了意想不到的副作用,设定了明确的保护措施,防止智能体失控。最后,我们专注于快速迭代循环,确保可观察性和测试案例。
智能体的有效评估
良好的评估对于构建可靠的 AI 应用至关重要,智能体也不例外。然而,评估多智能体系统带来了独特的挑战。传统评估通常假定 AI 每次都遵循相同的步骤:给定输入 X,系统应遵循路径 Y 以生成输出 Z。但多智能体系统并不以这种方式工作。即使从相同的起点出发,智能体也可能采取完全不同的有效路径达到目标。一个智能体可能搜索三个来源,而另一个搜索十个,或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么,所以通常无法简单检查智能体是否遵循了我们事先设定的“正确”步骤。相反,我们需要灵活的评估方法,来判断智能体是否达成了正确的结果,同时也遵循合理的过程。
立即开始用小样本评估。 在早期的智能体开发中,由于存在大量的“低垂的果实”,变化往往会产生显著影响。一个提示的微调可能将成功率从 30% 提升到 80%。当效应值如此之大时,您只需少量测试案例即可识别出变化。我们开始使用约 20 个查询的集合,代表真实的使用模式。测试这些查询往往使我们能够清晰地看到变化的影响。我们经常听到 AI 开发团队推迟创建评估,认为只有带有数百个测试案例的大型评估才有用。然而,最好是立即从少量示例的小规模测试开始,而不是等到能够构建更详尽的评估后再开始。
LLM 作为评判者的评估在做好时会有良好扩展性。 研究输出难以通过程序评估,因为它们是自由格式的文本,且很少有单一的正确答案。LLMs 自然适合评分输出。我们使用 LLM 评判者根据评估标准评估每个输出:事实准确性(声称是否与来源匹配?)、引文准确性(引用的来源是否与主张一致?)、完整性(所有请求的方面是否都涵盖?)、来源质量(是否使用了主要来源而非低质量的二手来源?)和工具效率(是否合理使用了正确的工具?)。我们实验使用了多个评判者来评估每个组件,但发现使用单个 LLM 调用和一个输出从 0.0 到 1.0 的评分与通过-未通过的等级最为一致,并且与人工判断一致。这种方法在评估测试案例 确实 存在明确答案时尤为有效,我们可以使用 LLM 评判者简单检查答案是否正确(即它是否准确列出了研发预算最高的制药公司)。使用 LLM 作为评判者允许我们可扩展地评估数百个输出。
人工评估捕捉自动化遗漏的部分。 测试智能体的人员发现评估遗漏的边缘案例。这些包括在不寻常查询上产生的幻觉答案、系统故障或细微的来源选择偏见。在我们的案例中,人类测试人员注意到我们早期的智能体持续选择 SEO 优化的内容农场,而不是像学术 PDF 或个人博客这样权威但排名较低的来源。将来源质量的启发式添加到我们的提示中有助于解决这个问题。即使在一个自动评估的世界中,人工测试依然是必不可少的。
多智能体系统具有涌现行为,这些行为没有特定的编程。例如,主智能体的小变化可能会不可预测地改变子智能体的行为。成功需要理解交互模式,而不仅仅是单个智能体的行为。因此,对这些智能体最佳的提示不仅是严格的指令,而是协作的框架,以定义劳动分工、解决问题的方法和努力预算。实现这一目标依赖于精心的提示和工具设计、扎实的启发式规则、可观察性和紧密的反馈循环。查看我们的 Cookbook 中的开源提示以获取来自我们系统的示例提示。
生产可靠性和工程挑战
在传统软件中,bug 可能会破坏某个特性、降低性能或导致停机。在智能体系统中,微小的变更可能会引发大的行为变化,这使得为复杂智能体编写 code 以维持状态变得极其困难,尤其是在长期运行的过程中。
智能体是有状态的,错误会累积。 智能体可以长时间运行,在许多工具调用中保持状态。这意味着我们需要耐心地执行代码并处理沿途的错误。如果没有有效的缓解措施,微小的系统故障可能对智能体造成灾难性影响。当错误发生时,我们不能仅从头开始:重启对于用户来说是耗时且令人沮丧的。相反,我们构建了可以在发生错误时从智能体停止的地方恢复的系统。我们还利用模型的智能来优雅地处理问题:例如,通知智能体某个工具正在失败并让它适应,这种方式效果意外地好。我们将基于 Claude 的 AI 智能体的适应性与确定性保护措施(如重试逻辑和定期检查点)结合起来。
调试得益于新方法。 智能体进行动态决策,并且在运行之间是非确定性的,即使提示完全相同。这使调试更加困难。例如,用户会报告智能体“未找到显而易见的信息”,但我们无法看到原因。是智能体使用了糟糕的搜索查询?选择了糟糕的来源?遇到了工具故障?全面的生产跟踪让我们能够诊断智能体失败的原因,并系统性地修复问题。除了标准的可观察性,我们监控智能体的决策模式和交互结构——所有这些都不监控单独对话的内容,以维护用户隐私。这种高层次的可观察性帮助我们诊断根本原因,发现意外行为并修复常见故障。
部署需要仔细协调。 智能体系统是由提示、工具和执行逻辑构成的高度状态化的网络,它们几乎不断运行。这意味着,每当我们部署更新时,智能体可能会处于其过程中的任何位置。因此,我们需要防止我们的良好意图的代码更改破坏现有的智能体。我们不能同时将每个智能体更新到新版本。相反,我们使用彩虹部署来避免干扰正在运行的智能体,通过逐渐将流量从旧版本转移到新版本的方式,同时保持两者的运行。
同步执行造成瓶颈。 目前,我们的主智能体同步执行子智能体,等待每组子智能体完成才能继续。这简化了协调,但在智能体之间的信息流动中造成了瓶颈。例如,主智能体无法引导子智能体,子智能体之间无法协调,而整个系统在等待单个子智能体完成搜索时可能会被阻塞。异步执行将允许额外的并行性:智能体并行工作,并在需要时创建新的子智能体。但是,这种异步性增加了结果协调、状态一致性和错误传播等挑战。随着模型能处理更长更复杂的研究任务,我们预计性能提升将弥补复杂性带来的问题。
结论
在构建 AI 智能体时,最后一公里往往占据了大部分旅程。在开发者机器上工作的代码库,需要大量工程以成为可靠的生产系统。智能体系统中错误的复合性质意味着,传统软件中的微小问题可能会完全 derail 智能体。一步失败可能导致智能体探索完全不同的轨迹,从而导致不可预测的结果。出于在这篇文章中描述的所有原因,原型和生产之间的差距往往比预期的要大。
尽管面临这些挑战,多智能体系统在开放式研究任务中已经证明了其价值。用户表示,Claude 帮助他们发现了之前未考虑的商业机会、导航复杂的医疗选择、解决棘手的技术故障,并通过揭示他们独自无法发现的研究连接,节省了多达数天的工作时间。多智能体研究系统能够在规模较大时可靠运行,前提是具有谨慎的工程、全面的测试、注重细节的提示和工具设计以及扎实的运营实践,同时与对当前智能体能力有深入理解的研究、产品和工程团队紧密合作。我们已经看到这些系统正在改变人们解决复杂问题的方式。
一张 Clio 嵌入式图,展示了人们今天使用研究功能的最常见方式。最常见的用例类别包括开发专业领域的软件系统(10%)、开发和优化专业及技术内容(8%)、制定商业增长和创收策略(8%)、辅助学术研究和教育材料开发(7%),以及研究和核实有关人物、地点或组织的信息(5%)。
感谢
本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。该工作反映了 Anthropic 跨多个团队的集体努力,促成了研究功能的实现。特别感谢 Anthropic 应用工程团队,他们的奉献使这个复杂的多智能体系统投入生产。我们也对早期用户的优秀反馈表示感激。
附录
以下是一些关于多智能体系统的额外杂项提示。
评估在多轮对话中可变状态的智能体的最终状态。 评估在多轮对话中修改持久状态的智能体的过程带来了独特的挑战。与只读研究任务不同,每个行动都可能改变后续步骤的环境,创建依赖关系,而传统评估方法难以处理。我们发现,聚焦于最终状态的评估比逐步分析更为成功。评估智能体是否取得正确的最终状态,而不是判断其是否遵循特定流程。这种方法承认智能体可能找到替代路径达成相同目标,同时确保它们达成预期结果。对于复杂工作流程,将评估分解为离散的检查点,以确保特定的状态变化发生,而不是尝试验证每个中间步骤。
长时间对话管理。 生产智能体通常进行数百轮的对话,这要求谨慎的上下文管理策略。随着对话的延续,标准的上下文窗口变得不足,迫切需要智能压缩和记忆机制。我们实现了智能体总结已完成工作阶段并将必要信息存储到外部内存中的模式,然后再进行新任务。当上下文限额接近时,智能体可以生成新的子智能体以保持清晰的上下文,同时通过小心的交接保持连续性。此外,它们可以从其内存中检索存储的上下文,例如研究计划,而不是在达到上下文限额时丢失先前的工作。这种分布式方法可以防止上下文溢出,同时保持扩展交互的对话一致性。
将子智能体输出到文件系统以最小化“电话游戏”。 在某些类型的结果中,直接的子智能体输出可以绕过主协调者,从而提高准确性和性能。与其要求子智能体通过主智能体通信所有信息,不如实施艺术品系统,让专业的智能体可以独立创建持久输出。子智能体调用工具将其工作存储在外部系统中,然后将轻量级的引用传递回协调者。这防止在多阶段处理中丢失信息,并减少因通过对话历史复制大量输出而产生的标记开销。该模式特别适用于代码、报告或数据可视化等结构化输出,其子智能体的专业提示可以生成比一般协调者更好的结果。
原文链接:https://www.anthropic.com/engineering/built-multi-agent-research-system