别学 subagent 了，Claude 官方直言多 Agent 架构要凉

前两天，Claude 发布了一篇文章《Building agents: When to fold subagents into your main agent loop》，非常值得仔细研读，里面提出了不少新想法。

看完之后算是被点醒了。原来我们现在玩的 multi-agent 思路，在 A 社看来已经是旧时代的产物了。估计又有一批做多 Agent 方向的产品要慢慢被淘汰掉。

他们现在主张的玩法，是单 Agent + Main Loop 循环。

在 Claude 上构建 Agent 时，减少 subagent 的数量，改用渐进式呈现上下文与工具的策略，既能提升质量，又能降低成本和延迟。

刚开始，Claude 先插播了一条建议：如果大家正在用多 Agent 的智能体，可以试试他们的迁移工具包，能自动把 subagent 并入主 Agent 循环中。

emmm，下面才是正文。

subagent 和主 Agent 一样，拥有各自的上下文窗口、工具和指令，统一由协调者（Coordinator）负责调度和规划，这是智能体设计的核心组成部分。

你会发现，随着 AI 架构的不断演进，越来越像 CPU 线程和子线程的设计了。

Claude 是最推崇这种架构的，这篇文章也提到，这一直是 Claude 平台构建智能体的机制和方式。

不过最近，应用人工智能体团队（Applied AI）在企业级智能体部署中发现了一种新模式：将路由模块（Router）、规划模块（Planner）以及特定领域的 subagent 整合进 Main Agent Loop 中，能够带来显著成效。

然后 A 社强调，他们横向对比了多个企业级部署，在质量方面，一个拥有多个 skill 的单个 Agent 往往优于万能提示词方案和 subagent 方案。此外，这种方案在单项任务上的成本和延迟通常也更低。

A 社还提到，他们见过不少 Agent 方案，通常遵循一种比较常见的架构演进路径——包含意图分类器、固定的多步推理流程、基于用户分群体的逻辑、独立的推荐分支，以及最上层的多智能体协调器。

然而实际运行中给出的反馈恰恰相反，这种架构里大部分组件其实是多余的。事实上，只需要一个清晰的 prompt + 4、5 个轻量级工具，再加上稳健的 约束机制（guardrails），就足以覆盖绝大多数应用场景。

图：根据官方动图中文重绘

不过 A 社也没有完全否定 subagent 的价值，他们承认 subagent 在以下场景中仍有用武之地：

• 单一 Agent 在循环运行中因上下文膨胀出现明显性能下降时
• 需要并行处理多项任务，任务完成后即可丢弃时
• 单一 Agent 难以选择合适的工具，或者 system prompt 中存在相互冲突的指令时

然而，实际中常见的情况是：企业为每个团队或问题类型各配一个 subagent，导致 Agent 架构最终成了组织架构的翻版——这正是“康威定律”在起作用。

什么是“康威定律”（Conway's Law）？

说人话就是：公司里有客服部、物流部、售后退款部，大家一上手搞 AI Agent，第一反应往往也是按部门对号入座，建一个客服 Agent、物流 Agent、退款 Agent，再设一个平台“领导”编排器（Orchestrator）在上面统筹调度。

表面上看分工严密、各司其职，但实际上这是把人类团队的组织架构直接照搬到 AI 系统架构上。大模型之间互相传话可不像人那样灵活，反而会陷入严重的“传声筒效应”（Telephone Game）。信息每经过一次 subagent 的转述和摘要，就会丢失大量细节，延迟和 Token 成本却翻倍飙升。

所以下面的内容围绕如何把 subagent 并入 Main Loop 来展开，A 社也分享了具体的最佳实践。

---

企业中的 Agent 构建失效模式

很多企业都想构建一个 Agent，将多种产品和功能整合到统一的客户交互界面中。

常见的做法是：每项能力由各自的团队负责开发各自的 Agent，然后由中心平台架构组负责整合，整合过程会用到 编排器（Orchestrator）。

这种整合方式有很多种，比如 Orchestrator ──> Agent 模式，或者简单点，直接将 Agent 挂到 MCP 中，再把 MCP 集成进去。

这些架构模式看着简单，但往往会引入一系列复杂性问题：

• 上下文管理：你需要确定 Agent 之间交换哪些上下文信息，而在频繁的信息交换过程中，细节往往会丢失。

• subagent 泛滥：每个团队都各自部署 subagent，企业最终积累了数百个功能重叠的 subagent，没有统一标准，出事了找不到责任归属。

• 拼凑式 prompt：每个团队都在 system prompt 里加一句话，规则相互冲突，语调也没法保持一致。

