从原型到生产：Anthropic 如何用多智能体架构打造 Research 功能

这两篇文章均来自 Anthropic 工程博客。第一篇「Building Effective Agents」发表于 2024 年 12 月，作者为 Erik Schluntz 和 Barry Zhang，系统梳理了 Agent 系统的基础构建模块——从增强型 LLM、五种经典 Workflow 到自主 Agent。第二篇「How we built our multi-agent research system」发表于 2025 年 6 月，作者为 Jeremy Hadfield、Barry Zhang 等人，首次公开了 Claude Research 功能背后的多智能体架构设计、工程挑战与经验教训。

两篇文章一脉相承：前者是理论基础，后者是实战落地。Anthropic 用自己的产品验证了那些设计原则，并在工程实践中发现了很多教科书里不会告诉你的东西。

文章链接：

Anthropic 对 Agentic Systems 的分类：Workflow 与 Agent 的区别

先搞清楚一个问题：什么是「Agent」？

「Agent」这个词在行业里用得很乱。有人拿它指完全自主的系统，有人拿它描述按固定流程跑的脚本。Anthropic 给了一个清晰的分类框架：所有这些都叫「Agentic Systems」，但内部要区分两种东西——

Workflow：LLM 和工具通过预定义的代码路径编排。路径是写死的。

Agent：LLM 动态决定自己的流程和工具使用，自己控制怎么完成任务。

区别的关键在于「控制权」在谁手里。Workflow 里，代码是老板，LLM 是打工人。Agent 里，LLM 自己就是老板。

那什么时候该用哪种？Anthropic 的建议很务实：从最简单的方案开始，只有当简单方案不够用时才加复杂度。 很多场景下，单次 LLM 调用加上检索和上下文示例就够了。Workflow 适合任务明确、步骤可预测的场景。Agent 则适合开放性问题，你没法提前知道要走几步、怎么走。

五种经典 Workflow 模式

在进入多智能体系统之前，Anthropic 先定义了五种经过验证的 Workflow 模式。这些模式不是理论假设，而是他们在与数十个团队合作中观察到的最成功实践。

五种 Workflow 模式概览

「Prompt Chaining」——把任务拆成流水线

将一个任务分解成一系列步骤，每个 LLM 调用处理上一个的输出。中间可以插入程序化的检查点（Gate）来确保流程没跑偏。

典型场景：先生成营销文案，再翻译成另一种语言。先写文档大纲，检查大纲质量，再根据大纲写正文。本质是用延迟换取更高的准确性——每一步的子任务更简单，出错率更低。

「Routing」——先分类，再分发

对输入进行分类，然后路由到专门的处理流程。核心好处是「关注点分离」。如果不做路由，为了一种输入做的优化可能会伤害其他输入的表现。

典型场景：不同类型的客服咨询被分到不同的处理链路。简单问题用小模型（如 Claude Haiku 4.5），困难问题用大模型（如 Claude Sonnet 4.5），在性能和成本之间找平衡。

Parallelization 工作流：Sectioning 和 Voting 两种变体

「Parallelization」——能并行的就别串行

两种变体：「Sectioning」把任务拆成独立子任务并行跑；「Voting」让多个 LLM 对同一个任务给出不同结果，投票决定最终答案。

典型场景：一个模型处理用户请求的同时，另一个模型检查内容是否合规。或者多个 Prompt 从不同角度审查代码漏洞，互相补充。

Orchestrator-Workers 工作流：动态拆解任务并委派

「Orchestrator-Workers」——中央调度，动态分工

一个「编排者」LLM 动态拆解任务，委派给「工作者」LLM，然后综合结果。和 Parallelization 的关键区别是灵活性——子任务不是预定义的，而是由编排者根据输入动态决定。

这正是 Claude Research 功能所采用的架构。后面会详细展开。

Evaluator-Optimizer 工作流：生成-评估循环

「Evaluator-Optimizer」——边做边检查，循环迭代

