从ChatGPT时代到现在，大家逐渐达成共识：大模型的应用核心不是算法问题，而是工程问题。大模型本身作为基础设施已经就位，关键在于如何通过工程手段解决记忆存储、上下文管理、工具调用和提示词优化等实际问题。

最近读了Anthropic关于多智能体系统的工程实践， 感觉很有意思，所以分享出来。这一篇将解析：

1. 1. Multi Agent的架构设计（Orchestrator-Worker模式）
2. 2. Multi Agent的优劣势
3. 3. 提示工程实践（8条 Anthropic 核心经验）

下一篇写Anthropic的智能体评估、生产可靠性和工程挑战。

Multi Agent 的架构

Orchestrator-Worker模式解析

Anthropic采用orchestrator-worker架构模式。

在AI的论文中经常可以看见orchestrate这个单词。orchestrator的本义是是管弦乐的编曲者，是把一首乐曲改编成适合管弦乐队演奏、并为每种乐器分配合适声部和旋律的人。

在这里orchestrator 引申为“负责总体调度、协调、编排所有子任务的组件，又叫lead agent（主智能体）。 worker是执行子任务的智能体，又叫subagent（子智能体）。

主智能体作为系统的"指挥中心"，其核心职责包括：

• • 任务分解与分配
• • 资源协调与调度
• • 结果整合与决策

子智能体则专注于执行特定子任务，彼此并行工作，通过分工协作提升系统整体效率。

架构图

下面是研究系统的架构图。

（图源于Anthropic官网）

如图所示，当用户提交查询时，主智能体会进行分析，制定策略，通过子智能体迭代使用搜索工具收集信息，然后将信息返回给主智能体，最后汇总成最终答案。

多智能体与RAG的不同：

检索增强生成 (RAG) 一种静态检索，它们会获取与输入查询最相似的一组词块，并使用这些词块生成响应。而多智能体架构采用多步骤搜索，可以动态地查找相关信息，适应新的发现，并分析结果以生成高质量的答案。

交互流程

下面是多智能体系统的交互流程，这里可以看出，除了不同的智能体、还有Memory模块和Citation Agent。

（图源于Anthropic官网）

步骤如下：

1. 1. 当用户提交查询时，系统会创建一个 LeadResearcher（主研智能体），它进入迭代式研究循环。
2. 2. 主研先思考整体方案，并把计划写入 Memory（记忆模块），以保证上下文被持久化——因为上下文窗口一旦超过 20 万 token 就会被截断，保留计划至关重要。
3. 3. 主研创建若干专门的 Subagent（分研智能体，图中示例为 2 个，实际数量可任意），各自领取具体的子任务。
4. 4. 每个分研独立执行网页搜索，并用“Interleaved thinking”的方式评估工具返回结果，随后将发现返回给主研。
5. 5. 主研汇总这些结果，并判断是否需要继续研究；
6. 6. 如需继续，它可以再创建新的分研或调整策略。当信息足够后，系统退出研究循环，把所有发现交给 CitationAgent（引用智能体）。
7. 7. 引用智能体对文档和研究报告进行处理，为每一处需要引用的内容定位具体来源，确保所有结论都能追溯到出处。最终，带完整引用的研究结果返回给用户。

值得一提的是，这里说到Interleaved thinking 是指交错思考。

Claude 4 模型在调用工具（tool calls）时，不把“思考过程”一次性打包完，而是在每次得到工具返回结果之后，再插入一段新的思考（reasoning），然后再决定下一步要不要继续调用工具、调用哪一个工具。

整个“思考—调用工具—再思考—再调用……”的流程像齿轮交错一样穿插进行，而不是传统的“先一口气想好所有步骤，再连续执行”。

Multi Agent的优劣势

为什么研究性的工作适合用Multi Agent 来做？

因为研究工作主要涉及开放性的问题，研究者会根据在研究过程中出现的线索，持续更新自己的研究方法。

研究工作的不确定性刚好和AI Agent的特性匹配。AI Agent可以做到自主运行多轮，并根据中间发现决定后续方向。

这样复杂的任务又意味着线性的、一次性的Single Agent 无法处理，必须是Multi Agent协同工作。

Multi Agent Research System擅长什么？

多智能体研究系统尤其擅长处理同时涉及多个独立方向的广度优先查询。

主智能体下发任务，子智能体通过与各自的上下文窗口并行运行，同时探索问题的不同方面，提炼每个部分的最重要的信息。

每个子智能体的关注点不相同，他们有不同的工具、提示和探索轨迹，从而减少路径依赖，并支持进行彻底、独立的研究。

Multi Agent Research System有什么缺点？

缺点是token消耗的很快。Agent使用的token数量是chat 的4倍，Multi Agent使用的token数量是chat 的15倍。

因此，multi agent适合高价值的任务，适合并行任务，multi agent不适合有流程编排的任务，因为它成本巨大。相比研究工作来说，编码工作的并行任务就比较少。

什么决定Multi Agent的性能？

系统性能主要取决于三大要素：

1. 1. 是否使用了充足的token
2. 2. 工具调用的次数
3. 3. 基座模型能力：底层大模型的性能决定系统上限

上面的结论是Anthropic使用OpenAI提出的BrowseComp基准进行评估得出来的。BrowseComp是一个用来评估AI Agent查找困难信息的能力的基准。

Multi Agent 提示工程实践

多智能体系统与单智能体系统的关键区别是协调复杂性的快速增长。

早期的智能体会犯一些错误：

