How we built our multi-agent research system
我们如何构建过智能体研究系统
原文链接：How we built our multi-agent research system \ Anthropic
overview
主要涉及：多智能体系统构建中的系统架构、工具设计与提示工程经验。
本篇文章主要涉及到 研究系统 智能体，根据用户查询来规划研究过程(plan)，然后通过并行智能体来搜索汇总信息。这一块与我目前参与的saa-deepresearch基本类似。构建过程中涉及到智能体协调、评估、可靠性方面的挑战。
Benefits of a multi-agent system
多智能体系统的优势
对于Research研究工作本身而言，是一个开放性的任务，本身很难预测所需的步骤。要想探索某一个复杂主题，无法预设一条固定的路径，因为这个过程本质上是动态且路径依赖的。
因此agent特别适合研究任务。模型必须自主运行多轮，根据中间结果决定要探索的方向。而我们提到的线性、一次性的工作流程无法处理这些任务。
搜索的本质在于压缩：从庞大的语料库中提炼出见解。子agent在各自上下文窗口中并行操作来“促进压缩”，同时探索问题的不同方向，为主agent提供信息。每个子agent还提供了关注点分离——不同的工具、提示和探索路径——有效减少了路径依赖，并能进行彻底、独立的调查。
Multi-agent之所以能发挥作用，得益于它有助于消耗足够的tokens来解决问题。在我们的分析中，三个因素解释了95%的在BrowComp评估中的性能差异(该评估测试了browsing agent在定位难以找到的信息的能力)。我们发现，token消耗解释了80%的差异，工具调用次数和模型选择是另外两个因素。这一发现证实了我们的架构，**即将工作任务分配给具有独立上下文窗口的agent来提升并行推理的能力。**多智能体架构有效的拓展token的使用，即用来完成但agent无法完成的任务。
不过这也有个缺点：在实际过程中，该架构消耗token的速度很快，agent是chat交互的4x，multi-agent则是15x。为了经济上的可行，multi-agent需要任务的价值足够高，以支付性能提升的成本。此外，一些需要所有agent共享上下文或互相依赖的领域，并不适合multi-agent。比如，大多数的coding任务中真正可并行化的任务比研究任务少，且LLM代理在实时协调和委托给其他代理方面还不够出色。我们发现，多代理系统在涉及大量并行化、信息超出单个上下文窗口及与众多复杂工具交互的有价值的任务中表现出色。
涉及词汇：hardcode 预设、硬编码；inherently 本质上；approach方法；pivot 自主; tangential 相关、切向; simultaneously 同时地; condense 浓缩; trajectory 轨迹; thorough 彻底地；threshold 阈值；exponentially 指数级地；collective 集体的；excel 擅长；decompose分解；board members董事会成员；variance 方差、差异；vaildate 使生效，证实；scale 拓展,规模；downside 缺点；viability可行性; delegate委托；in real time实时；inferfaceing连接；further此外
Architecture overview for Research
研究架构概述
我们的研究系统采用多代理架构，遵循协调器-工作者模式。主代理负责协调整个流程，同时将任务委派给专门的子agent并行运行。
与我所参与的saa-deepresearch结构相似因此省略......
涉及词汇：orchestrator-worker 协调器-工作者模式；speciallized专门的；
Prompt engineering and evaluation for research agents
研究agents的提示词工程与评估
multi-agent和agent存在关键的差异，包括协调难度的飞速增长。早期agents为了一些简单的queries错误的生成50个子agents，在web上无止尽的搜索不存在的来源，并且因过度更新导致互相干扰。自从每个agent被prompt调整后，prompt工程是我们改善agent表现的主要手段。以下是一些我们在提示智能体方面学到的一些原则：
1.要向你的代理一样思考： 为了迭代提示词，你必须了解其效果。为了帮助我们做到这一点，我们搭建了一个控制台，使用来自系统中的确切的提示词和工具，然后一步一步观察agent工作。这立刻揭示了失败模式：在已经有了足够的结果的情况下，agent继续的进行冗长的搜索或者使用错误的工具 **这种模式。**有效的提示依赖于开发agent确切的心理模型。这可以使得影响效果最明显。
2.教会协调者如何任务分配： 在我们的系统中，主agent拆分queries并描述给子agent。每个子agent都需要一个明确的目标、输出格式、关于使用工具和信息来源的指导以及清晰的任务边界。如果没有详细的任务描述，agents就会重复工作，留下空白，或者无法找到必要的信息。我们起初允许主代理给出“研究半导体短缺情况”这也简单、简短的指令，但发现这些指令往往不够明确，导致子代理误解任务或完全进行相同的搜索。例如，一个子代理研究了2021年汽车芯片危机，然而另外两个子代理则重复工作，调查当前2025年的供应链情况，没有实现有效的分工。
3.根据查询复杂度调整投入： 代理难以判断不同任务需要的适当程度的投入，因此我们在提示中嵌入了缩放规则。简单的事实查找只需要1个agent和3~10个tool，直接比较需要2~4个agent，每个agent有10~15个tool call。复杂的研究可能使用超过10个子agent且有清晰分明的职责划分。这些明确的指导方针有助于主代理高效分配资源，并防止在简单查询上过度投入。
4.工具的设计和选择至关重要： agent的tool是非常重要的。比如agent在互联网上搜索仅存在于内网是数据就是完全徒劳。由于MCP服务允许模型访问外部工具，这种情况进一步恶化，因为agent会遇到各种质量参差不齐的未知tool。 我们给agent一个明确的探索方法：例如，首先查看所有符合要求的tool，与用户意图匹配，在互联网上进行广泛的外部探索，或者优先选择专用工具而非通用工具。 糟糕的工具描述可能会让代理走上完全错误的道路，因此每个工具都需要有明确的目的和清晰的描述。
5.让代理自行改进： 让代理自行改进。我们发现，Claude 4 模型能够成为出色的提示工程师。当给定一个提示和一个失败模式时，它们能够诊断出代理失败的原因，并提出改进措施。我们甚至创建了一个工具测试代理——当给定一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过数十次测试该工具，这个代理发现了关键的细微差别和漏洞。这一改进工具人机工程学的过程使得未来使用新描述的代理完成任务的时间减少了 40%，因为他们能够避免大多数错误。
6.先广后精： 搜索策略应效仿专家的研究方法：先探索整体情况，再深入细节。agent常常默认使用过于冗长、具体的查询，导致返回的结果甚少。我们通过代理程序，先从简短、宽泛的查询开始，评估可用信息，然后逐步缩小范围，来克服这种倾向。
7.引导思考过程： 扩展思考模式能让克劳德以可见的思考过程输出更多内容，从而充当一个可控的草稿板。引导者利用思考来规划其方法，评估哪些工具适合任务，确定查询的复杂程度和子代理的数量，并定义每个子代理的角色。我们的测试表明，扩展思考提高了指令遵循、推理和效率。子代理也会进行规划，然后在工具结果出来后使用交错思考来评估质量、识别差距并完善其下一个查询。这使得子代理在适应任何任务时都更有效。
8.并行工具调用提升速度与性能： 并行工具调用提升了速度和性能。复杂的研究任务自然涉及对众多来源的探索。我们早期的代理程序执行的是串行搜索，速度极其缓慢。为了提高速度，我们引入了两种并行化方式：（1）主代理程序会并行启动 3 至 5 个子代理程序，而非依次启动；（2）子代理程序会并行使用 3 种工具。 这些改变使得复杂查询的研究时间缩短了多达 90%，让研究部门能够在几分钟内完成原本需要数小时的工作，而且覆盖的信息量也比其他系统更多。
我们的提示策略侧重于灌输良好的启发式方法而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的提示中——比如将难题分解为较小的任务、仔细评估信息来源的质量、根据新信息调整搜索方法，以及识别何时应深入探究（详细研究一个主题）与何时应广泛探索（同时研究多个主题）。我们还通过设置明确的防护措施来主动防止意外的副作用，以避免代理失控。最后，我们专注于快速迭代循环，注重可观察性和测试用例。
涉及词汇：steer 引导； lever 手段、工具; simulations 模拟; verbose冗长的；duplicate重复的；vague模糊；appropriate 适当的；scaling rules缩放规则；explicit明确的；compound复合，恶化；strictly necessary绝对必要；doom徒劳；wildly varying quality 质量参差不齐；intent意图；heuristics 探索方法；over（在特定场合）而非；send down让..走上...；flawed有缺陷的；nuance细微差别；mirror镜子，效仿；drilling into specifics深入细节；progressively逐步的；tendency趋势、倾向；interleave 交错；instill 逐渐灌输；rigid 严格的；proactively 先发的；mitigate 减缓；spiraling 盘旋的；prescribe 规定；
Effective evaluaion of agents
评估多智能体系统存在独特的挑战。传统的评估通常假定 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 以生成输出 Z。但多智能体系统并非如此。即使起点相同，智能体也可能采取完全不同的有效路径来实现目标。一个智能体可能搜索三个来源，而另一个搜索十个，或者它们可能使用不同的工具来找到相同的答案。由于我们并不总是知道正确的步骤是什么，所以我们通常不能仅仅检查智能体是否遵循了我们事先规定的“正确”步骤。相反，我们需要灵活的评估方法，来判断智能体是否在遵循合理过程的同时实现了正确的结果。
立即用小样本开始评估。在早期的代理开发阶段，改动往往会产生显著的影响，因为存在大量容易实现的成果。一个小小的调整可能会将成功率从 30% 提升到 80%。效果如此显著，仅用几个测试案例就能发现变化。我们从大约 20 个代表真实使用模式的查询开始。测试这些查询通常能让我们清楚地看到改动的影响。我们经常听到 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试案例的大规模评估才有用。然而，最好立即从小规模测试开始，用几个例子，而不是等到能够构建更全面的评估时才行动
当运用得当，LLM（大型语言模型）作为评判者的效果很好。研究产出难以通过程序化的方式进行评估，因为它们是自由格式的文本，且很少有唯一正确的答案。LLM 评判研究产出是再合适不过的了。我们使用了一个 LLM 评判者，它根据评分标准对每个产出进行评判：事实准确性（主张是否与来源相符？）、引用准确性（引用的来源是否与主张相符？）、完整性（是否涵盖了所有要求的方面？）、来源质量（是否优先使用了高质量的一手资料而非低质量的二手资料？）以及工具效率（是否合理地使用了恰当的工具？）。我们尝试了多个评判者来评估每个组成部分，但发现通过一个 LLM 调用，使用一个提示输出 0.0 到 1.0 的分数以及通过/未通过的等级是最具一致性的，且与人类评判者的评判结果最为吻合。当评估测试案例确实有明确答案时，这种方法尤其有效，我们可以用 LLM 评判者来简单地检查答案是否正确（例如，它是否准确列出了研发预算排名前三的制药公司？）。使用 LLM 作为评判者使我们能够大规模地评估数百个产出。
人工评估能发现自动化评估所遗漏的问题。人工测试代理时能发现自动化评估所忽略的极端情况，比如对不寻常查询给出的凭空想象的答案、系统故障或细微的来源选择偏差。在我们的案例中，人工测试人员发现早期的代理总是选择经过搜索引擎优化的内容农场，而不是权威性更强但排名较低的来源，比如学术论文或个人博客。在提示中加入来源质量的启发式方法解决了这个问题。即便在自动化评估盛行的时代，人工测试依然至关重要
多智能体系统具有涌现行为，这种行为并非通过特定编程产生。例如，对主导智能体的细微改动可能会不可预测地改变子智能体的行为方式。要取得成功，需要理解交互模式，而不仅仅是单个智能体的行为。因此，针对这些智能体的最佳提示不仅仅是严格的指令，而是协作框架，该框架定义了分工、问题解决方法和努力预算。做好这一点依赖于精心设计的提示和工具、可靠的启发式方法、可观测性和紧密的反馈循环。请参阅我们的“食谱”中的开源提示，以获取来自我们系统的示例提示。
涉及词汇：identical 同一的；low-hanging 低垂的，low-hangding fruit容易拿到的果实（显著的成果）tweak 轻微调整(轻轻拧一下)；spot 发现；With effect sizes this large效果如此显著；represent代表；a set of大约；free-form自由格式；programmatically通过程序化的方式；grading分阶段，分级；against 反对，违背，对比；criteria标准；rubric标题；ailgned与...对其；hallucinated 幻觉的凭空想象的；bias偏差；emergent 新兴事物，涌现；
Production reliability and engineering challenges
生产可靠性与工程挑战
在传统软件中，一个漏洞可能会破坏某个功能、降低性能或导致系统中断。而在代理系统中，细微的变化会引发重大的行为变化，这使得为必须在长期运行过程中保持状态的复杂代理编写代码变得极其困难。
代理是有状态的，错误会累积。代理可以长时间运行，在多次工具调用中保持状态。这意味着我们需要可靠地执行代码，并处理过程中出现的错误。如果没有有效的缓解措施，即使是轻微的系统故障也可能对代理造成灾难性影响。当出现错误时，我们不能只是从头开始重启：重启既费时又让用户感到沮丧。相反，我们构建了能够从错误发生时的状态恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让代理知道某个工具出现故障，并允许其进行适应，这种方法的效果出奇地好。我们将基于 Claude 构建的 AI 代理的适应性与诸如重试逻辑和定期检查点等确定性保障措施相结合。
调试工作得益于新方法。代理程序会做出动态决策，并且在相同的提示下每次运行的结果也不确定。这使得调试工作变得更加困难。例如，用户会报告代理程序“找不到显而易见的信息”，但我们却不知道原因。是代理程序使用的搜索查询有问题吗？选择的来源不好吗？还是工具出现了故障？添加全面的生产跟踪让我们能够诊断出代理程序失败的原因，并系统地解决问题。除了标准的可观测性之外，我们还监控代理程序的决策模式和交互结构——所有这些都不涉及对单个对话内容的监控，以保护用户隐私。这种高层次的可观测性帮助我们诊断根本原因，发现意外行为，并解决常见故障。
部署需要精心协调。代理系统是由提示、工具和执行逻辑构成的高度有状态的网络，几乎持续运行。这意味着，每当我们要部署更新时，代理可能处于其流程中的任何位置。因此，我们需要防止善意的代码更改破坏现有的代理。我们不能同时将所有代理更新到新版本。相反，我们使用彩虹部署来避免中断正在运行的代理，通过逐步将流量从旧版本转移到新版本，同时让两者并行运行。
同步执行会造成瓶颈。目前，我们的主代理同步执行子代理，每组子代理完成任务后才继续进行。这简化了协调工作，但会在代理之间的信息流中造成瓶颈。例如，主代理无法引导子代理，子代理无法协调，整个系统在等待单个子代理完成搜索时可能会被阻塞。 异步执行将实现更多的并行性：代理可以同时工作，并在需要时创建新的子代理。但这种异步性在结果协调、状态一致性和错误传播方面给子代理带来了挑战。随着模型能够处理更长和更复杂的研究任务，我们预计性能提升将足以弥补这种复杂性。
涉及词汇：cascade 串联；catastrophic 灾难的；deterministic 确定性的；deploy 调用部署；disrupting 扰乱；traffic 联系，来往，交通；well-meaning 善意；steer 引导操控；bottlenecks 瓶颈；propagation 增值、传播；compound 混合、复合的；
Conclusion
在构建人工智能代理时，最后的这一英里往往占据了整个旅程的大部分。在开发人员机器上运行良好的代码库需要大量的工程工作才能成为可靠的生产系统。代理系统中错误的复合性质意味着，对于传统软件来说是小问题的问题，可能会使代理完全脱轨。一步出错可能导致代理探索完全不同的轨迹，从而导致不可预测的结果。由于本文所述的所有原因，原型与生产之间的差距往往比预期的要大。
尽管面临这些挑战，多智能体系统已被证明对开放式研究任务很有价值。用户表示，Claude 帮助他们发现了未曾考虑过的商业机会，帮助他们应对复杂的医疗保健选择，解决了棘手的技术问题，并通过揭示他们独自无法发现的研究联系，节省了多达数天的工作时间。多智能体研究系统在精心设计、全面测试、注重细节的提示和工具设计、稳健的运营实践以及研究、产品和工程团队之间的紧密合作（这些团队对当前智能体的能力有深刻理解）下，能够可靠地大规模运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。
涉及词汇：trajectory 轨道；derail使脱轨；proven证明；thorny 棘手的；open-ended 开放式；
Appendix
附录
对在多轮对话中改变状态的代理进行最终状态评估。评估那些在多轮对话中修改持久状态的代理带来了独特的挑战。与只读研究任务不同，每个动作都可能改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现专注于最终状态评估而非逐轮分析是成功的。不要判断代理是否遵循了特定的过程，而是评估它是否达到了正确的最终状态。这种方法承认代理可能会找到实现相同目标的替代路径，同时仍确保它们实现了预期的结果。对于复杂的流程，将评估分解为特定状态变化应已发生的离散检查点，而不是试图验证每个中间步骤。
长期对话管理。生产代理经常参与数百轮的对话，这需要谨慎的上下文管理策略。随着对话的延长，标准的上下文窗口变得不够用，这就需要智能的压缩和记忆机制。我们实现了这样的模式：代理在进入新任务之前，会总结已完成的工作阶段，并将关键信息存储在外部记忆中。当上下文限制接近时，代理可以生成具有干净上下文的新子代理，同时通过谨慎的交接来保持连续性。此外，当达到上下文限制时，它们可以从记忆中检索存储的上下文，例如研究计划，而不是丢失之前的工作。这种分布式方法防止了上下文溢出，同时在长时间的交互中保持了对话的连贯性。
为减少“传话游戏”，子代理可直接将输出写入文件系统。对于某些类型的成果，直接的子代理输出可以绕过主协调器，从而提高准确性和性能。不必要求子代理通过主代理来传递所有信息，而是实施工件系统，让专门的代理能够生成独立持久的输出。子代理调用工具将其工作存储在外部系统中，然后将轻量级引用传递回协调器。这可防止在多阶段处理过程中信息丢失，并减少因通过对话历史记录复制大型输出而产生的令牌开销。这种模式对于代码、报告或数据可视化等结构化输出特别有效，因为子代理的专门提示能产生比通过通用协调器过滤更好的结果。