一个 LLM 生成回答，另一个 LLM 评估并给出反馈，循环往复直到质量达标。适合有明确评估标准、且迭代改进能带来可衡量收益的场景。

典型场景：文学翻译中，评估者能捕捉到译者遗漏的细微语义。或者复杂搜索任务中，评估者决定是否需要更多轮搜索。

从理论到实战：Claude Research 的多智能体架构

以上五种模式是「零件」。现在看 Anthropic 怎么用这些零件搭建一个真正的生产系统。

多智能体架构：用户查询流经主 Agent，生成专门子智能体并行搜索

为什么 Research 需要多智能体？

研究任务有一个本质特征：路径不可预测。 你没法提前硬编码一个固定流程来探索复杂问题。人类做研究时，会根据新发现不断调整方向，跟着线索走。Agent 需要同样的灵活性。

多智能体架构在此处展现了三个核心优势：

第一，并行压缩。搜索的本质是压缩——从海量语料中提炼洞见。子智能体各自拥有独立的上下文窗口，同时探索问题的不同方面，再把最重要的 Token 浓缩给主研究 Agent。

第二，关注点分离。每个子智能体有独立的工具、Prompt 和探索路径，减少了路径依赖。

第三，Token 规模化。Anthropic 的分析表明，Token 使用量本身解释了 BrowseComp 评估中 80% 的性能方差。多智能体架构通过将工作分配到独立的上下文窗口，有效扩大了可用 Token 总量。

数据说话：在内部评估中，使用 Claude Opus 4 作为主 Agent、Claude Sonnet 4 作为子 Agent 的多智能体系统，比单 Agent 的 Claude Opus 4 表现高出 90.2%。

但代价也很明显。Agent 通常使用约 4 倍于普通对话的 Token，而多智能体系统约 15 倍。经济可行性取决于任务价值是否足够高，能覆盖这笔开销。

Claude Research 系统完整工作流

架构细节：编排者-工作者模式的具体实现

Claude Research 采用了经典的编排者-工作者（Orchestrator-Worker）架构，但实现细节值得细看。

主研究 Agent（LeadResearcher） 负责分析用户查询、制定策略、创建子智能体、综合结果。它先通过「扩展思维」（Extended Thinking）规划方案，将计划存入「记忆」（Memory）以应对上下文窗口截断——超过 200,000 Token 时上下文会被截断，计划必须持久化。

子智能体（Subagents） 各自独立执行搜索任务。每个子智能体使用「交错思维」（Interleaved Thinking）在工具调用之间评估结果质量、识别信息空白、优化下一步查询。

引用 Agent（CitationAgent） 是最后一步的专门模块。它处理文档和研究报告，识别需要引用的具体位置，确保所有声明都有出处。

整个流程是迭代的。主 Agent 综合子智能体的结果后，如果信息不够，可以创建更多子智能体或调整策略。只有当信息足够时，才会退出研究循环。

八条 Prompt 工程经验

多智能体系统和单智能体系统有一个关键差异：协调复杂度急剧增长。 Anthropic 早期的 Agent 会为简单查询创建 50 个子智能体、在网上搜索不存在的来源、相互之间传递过多更新。每条经验都是从失败中总结出来的。

第一，像你的 Agent 一样思考。 Anthropic 在 Console 中用完全相同的 Prompt 和工具构建了模拟环境，逐步观察 Agent 的行为。这立刻暴露了失败模式：Agent 在已有足够结果时仍在继续、搜索查询过于冗长、选择了错误的工具。有效的 Prompt 工程依赖于对 Agent 行为的准确心智模型。

第二，教编排者如何委派。 早期 Anthropic 让主 Agent 给子 Agent 简单指令，比如「研究半导体短缺」。结果子 Agent 经常误解任务，或者多个子 Agent 做了完全相同的搜索。后来发现，每个子 Agent 需要：明确的目标、输出格式、工具和来源指引、清晰的任务边界。

