目录
- 一、多代理系统的优势
- 二、Research 的架构概览
- 三、Research Agent 的提示工程与评测
- 四、如何有效评测 Agent
- 五、生产可靠性与工程挑战
- 六、总结
- 七、致谢
- 八、附录
- TODO
一、多代理系统的优势
Claude 现在已经具备 Research capabilities，可以跨网页、Google Workspace 以及各类集成工具进行搜索，从而完成复杂任务。
这个多代理系统从原型走向生产的过程，让我们在系统架构、工具设计和提示词工程上学到了不少关键经验。所谓多代理系统，是指由多个 agent 组成的系统，这些 agent 会在循环中自主调用工具并协同工作。我们的 Research 功能中，有一个 agent 会根据用户查询规划研究流程，然后通过工具创建并行 agent，同时搜索信息。多代理系统也会引入一些新的挑战，例如 agent 协调、评测以及可靠性问题。
这篇文章将拆解那些对我们真正有效的原则。希望这些经验也能帮助你构建自己的多代理系统。
研究类工作通常是开放式问题，很难提前准确预测完成任务所需的步骤。面对复杂主题时，你无法把探索路径硬编码成一条固定流程，因为整个过程天生就是动态的，而且会受到前一步发现的影响。人类做研究时，往往也是一边调查、一边根据新发现调整方法，沿着过程中浮现出来的线索继续追踪。
这种不可预测性，使得 AI agent 特别适合研究任务。研究要求系统在调查过程中具备随时转向、或者探索旁支线索的灵活性。模型必须在很多轮交互中自主运行，根据中间发现决定下一步往哪里走。线性的、一次性完成的 pipeline 无法胜任这类任务。
搜索的本质是压缩，也就是从庞大的语料中提炼出有价值的洞见。子代理之所以有用，是因为它们可以带着各自独立的上下文窗口并行工作，同时探索问题的不同方面，然后再把最重要的信息压缩后交给主研究代理。每个子代理也天然形成了关注点分离，可以拥有不同的工具、提示词和探索轨迹，从而降低路径依赖，让调查更全面、更独立。
一旦智能达到某个阈值，多代理系统就会成为扩展性能的重要方式。举例来说，虽然过去 10 万年里单个人类个体变得更聪明了，但在信息时代，人类社会之所以呈指数级变强，靠的是群体智能以及协调能力。即使是具备通用智能的 agent，单独工作时也会受到限制；而一组 agent 协作时，能完成的事情会多得多。
我们的内部评测显示，多代理 Research 系统在那种需要同时沿多个独立方向展开的广度优先型查询上，表现尤其出色。我们发现，以 Claude Opus 4 作为主代理、Claude Sonnet 4 作为子代理的多代理系统，在内部 research eval 上，相比单代理 Claude Opus 4 的表现提升了 90.2%。例如，当系统被要求找出标普 500 信息技术板块公司全部董事会成员时，多代理系统可以把这个问题拆分给多个子代理分别处理，因此能够得到正确答案；而单代理系统只能缓慢地串行搜索，最终没能找到答案。
多代理系统之所以有效，很大程度上是因为它让系统愿意花足够多的 token 去解决问题。在我们的分析中，BrowseComp 评测中的性能方差，有 95% 可以由三个因素解释。这个评测主要测试浏览型 agent 寻找难检索信息的能力。我们发现，仅 token 用量这一项，就解释了其中 80% 的方差；另外两个因素是工具调用次数和模型选择。这个结果验证了我们的架构思路：通过拥有独立上下文窗口的多个 agent 分担工作，为并行推理增加更多容量。最新一代 Claude 模型会显著提升 token 的使用效率。比如，从 Claude Sonnet 3.7 升级到 Claude Sonnet 4，带来的性能提升比在 Claude Sonnet 3.7 上把 token 预算翻倍还要大。对于超出单代理能力上限的任务，多代理架构实际上是一种扩展 token 使用规模的有效方式。
当然，这种架构也有明显的代价：它在实际使用中会非常快地消耗 token。根据我们的数据，普通 agent 的 token 用量大约是聊天交互的 4 倍，而多代理系统的 token 用量大约是聊天交互的 15 倍。要想在经济上可行，多代理系统必须应用于那些任务价值足够高、能够覆盖额外性能成本的场景。进一步说，一些要求所有 agent 共享同一上下文，或者 agent 之间依赖关系非常多的领域，今天并不适合多代理系统。比如，大多数 coding 任务里，真正能并行化的部分就比 research 少得多，而且 LLM agent 目前也还不擅长实时协调和向其他 agent 做任务委派。我们的经验是，多代理系统最适合那些高价值、可高度并行、信息量超过单一上下文窗口、并且需要对接大量复杂工具的任务。
二、Research 的架构概览
我们的 Research 系统采用了多代理架构，并使用 orchestrator-worker 模式：由一个主代理负责整体协调，同时把任务委派给并行运行的专用子代理。
上图展示了多代理架构的实际工作方式：用户查询先进入主代理，由它创建多个专门的子代理，并行搜索问题的不同部分。
当用户提交一个查询时，主代理会先分析问题、制定策略，然后生成多个子代理，让它们同时探索不同方面。正如上图所示，子代理在这里扮演的是“智能过滤器”的角色。它们会不断调用搜索工具收集信息，在这个例子中是调查 2025 年的 AI agent 公司，然后把公司名单返回给主代理，由主代理整合出最终答案。
传统的 RAG，也就是 Retrieval Augmented Generation，采用的是静态检索方式。它通常只会取回一批与输入 query 最相似的文本片段，然后基于这些片段生成回答。相比之下，我们的架构使用的是多步搜索：系统会动态发现相关信息、根据新发现调整方向，并分析结果，最终形成高质量答案。
上图展示了我们的多代理 Research 系统完整工作流。当用户提交查询后，系统会创建一个 LeadResearcher 代理，并进入迭代式研究流程。LeadResearcher 会先思考整体方法，并把计划写入 Memory，用于持久化上下文。这样做是因为一旦上下文窗口超过 200,000 tokens，前面的内容就会被截断，而研究计划必须被保留下来。接着，它会创建多个带有明确研究任务的专用 Subagent，图中只画了两个，但实际数量可以是任意多个。每个 Subagent 都会独立执行网页搜索，并通过交错式 thinking 来评估工具返回结果，然后把发现汇报给 LeadResearcher。LeadResearcher 会综合这些结果，并决定是否还需要继续研究。如果还需要，它可以继续创建新的子代理，或者调整当前策略。一旦信息已经足够，系统就会退出 research loop，并把所有发现交给 CitationAgent。CitationAgent 会处理这些文档和研究报告，找出适合插入引用的具体位置，从而确保所有论断都能正确归因到来源。最终，带引用的研究结果会返回给用户。
三、Research Agent 的提示工程与评测
多代理系统和单代理系统有一个关键差异，就是随着 agent 数量增加，协调复杂度会迅速上升。我们的早期 agent 会犯很多错误，比如对一个简单查询就创建 50 个子代理、为了不存在的来源在网上无休止地搜索、或者通过过量更新彼此打扰。由于每个 agent 都是由 prompt 驱动的，prompt engineering 成了我们改进行为的主要杠杆。下面是我们在为 agent 设计 prompt 时学到的一些原则：
3.1 像 agent 一样思考
想要迭代 prompt，首先必须理解 prompt 会产生什么效果。为了做到这一点，我们使用 Console 基于系统里真实使用的 prompt 和工具构建模拟环境，然后逐步观察 agent 是如何工作的。这种做法很快暴露出失败模式，比如 agent 在已经拿到足够结果后还继续工作、使用过于冗长的搜索词，或者选错工具。有效的提示工程，依赖于对 agent 建立准确的心理模型；一旦模型建立起来，很多高影响力的修改就会变得很明显。
3.2 教会 orchestrator 如何委派任务
在我们的系统里，主代理需要把查询拆解成多个子任务，并向子代理描述这些任务。每个子代理都需要明确的目标、输出格式、推荐使用的工具和来源，以及清晰的任务边界。如果任务描述不够细致，agent 就会重复劳动、遗漏关键信息，或者根本找不到所需内容。我们一开始允许主代理只给出像 “research the semiconductor shortage” 这样简短的指令，但很快发现，这种指令往往模糊到足以让子代理误解任务，甚至和其他 agent 做完全相同的搜索。例如，一个子代理去研究 2021 年汽车芯片危机，另外两个子代理却重复调查 2025 年当前供应链情况，整个系统缺乏有效的分工。
3.3 根据查询复杂度调整投入强度
agent 并不擅长判断不同任务应该投入多少精力，因此我们把 effort scaling 的规则直接写进 prompt 里。简单的事实查找，只需要 1 个 agent 和 3 到 10 次工具调用；直接比较类任务，可能需要 2 到 4 个子代理，每个子代理大约进行 10 到 15 次工具调用；复杂研究任务则可能需要 10 个以上子代理，并且每个子代理都要承担明确分工。这些明确规则能帮助主代理更高效地分配资源，也能避免在简单问题上投入过度资源，而这正是我们早期版本中常见的失败模式。
3.4 工具设计与工具选择至关重要
agent-tool interface 的重要性，并不亚于 human-computer interface。选对工具不仅仅意味着效率更高，很多时候甚至是完成任务的前提。例如，如果某个上下文只存在于 Slack 里，而 agent 却去网页上搜索，那它从一开始就注定失败。随着 MCP servers 让模型接触到外部工具，这个问题会进一步放大，因为 agent 面对的是大量此前没见过、且描述质量参差不齐的工具。我们为 agent 设计了明确的工具选择启发式规则。比如，先查看有哪些工具可用；根据用户意图决定用什么工具；做广泛外部探索时优先搜索网页；优先使用专用工具而不是通用工具。糟糕的工具描述会把 agent 带到完全错误的路径上，因此每个工具都必须有清晰的用途和明确的说明。
3.5 让 agent 帮助改进自己
我们发现，Claude 4 系列模型本身就是很优秀的 prompt engineer。只要给它一个 prompt 和一个失败模式，它就能分析 agent 为什么出错，并给出改进建议。我们甚至专门做了一个 tool-testing agent。给它一个有缺陷的 MCP 工具后，它会尝试实际调用这个工具，然后改写工具描述，避免后续失败。通过对同一个工具做几十次测试，这个 agent 找到了许多关键细节和 bug。改进工具可用性的这套流程，让后续 agent 在使用新描述时，任务完成时间降低了 40%，因为它们能避开大多数原本会犯的错误。
3.6 先宽后窄
搜索策略应该像优秀的人类研究者那样，先摸清地形，再逐步深入。agent 往往会默认写出过长、过于具体的查询词，结果反而返回很少的结果。我们通过 prompt 抑制这种倾向，要求 agent 先用简短、宽泛的 query 进行探索，判断当前信息空间里有哪些内容，然后再逐步收窄焦点。
3.7 引导 thinking 过程
Extended thinking mode 会让 Claude 输出额外 token，展示可见的 thinking 过程，这可以作为一种可控的草稿空间。主代理会利用 thinking 来规划整体方法，例如判断哪些工具适合当前任务、估计查询复杂度和子代理数量、定义每个子代理的角色。我们的测试显示，extended thinking 能提升指令遵循、推理质量和整体效率。子代理也会先做规划，然后在拿到工具结果后使用 interleaved thinking，评估结果质量、识别信息缺口，并改进下一轮查询。这让子代理在面对不同任务时都能更灵活地自我调整。
3.8 并行工具调用会显著改变速度与表现
复杂研究任务天然需要探索大量来源。我们的早期 agent 是串行搜索的，这种方式慢得难以接受。为了解决速度问题，我们引入了两层并行化：第一，主代理会并行生成 3 到 5 个子代理，而不是按顺序一个个创建；第二，子代理内部也会并行调用 3 个以上工具。这些改变让复杂查询的 research 时间最多降低了 90%，使 Research 能够在几分钟内完成原本需要数小时的工作，同时覆盖的信息还更多。
我们的提示工程策略，更强调植入良好的启发式，而不是制定死板规则。我们研究了优秀人类研究者是如何处理 research 任务的，并把这些策略编码进 prompt 中，例如把复杂问题拆成更小的任务、认真评估来源质量、根据新信息调整搜索方式，以及判断当前更应该追求深度还是广度。与此同时，我们也通过设置明确护栏，主动避免 agent 意外失控。最后，我们始终坚持快速迭代闭环，依赖可观测性和测试案例来持续改进。
四、如何有效评测 Agent
高质量评测是构建可靠 AI 应用的基础，agent 也不例外。但多代理系统的评测有它自己的特殊难点。传统评测往往默认 AI 每次都会走相同步骤，也就是给定输入 X，系统应该沿着路径 Y 产生输出 Z。但多代理系统并不是这样工作的。即使起点完全一样，agent 也可能走出完全不同但同样有效的路径来达成目标。一个 agent 可能搜索 3 个来源，另一个可能搜索 10 个；它们也可能使用不同工具找到相同答案。因为很多时候我们事先并不知道“正确步骤”究竟是什么，所以通常无法简单地检查 agent 有没有按我们预先规定的步骤去做。相反，我们需要更灵活的评测方法：既要判断 agent 是否得到了正确结果，也要判断它的执行过程是否大体合理。
4.1 从一开始就评测，哪怕样本很小
在 agent 开发早期，很多改动的影响都非常大，因为系统里有大量“低垂果实”。一个小小的 prompt 修改，就可能把成功率从 30% 提升到 80%。在这种效应量很大的阶段，你只需要少量测试用例就能看出差异。我们一开始只用了大约 20 个 query，覆盖真实使用场景中的典型模式。很多时候，仅凭这些 query 就足以清楚看出某次改动的影响。我们经常听到一些 AI 开发团队说，他们之所以迟迟不做 eval，是因为觉得只有几百条测试用例构成的大型评测才有意义。但实际上，更好的做法是立刻从小规模测试开始，即便只有少数几个例子，也比一直等到大规模 eval 准备好要好得多。
4.2 LLM-as-judge 只要设计得当，就能扩展
Research 类输出很难用程序自动打分，因为它们是自由文本，而且通常不存在唯一正确答案。LLM 天然适合承担评委角色。我们使用了一个 LLM judge，根据预设 rubric 从多个维度评估输出，包括事实准确性，也就是论断是否与来源一致；引用准确性，也就是引用是否真的支持对应论断；完整性，也就是是否覆盖了用户要求的所有方面；来源质量，也就是是否优先使用了一手资料，而不是质量较低的二手来源；以及工具使用效率，也就是是否用了合适的工具，并以合理次数调用。我们曾尝试让多个 judge 分别评估不同组件，但最终发现，一次 LLM 调用、一个统一 prompt、输出 0.0 到 1.0 的得分以及 pass-fail 结论，这种方式反而最稳定，也最符合人工判断。尤其是在那些确实存在明确正确答案的 eval case 中，这种方法非常有效。比如，当问题是“是否准确列出了研发预算最高的前三家制药公司”时，LLM judge 可以很好地判断答案是否正确。使用 LLM 作为 judge，让我们能够以可扩展的方式评估数百条输出结果。
4.3 人工评测能发现自动化遗漏的问题
人工测试 agent 时，经常能发现 eval 没覆盖到的边角情况。例如，某些非常规查询下出现的幻觉答案、系统失败，或者一些不容易察觉的来源选择偏差。以我们自己的系统为例，人工测试人员发现，早期 agent 会系统性地优先选择经过 SEO 优化的内容农场，而不是学术 PDF 或个人博客这类权威但搜索排名没那么靠前的来源。后来，我们在 prompt 里加入了关于来源质量的启发式规则，这个问题才得到改善。即使在自动化评测越来越成熟的时代，人工测试依然是不可替代的。
多代理系统会出现一些涌现行为，也就是系统并没有被明确编程成那样，但行为却自然出现了。例如，只是对主代理做了一个小改动，就可能以不可预测的方式改变子代理的行为。要让系统成功运行，关键在于理解这些交互模式，而不仅仅是盯着单个 agent 的表现。因此，好的 prompt 不应该只是严格的命令集合，更应该是协作框架，用来规定分工方式、问题求解方法以及投入预算。要把这些做好，离不开精细的 prompt 和工具设计、可靠的启发式、良好的可观测性以及紧密的反馈回路。关于示例 prompt，你可以参考我们在 Cookbook 中开源的 patterns-agents-basic-workflows。
五、生产可靠性与工程挑战
在传统软件中，一个 bug 可能只是打断某个功能、拖慢性能，或者造成服务不可用。但在 agent 系统里，哪怕只是一个很小的改动，也可能引发巨大的行为变化。这使得为复杂 agent 编写代码变得异常困难，因为它们需要在长时间运行的过程中维持状态。
5.1 Agent 是有状态的，错误会层层放大
agent 可以长时间运行，并在大量工具调用之间持续维护状态。这意味着我们需要让代码具备持久执行能力，并且能在执行过程中妥善处理错误。如果缺少有效缓解手段，一些看似很小的系统故障，对 agent 来说就可能是灾难性的。当错误发生时，我们不能简单从头重启，因为重启既昂贵，也会让用户非常沮丧。为此，我们构建了能够从错误发生位置恢复执行的系统，而不是每次都重头开始。我们也会利用模型本身的智能，让它以更平滑的方式处理问题。例如，当某个工具失效时，直接告知 agent，让它自己调整，效果往往出奇地好。我们把基于 Claude 的 AI agent 的适应能力，与重试逻辑和定期 checkpoint 这类确定性 safeguard 结合起来使用。
5.2 调试需要新的方法
agent 会动态做决策，而且即便 prompt 完全相同，不同运行之间也并不确定。这让调试变得更加困难。例如，用户经常反馈 agent “没有找到明明很明显的信息”，但我们一开始并不知道原因。是因为搜索 query 写得不好？还是来源选得差？抑或是工具调用失败了？后来，我们为生产系统增加了完整 tracing，才能真正诊断 agent 为什么失败，并系统性地修复问题。除了标准意义上的可观测性之外，我们还会监控 agent 的决策模式和交互结构，同时不去监控单个对话的具体内容，以保护用户隐私。正是这种高层级的可观测性，让我们能够定位根因、发现意料之外的行为，并修复那些高频失败模式。
5.3 部署需要精细协调
agent 系统通常是一张高度有状态的网络，由 prompt、工具和执行逻辑共同组成，而且几乎持续不断地运行。这意味着每次我们部署更新时，系统中的 agent 可能正处在流程的任意位置。因此，我们必须防止那些原本出于好意的代码变更，反而把已经在跑的 agent 破坏掉。我们不能让所有 agent 在同一时刻全部切换到新版本。相反，我们使用 rainbow deployments 来避免打断正在运行的 agent。具体做法是让新旧版本同时运行，再把流量逐步从旧版本迁移到新版本。
5.4 同步执行会形成瓶颈
目前，我们的主代理还是以同步方式执行子代理，也就是说，它会等这一批子代理都完成之后，再继续下一步。这样做能简化协调逻辑，但也会在 agent 之间的信息流上形成瓶颈。例如，主代理无法实时引导子代理，子代理之间也无法协调，整个系统还可能因为等待某一个搜索较慢的子代理而被整体阻塞。如果改用异步执行，就能释放更多并行性，让 agent 真正并发工作，并在有需要时继续创建新的子代理。但异步也会带来新的困难，比如结果协调、状态一致性，以及错误在子代理之间如何传播。随着模型能够处理越来越长、越来越复杂的 research 任务，我们预计这种额外复杂度最终会被性能收益所抵消。
六、总结
在构建 AI agent 时，最后那一公里往往会变成整个旅程的大部分。一个在开发者机器上运行良好的代码库，要变成可靠的生产系统，往往还需要大量额外工程。agent 系统中错误的连锁效应，使得那些在传统软件里只算“小问题”的缺陷，也可能让 agent 整体跑偏。只要某一步失败，agent 就可能走上一条完全不同的轨迹，最终产生不可预测的结果。基于本文讨论的所有原因，原型到生产之间的差距，往往比人们原先预想的更大。
尽管如此，多代理系统在开放式研究任务上已经证明了自身价值。用户告诉我们，Claude 帮助他们发现了原本没有想到的商业机会、理清了复杂的医疗选项、解决了棘手的技术 bug，还通过挖掘他们自己本来不会发现的研究联系，节省了多达数天的工作时间。只要具备谨慎的工程实现、全面测试、细致的 prompt 与工具设计、健全的运行实践，以及研究、产品和工程团队之间基于当前 agent 能力边界的紧密协作，多代理 Research 系统就可以在大规模场景下稳定运行。我们已经看到，这类系统正在改变人们解决复杂问题的方式。
一张 Clio embedding plot，展示了今天用户最常见的 Research 使用方式。当前排名靠前的使用类别包括：在专业领域中构建软件系统，占比 10%；撰写和优化专业与技术内容，占比 8%；制定业务增长和营收策略，占比 8%；辅助学术研究和教育材料开发，占比 7%；以及检索和核验关于人物、地点或组织的信息，占比 5%。
七、致谢
本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 共同撰写。这项工作体现了 Anthropic 内部多个团队的集体努力，正是这些努力让 Research 功能成为可能。特别感谢 Anthropic 的 apps engineering 团队，他们的投入让这个复杂的多代理系统真正落地到生产环境。我们也感谢早期用户提供的高质量反馈。
八、附录
下面是一些关于多代理系统的补充建议。
8.1 对跨多轮修改状态的 agent，更适合做终态评估
对于那些会在多轮对话中持续修改持久状态的 agent，评测会有额外难点。与只读型的 research 任务不同，这类任务中的每一步操作都可能改变后续步骤所处的环境，从而形成传统评测方法难以处理的依赖关系。我们的经验是，终态评估往往比逐轮分析更有效。也就是说，不去判断 agent 是否走了一条特定流程，而是直接判断它最终是否达到了正确状态。这种方法承认 agent 可能通过不同路径达到同一个目标，同时也能保证最终结果符合预期。对于复杂工作流，可以把评测拆成一系列离散 checkpoint，在这些点上检查某些关键状态变化是否已经发生，而不是试图验证每一步中间过程。
8.2 长时程对话管理
生产级 agent 往往会持续几百轮对话，因此必须认真设计上下文管理策略。随着对话不断延长，普通上下文窗口会逐渐不够用，这就需要更智能的压缩和记忆机制。我们采用了一些模式，例如在一个工作阶段完成后，让 agent 先总结这一阶段内容，再把必要信息写入外部 memory，然后再进入后续任务。当上下文接近极限时，agent 也可以生成新的子代理，让它们带着干净上下文继续工作，同时通过精心设计的交接机制保持连续性。此外，当上下文到达上限时，它们还能从 memory 中重新读取诸如 research plan 这样的关键信息，而不是丢失此前已经完成的工作。这种分布式做法可以避免上下文溢出，同时维持长时交互中的整体连贯性。
8.3 让子代理把结果直接输出到文件系统，减少“传话游戏”
对于某些类型的结果，如果允许子代理直接输出，而不是所有内容都必须经过主协调者转述，往往能同时提升保真度和性能。与其让子代理把所有东西都通过主代理层层传达，不如设计一套 artifact 系统，让专用 agent 直接生成可以独立持久化的结果。子代理可以调用工具，把自己的工作结果写入外部系统，然后只把轻量级引用返回给协调者。这样可以减少多阶段处理中信息损失，也能避免为了在对话历史中传递大段输出而付出的额外 token 成本。这个模式尤其适用于代码、报告、数据可视化这类结构化输出，因为在这些场景中，子代理依靠其专用 prompt 产出的结果，往往比经过通用协调者二次过滤后的结果更好。
TODO
- 补充我的阅后笔记