我们如何构建多代理研究系统¶
- 原文链接：https://www.anthropic.com/engineering/multi-agent-research-system [64]
- 发布时间：2025-06-13
- 作者：Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox、Daniel Ford
Research 功能通过多个 Claude 代理并行探索复杂问题，我们分享工程挑战与经验教训。[64]
Claude 现已具备 Research 能力，可在 Web、Google Workspace 和各种集成中进行搜索，完成复杂任务。[64]
从原型到生产的多代理系统，教会我们关于系统架构、工具设计与提示工程的关键经验。多代理系统指多个代理（LLM 在工具循环中自主使用工具）协同工作。Research 功能中，一个代理会根据用户问题规划研究过程，并使用工具创建并行代理同时搜索信息。多代理系统在协调、评估与可靠性方面带来新挑战。[64]
本文总结了有效原则，希望能帮助你构建自己的多代理系统。[64]
多代理系统的收益¶
研究任务通常是开放式问题，很难预先预测步骤。你无法硬编码固定路径，因为研究过程天然是动态的、路径依赖的。人类研究时会根据新发现不断调整方向，追踪线索。[64]
这种不可预测性使 AI 代理非常适合研究任务：需要随时转向或探索旁支；模型必须在多轮中自主决策，基于中间发现决定下一步。线性的“一次性”管线无法胜任。[64]
搜索的本质是压缩：从海量信息中提炼关键洞察。子代理并行工作，各自拥有独立上下文，探索问题的不同维度，再把最重要的 token 压缩给主研究代理。每个子代理也提供了职责隔离——不同工具、提示与探索轨迹——减少路径依赖，提升独立调查质量。[64]
当智能达到一定阈值，多代理系统成为规模化性能的关键方式。人类个体智力在 10 万年内提升有限，但信息时代人类社会能力呈指数增长，正是因为集体智能与协作。即便是通用智能代理，单体也有上限；群体代理能完成更多任务。[64]
内部评测显示，多代理研究系统特别擅长“广度优先”查询（并行追多条独立线索）。我们发现：以 Claude Opus 4 为主代理、Claude Sonnet 4 为子代理的多代理系统，在内部研究评测上比单代理 Claude Opus 4 提升 90.2%。例如：要求找出信息技术行业 S&P 500 的所有董事，多代理系统会拆分任务给子代理并找到正确答案；单代理系统则因慢速串行搜索失败。[64]
多代理系统的效果来自于“足够多的 token 支出”。在 BrowseComp 评测中，我们发现 3 个因素解释了 95% 的性能方差：token 使用量（解释 80%）、工具调用数量、模型选择。该发现验证了我们的架构：通过多个上下文窗口分散工作，增加并行推理容量。最新 Claude 模型是 token 使用的效率倍增器：升级到 Claude Sonnet 4 的提升幅度甚至超过把 Claude Sonnet 3.7 的 token 预算翻倍。[64]
但缺点也明显：实际中这些架构消耗 token 很快。数据显示，代理任务平均用 4× token，多代理系统更是达到聊天的 15×。在经济上，多代理系统需要任务价值足以覆盖性能成本。同时，有些领域不适合多代理——需要共享同一上下文或存在大量依赖。例如多数编码任务并不具备足够并行性，LLM 代理也尚不擅长实时协调与委派。我们发现，多代理系统更适合高价值、强并行、信息超出单一上下文窗口、且工具复杂度高的任务。[64]
Research 架构概览¶
Research 使用 orchestrator-worker 模式：主代理协调流程，子代理并行执行具体任务。[64]
图注：用户查询进入主代理，由主代理创建专门子代理并行搜索不同维度。[64]
用户提交查询后，主代理分析问题、制定策略，并生成子代理同时探索不同方向。子代理迭代使用搜索工具，收集信息（例如 2025 年 AI agent 公司），再将公司列表回传主代理汇总。[64]
传统 RAG 使用静态检索：先取与查询最相似的文档片段，再生成回答。相比之下，我们采用多步搜索：动态发现信息、根据新发现调整、分析结果并生成更高质量答案。[64]
图注：Research 系统的完整流程。主代理保存计划到 Memory，创建子代理并行搜索，汇总后交给 CitationAgent 标注引用。[64]
流程说明：[64]
- 用户提交查询后，系统创建 LeadResearcher，进入迭代研究流程。
- LeadResearcher 先思考方法并把计划写入 Memory，以便在上下文超过 200k token 被截断时保留计划。
- 主代理创建多个子代理（示意图中为 2 个，但数量不限），每个负责具体任务。
- 子代理独立做 Web 搜索，使用 interleaved thinking 评估工具结果，并回传发现。
- 主代理综合结果，判断是否需要继续研究；若需要，生成新子代理或调整策略。
- 信息足够后退出研究循环，把全部发现交给 CitationAgent。
- CitationAgent 定位引用位置，确保声明有来源；最终带引用的结果返回给用户。
研究代理的提示工程与评测¶
多代理系统在协调复杂度上显著不同于单代理，早期版本出现了大量问题：简单查询生成 50 个子代理、为不存在的来源搜索、过度更新干扰其他代理等。因为每个代理都由提示词驱动，我们把提示工程作为主要杠杆。以下是关键原则：[64]
- 像代理一样思考。要迭代提示，必须理解其影响。我们在 Console 中用真实提示与工具做模拟，逐步观察代理行动，很快就发现失败模式：已有结果仍继续、搜索词过长、选错工具。有效提示依赖对代理行为的准确心智模型。
- 教主代理如何委派。主代理需要把问题拆分为子任务并描述给子代理。每个子代理需要目标、输出格式、工具与来源指引、明确边界。缺少细节会导致重复、遗漏或找不到关键信息。我们最初允许主代理只给简单指令（如“研究半导体短缺”），但这类指令太模糊，子代理会误解或重复搜索。例如，一个子代理研究 2021 车用芯片危机，另外两个重复搜索 2025 供应链，缺乏分工。
- 按问题复杂度缩放投入。代理很难自判断应投入多少资源，于是我们在提示中加入规则：简单事实查询只需 1 个代理 + 3–10 次工具调用；直接对比可能需要 2–4 个子代理，每个 10–15 次调用；复杂研究可超过 10 个子代理并明确分工。规则帮助主代理避免过度投入。
- 工具设计与选择至关重要。代理-工具接口等同于人机界面。用错工具会导致失败，例如去 Web 搜索本应在 Slack 找的信息。随着 MCP servers 加入，工具质量差异更大。我们制定显式启发式：先查看可用工具、匹配用户意图、Web 搜索用于泛化探索、优先专用工具等。工具描述不清会把代理引向错误路径，因此每个工具必须有明确目的与清晰描述。
- 让代理自我改进。Claude 4 模型非常擅长提示工程。给它一个提示与失败模式，它能诊断原因并提出改进。我们甚至创建了一个工具测试代理：给它一个有问题的 MCP 工具，它先尝试使用，然后重写工具描述避免失败。反复测试后，该描述使未来代理任务完成时间减少 40%。
- 先广后窄。搜索策略要像人类专家：先探索全局，再深入细节。代理容易写过长、过具体的查询，导致结果稀少。我们通过提示要求先用短、广查询，再逐步收窄。
- 引导思考过程。扩展思考模式 可作为可控的“思考草稿”。主代理用其规划：选择工具、判断复杂度与子代理数量、定义子代理角色。测试显示扩展思考提升了指令遵循、推理与效率。子代理也会规划，并在工具结果后使用 interleaved thinking 评估质量、发现缺口、优化下一次查询。
- 并行工具调用改变速度与性能。复杂研究需要探索大量来源。早期代理串行搜索，速度很慢。我们引入两种并行：主代理并行创建 3–5 个子代理；子代理并行使用 3+ 工具。研究时间最多缩短 90%，从数小时变为数分钟，同时覆盖更多信息。[64]
我们的提示策略强调“启发式”而非“死规则”：我们研究人类专家的研究方法，并把这些策略写进提示（分解问题、评估来源质量、动态调整搜索、决定深度/广度）。同时设定护栏防止代理失控，并以快速迭代、可观测性与测试用例支撑改进。[64]
代理评测的有效方法¶
评测对可靠 AI 应用至关重要，多代理系统更是如此。传统评测假设 AI 每次都走同一路径，但多代理并非如此：同样起点可能走不同路径，仍可达到正确结果。我们通常无法规定“正确步骤”，因此需要更灵活的方法：判断最终结果是否正确，同时过程是否合理。[64]
立即用小样本开始评测。 早期改动效果巨大，提示小调整可能让成功率从 30% 提升到 80%。我们从约 20 条真实查询开始测试，就能明显看到变化。很多团队延迟做评测，认为必须有上百案例才有用，但最佳做法是尽早小规模测试，而非等待完整评测集。[64]
LLM-as-judge 评测可扩展且有效。 研究输出难以程序化评估，因为文本开放且不唯一。LLM 作为裁判非常合适。我们使用 LLM 评审每个输出，依据 rubic：事实准确性（声明与来源是否一致）、引用准确性（引用是否匹配声明）、完整性（是否覆盖全部方面）、来源质量（是否优先使用一手资料）、工具效率（是否使用正确工具且次数合理）。我们尝试多评审，但发现单次 LLM 调用 + 单提示输出 0.0–1.0 评分和 pass/fail 最稳定、最符合人类判断。尤其当测试用例有明确答案时，LLM judge 可直接判对错（如是否准确列出研发预算最大 3 家药企）。这样可规模化评测数百输出。[64]
人工评测能发现自动化漏掉的问题。 人类测试能发现边界案例、系统故障或微妙偏差。例如我们早期代理倾向选择 SEO 内容农场，而非权威但排名较低的学术 PDF 或个人博客。我们在提示中加入来源质量启发式后解决了该问题。即便有自动化评测，人工测试仍不可替代。[64]
多代理系统具有“涌现行为”，小改动主代理会不可预测地影响子代理。成功需要理解交互模式，而不是仅观察单个代理。最佳提示应是协作框架，定义分工、求解方法与投入预算。实现依赖严谨提示与工具设计、强启发式、可观测性与紧密反馈回路。[64]
可参考我们的 Cookbook 开源提示。[64]
生产可靠性与工程挑战¶
传统软件中一个 bug 可能导致功能损坏、性能退化或宕机；而在代理系统中，小改动会级联成大幅行为变化，使维护长时间状态的复杂代理极难。[64]
代理有状态且错误会叠加。 代理会长时间运行并跨多次工具调用保持状态，需要持久执行与错误处理。如果没有有效缓解，小故障会变成灾难。发生错误时不能简单重启——成本高且用户体验差。我们构建了可从错误点恢复的系统，并利用模型适应性处理问题：让代理知道工具失败并调整策略，效果出乎意料地好。我们将 AI 适应性与确定性机制（重试逻辑、定期 checkpoint）结合。[64]
调试需要新方法。 代理决策是动态的，同样提示也可能产生不同路径。这使调试更难。用户反馈“找不到明显信息”，但原因不明：是查询差？来源差？工具失败？我们引入完整的生产追踪，定位失败原因并系统修复。除了常规可观测性，我们还监控代理决策模式与交互结构，同时不查看对话内容以保护隐私。这种高层观测帮助我们发现根因与异常行为。[64]
部署需要谨慎协调。 代理系统是提示、工具与执行逻辑组成的有状态网络，几乎持续运行。这意味着部署更新时，代理可能运行到不同阶段，无法同时更新。我们使用 rainbow deployments 逐步切换新旧版本，避免破坏正在运行的代理。[64]
同步执行造成瓶颈。 目前主代理同步等待每批子代理完成，这简化协作但导致信息流瓶颈：主代理无法中途调整子代理，子代理之间不能协调，系统也会因某个慢子代理而阻塞。异步执行能提升并行度：代理可并发工作、按需创建新子代理。但异步也带来协调、状态一致性与错误传播难题。随着模型能处理更复杂任务，性能收益可能足以抵消复杂度。[64]
结论¶
构建 AI 代理时，最后一公里往往占据绝大部分工程成本。能在开发机跑的代码，变成可靠生产系统需要大量工程投入。代理系统的错误是复合式的：传统软件的小问题可能让代理完全偏离路径，造成不可预测结果。[64]
尽管如此，多代理系统在开放式研究任务中极具价值。用户反馈：Claude 帮他们发现新的商业机会、探索复杂医疗选项、解决棘手技术问题，甚至节省数天工作。只要有细致的工程、全面测试、精心的提示与工具设计、稳健的运维实践，以及研究/产品/工程团队的紧密合作，多代理研究系统就能可靠规模化运行。我们已经看到它在改变人们解决复杂问题的方式。[64]
图注：Clio 嵌入图展示 Research 常见用途：软件系统开发（10%）、专业技术内容优化（8%）、业务增长策略（8%）、学术研究与教育材料（7%）、人员地点组织信息核验（5%）。[64]
致谢¶
本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox、Daniel Ford 撰写。这项工作凝聚了 Anthropic 多个团队的努力，特别感谢 Anthropic apps 工程团队将这一复杂系统推向生产，并感谢早期用户的反馈。[64]
附录¶
以下是多代理系统的一些补充建议：[64]
多轮状态修改任务的终态评估。 当代理在多轮对话中修改持久状态时，评估会更难，因为每一步都会改变后续环境。我们倾向于评估最终状态，而不是逐步过程：不要求代理走某条固定路径，而是确认它是否达到正确终点。对于复杂流程，可以按阶段设置检查点，而不是验证每个中间步骤。[64]
长时对话管理。 生产代理常涉及数百轮对话，需要更精细的上下文管理。当对话变长时，标准上下文窗口会不足，需要智能压缩与记忆机制。我们让代理在完成阶段后进行总结，并把关键信息写入外部 Memory；当接近上下文上限时，可生成新子代理并通过交接保持连续性。代理还可以从 Memory 中取回计划，避免上下文溢出导致丢失。[64]
子代理输出落地到文件系统以减少“传话游戏”。 某些结果可绕过主协调器，直接持久化输出。子代理可以把工作成果写入外部系统，再把轻量引用传回主代理。这能减少多级传递中的信息损耗，并降低 token 开销。该模式对结构化输出（代码、报告、数据可视化）尤其有效，因为子代理的专用提示往往比通用协调器更优。[64]