第三，按查询复杂度伸缩投入。 简单事实查询只需 1 个 Agent、3-10 次工具调用。直接对比可能需要 2-4 个子 Agent、每个 10-15 次调用。复杂研究可能用超过 10 个子 Agent，各自职责明确。

第四，工具设计和选择至关重要。 Agent-工具接口的重要性不亚于人机界面。一个在 Slack 里搜索本该在网上找的信息的 Agent，从一开始就注定失败。MCP Server 让问题更复杂——Agent 会遇到描述质量参差不齐的未知工具。Anthropic 的解决方案：给 Agent 明确的启发式规则，比如先检查所有可用工具、匹配用户意图选择工具、优先用专业工具而非通用工具。

第五，让 Agent 自我改进。 Claude 4 系列模型本身就是优秀的 Prompt 工程师。给它一个 Prompt 和一个失败案例，它能诊断原因并建议改进。Anthropic 甚至创建了一个工具测试 Agent——给它一个有缺陷的 MCP 工具，它会尝试使用、发现 Bug，然后重写工具描述。这个过程将未来 Agent 的任务完成时间降低了 40%。

第六，先宽后窄。 搜索策略应该模仿专家的做法：先广撒网了解全貌，再逐步聚焦。Agent 往往默认使用过长、过具体的查询，返回结果寥寥。Anthropic 通过 Prompt 引导 Agent 从短而宽的查询开始，评估可用内容，再逐步缩小焦点。

第七，引导思维过程。 扩展思维模式可以作为可控的草稿纸。主 Agent 用它来规划方案、评估工具适配、判断查询复杂度和子 Agent 数量。测试显示，扩展思维改善了指令遵循、推理质量和效率。

第八，并行化是性能倍增器。 两种并行化同时使用：主 Agent 同时启动 3-5 个子 Agent（而非串行），子 Agent 每次使用 3+ 个工具（而非逐个调用）。这些改变将复杂查询的研究时间缩短了 90%。

生产系统的工程挑战：教科书里不会告诉你的事

从原型到生产，是 Anthropic 反复强调的「最后一英里」。在传统软件里，一个 Bug 可能破坏某个功能或降低性能。但在 Agent 系统里，微小的变化会级联放大为巨大的行为变化。

Agent 是有状态的，错误会复利

Agent 可以长时间运行，在多次工具调用之间维护状态。这意味着需要持久化执行代码，并在过程中处理错误。当错误发生时，不能直接从头开始——重启代价高昂且让用户沮丧。

Anthropic 的解决方案是构建能从错误发生点恢复的系统。同时利用模型自身的智能来优雅处理问题——比如告知 Agent 某个工具出故障了，让 Agent 自行适应。这种 AI 适应性与确定性保障（重试逻辑、定期检查点）的组合被证明非常有效。

调试需要新思路

Agent 做动态决策，且即使 Prompt 完全相同，每次运行结果也不确定。用户报告 Agent「找不到明显的信息」，但团队看不到原因——是搜索查询太差？选错了来源？工具故障？

添加完整的生产追踪（Production Tracing）解决了这个问题。团队可以诊断 Agent 为什么失败并系统性地修复问题。他们还监控 Agent 的决策模式和交互结构——但不监控对话内容，以保护用户隐私。

部署需要「彩虹策略」

Agent 系统是高度有状态的 Prompt、工具和执行逻辑网络，几乎持续运行。每次部署更新时，Agent 可能处于流程中的任何位置。Anthropic 使用「彩虹部署」（Rainbow Deployment）来解决——同时保持新旧两个版本运行，逐步将流量从旧版本切换到新版本，避免中断正在运行的 Agent。

同步执行是当前瓶颈

当前架构中，主 Agent 同步等待子 Agent 完成，才能进入下一步。这简化了协调，但制造了瓶颈：主 Agent 无法在过程中调整子 Agent 的方向，子 Agent 之间无法协调，整个系统可能因为单个子 Agent 搜索缓慢而被阻塞。

Anthropic 认为异步执行是下一个重大改进方向，但异步带来的结果协调、状态一致性和错误传播问题仍然是开放挑战。

