Anthropic官方劝退Multi-Agent：快2倍更省钱，你学的架构要凉了

年初那阵子，你刷到的 Agent 教程，十个里有八个在教你搭 Multi-Agent：先写个编排器，再拆出客服 Agent、检索 Agent、写码 Agent，中间加个规划器，最后用一个“总指挥”把它们全串起来。

一套下来，架构图漂亮得像家正经公司。

10 月 22 日，Anthropic 自己挂出一篇 18 分钟的长文，标题直译过来是：《构建 Agent：什么时候把 subagent 塞回主循环》。作者 Diane Sarkis。核心结论一句话——

把你的 subagent 砍了。

一个装了多个技能的单 Agent，质量往往比“万能提示词”和“一群子代理”都好，成本和延迟还更低。他们有个客户，把自家的多 Agent 架构换成单 Agent 循环之后，跑起来快了约 2 倍。

官方甚至配了个迁移工具包，放在 GitHub 上，名字就叫 single-agent-loop-kit，专门帮你把 subagent 并回主循环。

年初人人吹捧的架构，写它的公司自己来劝退了。

你的 Agent 架构，可能是公司组织架构的复印件

为什么编排器那一套不灵了？文章里有个特别扎心的观察。

企业一上手做 Agent，最容易犯的错是按部门对号入座：客服部就建客服 Agent，物流部建物流 Agent，退款部建退款 Agent，再设个编排器在顶上当“领导”。

表面分工严密，实际是把人类的组织架构，原样复印到了 AI 系统上。

这个毛病有个名字，康威定律——系统架构，会长成组织架构的样子。

放在人身上没问题，人传话会自动补细节。可两个大模型之间传话，走的是“摘要”：每经过一个 subagent 转述，细节就丢一截，延迟和 token 成本翻一倍。Anthropic 给这现象起了个形象的名字，传声筒效应。

他们在企业部署里反复见到五类失效模式，条条都跟这套架构有关：

· 上下文管理：Agent 之间交换信息，换来换去细节全丢了；

· subagent 泛滥：每个团队各建各的，最后攒出几百个功能重叠的子代理，没有统一标准，出了事找不到负责人；

· 拼凑式 prompt：每个团队往系统提示词里塞一句自己的规则，规则互相打架，连语调都统一不了；

· 评估失真：各团队给自家 subagent 定指标，指标只对自家有利，管理层拿着被稀释的分数做决策；

· 延迟：多 Agent 绕一大圈，客户实测单 Agent 循环快约 2 倍。

替代方案长什么样：一个循环，四个分工

那 Anthropic 推荐的单循环，到底怎么干活？

蓝图其实很朴素：一个模型，一个全局上下文窗口，一轮一轮跑下去。接到任务，先在上下文里写计划；然后一批一批并行调工具，原始结果直接回上下文；看到工具返回的最新情况，随时改计划；该追问用户就追问，该出结论就出结论；跑到了轮数或 token 预算上限，循环终止。

定计划的大脑，和干活的大脑，是同一个。

整个系统拆成四块，各管各的：

· 模型管决策：看反馈、改计划，以前外层写死的规划规则，可以删了；

· Skills 管领域知识：原来各个 subagent 提示词里沉淀的业务规范，提炼成技能，平时只露一行描述，用到了才加载全文；

· Tools 管执行：读写操作、数据检索封装成工具，权限校验、人机审批这些安全防线直接下沉到工具内部——模型越权时，工具直接返回拦截提示，不用再挂个“审批 Agent”；

· 传统代码管脏活：正则提取订单号、拼 API 参数、解析流式响应，这些确定性工作交给普通代码，别浪费模型的算力。

配套的关键机制叫“渐进式披露”，说白了就是说明书按需取用。这里有个数字值得记：系统提示词里的工具定义超过 30~50 个，模型选工具就开始变差。所以起步只给少量常用工具和一个搜索入口，剩下的等模型真用到了再加载。

Claude Code 自己就是受益者——靠这套思路，针对更强模型的系统提示词，砍掉了 80% 以上。

说句公道话：subagent 没死，只是活变少了

Anthropic 没把话说绝，文章明确列了三种还该用 subagent 的场景：

1. 单 Agent 跑着跑着上下文膨胀，性能明显往下掉；

2. 一堆任务要并行处理，干完即弃；

3. 工具太多模型选不过来，或者系统提示词里的指令互相冲突。

而且“单 Agent 更好”这个结论，有个大前提——模型变强了。文章原话：从 Opus 4.5 开始，模型单次循环能干的活，远超大多数团队的预期；到 Opus 5.5 和 Fable 5.1，思考过程连关都关不掉，模型会自己汇报进度、自己核对成果。

翻译一下：以前需要外挂编排器干的活，模型自己接管了。官方甚至说了，决策尽量放回模型里，连 Harness（外层框架）以后都可能变得多余。

还有一句更实在的：迁移不是一键的事。Anthropic 自己举了个客服 Agent 的例子——把某个 subagent 并进主循环后，延迟确实降了，结果主 Agent 查订单时没去问物流 subagent 要配送日期，自己张口就答，原本跑得通的流程反而坏了。

所以官方给的迁移姿势是：先建评估集，从用得最勤的 subagent 开始，一个一个试着并入，每次对比“哪些任务的结果反转了”，再决定留不留。

我的两点观察

写这篇之前，我把官方原文通读了一遍，跟中文圈流传的解读版逐个数字对过：快 2 倍、30~50 个工具上限、提示词砍 80%，全部对得上官方原文，这篇解读没有加戏。

对的过程里还有个小插曲：原文里 Opus 5.5、Fable 5.1、Mythos 这几个模型名，我一度以为是解读文章写岔了——跑去官方原文搜了一遍，都是真名。这批模型迭代到什么程度，可见一斑。

另一点：我天天在用的 AI 编程客户端，现在回头看就是这套架构的活标本——一个主循环，技能平时只露一行简介，用到了才加载全文，工具也是按需注册。年初那种“总指挥 + 一堆子代理”的玩法，在我自己的工具链里，已经找不到影子了。

写在最后

年初人人都在教 Multi-Agent，几个月后写它的公司自己来劝退——这个节奏下，真正值得学的不是“哪个架构是对的”，而是底下那层判断力：

架构是给模型能力不够时打的补丁。模型每强一代，补丁就该撕一层。

下次再有人教你搭“总指挥 + 十个子 Agent”，先问一句：这是业务真的需要，还是康威定律又发作了？

对了，官方那篇长文还配了个迁移工具包（GitHub 上的 single-agent-loop-kit），想把多 Agent 拆回单循环的可以去看看，带 demo，能先在模拟环境里试。

下篇拆单 Agent 迁移的具体操作：评估集怎么搭、subagent 怎么逐个并回去，关注别错过。

FAQ

Multi-Agent 架构真的过时了吗？

A：官方口径不是一刀切。大多数场景用“单 Agent + Skills + 工具搜索”就够，但上下文膨胀明显、任务需要并行用完即弃、提示词指令冲突这三种情况，subagent 仍然该用。

什么是渐进式披露？

A：平时只让模型看到技能和工具的一行描述，真正用到时才加载完整定义，控制上下文体积。官方给的参考线：系统提示词里工具定义超过 30~50 个，模型选工具就开始变差。

已有的多 Agent 系统要不要迁？

A：先别大动。官方姿势是先建端到端评估集，从使用频率最高的 subagent 开始逐个试并入，对比任务成败再决定去留——它自己就举过“迁完反而把流程弄坏”的客服案例。

这篇要是让你想起了自己搭过的架构，评论区聊聊；顺手点个赞或在看，也行。