90.2%性能提升的背后: Claude 多智能体架构设计全解析 原创

Claude现在拥有研究功能^{[1]，可以在网络、Google Workspace和任何集成中进行搜索，以完成复杂的任务。}

这个多智能体系统从原型到生产的旅程教会了我们关于系统架构，工具设计和prompt工程的关键教训。多代理系统由多个代理（LLMs在循环中自主使用工具）组成。我们的研究功能涉及一个代理，它根据用户查询计划研究过程，然后使用工具创建同时搜索信息的并行代理。具有多个代理的系统在代理协调、评估和可靠性方面引入了新的挑战。

这篇文章分解了这些原则，我们希望你在构建自己的多智能体系统时能发现它们的有用之处。

本文内容翻译自built-multi-agent-research-system^[2]

多Agent系统的优势

适应开放式研究需求

研究工作往往涉及开放式问题，其解决路径难以预先规划。由于探索过程具有动态性和路径依赖性，固定的线性流程无法应对复杂课题的挑战。研究者通常需要根据阶段性发现不断调整方向，追踪线索。这种不可预测性恰恰凸显了AI智能体的优势——它们能够自主决策，灵活转向或探索分支路径，而传统的单次线性流程则无法胜任此类任务。

并行探索

研究的本质在于从海量信息中提炼关键信息。多智能体系统通过子智能体并行运作，每个子智能体拥有独立的上下文窗口，能够同时探索问题的不同侧面，再将核心信息压缩传递给主导智能体。这种分工不仅实现了“关注点分离”（各子智能体可配备专属工具、指令和探索路径），还降低了单一路径依赖，使研究更全面、独立。

突破个体的局限

当个体的智力水平达到一定阈值时，多智能体系统成为提升效能的关键。类比人类社会发展：尽管个体智力在十万年间进步有限，但信息时代的集体协作能力带来了指数级的能力跃升。同样，即使通用智能体也存在个体局限，而智能体群组能实现更复杂的任务。例如，内部测试显示，以Claude Opus 4为主导、Claude Sonnet 4为子智能体的系统，在研究类任务中的表现比单智能体高出90.2%。

效能提升的核心机制

多智能体系统的优势源于其对计算资源的合理分配。在浏览信息类任务（BrowseComp）中，三个因素解释了95%的性能差异：Token用量（占80%）、工具调用次数和模型选择。该系统通过分配独立上下文窗口实现并行推理扩容，而Claude新版模型进一步放大了Token使用效率（如升级至Sonnet 4的增益超过双倍Sonnet 3.7的Token预算）。

适用场景与经济权衡

多智能体系统也存在局限性：其Token消耗约为单智能体的15倍，因此需权衡任务价值与经济成本。此外，需共享上下文或高度依赖的任务（如多数编码场景）目前并不适用。当前该系统更擅长高价值、强并行化、超单窗口信息量的任务，尤其在调用复杂工具时表现突出。未来随着实时协作能力的提升，其应用边界将进一步扩展。

技术架构

我们的研究系统使用了一个多Agent架构与协调工作者模式，其中一个领导代理协调的过程，同时委托给专门的子代理并行操作。

当用户提交一个查询时，主代理分析它，制定一个策略，并产生子代理同时探索不同的方面。如上图所示，子代理作为智能过滤器，通过迭代使用搜索工具收集信息。

使用检索增强生成（RAG）的传统方法使用静态检索。也就是说，它们获取一些与输入查询最相似的块集，并使用这些块来生成响应。相比之下，我们的架构使用多步搜索，动态查找相关信息，适应新的发现，并分析结果，以制定高质量的答案。

流程图显示了我们的多代理研究系统的完整工作流程。当用户提交查询时，系统创建一个LeadResearcher代理，该代理进入迭代研究过程。LeadResearcher首先考虑这种方法，并将其计划保存到内存中以持久化上下文，因为如果上下文窗口超过200，000个令牌，它将被截断，保留计划非常重要。然后，它会创建具有特定研究任务的专用子代理（此处显示了两个，但可以是任何数量）。每个子代理独立执行Web搜索，使用交错思维^[3]评估工具结果，并将结果返回给LeadResearcher。首席研究员综合这些结果，并决定是否需要更多的研究-如果是这样，它可以创建更多的子代理或完善其策略。 一旦收集到足够的信息，系统就会退出循环，并将所有发现传递给CitationAgent，CitationAgent处理文档和研究报告，以确定引用的具体位置。这确保了所有主张都正确地归因于其来源。最终的研究结果，包括引用，然后返回给用户。

