【Anthtopic好文】如何搭建多智能体研究系统

https://www.anthropic.com/engineering/multi-agent-research-system

我们是如何搭建多智能体研究系统的

我们的 Research 功能利用多个 Claude 智能体，更高效地探索复杂主题。本文分享了我们在构建该系统过程中遇到的工程挑战和经验教训。

Claude 现已具备Research 能力，可以在网络、Google Workspace 及各种集成环境中搜索，以完成复杂任务。

这个多智能体系统从原型到生产的历程，让我们在系统架构、工具设计和提示词工程方面获得了关键经验。多智能体系统由多个智能体（LLM 自动循环调用工具）协同工作。我们的 Research 功能包含一个智能体，根据用户查询规划研究流程，然后利用工具创建并行智能体同时搜索信息。多智能体系统带来了智能体协调、评估和可靠性等新挑战。

本文将拆解我们实践中有效的原则——希望你在构建自己的多智能体系统时也能有所借鉴。

多智能体系统的优势

研究工作通常是开放性问题，很难提前预测所需步骤。你无法为探索复杂主题硬编码一条固定路径，因为过程本质上是动态且依赖路径的。人们进行研究时，会根据新发现不断调整方法，跟随调查过程中出现的线索。

这种不可预测性使得 AI 智能体非常适合研究任务。研究需要在调查过程中灵活转向或探索相关连接。模型必须能自主运行多轮，根据中间发现决定下一步方向。线性的一次性流程无法胜任这些任务。

搜索的本质是压缩：从海量语料中提炼洞见。 子智能体通过各自的上下文窗口并行运行，探索问题的不同方面，然后将最重要的 token 压缩给主研究智能体。每个子智能体还实现了关注点分离——不同的工具、提示词和探索路径——这减少了路径依赖，使调查更彻底、独立。

一旦智能达到一定门槛，多智能体系统就成为扩展性能的关键方式。例如，虽然个体人类在过去十万年变得更聪明，但信息时代的人类社会因集体智能和协作能力而变得指数级强大。即使是通用智能体，单独行动也有极限；智能体群体能完成更多任务。

我们的内部评估显示，多智能体研究系统在需要同时追踪多个独立方向的广度优先查询中表现尤为突出。我们发现，以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在内部研究评测中比单智能体 Claude Opus 4 高出 90.2%。例如，查询 S&P 500 信息技术公司所有董事会成员时，多智能体系统通过任务分解让子智能体分别查找，最终找到正确答案，而单智能体系统用缓慢的串行搜索未能找到。

多智能体系统之所以有效，主要是因为它们能消耗足够的 token 来解决问题。我们的分析发现，在 BrowseComp 评测（测试浏览智能体定位难找信息的能力）中，三个因素解释了 95% 的性能差异：token 使用量占 80%，工具调用次数和模型选择是另外两个解释因素。这验证了我们将工作分配到拥有独立上下文窗口的智能体架构，提升了并行推理能力。最新的 Claude 模型在 token 使用效率上提升巨大，升级到 Claude Sonnet 4 比将 Claude Sonnet 3.7 的 token 翻倍还有效。多智能体架构能有效扩展 token 用量，适用于超出单智能体极限的任务。

但也有缺点：实际中这些架构消耗 token 很快。我们的数据表明，智能体通常比聊天交互多用约 4 倍 token，多智能体系统则比聊天多用约 15 倍 token。要实现经济可行性，多智能体系统需用于任务价值足以支付性能提升的场景。此外，要求所有智能体共享同一上下文或智能体间依赖性很强的领域，目前并不适合多智能体系统。 例如，大多数编程任务真正可并行化的部分远少于研究，LLM 智能体在实时协调和委派方面也还不够强。我们发现，多智能体系统在需要高度并行、信息超出单一上下文窗口、需对接大量复杂工具的高价值任务中表现最佳。

Research 架构概述

我们的 Research 系统采用多智能体架构，采用协调者-工作者模式：主智能体负责整体协调，并将任务分配给并行运行的专业子智能体。

多智能体架构实际运行时：用户查询经主智能体流转，主智能体创建专业子智能体并行搜索不同方面。

当用户提交查询时，主智能体会分析问题、制定策略，并生成子智能体同时探索不同方向。如上图所示，子智能体通过迭代使用搜索工具收集信息（如 2025 年 AI 智能体公司），然后将公司列表返回给主智能体，由主智能体汇总最终答案。

