原文链接：从原型到生产：Anthropic 多智能体研究系统架构全解析（附 8 条提示词工程原则）

多智能体系统，AI 圈讨论了快两年了。

论文看了一堆，概念图画了无数，但真正把多智能体系统做到生产环境、服务真实用户的，屈指可数。大多数还停留在"Demo 很惊艳，上线就拉胯"的阶段。

从原型到生产，中间隔着的不是一条河，是太平洋。

这次，Anthropic 终于交出了一份"作业"——他们详细复盘了 Claude Research 功能背后的多智能体系统是怎么构建的。

这篇文章最珍贵的地方在于：它不是在讲"多智能体能做什么"，而是在讲"我们踩了哪些坑、怎么爬出来的"。

提示词怎么写才能让智能体不发疯？评估体系怎么搭？生产环境的部署有哪些坑？这些实打实的工程经验，比任何理论文章都值钱。

如果你正在考虑构建多智能体系统，或者已经在坑里挣扎，这篇文章值得你反复研读。

什么是 Agent？先把概念捋清楚

在深入之前，我们先对齐一下概念。

Agent（智能体），简单来说，就是能在"思考→行动→观察→再思考"的循环中，自主调用工具完成任务的 LLM。

注意关键词：自主和循环。

如果你的 AI 只是接收输入、生成输出，那它只是个聊天机器人。但如果它能根据中间结果，自己决定下一步该干什么、该调用什么工具，那它才算得上是个 Agent。

而多智能体系统（Multi-Agent System），顾名思义，就是多个 Agent 协同工作。就像一个公司里，有领导负责统筹，有员工负责执行，各司其职，最后汇总成果。

为什么需要多智能体？单打独斗的局限

Anthropic 的 Research 功能，是用来处理开放性研究问题的。

什么叫开放性问题？就是那种你没法提前规划好路径的任务。比如"帮我调研一下 2025 年 AI Agent 领域的主要玩家"，你不知道会搜到什么，也不知道搜到之后会引出什么新问题。

这种任务，传统的线性流程根本搞不定。你没法写一个 if-else 来覆盖所有情况。

这正是 Agent 的用武之地：它能根据中间发现，动态调整策略。

但单个 Agent 也有天花板。Anthropic 发现，当任务需要同时探索多个方向时，单 Agent 就力不从心了。

于是他们引入了多智能体架构：

• 主智能体（Lead Agent）：负责理解问题、制定策略、分配任务
• 子智能体（Subagents）：各自独立探索不同方向，然后把结果汇总给主智能体

这就像做学术研究：导师定方向，研究生们分头去查文献，最后导师汇总写论文。

多智能体的核心优势：不只是"人多力量大"

你可能会问：多搞几个 Agent 并行跑，不就是为了快吗？

没那么简单。Anthropic 总结了多智能体的几个核心优势：

1. 信息压缩与关注点分离

搜索的本质是什么？从海量信息中提炼关键洞察。

每个子智能体都有自己独立的上下文窗口，可以深入探索问题的某个方面，然后把最重要的信息"压缩"后交给主智能体。

更重要的是，不同子智能体可以使用不同的工具、不同的提示词、走不同的探索路径。这种关注点分离，能有效减少路径依赖，避免"一条道走到黑"。

2. 突破单体智能的天花板

Anthropic 在文章里有一段话让我印象深刻：

“人类个体在过去 10 万年里变得更聪明了，但人类社会在信息时代的能力是指数级增长的，因为我们有集体智慧和协作能力。”

即使是通用智能体，单打独斗也有极限；但一群智能体协作，能做到的事情远超个体之和。

3. 实打实的性能提升

Anthropic 做了内部评测：以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在研究任务上比单 Agent Opus 4 高出 90.2%。

举个例子：让系统找出标普 500 信息技术板块所有公司的董事会成员。多智能体系统通过任务分解，成功找到了答案；而单智能体用顺序搜索，直接卡住了。

但是，多智能体不是银弹

说完优点，必须泼一盆冷水。

多智能体系统有一个致命缺点：烧钱。

Anthropic 给出了一组数据：

• 普通聊天：1x token 消耗
• 单 Agent：约 4x token 消耗
• 多 Agent：约 15x token 消耗

是的，你没看错，15 倍。

所以 Anthropic 的建议很实在：如果任务的价值不足以覆盖成本，就别用多智能体。 因为钱包兜不住啊！

另外，有些任务天然不适合多智能体：

