我们的研究功能使用多个 Claude 智能体来更有效地探索复杂主题。我们分享了构建此系统时遇到的工程挑战和经验教训。
Claude 现在具备研究能力，可以跨网络、Google Workspace 以及任何集成进行搜索，以完成复杂任务。
这个多智能体系统从原型到产品的过程，让我们在系统架构、工具设计和提示工程方面学到了宝贵的经验。多智能体系统由多个智能体（自主循环使用工具的 LLM）协同工作。我们的研究功能涉及一个智能体，它根据用户查询规划研究过程，然后使用工具创建并行的智能体，同时搜索信息。多智能体系统在智能体协调、评估和可靠性方面带来了新的挑战。
本文分解了对我们行之有效的原则——我们希望您在构建自己的多智能体系统时会发现它们很有用。
多智能体系统的好处
研究工作涉及开放式问题，很难预先预测所需的步骤。您无法为探索复杂主题硬编码固定的路径，因为这个过程本质上是动态和路径依赖的。当人们进行研究时，他们倾向于根据发现不断更新他们的方法，跟随调查过程中出现的线索。
这种不可预测性使得人工智能智能体特别适合研究任务。研究要求在调查展开时具有转向或探索切向联系的灵活性。模型必须自主运行多个回合，根据中间发现决定追求哪个方向。线性的、一次性的管道无法处理这些任务。
搜索的本质是压缩：从庞大的语料库中提炼见解。子智能体通过在各自的上下文窗口中并行操作来促进压缩，在为主要研究智能体浓缩最重要的令牌之前，同时探索问题的不同方面。每个子智能体还提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖，并实现了彻底、独立的调查。
一旦智能达到一个阈值，多智能体系统就成为扩展性能的重要途径。例如，尽管在过去 10 万年中，个体人类变得更加智能，但由于我们的集体智能和协调能力，人类社会在信息时代的能力呈指数级增长。即使是通用智能的智能体在作为个体操作时也会面临限制；智能体群体可以完成更多的工作。
我们的内部评估表明，多智能体研究系统特别擅长于广度优先的查询，这些查询涉及同时追求多个独立的方向。我们发现，一个以 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 智能体在实时协调和委托给其他智能体方面还不是很出色。我们发现，多智能体系统在涉及大量并行化、信息超出单个上下文窗口以及与众多复杂工具接口的有价值任务中表现出色。
研究架构概述
我们的研究系统使用多智能体架构，采用编排者-工作者模式，其中一个主要智能体协调过程，同时委托给并行操作的专门子智能体。
多智能体架构的实际应用：用户查询流经一个主要智能体，该智能体创建专门的子智能体以并行搜索不同方面。
当用户提交查询时，主要智能体对其进行分析，制定策略，并生成子智能体以同时探索不同方面。如上图所示，子智能体充当智能过滤器，通过迭代使用搜索工具收集信息（在本例中是关于 2025 年的人工智能智能体公司），然后将公司列表返回给主要智能体，以便其编译最终答案。
使用检索增强生成（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 在可见的思维过程中输出额外的令牌，可以作为一个可控的草稿纸。主要智能体使用思维来规划其方法，评估哪些工具适合任务，确定查询复杂性和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思维提高了指令遵循、推理和效率。子智能体也进行规划，然后在工具结果后使用交错思维来评估质量、识别差距并完善其下一个查询。这使得子智能体能更有效地适应任何任务。
- 并行工具调用改变了速度和性能。复杂的研究任务自然涉及探索许多来源。我们早期的智能体执行顺序搜索，速度非常慢。为了提高速度，我们引入了两种并行化：(1) 主要智能体并行启动 3-5 个子智能体，而不是串行启动；(2) 子智能体并行使用 3 个以上的工具。这些更改将复杂查询的研究时间缩短了高达 90%，使“研究”功能能够在几分钟而不是几小时内完成更多工作，同时比其他系统覆盖更多信息。
我们的提示策略侧重于灌输良好的启发式方法，而不是僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的提示中——诸如将难题分解为更小的任务、仔细评估来源质量、根据新信息调整搜索方法，以及认识到何时应侧重于深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外的副作用，以防止智能体失控。最后，我们专注于一个具有可观察性和测试用例的快速迭代循环。
对智能体进行有效评估
良好的评估对于构建可靠的人工智能应用程序至关重要，智能体也不例外。然而，评估多智能体系统提出了独特的挑战。传统评估通常假设人工智能每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 以产生输出 Z。但多智能体系统并非如此。即使起点相同，智能体也可能采取完全不同的有效路径来达到其目标。一个智能体可能搜索三个来源，而另一个搜索十个，或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常不能仅仅检查智能体是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评估方法，以判断智能体是否取得了正确的结果，同时遵循了合理的过程。
立即开始用小样本进行评估。在智能体开发的早期，由于存在大量唾手可得的成果，变更往往会产生巨大的影响。一个提示的调整可能会将成功率从 30% 提高到 80%。在如此大的效应量下，你只需几个测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询集开始。测试这些查询通常能让我们清楚地看到变化的影响。我们经常听说人工智能开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好是立即从几个例子开始进行小规模测试，而不是等到可以构建更全面的评估时再开始。
LLM-as-judge 评估在做得好时可以扩展。研究产出很难通过编程进行评估，因为它们是自由格式的文本，很少有唯一的正确答案。LLM 自然适合对产出进行评分。我们使用了一个 LLM 评委，它根据一个评分标准中的标准来评估每个产出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有被要求的方面？）、来源质量（它是否使用了主要来源而不是质量较低的次要来源？），以及工具效率（它是否合理地使用了正确的工具？）。我们尝试了多个评委来评估每个部分，但发现单个 LLM 调用，使用单个提示输出 0.0-1.0 的分数和一个通过/失败的等级，是最一致且与人类判断最相符的。当评估测试用例确实有明确答案时，这种方法尤其有效，我们可以使用 LLM 评委简单地检查答案是否正确（即，它是否准确地列出了研发预算前三名的制药公司？）。使用 LLM 作为评委使我们能够可扩展地评估数百个产出。
人工评估能捕捉到自动化所遗漏的东西。测试智能体的人员会发现评估所遗漏的边缘情况。这些情况包括对不寻常查询的幻觉性回答、系统故障或微妙的来源选择偏见。在我们的案例中，人工测试人员注意到，我们早期的智能体始终选择经过 SEO 优化的内容农场，而不是像学术 PDF 或个人博客这样权威但排名不高的来源。在我们的提示中加入来源质量启发式方法帮助解决了这个问题。即使在自动化评估的世界里，手动测试仍然至关重要。
多智能体系统具有涌现行为，这些行为是在没有特定编程的情况下出现的。例如，对主要智能体的微小改变会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体的行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义了分工、解决问题的方法和投入预算的协作框架。要做到这一点，需要仔细的提示和工具设计、可靠的启发式方法、可观察性以及紧密的反馈循环。请参阅我们Cookbook 中的开源提示以获取我们系统中的示例提示。
生产可靠性和工程挑战
在传统软件中，一个 bug 可能会破坏一个功能、降低性能或导致服务中断。在智能体系统中，微小的变化会级联成巨大的行为变化，这使得为必须在长期运行过程中维持状态的复杂智能体编写代码变得异常困难。
智能体是有状态的，错误会累积。智能体可以长时间运行，在多次工具调用中维持状态。这意味着我们需要持久地执行代码并处理沿途的错误。没有有效的缓解措施，微小的系统故障对智能体来说可能是灾难性的。当错误发生时，我们不能简单地从头开始：重启既昂贵又让用户感到沮丧。相反，我们构建了可以从智能体出错的地方恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让智能体知道工具何时出现故障并让其适应，效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障措施相结合。
调试受益于新方法。智能体做出动态决策，并且即使提示相同，每次运行之间也是非确定性的。这使得调试更加困难。例如，用户会报告智能体“找不到明显的信息”，但我们看不出原因。是智能体使用了错误的搜索查询吗？选择了糟糕的来源？遇到了工具故障？添加完整的生产跟踪让我们能够诊断智能体失败的原因并系统地解决问题。除了标准的可观察性，我们还监控智能体的决策模式和交互结构——所有这些都在不监控单个对话内容的情况下进行，以维护用户隐私。这种高层次的可观察性帮助我们诊断根本原因、发现意外行为并修复常见故障。
部署需要仔细协调。智能体系统是高度状态化的，由提示、工具和几乎连续运行的执行逻辑组成。这意味着无论何时我们部署更新，智能体可能处于其流程的任何位置。因此，我们需要防止我们善意的代码更改破坏现有智能体。我们不能同时将所有智能体更新到新版本。相反，我们使用彩虹部署来避免干扰正在运行的智能体，方法是逐渐将流量从旧版本转移到新版本，同时保持两者同时运行。
同步执行会造成瓶颈。目前，我们的主要智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈。例如，主要智能体无法引导子智能体，子智能体之间无法协调，整个系统可能会因等待单个子智能体完成搜索而被阻塞。异步执行将实现额外的并行性：智能体可以并发工作，并在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性以及跨子智能体的错误传播方面增加了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能的提升将证明这种复杂性是值得的。
结论
在构建人工智能智能体时，最后一英里往往成为旅程的大部分。在开发人员机器上工作的代码库需要大量的工程才能成为可靠的生产系统。智能体系统中错误的复合性质意味着，传统软件的微小问题可能会完全让智能体脱轨。一个步骤的失败可能导致智能体探索完全不同的轨迹，从而导致不可预测的结果。由于本文中描述的所有原因，原型和生产之间的差距往往比预期的要大。
尽管存在这些挑战，多智能体系统在开放式研究任务中已被证明是有价值的。用户表示，Claude 帮助他们找到了他们没有考虑过的商业机会，驾驭了复杂的医疗保健选择，解决了棘手的技术错误，并通过发现他们自己不会找到的研究联系，节省了长达数天的工作时间。通过精心的工程、全面的测试、注重细节的提示和工具设计、稳健的操作实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统可以可靠地大规模运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。
一个 Clio 嵌入图，显示了人们今天使用研究功能的最常见方式。排名前列的用例类别是：在专业领域开发软件系统（10%）、开发和优化专业及技术内容（8%）、制定业务增长和收入生成策略（8%）、协助学术研究和教育材料开发（7%），以及研究和验证关于人物、地点或组织的信息（5%）。
致谢
由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作反映了 Anthropic 多个团队的集体努力，他们使研究功能成为可能。特别感谢 Anthropic 应用程序工程团队，他们的奉献精神将这个复杂的多智能体系统带到了生产环境中。我们也感谢我们的早期用户提供了宝贵的反馈。
附录
以下是关于多智能体系统的一些额外杂项提示。
对多回合改变状态的智能体进行最终状态评估。评估在多回合对话中修改持久状态的智能体提出了独特的挑战。与只读研究任务不同，每个动作都可以改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现，专注于最终状态评估而不是逐回合分析是成功的。与其判断智能体是否遵循了特定的过程，不如评估它是否达到了正确的最终状态。这种方法承认智能体可能会找到达到相同目标的不同路径，同时仍确保它们提供预期的结果。对于复杂的工作流，将评估分解为离散的检查点，在这些检查点上应该已经发生了特定的状态变化，而不是试图验证每个中间步骤。
长跨度对话管理。生产环境中的智能体通常会进行跨越数百回合的对话，这需要谨慎的上下文管理策略。随着对话的延长，标准的上下文窗口变得不足，需要智能压缩和记忆机制。我们实现了一些模式，其中智能体在进入新任务之前，会总结已完成的工作阶段，并将基本信息存储在外部存储器中。当接近上下文限制时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接保持连续性。此外，当达到上下文限制时，它们可以从其存储器中检索存储的上下文，如研究计划，而不是丢失先前的工作。这种分布式方法可以防止上下文溢出，同时在扩展交互中保持对话的连贯性。
子智能体输出到文件系统以最小化“传话游戏”的影响。直接的子智能体输出可以绕过主协调器处理某些类型的结果，从而提高保真度和性能。与其要求子智能体通过主智能体传达所有信息，不如实施工件系统，让专门的智能体可以创建独立持久化的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传回协调器。这可以防止在多阶段处理过程中信息丢失，并减少因通过对话历史复制大量输出而产生的令牌开销。这种模式特别适用于结构化输出，如代码、报告或数据可视化，因为子智能体的专门提示比通过通用协调器过滤产生更好的结果。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
