最近读了 Claude 团队做 Research 功能的工程文章，感觉被点醒了。

多智能体并不是我们想象的“多模型乱跑”，而是一套非常讲究实战经验的工程体系。


把我觉得最值钱的点分享出来，算是备忘，也给正在做 Agent 的朋友一些灵感。

我把那些读完后想立刻拿来用的部分整理成了下面这 12 条思考。



01. 多智能体的终极价值：扩大 token = 扩大智力

Claude 的团队给出的最本质 insight：

多智能体 = 安全地扩大 Token、上下文、探索路径的规模。

Token 消耗解释了 80% 的性能差异。

也就是说：

单智能体的局限是 线性推理 + 有限上下文。

多智能体通过 并行上下文窗口 → 撑大推理深度与覆盖面积

这比提升模型本身更具收益（Sonnet 3.7 → 4 不如多智能体带来的收益）



02. 最适合多智能体的任务：高并行 + 信息巨量 + 方向不确定

Claude 总结多智能体真正的 sweet spot：

✔ 开放式研究

✔ 多方向并行探索

✔ 信息分散、来源多样

✔ 工具链复杂

✔ 单一 agent 无法“一次性抓全”的任务


不适合：

✘ 代码生成（依赖共享上下文）

✘ 强依赖一致状态的任务（你必须 every turn 同步）



03.Orchestrator → Subagents，是目前最稳的架构

这是 Claude 的生产结论：

主智能体 orchestrate

子智能体 parallel explore

Lead 聚合、校验、再规划

自由协作的多智能体会发疯，有“主智能体 orchestration + 子智能体执行”能稳定落地。

原因：

  • 控制爆炸性增长

  • 容易设任务边界

  • 清晰的错误恢复机制



04. 工具 = 智能体的世界边界 —— 工具设计比提示更重要

Claude 的一个很核心观点：

工具就是智能体的世界模型。

工具描述不清 = 智能体理解现实错误。

他们发现：

工具描述稍微差一点，agent 会持续犯错。

改好工具描述，性能可提升 40%。


工具需要：

一句话说清楚用途（“解决什么问题”）。

明确输入类型、输出结构。

明确错误提示。

明确边界。


我们写工具的时候自以为很清楚，但对于模型来说，模糊一点点它都会理解成完全不同的事情。

Anthropic 团队甚至专门做了一个工具文档自动优化智能体。
光是重写工具描述就能让任务完成速度提升 40%。

所以工具不是提供一个 API，而是为智能体定义一个可理解的物理世界。



05. Prompt 的重点不是“指令”，而是“合作框架”

很多人会把 prompt 写成执行流程：“你应该这样做：A → B → C”

Anthropic 团队指出你不该告诉智能体：“怎么做”，你应该告诉它们“角色、目标、边界、资源预算”。

即：多智能体系统最有效的 prompts 是 “协作准则 + 协作结构”。

包括：

  • 如何划分任务
  • 什么时候扩展方向
  • 怎么评估来源质量
  • 子智能体之间不互相重复
  • 什么时候该停止

把智能体看成同事，而不是员工。



06. 智能体永远不知道任务难度，需要“努力预算”

特别有意思的一点：

Agent 不知道任务是简单还是困难，你必须告诉它“要投入多少 effort”。

比如：

  • 简单问题：1 个 agent + 3–10 次工具

  • 中等问题：3–4 个 agent 并行

  • 大复杂问题：10+ 个 agent 全线铺开

不然 Agent 会：

  • 简单问题开几十个 subagent（真实发生）

  • 大问题敷衍一下（也真实发生）

这种 Effort Guideline 很像我们给新人做任务时说的那句“这个别搞太久”。



07. 没有观测，就没有多智能体

他们花了大量篇幅讲 observability。

因为多智能体有个很要命的特征：

同样输入，同样 prompt，走出来的路径不一定一样。


要调试这种系统，你必须能看到：

  • 每次搜索什么
  • 为什么这么做
  • 工具结果是什么
  • 哪个 subagent 决策不合理
  • Lead 是怎么汇总结果的

说白了：
没有 trace，就没办法 debug 多智能体。

Anthropic 团队构建了一套观测系统：全量工具调用 trace + 每一步的思考过程 + 决策链路图 。



08. 分布式上下文管理：长任务必须总结 + 刷新上下文

一句话概括：

多智能体的本质，是“多个干净上下文窗口接力工作”。

Claude 的策略：

  • 阶段性总结
  • 存入 Memory
  • 创建新子智能体继续，避免上下文爆炸
  • 主智能体通过 Memory 保持连贯性

这才能让 200k token 的限制变成可管理问题。



09. 并行工具调用才是性能提升的真王道

他们的最终结果很夸张：

研究任务的速度，比顺序执行快了 90%。

就因为主智能体一次性创建多个 subagent，每个 subagent 内部又同时调用多个工具。

这个结构本质上把任务从“串行堆积”变成“分布式计算”。


用他们的话说：

Multi-Agent 的意义不是“多个模型”，而是“把模型拆成多核并行”。


三大并行：

  • Lead 同时创建多个 Subagents
  • Subagents 内部同时用多个工具
  • 工具链内部也可并行


10. 评估必须是“结果优先”，而不是“过程对不对”

因为多智能体每次走的路都不一样，所以 Claude 直接用 LLM-as-judge，只看：

  • 结果是否正确
  • 覆盖是否完整
  • 引用是否准确
  • 工具数量是否合理
  • 来源质量是否高

这是一种对复杂系统更健康的评估方式。



11. 错误不可避免，但必须能“从中断点恢复”

多智能体是有生命周期的。
一次工具报错，如果你让它重来整个任务，用户直接爆炸。

Claude 的工程经验：

  • 智能体是长生命周期、持续状态的
  • 工具失败 → 不能重来，只能继续
  • 系统必须保存中间状态（checkpoints）
  • 同时智能体自身可 adapt 错误

这是所有 Agent 系统都需要的“耐用性设计”。



12. 多智能体不是 prompt 玩具，是系统工程

文章的最后一句大意是：

Multi-Agent 的困难在“最后一公里”，工程化程度远超我们过去想象。

我也越来越觉得：工具、可观测性、容错、执行链路、协作协议、Memory 管理、分布式上下文、并行执行，这些比“让模型聪明”更难，也更关键。

Multi-Agent 是生产级工程，它是工程系统 + 协作协议 + 工具生态。