• 需要所有智能体共享同一上下文的任务
• 智能体之间依赖关系很强、难以并行的任务
• 大多数编码任务（真正能并行的部分其实不多）

多智能体的甜蜜点在哪？

• 高价值、可大规模并行的任务
• 信息量超过单个上下文窗口的任务
• 需要与大量复杂工具交互的任务

Research 系统的架构：编排者-工作者模式

Anthropic 的 Research 系统采用了经典的 Orchestrator-Worker（编排者-工作者） 模式。

简单来说：

• 主智能体（Lead Agent）：接收用户查询，制定研究策略，分配任务，汇总结果
• 子智能体（Subagents）：并行执行具体的搜索任务，各自独立探索

整个流程是这样的：

1. 用户提交查询
2. 系统创建一个主研究智能体（LeadResearcher）
3. 主智能体先"思考"，制定研究计划，并把计划存到 Memory 里（因为上下文超过 20 万 token 会被截断，计划不能丢）
4. 主智能体创建多个子智能体，分配具体任务
5. 每个子智能体独立进行网络搜索，用交错思考（Interleaved Thinking） 评估结果
6. 子智能体把发现返回给主智能体
7. 主智能体综合结果，决定是否需要更多研究
8. 信息足够后，系统把所有发现交给引文智能体（CitationAgent） 处理引用
9. 最终结果（带引用）返回给用户

这套架构和传统 RAG 有什么区别？

传统 RAG 是静态检索：找到和查询最相似的文本块，直接生成回答。一锤子买卖。

Research 架构 是动态多步搜索：能搜索最新信息，能根据发现调整策略，能迭代深入。这才是真正的"研究"。

提示词工程：8 条血泪教训

多智能体系统和单智能体有本质区别，最大的挑战是协调复杂度的指数级增长。

Anthropic 早期的智能体闹过不少笑话：

• 一个简单查询，愣是生成了 50 个子智能体
• 在网上无休止地搜索根本不存在的来源
• 子智能体之间疯狂"互相通知"，啥正事没干

既然智能体是由提示词驱动的，那提示词工程就是解决问题的核心手段。以下是 Anthropic 总结的 8 条原则：

原则 1：像你的智能体一样思考

想优化提示词，你得先理解它们的效果。

Anthropic 的做法是：用 Console 搭建仿真环境，用和生产环境一模一样的提示词和工具，然后一步一步看智能体在干什么。

这样做立刻暴露了问题：

• 明明已经拿到结果了，还在继续搜索
• 搜索词写得又臭又长，返回结果寥寥无几
• 选错工具，南辕北辙

有效的提示词优化，依赖于你对智能体行为的准确心智模型。 一旦你理解了它"怎么想"，很多改进方向就显而易见了。

原则 2：教会编排者如何分配任务

主智能体的核心职责是把大任务拆成小任务，然后分配给子智能体。

但"分配任务"这件事，没你想的那么简单。每个子智能体需要知道：

• 任务目标：到底要干什么
• 输出格式：结果长什么样
• 工具指南：该用什么工具、参考什么来源
• 任务边界：什么该做、什么不该做

如果描述模糊，子智能体就会：重复劳动、遗漏关键信息、或者干脆跑偏。

Anthropic 早期犯过这个错：让主智能体给子智能体下达简短指令，比如"研究一下半导体短缺"。结果呢？一个子智能体去查 2021 年的汽车芯片危机，另外两个都在查 2025 年的供应链，完全重复劳动。

原则 3：根据任务复杂度调整投入

智能体自己很难判断一个任务该投入多少资源。所以你得在提示词里显式地告诉它。

Anthropic 的经验法则：

• 简单任务：1 个智能体，3-10 次工具调用
• 对比类任务（比较两个选项）：2-4 个子智能体，每个 10-15 次调用
• 复杂研究：10+ 个子智能体，明确分工

这样可以防止在简单问题上过度投入——这是早期版本的常见翻车场景。

原则 4：工具设计和选择至关重要

智能体和工具的接口，就像人机交互界面一样重要。用对工具是高效的前提，有时候甚至是必要条件。

举个例子：如果智能体需要的信息在 Slack 里，但它只会用网络搜索，那从一开始就注定失败。

随着 MCP（Model Context Protocol）服务的普及，智能体会遇到各种各样的第三方工具，而这些工具的描述质量参差不齐。

Anthropic 的解决方案是给智能体植入显式的启发式规则：

• 先检查所有可用工具
• 把工具使用和用户意图匹配起来
• 用网络搜索做广泛探索
• 优先使用专用工具而非通用工具

