Anthropic 劝企业拆掉子智能体：Agent 架构不该照抄组织架构图

如果你最近在公司里搭过 Agent，大概率画过这样一张图：最上面一个路由器，中间一个规划器，下面挂一排”客服 Agent””订单 Agent””财务 Agent”，每个由对应业务团队维护，再套一个总编排器。Anthropic 应用 AI 团队最新发布的工程文章，基本是在劝大家把这张图揉成一团：在多数企业场景里，它带来的不是能力，而是成本。

核心看点

• Anthropic 在多组企业部署中对比后发现：一个带技能的单一 Agent，在质量、成本、每任务延迟三项上经常同时胜过”编排器 + 专家子智能体”的结构。
• 有客户拿自己的多智能体框架和单循环做实测，后者运行速度大约快 2 倍。
• 官方给出三条理由：共享上下文能产出更好的答案、渐进披露压住了上下文膨胀、模型本身已经变强。
• 配套放出了迁移工具包，可以先在模拟系统上跑一遍，再动生产环境。

为什么”照抄组织架构”会翻车

文章点了一个很扎心的现象：企业做 Agent，往往先让各团队各建一个，再由平台团队在上面加编排层。这符合直觉，却同时引入了五种麻烦。

一是上下文管理。Agent 之间要传什么、丢什么，需要人为设计，信息在来回传递中不断损耗。二是子智能体泛滥，每个团队都发一个，最后出现几百个功能重叠、没有统一标准、也没有明确归属的 Agent。三是”缝合怪提示词”：每个团队往系统提示里加一句话，规则互相冲突，整体语气也没法统一。四是评测各自为政，每个团队只针对自己的子任务优化，没人对全局分数负责，管理层看到的是被稀释过的局部指标。五是延迟，架构越复杂越慢。

文章特别提了一句 Conway 定律：组织结构长什么样，Agent 架构就长什么样。这在软件史上从来不是夸奖。

替代方案：一个循环 + 渐进披露

Anthropic 建议的方向是把路由器、规划器、领域子智能体折进主循环，用两件事替代它们：技能做渐进披露，工具搜索做工具渐进披露。Agent 先只看到技能和工具的简短说明，需要时才完整加载。

这样做的好处很直接。长时间运行的 Agent 需要把多个任务的上下文留在同一个窗口里，它看过前面每一步的结果，才能把线索连起来，而不是拿着一堆子智能体交回来的摘要做二次猜测。上下文窗口少了，有损交接也就少了。

更关键的是模型变了。文章提到，从 Opus 4.5 开始，模型在单循环里能管理的东西远超多数团队预期；Opus 5.5 和 Fable 5.1 已经不能关闭思考，还会主动播报进度、边做边自查，很多原本写在框架里的工作变成了冗余。Anthropic 自己把 Claude Code 面向新模型的系统提示砍掉了八成以上，其中就包括渐进披露相关的部分。

不过单循环并不省事，反而更吃纪律：系统提示要精雕细琢，技能和工具的描述要在正确的时机触发，上下文、记忆、笔记都要刻意设计。文章的建议是由一个中央小团队对端到端质量和系统提示负责，所有新工具和新评测上线前都要过一遍。

什么时候仍然该用子智能体

文章没有一刀切。三种情况下子智能体依然是对的：单循环因为上下文膨胀出现可测量的性能下降；多个任务需要并行、且用完就能丢弃的干净上下文；单 Agent 在选工具上犯难，或者系统提示里出现了互相冲突的指令。

真要走多智能体路线，就从最简单的模式起步，并且按上下文切分而不是按问题类型切分：给每个子智能体一块几乎不需要依赖系统其余部分的工作，交回一个紧凑结果。按问题类型切分最容易变成”传话游戏”，每交接一次，保真度掉一截。

迁移怎么落地

文章给的路径很具体。第一步先建评测集，一个中央团队维护的端到端集合，加上各技能自带的小评测集，十条黄金样例就能起步。评分先看最终回答对不对；还留着编排器时，顺带记录路由准确率；子智能体折进去之后，改看 Agent 有没有加载正确的技能、调用正确的工具。

然后按共享上下文逐步合并，优先合并使用量最大的专家。目标形态是：一个模型、一个上下文窗口、一个开放式工具循环，轮次预算、成本预算、写入门禁都设在框架层；模型每轮发一批工具调用，框架并行执行并把原始结果回给它；计划由模型在第一轮写下，并随结果随时改写——写计划的和执行计划的是同一个模型，这是与编排器结构最本质的差别。排序和领域流程搬进技能，校验、审批这类硬限制搬进工具。

官方还放了迁移工具包，先用引导流程识别现有模式、评估替代方案，再在模拟系统上验证。对已经上线的多智能体系统来说，这大概是成本最低的一次”拆架构”预演。

一句话总结

Agent 架构不该是组织架构的影子。团队越多，越需要一个能自己看全局的循环，而不是一堆各自为政、互相传话的专家。