• 未经审核且过于局部的评估：每个人都自行添加评估指标，针对各自 subagent 过度优化。整个评估体系缺乏统一负责人，管理层做决策时依据的是被稀释且过于局部的评分结果。

• 延迟累积：多 Agent 架构的复杂性会增加延迟。A 社客户对比多 Agent 框架和单 Agent + Loop 架构后发现，后者的速度快了约两倍。

图：根据官方原文的五类失效模式整理，动画为补充说明。

---

采用渐进式呈现机制的 Agent Loop

前面提到的 Orchestrator ──> Agent 模式，确实是构建 Agent 的一种可行方案，但不是最佳方案。往往更有效的做法是：用 Skills 来呈现上下文，并通过 Tool Search（工具搜索） 来逐步提供可用工具。

也就是说，Agent 最初只能看到 Skills 和工具的简短描述，只有真正需要时，才会加载其完整内容。

插一句：这里的 Tool Search 和我们平时说的 Tool Use 有什么区别？

Tool Use（工具调用） 说的是模型怎样调用工具。在默认一次暴露全部工具的做法里，你需要把这些工具的完整定义、参数类型、JSON Schema 和使用说明，全部放进模型上下文。工具一多，说明书就会先占掉大量 Token。A 社在原文中也有提到，system prompt 中暴露超过 30 到 50 个工具定义后，工具选择往往会变差。

Tool Search（工具搜索） 解决的则是“先发现、再加载”的问题。它可以和 Tool Use 搭配使用：

1. 起步只放少量内容：Skills 先提供简短描述；工具方面，先让模型拿到 Tool Search 和少量常用工具，其他工具的完整定义暂不进入模型上下文。
2. 需要时再搜索和加载：模型发现要查订单，先通过 Tool Search 搜索工具目录，命中后再把对应工具的完整参数规格和说明加载进来。
3. 加载后照常调用：模型再通过 Tool Use 调用订单工具，结果继续返回同一个上下文。

说白了，就是把工具说明书改成按需取用。这里的延迟加载控制的是内容何时进入模型上下文；使用官方 API 时，客户端仍要提交工具的完整定义，供服务端搜索和展开。

图：补充示意，机制参照 Tool Search 官方文档。

这么做的依据有三点：

• 共享上下文有助于生成更优质的回答：对于长期运行的 Agent，我们希望来自多个不同任务的上下文都能保留在主上下文窗口中。如果 Agent 能掌握此前每一步的执行结果，它便能将这些步骤串联起来。

• 渐进式披露：这是一种能有效避免上下文过于臃肿的机制。通过这项技术，团队可以构建出能完成多种任务的单个 Agent，而不必把所有上下文一次性塞进 system prompt。采用渐进式披露，消除了以往团队为了应对上下文限制而不得不把任务拆分给多个 subagent 的主要原因。 Claude Code 针对更强模型的系统提示词缩减了 80% 以上，其中就包括渐进式披露带来的精简。

• 模型能力会变得更强：A 社强调，从 Opus 4.5 开始，模型在单次循环中能处理的任务量远超大多数团队的预期。在 Opus 5.5 和 Fable 5.1 等模型中，你无法关闭其思考（思维链）过程；这些模型在执行任务时，会越来越主动地阐述进展并自行核对成果，让原本 Harness 中的某些组件变得多余。此外，每一代模型能力的跃升，都会让更多决策从外部框架中剥离，转而由模型本身来决定。以后 Harness 里可剥离的决策会越来越多，最后剩下的可能就是模型能力的差异了。

单 Agent 的设计需要严谨把控，主要包括这些细节：

1. 需要精心管理的 system prompt
2. 能在恰当时机触发的 Skills 与工具描述
3. 上下文窗口、记忆和笔记记录的审慎处理

因此，A 社建议应当有一个负责端到端 system prompt 质量把控的核心团队，并在每项新工具或评估方案正式发布前进行审核。

如果要选择多智能体架构（multi-agent），可以从简单的 generator ──> verifier（生成器 → 验证器）或者 Orchestrator ──> subagent 模式入手。

应该根据上下文合理划分边界：为每个 subagent 分配独立任务，完成后返回精简结果。如果按照问题类型来拆分 Agent，很容易陷入三人成虎、信息失真的困境。

图：根据官方静态图中文重绘，并补充交接动画。

---

如何将 subagent 合并进 Main Loop

目前绝大多数企业和团队在线上运行的 Agent，基本都是经典的 Orchestrator ──> Agents 架构：一个总编排调度器，下面挂一堆专精各业务的 subagent。