评估：怎么知道多智能体系统到底好不好？

多智能体系统的评估有其独特挑战。传统评估假设 AI 每次走相同的步骤，但 Agent 可能走完全不同的有效路径。Anthropic 分享了三条经验。

立刻开始小样本评估。 在早期，变更的影响往往非常显著——一个 Prompt 调整可能将成功率从 30% 提升到 80%。这种效应量下，20 个测试用例就足以看清变化的影响。不要等到有几百个测试用例才开始做评估。

LLM-as-Judge 在做得好时可以规模化。 Anthropic 使用 LLM 评分员，按标准评判输出：事实准确性、引用准确性、完整性、来源质量、工具效率。出乎意料的是，一个 LLM 调用、一个 Prompt、输出 0.0-1.0 分和通过/不通过评级的方案，比多个评分员的组合更一致，也更符合人类判断。

人类评估能捕获自动化遗漏的问题。 人工测试者发现了评估系统遗漏的边界情况：对不常见查询的幻觉回答、系统故障、微妙的来源选择偏差。比如早期 Agent 一致性地选择 SEO 优化的内容农场，而非权威但排名较低的学术 PDF 或个人博客。在 Prompt 中加入来源质量启发式规则解决了这个问题。

工具工程：被低估的核心能力

在「Building Effective Agents」的附录中，Anthropic 专门用了一整节讨论工具的 Prompt 工程。这个主题通常被忽视，但实际极其重要。

核心理念是：Agent-计算机接口（ACI）和人机接口（HCI）一样重要。 如果一个工具对人类开发者来说描述不清、容易用错，那对 LLM 也一样。好的工具定义应该包含示例用法、边界情况、输入格式要求和与其他工具的清晰边界。

几个实用的经验法则：

  • 给模型足够的 Token 去「思考」，不要让它写到一半才发现走错了方向。
  • 格式尽量接近模型在互联网文本中自然见过的形式。写 diff 需要提前知道变更行数，写 JSON 里的代码需要额外转义——这些都是不必要的认知负担。
  • 防呆设计（Poka-yoke）。改参数设计，让错误更难发生。Anthropic 在构建 SWE-bench Agent 时发现，模型在使用相对路径时频繁出错——切换到强制使用绝对路径后，问题消失。

有意思的是，Anthropic 表示他们在 SWE-bench Agent 上花在优化工具上的时间，比优化整体 Prompt 还多。

自主 Agent 的高层流程

三个核心原则

回到这两篇文章的共同主题。Anthropic 在构建 Agent 系统时遵循三个原则：

  1. 保持简单。 Agent 设计的简单性是最重要的。能用 Workflow 解决的就不要用自主 Agent。能用单 Agent 解决的就不要用多 Agent。复杂度只在它确实能改善结果时才值得引入。

  2. 保持透明。 Agent 的规划步骤应该明确可见。用户和开发者都需要理解 Agent 为什么做了某个决策。

  3. 精心设计接口。 ACI（Agent-Computer Interface）值得和 HCI 一样多的投入。工具的文档、测试和迭代优化是 Agent 系统成功的基石。

这些原则不复杂。但从原型到生产系统的差距往往比预期大得多——这正是 Anthropic 用一整篇文章分享工程经验的初衷。

正如文章最后所言：当构建 AI Agent 时，最后一英里往往成为大部分旅程。在开发者机器上跑得通的代码，要成为可靠的生产系统，需要大量额外的工程投入。Agent 系统中错误的复利性质意味着，传统软件中的小问题可能让 Agent 完全偏离轨道。一步失败可能导致 Agent 走上完全不同的路径，产生不可预测的结果。

但也正因为如此，当这些系统被做对的时候，效果是惊人的。Anthropic 提到，用户反馈 Claude Research 帮他们发现了没考虑过的商业机会、在复杂的医疗方案中做出选择、排查棘手的技术 Bug、甚至节省了数天的工作量。多智能体研究系统，正在改变人们解决复杂问题的方式。