智能体的提示工程与评估

多智能体系统与单智能体系统有着关键的区别，包括协调复杂性的快速增长。早期的我们也犯了一些错误，比如为简单的查询生成50个子代理，无休止地在网上搜索不存在的资源，以及用过多的更新来分散彼此的注意力。由于每个代理都是由提示引导的，因此提示工程是我们改善这些行为的主要手段。下面是我们学到的一些提示代理的原则：

像智能体一样思考

要改进智能体的表现，必须深入理解其行为模式。我们通过在控制台中复现系统提示词与工具，逐步观察智能体的运行过程，从而暴露典型问题：例如在结果已充足时仍继续搜索、使用冗长低效的查询语句或错误选择工具。高效的提示词设计依赖于对智能体思维模型的精准把握——只有明确其决策逻辑，才能针对性优化。

强化协调器的指派能力

在我们的系统中，领导代理（lead agent）的职责是将查询分解为多个子任务，并将这些子任务的具体信息描述给下属代理（subagents）。为了确保每个子代理能有效地执行分配给它们的任务，它们需要获得几个关键信息：任务目标、输出格式、使用工具和来源的指导以及明确的任务界限。如果没有详细的任务描述，代理们很可能会重复工作、留下遗漏或者找不到必要的信息。

最初，我们允许领导代理给出简单、短小的指令，比如“研究半导体短缺”，但我们发现这样的指令往往足够模糊，以致于下属代理误解了任务或者与其他代理执行了完全相同的搜索。例如，一个下属代理调查了2021年汽车芯片危机，而另外两个代理则重复工作，调查了2025年当前的供应链情况，这导致劳动力的划分不够有效。

综上所述，教会协调者如何委派任务是至关重要的。这包括如何清晰地定义每个子任务，确保每个代理都有明确的工作指导，从而避免工作重复、遗漏和信息查找失败，确保任务高效、有序地完成。优化后的分派需包含四大要素， 这套标准使多智能体协作效率提升3倍。

1. 明确目标（如"分析2021年汽车芯片危机对当前产能的影响"）
2. 输出格式规范（结构化表格/时间轴）
3. 工具与数据源指引（优先使用行业报告数据库）
4. 任务边界定义（避免与其它子任务重叠）

根据查询复杂性调整规模

在不同的任务中，智能体往往难以判断应当付出多大的代价，因此我们在提示中加了规模调整规则。对于简单的事实查找，只需要1个代理进行3-10次工具调用；直接比较可能需要2-4个子代理，每个子代理进行10-15次调用；而复杂的研究可能需要超过10个子代理，并明确分配各自的责任。这些明确的指南帮助主要代理有效地分配资源，并防止在简单查询中过度投资，这是我们早期版本中常见的失败模式。

工具的设计和选择

工具的选择直接决定智能体任务的成败，例如，如果一个代理在网上去搜索只存在于Slack中的信息，那么从一开始就注定失败。为此我们开发了智能体专用启发式规则：

1. 优先选择专用工具（如专利数据库>通用搜索引擎）
2. 工具描述需包含输入输出示例
3. 对模糊描述工具启动验证流程

让模型自我优化

我们发现，Claude 4模型可以成为出色的提示工程师。当给定一个提示和一个失败模式时，它们能够诊断智能体为何失败，并提出改进建议。我们甚至创建了一个工具测试代理——当给定一个有缺陷的MCP工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过对工具进行数十次测试，这个代理找到了关键的细微差别和漏洞。

搜索策略

在深入具体问题之前，Agent应该先探索整个领域。代理们常常默认使用过长、过于具体的查询，导致返回结果很少。我们通过提示代理开始时使用短的、广泛的查询，评估可用信息，然后逐步缩小焦点来抵制这种倾向。

引入思考过程