这种架构在早期模型推理能力弱、上下文窗口小的时候确实顶过一阵子，但现在弊端越来越明显——细节丢失严重，延迟动辄翻倍。

那 A 社推荐的单循环到底长什么样？它凭什么能取代一群 subagent？

1. 核心运行机制：单一上下文 + 开放式工具循环

以往的多 Agent 架构喜欢把业务切得很碎，每个子 Agent 都有独立上下文。而单循环的核心是：全程只用一个模型，只维护同一个全局上下文窗口。

整个 Loop 的运转逻辑是这样的：

• 第一轮写计划：模型接收到任务后，直接在自己的上下文里写下执行计划。

• 批量并行调用工具：每一轮交互中，模型根据当前执行计划发起一批工具调用（Tool Calls）。外层的 Harness 负责并发调用下游 API，并将最原始的数据直接返回给模型。

• 边执行、边改计划（动态规划）：这是单循环与传统 Orchestrator 方案最大的质变。过去计划由外面的编排器或硬编码规则写死；现在定计划的大脑和干活的大脑是同一个。模型看到工具返回的最新结果，发现情况有变，可以立刻在上下文里动态修正后续计划。

• 自主决定下一步：由模型根据当下的全局信息，自主决定是继续发起下一批工具调用、向用户追问细节，还是输出最终结论。

• 终止条件与兜底：当模型给出最终回答，或触发外部预算阈值（如最大轮数、Token 预算耗尽）时，循环终止。如果业务有严格的质检需求，还可以在回答后外挂一个轻量的 Goal / Verifier 核查程序。

图：根据官方原文的单循环设计补充。

不知大家发现没有？这完全就是一个自驱力极强、拥有全局视野的超级大脑在独立解决问题，不再需要任何外部协调器在旁边指手画脚。

2. 职责四分法：模型、Skills、Tools 与代码

A 社把整个系统的职责边界划分得非常清晰，四大组件各司其职，彻底解耦：

1. 模型（Brain——全局大脑）

• 负责全局战略决策与动态规划。
• 自己看反馈、自己改计划，以往靠外层代码写死、按规则目录强行重写计划的繁琐逻辑，全部可以删掉。

2. Skills（领域业务 SOP）

• 原来每个专属 subagent 的 system prompt 里沉淀的业务规范、执行顺序和行业准则，全部提炼为 Skills。
• 采用前面提到的渐进式披露：平时只露简短描述，模型判定需要时才动态加载对应领域的完整 SOP。

3. Tools（能力接口）

• 所有真正的系统读写操作、数据检索，以及对话中临时需要的动作（如记忆检索），全部封装为 Tools。
• 更关键的是，硬性规则与安全防线（如校验逻辑、人机审批 Approval Gates、用户权限校验）全部下沉到 Tools 内部。如果模型执行时缺少参数或越权，Tool 直接返回明确的拦截指示，模型看懂后自会调整动作，无需外挂专门的权限审核 Agent。

4. 传统代码（脏活累活）

• 别迷信大模型能搞定一切，传统写死的代码依然大有用武之地，专门负责低开销、确定性的机械工作。
• 比如提前用正则或轻量逻辑提取用户输入中的实体（订单号、用户 ID），直接注入上下文；或者在 Tool 内部负责构造 API Payload、解析流式响应、处理断点恢复。这些活交给普通代码又快又省，完全不需要浪费模型的思考算力。

A 社在文中点出了一个非常深刻的结论：

很多团队梦寐以求的终极目标，是构建一个能够真正理解用户高层意图、并能代其自主采取行动的通用 Agent。

但在多 Agent 架构下，各个 subagent 就像各自为政的部门员工，彼此之间只能靠损耗极大的摘要信息来回传话，没有一个人能看清全貌。

而单循环设计把 Agent 在整个执行过程中学到的一切、走过的所有弯路、看到的全部原始数据都保留在同一个上下文中。模型拥有了连贯的全局记忆，才能把前面每一步的线索串联起来，做出真正有深度的洞察与决策。

---

从大家熟悉的 Multi-Agent 架构平滑迁移到单 Agent Main Loop，A 社在帮助不少企业完成迁移后，总结了一套策略：

评估任务完成情况

第一步是构建评估集，评估某个 subagent 是否适合整合进 Main Loop。A 社的评判架构是：核心团队负责维护共享、端到端的测评集；同时，Skills 的负责团队各自提供规模较小的评估集，并随相应 Skills 一同发布。

实际执行中，需要对 Agent 的回复做质量评估。如果系统中存在 orchestrator，还需要评估路由的准确性。