传统的检索增强生成（RAG）方法采用静态检索，即获取与输入查询最相似的一组片段，用这些片段生成回复。而我们的架构采用多步搜索，动态发现相关信息，适应新发现，并分析结果以形成高质量答案。

流程图展示了我们多智能体 Research 系统的完整工作流。用户提交查询后，系统创建 LeadResearcher 智能体，进入迭代研究流程。LeadResearcher 首先思考方法并将计划保存到 Memory，以持久化上下文（因为上下文窗口超过 200,000 token 时会被截断，保留计划很重要）。随后创建专业子智能体（图中示例为两个，实际可任意数量），分配具体研究任务。每个子智能体独立进行网页搜索，利用交错思考评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，决定是否需要进一步研究——如有需要，可再创建子智能体或优化策略。当信息收集充分后，系统退出研究循环，将所有发现交给 CitationAgent，由其处理文档和研究报告，定位具体引用位置，确保所有论据均有来源。最终研究结果（含引用）返回给用户。

研究智能体的提示词工程与评估

多智能体系统与单智能体系统有显著不同，协调复杂度急剧增加。早期智能体会犯一些错误，比如对简单查询生成 50 个子智能体、无休止地在网上搜索不存在的信息、互相干扰频繁更新。由于每个智能体都由提示词驱动，提示词工程是我们优化行为的主要手段。以下是我们在智能体提示词设计中总结的原则：

1. 像你的智能体一样思考。 要迭代提示词，必须理解其效果。为此，我们用系统中的真实提示词和工具在Console中搭建模拟，观察智能体逐步工作。这能立刻暴露失败模式：智能体在结果已足够时还继续、搜索查询过于冗长、选择了错误工具。有效的提示词依赖于对智能体的准确心智模型，这样最有影响力的改动会变得显而易见。
2. 教会协调者如何分工。 在我们的系统中，主智能体将查询拆分为子任务并描述给子智能体。每个子智能体需要目标、输出格式、工具和信息源指引，以及明确的任务边界。没有详细任务描述，智能体会重复劳动、遗漏内容或找不到必要信息。我们一开始让主智能体只给出简单指令如“研究半导体短缺”，但发现这些指令太模糊，子智能体容易误解任务或做出完全相同的搜索。例如，一个子智能体查 2021 年汽车芯片危机，另外两个重复查 2025 年供应链，分工不明确。
3. 根据查询复杂度分配努力。 智能体难以判断不同任务所需努力，因此我们在提示词中嵌入了分级规则。简单事实查找只需 1 个智能体、3-10 次工具调用；直接对比可能需要 2-4 个子智能体、每个 10-15 次调用；复杂研究则用 10 个以上子智能体，职责明确。这些显式指南帮助主智能体高效分配资源，防止在简单查询上过度投入，这是早期常见的失败模式。
4. 工具设计与选择至关重要。 智能体-工具接口和人机接口一样重要。用对工具很高效——有时是必须的。例如，智能体在网页上查只存在于 Slack 的信息，注定失败。随着MCP 服务器让模型能访问外部工具，这个问题更复杂，智能体会遇到描述质量参差不齐的新工具。我们给智能体明确的启发式：如先浏览所有可用工具、工具使用要匹配用户意图、广泛探索用网页搜索、优先用专业工具而非通用工具。糟糕的工具描述会让智能体走错路，因此每个工具都需有明确目的和清晰描述。
5. 让智能体自我改进。 我们发现 Claude 4 模型本身就是优秀的提示词工程师。给定提示词和失败模式，它能诊断智能体为何失败并提出改进建议。我们甚至创建了工具测试智能体——给它一个有缺陷的 MCP 工具，让它尝试使用并重写工具描述以避免失败。经过数十次测试，这个智能体发现了关键细节和 bug。改进工具易用性的过程让后续智能体任务完成时间缩短了 40%，因为能避免大多数错误。
6. 先广后深。 搜索策略应像专家人类研究一样：先广泛探索，再深入细节。智能体常常默认用过长、过细的查询，结果很少。我们通过提示词引导智能体先用简短、宽泛的查询，评估可用信息，再逐步聚焦。
7. 引导思考过程。 扩展思考模式让 Claude 输出更多可见思考 token，可作为可控的草稿板。主智能体用思考规划方法，评估哪些工具适合任务、确定查询复杂度和子智能体数量、定义每个子智能体角色。我们的测试显示，扩展思考提升了指令遵循、推理和效率。子智能体也会先规划，再在工具结果后用交错思考评估质量、发现缺口、优化下一步查询。这让子智能体更能适应各种任务。
8. 并行工具调用极大提升速度和性能。 复杂研究任务天然需要探索大量信息源。早期智能体串行搜索，速度极慢。为提速，我们引入了两种并行：1）主智能体并行生成 3-5 个子智能体，而非串行；2）子智能体并行调用 3 个以上工具。这些改动让复杂查询研究时间缩短高达 90%，几分钟内完成原本需数小时的工作，覆盖信息也更多。