扩展思考模式使Claude能够输出可见的思考过程，这可以作为一种可控制的草稿纸。主导智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子代理数量，并定义每个子代理的角色。我们的测试显示，扩展思考提高了指令执行、推理和效率。子代理也进行计划，然后在工具结果之后使用交错思考来评估质量，识别差距，并优化他们的下一个查询。这使得子代理在适应任何任务时更为有效。

并行化拓展性能

复杂的研究任务自然涉及探索许多来源。我们早期的代理执行顺序搜索，这是痛苦的缓慢。为了提高速度，我们引入了两种并行化：

1. 主代理并行而不是串行地启动3-5个子代理
2. 子代理并行使用3个以上的工具。

这些变化将复杂查询的研究时间缩短了90%，使研究能够在几分钟内完成更多工作，而不是几小时，同时覆盖比其他系统更多的信息。

如何评估你的智能体

在构建可靠的人工智能（AI）应用中，良好的评估是不可或缺的，而对于智能体而言，这一点同样适用。然而，多智能体系统的评估呈现出独特的挑战，这一挑战的根源在于传统评估方法的局限性以及多智能体系统的复杂性。

传统评估方法的局限性

传统评估方法往往基于一个假设：AI在每次给定输入X时，都会遵循相同的步骤Y来产出结果Z。这种评估方式忽略了多智能体系统的动态性和多样性。在多智能体系统中，即便是在相同的起始条件下，不同的智能体可能会采取完全不同但同样有效的路径来达成目标。例如，一个智能体可能会检索三个资源来寻找答案，而另一个智能体则可能检索十个资源，或者它们可能会使用不同的工具来找到相同的答案。

这种多样性带来的挑战是，我们无法总是预先知道哪一步骤是正确的，因此也就无法仅仅通过检查智能体是否遵循了我们预设的“正确”步骤来进行评估。多智能体系统的特点在于其灵活性和适应性，而这恰恰是传统评估方法难以捕捉的。

因此，我们需要的是一种灵活的评估方法，这种方法能够在判断智能体是否实现了正确的结果的同时，也考虑到它们是否遵循了一个合理的过程。这意味着评估不仅仅关注最终的输出是否正确，还关注智能体达成目标的方式是否高效、是否采用了合理的策略。

关键方法

小样本快速评估

在早期的智能代理开发阶段，即使是微小的变化也可能引起巨大的影响。一个简单的调整可能就能将成功率从30%提升到80%。当效果大小如此之大时，你只需通过几个测试案例就能发现变化。我们开始时选取了大约20个查询，这些查询代表了真实的使用模式。频繁地测试这些查询使我们能够清晰地看到变化的影响。

我们经常听到AI开发团队延迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好从几个例子开始小规模的测试，而不是拖延到你可以建立更全面的评估。

使用LLM对结果进行评估

由于研究输出通常是自由文本，且往往没有唯一正确答案，传统的程序化评估方法难以适用。而大语言模型（LLM）天然适合这类开放式评估任务。我们设计了一套基于LLM的评分体系，用于对研究输出进行标准化评估。

我们采用了一个LLM作为“裁判”（judge），根据以下维度对研究输出进行打分（0.0-1.0），并给出“通过/未通过”判定：

1. 事实准确性（Factual Accuracy）：研究结论是否与引用来源一致？
2. 引用准确性（Citation Accuracy）：引用的来源是否真实支持相关论点？
3. 完整性（Completeness）：是否覆盖了研究问题的所有关键方面？
4. 来源质量（Source Quality）：是否优先使用高质量的一手资料（如学术论文、官方报告），而非低质量的二手信息？
5. 工具使用效率（Tool Efficiency）：是否合理选择工具，并避免冗余调用？

人工审核也很重要

即使最完善的自动化评估体系（如LLM裁判）也无法覆盖所有现实场景中的边界情况。人工测试者能够捕捉到评估标准忽略的典型问题，包括：

1. 异常查询下的幻觉回答

• 当用户提出罕见或高度开放式问题时（如“请比较18世纪与21世纪的半导体供应链”），智能体可能生成看似合理但完全虚构的结论。
• 解决方案：在提示词中强制要求“对超出训练数据范围的问题明确声明不确定性”，并设置回退机制（如转人工审核）。