但由于每次回答无法保证 100% 复现，且很难模拟，评估起来会比较复杂。一种可行做法是：记录关键事件的时间戳，等日后重现时再做评估。

逐步减少 subagent

向单一 Agent Loop 演进，意味着把 subagent 整合为工具和 Skills。

具体实现方式包括：合并某些领域内的 subagent、将其作为工具调用，或者用 Skills 和工具来替代它们。

图：根据官方迁移动图中文重绘。三种方式可以分阶段采用，保留与否要逐个通过端到端评测判断。

整合领域智能体

在首次合并领域内 Agent 之前，先构建一套小型的端到端评估方案。然后基于共享上下文，将使用频率最高的 subagent 逐步整合。

有些 Agent 是交互性的，输出互为输入，或者经常同时调用的专用 Agent，应该优先合并。存在紧密耦合关系的 Agent 适合合并为一个统一的 Domain Agent（领域内智能体）。

subagent 作为 tools

如果你的 subagent 符合前面提到的三种适用场景之一，就可以考虑把 subagent 作为工具让 Main Loop 调用，由 Main Agent 掌控 subagent 和用户的对话过程。

只有当 subagent 确实需要与用户交互时，才让它来接管。除此之外，subagent 只适合作为 Skills 和工具集成到 Main Loop 中。

你可以为 subagent 制定统一的响应模式，让 Main Agent 验证 subagent 的结论，对内容进行精简后再汇总。

不过，仍会存在一些潜在的失效情况：

• 每个专用 Agent 都有各自的 prompt、上下文、负责团队以及评估指标。
• 每次调用后，返回的仅是经过信息损耗的摘要（lossy summary）。
• 每次调用都相当于一个嵌套的模型运行循环，增加系统延迟。

通过 Skills 和工具将 subagent 整合

将 subagent 并入 Main Loop 的方式：将其提示词 prompts 转化为 Skills，并将 API 调用转换为 MCP 工具，然后对比有无该 subagent 时的评估表现，进而决定是否保留。

对比时不要只关注最终得分，还要查看具体是哪些任务的结果发生了反转。

A 社举例说，他们在测试一个客服 Agent 时发现，将某个 subagent 整合进去虽然降低了延迟，却导致原本能顺利完成的流程出了故障——Main Agent 在自行处理订单查询时，没有向负责物流的 subagent 询问配送日期，而是直接给出了回答。

---

多个团队如何 build 单个 Agent

A 社的意思是，Domain 的推理能力可以从知识库、Skills 和 MCP 工具中获取，Agent 团队可以将所有权从 Agent 层面下放到 Skills 和工具层面。

MCP 工具

当 Agent 需要执行操作、从系统中读取实时数据，或以固定格式返回结果时，使用工具是最合适的方案。在系统迁移过程中，也可以利用工具来持续调用 subagent。

Skills

当 Agent 需要了解团队的具体工作——比如专家型 subagent 在执行任务时所遵循的步骤、规则及判断标准——Skills 便是最合适的方案。

扩展 Skill 库的策略是，将维护工作交还给 Skill 的创建者。Claude 可以承担维护任务，通过扩展、测试和精简 Skill 的方式实现 Skill 库的自动化管理。

使用 /skill-creator 可以创建结构规范的 Skill，也能对现有技能进行审计，从而精简、去重、重构。使用 /skill-doctor 可以查看 Skill 库中各项技能的成本和实际使用频率，进而清理掉冗余或无效的 Skill。

知识库

知识库非常适合存放特定的参考资料。各类事实和参考资料既可以通过模型调用的搜索或查询工具来获取，也可以作为参考文件包含在 Skill 中。需要避免的是通过代码检索这些上下文信息并将其粘贴到 prompt 中。

总结一下：Tools 管执行，Skills 管做事的方法，知识库管参考资料，核心团队管整个 Agent 最后有没有把事做成。

---

最后 A 社也不忘给自己的工具打广告，说 Claude API 工具能协助完成上面讨论的大部分工作。

看完这篇文章，不得不说 AI 时代变化太快了。还记得年初的时候，大家都在讨论多 Agent 架构，甚至 A 社自己也推崇 multi-agent 架构。中间也就过了几个月，这种架构就慢慢要过时了。现在的玩法是单个 Agent + Main Loop，就像一个超级大脑不断在脑海中循环迭代，检查自己每项工作有没有做得更到位。以后的模型可能也会按照这种方式来运作。

这是不是 DeepSeek 所崇尚的 AGI 呢？

而且 A 社还说，以后的决策尽量放在模型中，这也就意味着，Harness 可能也要过时了……

真是应了那句话：只要学得晚，就可以不用学了。