1. 1. 为了一个简单查询就生成 50 个子智能体
2. 2. 在网络上无休止地搜索不存在的信息源
3. 3. 过度更新导致偏离主方向

注意，上面这些问题，都是纯靠提示工程优化来解决的哦。提示工程远远比想象中还要重要。

在Anthropic的多智能体系统里，每一个智能体都有一个提示引导。

Anthropic总结了以下8条经验：

站在智能体的角度思考。Think like your agents.

**要迭代提示，必须了解其效果。**有效的提示工程，取决于使用者是否能在脑子里建立对 Agent 的“精确预期模型”；一旦预期有了，最该改什么、怎么改，往往就一目了。

教会主智能体如何分发任务。Teach the orchestrator how to delegate.

在多智能体系统中中，主智能体将查询分解为子任务，并将它们描述给子智能体。

主智能体写的任务说明书必须包含四件套：
• objective——到底要产出什么结论或数据
• output format——以什么格式交卷（表格、段落、JSON …）
• tools & sources——能用哪些工具、查哪些库/网站
• task boundaries——责任边界，防止“三不管地带”或“抢地盘”

如果说明书太简陋，就会出现三类问题：
• 重复劳动（duplicate work）
• 遗漏信息（leave gaps）
• 找不到关键资料（fail to find necessary information）

Anthropic发现，简单、简短的指示是行不通的，例如给出“研究半导体短缺问题”的指示，这些指示非常模糊，以至于子智能体会误解任务，或者执行与其他代理完全相同的搜索。

根据查询复杂度调整工作量。 Scale effort to query complexity.

智能体难以判断不同任务的合理工作量，因此Anthropic在提示中写了scaling rules。

• • 简单的事实调查（fact-finding）只需 1 名智能体调用 3-10 个工具；
• • 直接比较（direct comparisons）可能需要 2-4 名子智能体，每名子智能体调用 10-15 个工具；
• • 复杂的研究（complex research）可能需要 10 名以上子智能体，并明确划分职责。

这个scaling rules 有两个好处：让班长智能体高效地分配资源；避免在简单查询上投入过多资源。

工具的设计和选择至关重要。Tool design and selection are critical.

很多人在设计工具的时候经常忽视两点，一是代理跟工具之间的“接口体验”，这相当于人跟软件的 UI/UX。对人来说按钮看不懂会点错；对代理来说 schema 不清、描述含糊就调错。选错工具不仅低效，而且常常意味着任务从根上失败。

二是工具的定义不清晰。例如MCP（Model-Context-Protocol）服务器可能一次性把几十个外部工具塞进代理视野，其中很多工具彼此重叠或描述质量参差不齐。

工具本身的设计（功能边界、输入输出格式）和“选哪个工具”这两个决策点，直接决定智能体能否完成任务。

对此，Anthropic采取的策略是：
• 先扫一遍所有可用工具，整体心里有数
• 把工具能力与用户意图做匹配（intent → tool mapping）
• 需要广泛外部信息时才用通用 web search
• 能用专用工具就不用通用工具（specialized > generic）

Anthropic对工具描述规定了“三有”：
• 有独特定位：功能不跟别人撞车
• 有清晰描述：一句话就能让代理明白“什么时候该用它”
• 有明确边界：输入需要什么、输出给什么、不能干什么

让智能体自我提升。Let agents improve themselves.

让智能体自己发现问题 → 自己出改进方案 → 自己验证效果。

Anthropic写了一个 Tool-testing agent（工具打磨智能体），是这么用的：

• • 输入：一个刚写好的 MCP 工具（schema + 描述往往有缺陷）。
• • 动作：
  ① 反复调用该工具（几十次），记录所有失败、边界情况、误用场景。
  ② 自动重写工具描述：补充必填字段说明、加示例、标陷阱、改格式。
• • 输出：性能更好的新版工具说明书。

这个工具带来了性能的提升：新版工具描述上线后，后续代理使用该工具的任务完成时间下降 40%；因为常见坑点已被前置说明，智能体不再踩雷。

搜索策略的第一步是“宽”，第二步才是“深”。Start wide, then narrow down.

智能体的问题：query由又长又专业的词组合而成，结果找出的信息有限。
改进做法：

• • 先用核心关键词做“广度搜索”；
• • 浏览返回结果，逐步增加限定词（时间、地域、指标等），让目标更集中，做深度搜索。

这个思路是仿人类的做法：人类专家查资料时，总是先看“这片领域有什么”，再决定“哪个点值得深挖”；智能体也应照做。

指导思考过程。Guide the thinking process.

拓展思考和交错思考进行。

并行工具调用提升了速度和性能。 Parallel tool calling transforms speed and performance.

复杂的研究任务自然需要探索众多来源，但是串行会使任务执行得非常漫长。

为了提高速度，Anthropic引入了两种并行化方式：(1) 主智能体并行启动 3-5 个子智能体；(2) 子智能体并行使用 3 个或以上工具。这些改进将复杂查询的研究时间缩短了高达 90%。

总结

Anthropic的这套提示词是启发式的，也就是说来源于人类的经验，而不是定死的规则。

我觉得他们的工程做得很细致。他们研究了专家如何处理研究任务，并将这些策略融入到提示中——例如根据新信息调整搜索方法，以及识别何时关注深度（详细研究一个主题）而非广度（并行探索多个主题）。

他们还通过Tool-testing agent进行自我迭代，同时为每个智能体设置提示词，制定了一些标准防止智能体失控。不过考虑到token的巨大消耗，还需要在成本控制、错误预防和流程优化等方面持续改进。