2. 系统性故障模式

• 例如，早期版本智能体在连续调用多个工具时，可能因API速率限制导致任务链崩溃，而自动化测试未模拟此类场景。
• 解决方案：人工测试中发现该问题后，我们增加了工具调用熔断机制——当子智能体连续3次调用失败时，自动切换备用工具或上报主控智能体。

3. 隐蔽的数据源偏见

• 在提示词中嵌入来源质量启发式规则（例如：​​优先选择.edu/.gov域名、预印本平台arXiv、知名机构报告​​）。
• 为搜索引擎工具添加​​site:*.edu OR filetype:pdf​​等高级筛选参数。
• 这一调整使权威来源引用率从32%提升至78%。
• 人工测试者发现，智能体倾向于选择SEO优化但低质量的内容农场（如某些商业科技网站），而非权威性更高但搜索排名较低的来源（如学术PDF或个人专家博客）。
• 改进措施：

多智能体的涌现行为

多智能体系统会自发产生涌现行为（Emergent Behaviors）——这些行为并非预先编程，而是由智能体间的交互动态形成。例如：

• 微小改动引发级联效应：若调整主控智能体的任务分派策略（如从"严格分工"改为"动态抢单"），可能导致子智能体出现资源竞争或任务遗漏
• 非线性响应：某个子智能体工具调用失败时，系统可能自动触发"任务重分配"或"备用工具切换"，即使该流程未被显式编码

典型案例：在早期实验中，我们仅修改主控提示词中的​​"请分配3个子任务"​​​为​​"请确保至少3个角度被覆盖"​​，结果某些子智能体开始自发拆分任务，产生7-8个微任务，导致token消耗激增。

工程上的挑战

生产上有哪些调整

在传统软件开发中，Bug的影响通常局限于某个功能失效、性能下降或服务中断。但在智能体系统（Agentic Systems）中，微小的改动可能引发级联效应，导致系统行为发生巨大变化。这种差异源于智能体的状态持续性（Statefulness）和长时程任务（Long-Running Processes）特性，使得错误会不断累积，而非简单重启就能解决。

状态持续性

智能体在执行任务时，会维护一个长期记忆状态（如对话历史、中间推理结果、工具调用记录）。与传统无状态服务（如HTTP请求-响应模式）不同，错误可能导致：

• 状态污染：错误的中间结果影响后续决策（如错误的数据分析导致后续查询偏离正轨）
• 不可逆操作：某些工具调用（如发送邮件、提交订单）无法简单回滚

长时程任务

智能体可能运行数小时甚至数天（如市场趋势分析、跨平台数据整合），这使得：

• 错误恢复成本高：重启意味着丢失所有中间进展
• 资源浪费：重复执行已完成的工具调用（如重新爬取已获取的网页）

级联行为变化

• 提示词微小调整可能导致智能体策略剧变（如修改“尽量详细”为“尽量简洁”后，智能体跳过关键验证步骤）
• 工具API的变动（如返回格式变化）可能让智能体解析逻辑完全失效

智能体容错系统的核心设计

可恢复执行

• 检查点（Checkpointing）：定期保存智能体的完整状态（如对话历史、工具调用记录、中间结论）

     例如：每完成3个工具调用或消耗5000token后自动快照

• 断点续跑（Resume from Failure）：

    错误发生时，从最近的有效检查点恢复，而非从头开始

    用户无感知（如“系统已自动修复，继续分析中…”）

自适应恢复

• 错误感知与自主调整：

    当工具连续失败时，智能体自动切换备用方案（如用Google搜索替代失效的内部数据库查询）

    通过​​[THOUGHT]​​输出暴露决策逻辑（如“检测到API返回格式异常，尝试清洗数据后重试”）

• 受限重试机制（Guarded Retry）：

    不是无限制重试，而是设置熔断条件（如最多3次失败后触发升级流程）

确定性保护层

调试、部署与执行优化

1. 调试新范式：应对非确定性行为

智能体的动态决策特性使得传统调试方法失效——即使输入相同，每次运行可能产生不同结果。我们采用以下方法应对：