我们的提示词策略注重灌输良好启发式而非死板规则。我们研究了人类专家如何开展研究，并将这些策略编码进提示词——如将难题拆分为小任务、仔细评估信息源质量、根据新信息调整搜索方法、识别何时聚焦深度（细查一个主题）与广度（并行查多个主题）。我们还主动设置显式防护，防止智能体失控。最后，专注于快速迭代、可观测性和测试用例。

智能体的有效评估

良好的评估对构建可靠的 AI 应用至关重要，智能体也不例外。但多智能体系统评估有独特挑战。传统评估假定 AI 每次都走同样的步骤：输入 X，系统应按路径 Y 得到输出 Z。但多智能体系统不是这样。即使起点相同，智能体也可能走完全不同但有效的路径达成目标。一个智能体查 3 个信息源，另一个查 10 个，或用不同工具找到同一答案。因为我们通常不知道“正确”步骤是什么，无法只检查智能体是否按预设流程执行。我们需要灵活的评估方法，既判断智能体是否达成正确结果，也关注其过程是否合理。

立即用小样本开始评估。 智能体开发早期，改动影响巨大，因有大量“低垂果实”。提示词微调能让成功率从 30% 提升到 80%。效果如此明显，只需几个测试用例就能看出变化。我们一开始用约 20 个真实使用场景的查询，测试这些查询能清楚看到改动影响。常听到 AI 开发团队因认为只有数百测试用例的大型评测才有用而拖延评估，但其实最好立刻用少量样例小规模测试，而不是等到能做更全面评测。

LLM 评审法规模化效果好。 研究输出难以程序化评估，因为是自由文本，很少有唯一正确答案。LLM 天然适合评分输出。我们用 LLM 评审，按评分标准评估每个输出：事实准确性（论据是否与来源一致）、引用准确性（引用是否与论据匹配）、完整性（所有要求方面是否覆盖）、信息源质量（是否用主信息源而非低质量二手源）、工具效率（是否合理调用工具次数）。我们尝试过多个评审智能体，但发现用单次 LLM 调用、单一提示词输出 0.0-1.0 分和通过/未通过结果，最一致且与人工判断最吻合。此法在评测用例有明确答案时尤其有效，比如只需检查答案是否正确（如是否准确列出研发预算前三的制药公司）。用 LLM 评审让我们能规模化评估数百个输出。

人工评测能发现自动化遗漏。 人工测试智能体能发现评测遗漏的边缘案例，包括异常查询下的幻觉答案、系统故障、信息源选择偏差。我们早期智能体常选 SEO 优化内容农场而非权威但排名低的学术 PDF 或个人博客。为此我们在提示词中加入信息源质量启发式，解决了这个问题。即使自动化评测普及，人工测试仍不可或缺。

多智能体系统有涌现行为，非特定编程产生。例如，主智能体的小改动会不可预测地改变子智能体行为。成功需要理解交互模式，而不仅是单个智能体行为。因此，最好的提示词不是死板指令，而是协作框架，定义分工、解题方法和努力预算。做到这一点依赖于精心的提示词和工具设计、扎实的启发式、可观测性和紧密反馈循环。可参考我们系统的开源 Cookbook 提示词。

生产可靠性与工程挑战

传统软件中，一个 bug 可能导致功能损坏、性能下降或宕机。在智能体系统中，微小改动会引发巨大行为变化，使得为复杂智能体编写长期维护状态的代码极具挑战。

智能体有状态，错误会累积。 智能体可长时间运行，跨多次工具调用保持状态。这要求我们能持久执行代码并处理过程中出现的错误。没有有效缓解措施，微小系统故障对智能体可能是灾难性的。出错时不能简单重启：重启代价高且用户体验差。我们构建了能从错误发生点恢复的系统，也利用模型智能优雅处理问题：如让智能体知道工具失效并自适应，效果出奇地好。我们结合了 Claude 智能体的适应性和确定性保障，如重试逻辑和定期检查点。