糟糕的工具描述会让智能体彻底跑偏。 所以每个工具都需要清晰、明确、无歧义的描述。

原则 5：让模型自我改进

这条有点"套娃"的意思：用 Claude 来优化 Claude 的提示词。

Anthropic 发现，Claude 4 系列模型本身就是优秀的提示词工程师。给它一个提示词和失败案例，它能诊断出问题并提出改进建议。

他们甚至搞了一个"工具测试智能体"：给它一个有问题的 MCP 工具，它会反复尝试使用，然后重写工具描述来避免错误。通过几十次测试，这个智能体能发现很多微妙的 bug 和边界情况。

结果？任务完成时间减少了 40%，因为后续智能体能避开大部分坑。

原则 6：先广度，再深度

智能体的搜索策略应该模仿人类专家的研究方式：先鸟瞰全局，再深入细节。

但智能体有个坏习惯：默认使用又长又具体的搜索词，结果返回的内容少得可怜。

Anthropic 的对策是在提示词里明确要求：

1. 先用简短、宽泛的查询
2. 评估有什么可用信息
3. 再逐步缩小范围、深入挖掘

原则 7：引导思维过程

扩展思考模式（Extended Thinking） 是让 Claude 在回复之前，先展示自己的思考过程。你可以把它理解成一个"可控的草稿纸"。

主智能体用扩展思考来规划：

• 评估哪些工具适合当前任务
• 判断查询的复杂度
• 决定需要多少子智能体
• 定义每个子智能体的角色

Anthropic 的测试表明，扩展思考能显著提升指令遵循、推理能力和执行效率。

子智能体也会做规划，但它们用的是交错思考（Interleaved Thinking）——在每次工具调用后进行质量评估、识别信息缺口、优化下一步查询。这让子智能体能灵活适应各种任务。

原则 8：并行工具调用，速度与性能的革命

复杂研究任务需要探索大量来源。早期的智能体是顺序执行的，慢得让人抓狂。

为了提速，Anthropic 引入了两层并行：

1. 主智能体层：同时启动 3-5 个子智能体（而不是一个一个来）
2. 子智能体层：每个子智能体同时调用 3+ 个工具

效果立竿见影：复杂查询的研究时间减少了 90%。原本需要几小时的任务，现在几分钟就能搞定，而且覆盖的信息量更大。

小结一下提示词策略的核心思路：

Anthropic 的方法论不是死板的规则，而是启发式的框架。他们研究了人类专家是怎么做研究的，然后把这些策略编码到提示词里：

• 把难题拆成小任务
• 仔细评估来源质量
• 根据新发现调整搜索方向
• 识别什么时候该深挖、什么时候该广撒网
• 设置明确的防护措施，防止智能体失控
• 保持快速迭代，重视可观测性

如何评估多智能体系统？

好的评估方法是构建可靠 AI 应用的基石。但多智能体系统的评估，和传统方法有本质区别。

传统评估假设 AI 每次都走相同的路径：输入 X → 过程 Y → 输出 Z。

但多智能体不是这样。即使起点完全相同，不同的智能体可能走完全不同的路径，却都能得到正确答案。 一个智能体可能搜了 3 个来源，另一个搜了 10 个；它们可能用了不同的工具，但最终答案一样。

所以我们需要更灵活的评估方法：关注结果是否正确，同时检查过程是否合理。

评估原则 1：小样本，快启动

在智能体开发早期，改动的效果往往非常显著。一个提示词调整，可能把成功率从 30% 拉到 80%。

效果这么明显，几个测试用例就能看出变化。

Anthropic 的做法是：从大约 20 个代表真实使用场景的查询开始。不要等到构建了几百个测试用例的完整评估体系才行动——先跑起来，边跑边完善。

评估原则 2：LLM 是天生的裁判

Research 的输出是自由形式的文本，很难用程序化的方式评估，也没有什么"标准答案"。

这时候，用 LLM 来当裁判就很合适。

Anthropic 设计了一个 LLM 裁判，根据评分标准对输出打分：

• 事实准确性：声明是否与来源一致？
• 引文准确性：引用的来源是否支持声明？
• 完整性：是否覆盖了所有要求？
• 来源质量：是否优先使用一手来源，而非低质量的二手来源？
• 工具效率：是否以合理的次数正确使用工具？

他们试过用多个裁判分别评估各个维度，但发现单个 LLM 调用 + 单个提示词，输出 0.0-1.0 的分数和通过/不通过的判定，效果最好，也最符合人类判断。