• 全链路追踪（Full Production Tracing）

    记录每个决策节点的完整上下文（如工具调用参数、搜索结果排序、中间推理逻辑）

    案例：用户报告“找不到明显信息”时，追踪发现智能体因过度依赖​​site:.com​​过滤而遗漏.edu域名的权威资料

• 高阶行为监控（High-Level Observability）

    工具调用频率异常（如某API突然被密集调用）

    决策路径偏离（如80%的子智能体意外选择同一低效搜索策略）

    不记录具体对话内容（保护隐私），但分析宏观模式：

    成效：发现某次更新后，智能体因提示词微调产生“工具依赖症”——调用次数增加3倍但信息质量未提升

• 非确定性调试工具箱

    重放测试（Replay Testing）：用历史输入+随机种子复现问题

    差异对比（Diff Debugging）：并行运行新旧版本，比较决策路径分歧点

2. 部署策略：状态化系统的挑战

智能体的长时程特性要求独特的部署协调：

• Rainbow Deployment

1. 新旧版本并行运行，通过路由层控制流量比例
2. 新任务分配给新版本，进行中任务继续使用旧版本至完成
3. 监控错误率，全量切换前确保无状态兼容问题

• 状态兼容性检查

       a. 新旧版提示词能否加载同一检查点？

       b. 工具API变更是否导致历史中间结果失效？

       c. 版本升级时自动验证：

       d. 案例：某次数据库schema更新导致智能体无法解析已保存的JSON，触发自动回滚

3. 同步 vs 异步执行

当前同步模式的瓶颈：

• 主控智能体阻塞：必须等待所有子任务完成才能继续
• 资源利用率低：快速完成的子智能体闲置等待慢速任务
• 缺乏动态调整：无法根据中间结果实时增减子智能体

异步化的潜在收益与挑战：

graph LR  
A[主控智能体] -->|异步触发| B[子智能体1]  
A -->|异步触发| C[子智能体2]  
B --> D[工具调用]  
C --> E[网络搜索]  
A -->|实时订阅| F[结果流]

• 关键技术需求：

     a. 事件驱动架构：子智能体通过消息队列发布进展

     b. 一致性快照：异步环境下仍能保存全局一致状态

     c. 优先级抢占：当某结果显著改变任务方向时（如发现关键证据），终止低优先级子任务

• 性能权衡实验

4. 未来方向

• 混合执行模型：

     关键路径同步（如事实核查），非关键路径异步（如背景资料收集）

• LLM驱动的协调器：

     训练专用模型实时决策“何时该同步/异步”

• 故障注入测试框架：

     模拟网络延迟、工具故障等场景，验证系统韧性

智能体系统的复杂性本质上是人类协作复杂性的镜像——正如团队管理需要平衡自由度与控制力，技术架构也需在灵活性与可靠性间找到动态平衡点。

总结

当构建人工智能(AI)代理时，最后一公里往往变成了整个旅程的大部分。在开发者的机器上能够运行的代码库需要进行大量的工程化处理，才能变成可靠的生产系统。代理系统中错误的复合性意味着，对于传统软件来说的微小问题可能会完全偏离代理的轨道。一个步骤的失败可能导致代理探索完全不同的轨迹，导致不可预测的结果。

正如本文所描述的所有原因，原型到生产的鸿沟通常比预期的要宽。尽管存在这些挑战，多代理系统在开放式研究任务中已被证明是有价值的。用户表示，Claude帮助他们发现了他们之前没考虑过的商业机会，导航复杂的医疗选择，解决棘手的技术错误，并通过揭示他们独自一人找不到的研究联系，节省了多达数天的工作。通过细致的工程设计、全面的测试、注重细节的提示和工具设计、健壯的操作实践以及研究、产品和工程团队之间的紧密合作（这些团队需要对当前代理能力有深刻的理解），多代理研究系统可以在规模上可靠地运行。我们已经开始看到这些系统如何改变人们解决复杂问题的方式。

参考资料

[1] 研究功能: ​​https://www.anthropic.com/news/research​​

[2] built-multi-agent-research-system: ​​https://www.anthropic.com/engineering/built-multi-agent-research-system​​

[3] 交错思维: ​​​https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking#interleaved-thinking​​

本文转载自​​AI 博物院​​ 作者：longyunfeigu