调试需新方法。 智能体决策动态，即使提示词相同，每次运行也不确定。这让调试更难。例如，用户反馈智能体“找不到明显信息”，但我们无法定位原因。是搜索查询不好？信息源选择差？工具故障？加入全量生产追踪让我们能系统诊断智能体失败原因并修复。除了标准可观测性，我们还监控智能体决策模式和交互结构——无需监控具体对话内容，保护用户隐私。高层次可观测性帮助我们定位根因、发现异常行为并修复常见故障。

部署需精细协调。 智能体系统是高度有状态的提示词、工具和执行逻辑网络，几乎持续运行。每次部署更新时，智能体可能处于流程任意阶段，因此需防止善意代码改动破坏现有智能体。不能让所有智能体同时升级新版本，而是采用彩虹部署，逐步将流量从旧版本切换到新版本，保证两者并行运行，避免干扰。

同步执行带来瓶颈。 目前主智能体同步执行子智能体，需等一批子智能体全部完成才能继续。这简化了协调，但造成智能体间信息流瓶颈。例如，主智能体无法实时引导子智能体，子智能体间无法协调，整个系统可能因一个子智能体搜索未完成而阻塞。异步执行可带来更多并行：智能体可同时工作并按需生成新子智能体。但异步也带来结果协调、状态一致性和错误传播等新挑战。随着模型能处理更长更复杂研究任务，我们预计性能提升将值得这些复杂性。

结论

构建 AI 智能体时，最后一公里往往变成了整个旅程。能在开发者机器上运行的代码库，要变成可靠的生产系统需要大量工程投入。智能体系统的错误是复合的，传统软件中的小问题可能让智能体完全失控。一步失败会让智能体走向完全不同的轨迹，结果不可预测。正如本文所述，原型到生产的鸿沟往往比预期更大。

尽管有这些挑战，多智能体系统在开放性研究任务中已展现巨大价值。用户反馈 Claude 帮他们发现未曾考虑的商业机会、应对复杂医疗选择、解决棘手技术 bug，并通过发现研究关联节省了数天工作。只要有细致工程、全面测试、精细提示词和工具设计、健全运维实践，以及研究、产品、工程团队紧密协作、深刻理解智能体能力，多智能体研究系统就能可靠规模化运行。我们已看到这些系统正在改变人们解决复杂问题的方式。

Clio 嵌入图展示了用户当前使用 Research 功能的主要方式。最常见用例包括跨专业领域开发软件系统（10%）、开发和优化专业技术内容（8%）、制定业务增长和营收策略（8%）、协助学术研究和教材开发（7%）、研究和核查人物、地点或组织信息（5%）。

附录

以下是多智能体系统的一些补充技巧。

多轮变更状态智能体的终态评估。 评估跨多轮对持久状态进行修改的智能体有独特挑战。与只读研究任务不同，每步操作都会改变后续环境，产生依赖，传统评估方法难以应对。我们发现关注终态评估而非逐步分析更有效。不要只判断智能体是否按特定流程执行，而是看最终状态是否达成目标。这种方法承认智能体可能用不同路径达成同一目标，同时确保结果正确。复杂流程可将评估拆分为若干检查点，关注特定状态变化，而非验证每一步。

长周期对话管理。 生产智能体常需处理数百轮对话，需精细上下文管理。对话延长后，标准上下文窗口不够用，需智能压缩和记忆机制。我们采用智能体总结已完成阶段并将关键信息存入外部内存，再进入新任务。上下文接近极限时，智能体可生成新子智能体，拥有干净上下文，通过精细交接保持连续性。还可从内存中检索如研究计划等已存上下文，避免因上下文溢出丢失前期工作。这种分布式方法防止上下文溢出，保证长对话连贯。

子智能体输出到文件系统，减少“传话游戏”。 某些结果可让子智能体直接输出，绕过主协调者，提高保真度和性能。无需所有内容都经主智能体传递，可实现工件系统，让专业智能体独立生成持久输出。子智能体调用工具将成果存入外部系统，再将轻量引用返回协调者。这样可防止多阶段处理时信息丢失，减少因在对话历史中复制大输出而带来的 token 开销。该模式对代码、报告、数据可视化等结构化输出尤为有效，专业智能体的提示词能比通用协调者过滤后效果更好。