案例复盘：Anthropic 的多智能体研究系统是怎么协作的

把「研究」这类开放式任务工程化的一手样板。

最有含金量的是委派接口：目标、输出格式、工具指引、任务边界四件套，再配上与复杂度挂钩的投入档位——简单事实查证用 1 个 Agent，复杂研究动用 10 个以上子 Agent。评估侧同样务实：约 20 个真实查询的小样本起步，LLM 裁判按五维量表打分，人工测试补抓内容农场偏好这类自动化查不出的问题。

原文对成本足够诚实，多 Agent 的 token 消耗约为普通聊天的 15 倍；但对国内交付团队更关键的是适用面判断——这套架构最适合高价值、可并行、只读的情报型任务，客户现场的写路径操作与强流程依赖场景不建议硬套。多 Agent 的错误还会级联累积，检查点、灰度部署这些生产化苦活才是复刻成本的大头。

先挑 5 个真实研究类任务做单 Agent 与多 Agent 对照，算清质量提升能否覆盖 token 开销，再决定要不要把这套架构写进交付方案。

—— FDEChina编辑部 · 架构师视角

一、背景

案例主体是 Anthropic 的研究（Research）功能：Claude 可以搜索网络、Google Workspace 以及各类集成来完成复杂任务，支撑它的是一套多智能体系统——由多个在循环中自主使用工具的 LLM 协同工作。Anthropic 在工程博客《How we built our multi-agent research system》中公开拆解了这套系统从原型走向生产的过程，以及系统架构、工具设计与提示词工程上的经验教训。本篇基于该文复盘这套系统的协作方式，并讨论它对 FDE 交付中研究类 AI 任务的参考价值。

二、问题

研究任务的难点在开放式：无法提前预测要走的步骤，不能为探索复杂主题硬编码一条固定路径——研究者会随新发现调整方法、追踪过程中浮现的线索，模型必须自主运行许多轮、根据中间结果决定下一步方向，线性的、一次性的流水线处理不了这类任务。同时，搜索的本质是压缩：从海量语料中提炼洞见，单个模型的上下文窗口装不下，串行式的逐条搜索又慢又浅。在广度优先、需要同时追踪多个独立方向的查询上，单 Agent 很快撞到极限。

三、方案

Anthropic 采用编排者-工作者（orchestrator-worker）模式：一个主 Agent 负责分析用户查询、制定研究策略，再把任务委派给并行运作的专门化子 Agent。每个子 Agent 拥有独立的上下文窗口，充当「智能过滤器」：并行探索问题的不同侧面，把最重要的内容浓缩后交回主 Agent 汇总成最终答案。与 RAG 的静态检索（取回与查询最相似的一组文本块再生成回答）不同，这套架构是多步搜索——动态查找信息、适应新发现、对结果做分析。分工同时带来关注点分离：各子 Agent 使用不同的工具、提示词与探索轨迹，降低路径依赖。

四、实施过程

把架构跑起来，工程量集中在四件事上。

任务分解与委派。主 Agent 把查询拆成子任务，每个子 Agent 要拿到四样东西：目标、输出格式、所用工具与来源的指引、清晰的任务边界。早期版本允许「研究一下半导体短缺」这类简短指令，结果是子 Agent 重复执行同一搜索——一个在查 2021 年汽车芯片危机，另外两个还在重复调查 2025 年的供应链。

工作量缩放与并行。Agent 自己判断不好该投入多少精力，团队把缩放规则写进提示词：简单事实查证用 1 个 Agent、3-10 次工具调用；直接对比用 2-4 个子 Agent、各 10-15 次调用；复杂研究动用 10 个以上职责明确的子 Agent。并行化同步跟上：主 Agent 并行启动 3-5 个子 Agent，子 Agent 并行使用 3 个以上工具，复杂查询的研究时间因此最多缩短 90%。

评估先行。从约 20 个反映真实使用模式的查询起步做小样本评估；再用 LLM 裁判按量表打分，覆盖事实准确性、引用准确性、完整性、来源质量与工具效率；人工测试补自动化遗漏——早期 Agent 偏好 SEO 优化的内容农场而非学术 PDF，来源质量启发式规则由此补进提示词。

生产可靠性。Agent 有状态、错误会累积，团队用持久化执行、检查点与重试逻辑让系统从出错位置恢复而非从头重启；部署采用彩虹部署，新旧版本并行、逐步迁移流量；生产追踪只看决策模式与交互结构、不看对话内容，以保护用户隐私。

五、结果

以下均为原文披露口径。在 Anthropic 的内部研究评估中，以 Claude Opus 4 为主 Agent、Claude Sonnet 4 为子 Agent 的多 Agent 系统，比单 Agent 的 Claude Opus 4 高出 90.2%；典型场景是「找出标普 500 信息技术板块所有公司的董事会成员」，多 Agent 把它分解给子 Agent 后找到正确答案，单 Agent 缓慢顺序搜索、未能找到。在测试浏览型 Agent 的 BrowseComp 评估中，三个因素解释了 95% 的性能差异，其中仅 token 用量一项就解释了 80%。工程收益方面，并行化让复杂查询的研究时间最多缩短 90%。用户反馈口径：有用户称借此发现了未曾想到的商业机会、解决了棘手的技术问题，并节省了多达数天的工作量。

六、约束

这套架构的成立条件，原文写得很直接：多 Agent 系统的 token 消耗约为普通聊天的 15 倍（单 Agent 约 4 倍），要具备经济可行性，任务价值必须高到足以覆盖性能提升带来的成本。它适合重度并行化、信息量超出单个上下文窗口、需要与众多复杂工具交互的高价值任务；要求所有 Agent 共享同一上下文、或彼此存在大量依赖关系的领域并不适合——大多数编程任务可并行的部分就比研究少。工程侧还有两条现实约束：同步执行让主 Agent 等待每组子 Agent 完成，形成信息流瓶颈；Agent 的非确定性让调试必须依赖完整的生产追踪。

七、可复用经验

对中文 FDE 从业者与企业，这套案例中可直接迁移的做法（适用前提：交付中存在研究、情报、尽调类 AI 任务）：

委派即接口设计。给 AI 拆子任务时写清目标、输出格式、工具与边界——含糊指令在 Agent 与人身上都会造成重复劳动，这条同样适用于 FDE 向协作者派活。
给工作量定档位。按任务复杂度预设投入档位（几个子任务、几次调用），防止简单查询过度烧钱；国内客户对 token 成本敏感，档位表可以直接写进交付方案的成本模型。
评估先行、小样本起步。约 20 个真实查询加 LLM 裁判与人工抽检双轨，比等一套大而全的评估体系更快建立质量底线。
只读任务先行。多 Agent 架构先用于只读的情报型任务，写路径操作（改数据、动生产配置）暂缓——原文明确提示错误在 Agent 系统中会累积放大。

中国语境差异：国内企业交付常叠加数据不出域与权限审批约束，多 Agent 并行检索可能触碰权限边界，「Agent 能看什么」要先当作权限问题审一遍。

八、来源

原文：How we built our multi-agent research system，Anthropic 工程博客，anthropic.com；
口径说明：本篇数据（90.2%、95%、80%、15 倍、90% 等）均为 Anthropic 内部评估与原文披露口径，未经独立核实。