评估原则 3：自动化漏掉的，人工来补

人工测试能发现自动化评估遗漏的边缘情况：

• 对冷门查询的幻觉回答
• 系统故障
• 微妙的来源选择偏见

Anthropic 的人工测试员发现了一个有趣的问题：早期智能体总是选择 SEO 优化过的内容农场，而不是排名较低但更权威的来源（比如学术 PDF 或个人博客）。

解决方案？在提示词里加入来源质量启发式规则。

在自动化评估的时代，人工测试依然不可或缺。

生产环境的工程挑战

在传统软件里，一个 bug 可能导致功能异常、性能下降或服务中断。

但在智能体系统里，小改动会像多米诺骨牌一样，引发连锁反应。这让编写需要长时间运行、维护状态的复杂智能体变得异常困难。

挑战 1：智能体是有状态的，错误会累积

智能体可以长时间运行，在多次工具调用中保持状态。这意味着我们必须持续执行代码、处理各种错误。

如果没有有效的容错机制，一个小故障就可能是灾难性的。

而且，出错时不能简单地重启——重启的代价太大，用户体验也很糟糕。

Anthropic 的解决方案：

• 构建能从错误发生点恢复的系统
• 利用模型的智能来优雅地处理问题（比如让智能体知道某个工具挂了，让它自己调整策略）
• 结合确定性保障措施：重试逻辑、定期检查点

挑战 2：调试需要新方法

智能体会动态决策，即使提示词完全相同，每次运行的过程也可能不一样。这让调试变得非常棘手。

用户反馈"智能体找不到明显的信息"，但你根本不知道问题出在哪：是搜索词不对？来源选错了？还是工具调用失败了？

Anthropic 的解决方案：添加完整的生产追踪，系统性地诊断智能体失败的原因。

他们还监控智能体的决策模式和交互结构（当然，不涉及用户隐私）。这种高层次的可观测性，帮助他们发现根本问题、识别意外行为、修复常见错误。

挑战 3：部署需要精心协调

智能体系统是由提示词、工具和执行逻辑组成的高度状态化网络，几乎持续运行。

这意味着，当你部署更新时，智能体可能正处于流程的任何位置。你不能简单地一刀切更新所有智能体——这会破坏正在运行的任务。

Anthropic 采用了 彩虹部署（Rainbow Deployments）：新旧版本同时运行，流量逐步从旧版本迁移到新版本，确保正在运行的智能体不受影响。

挑战 4：同步执行的性能瓶颈

目前，主智能体是同步执行子智能体的：等一批子智能体全部完成，才能继续下一步。

这简化了协调工作，但也造成了瓶颈：

• 主智能体无法实时指导子智能体
• 子智能体之间无法协调
• 整个系统可能因为等待一个慢子智能体而卡住

异步执行可以实现更多并行：智能体并发工作，需要时随时创建新的子智能体。但这也带来了新挑战：结果协调、状态一致性、错误传播……

Anthropic 认为，随着模型能处理更长、更复杂的研究任务，性能提升将证明这种复杂性是值得的。

结语：最后一公里，往往是最长的路

Anthropic 在文章结尾说了一句话，让我印象深刻：

“构建 AI 智能体时，最后一公里往往成了整个旅程的大部分。”

在开发者机器上跑得好好的代码，要变成可靠的生产系统，需要大量的工程投入。

智能体系统的错误具有复合性——传统软件里的小 bug 可能只是个小麻烦，但在智能体系统里，一步错可能导致整个任务跑偏，结果完全不可预测。

这就是为什么原型和生产之间的鸿沟，往往比你想象的要大得多。

但 Anthropic 也用实际成果证明了：多智能体系统在开放性研究任务上确实有独特价值。用户反馈说，Claude 帮他们发现了没想到的商业机会、搞定了复杂的医疗选择、解决了棘手的技术 bug，甚至节省了好几天的调研时间。

关键在于：你得知道什么时候该用，以及怎么用对。

这篇文章给出的不是银弹，而是一套经过实战检验的方法论：

• 8 条提示词工程原则
• 3 条评估方法
• 4 个生产环境的工程挑战及解决方案

最后，送给所有想构建多智能体系统的开发者一句话：

别只看 Demo 有多炫，要问自己：这套系统能在生产环境里稳定跑三个月吗？

如果你对这个问题没有信心，那这篇文章里的经验，就是你的必修课。

参考资料：

• 原文：How we built our multi-agent research system
• 开源提示词示例：Anthropic Cookbook - Agent Patterns