别学 subagent 了，已经要凉了。

点击上方蓝字关注我，加个🌟标不迷路。

各位小伙伴们大家好，我是 cxuan。

前两天，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 循环中。

emmmm，下面才开始认真起来。

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

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

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

不过最近，应用人工智能体团队（Applied AI） 近期在企业级智能体部署中发现了一种模式。

这种模式是将路由模块（Router）、规划模块（Planner）以及特定领域的 subagent 整合进 Main Agent Loop.中，能够带来显著成效。

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

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

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

官方图中文版：模型外部叠加五层结构，与单个 Agent Loop 的执行流对比

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

不过 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 ，然后中心平台架构组将这些 Agent 整合，整合过程会用到编排器（Orchestrator） 。

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

这些架构模式看起来很简单，但往往会引入复杂性问题：

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

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

• 拼凑式 prompt：每个团队都在 system prompt 中加入一句话，导致规则相互冲突，且无法保持统一的语调。

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

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

企业多 Agent 的五类失效模式：上下文丢失、subagent 泛滥、prompt 冲突、局部评测失真和延迟累积

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

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

我们上面提到了 Orchestrator ----> Agent 模式架构，这其实是一种构建 Agent 的合理方案，不过不是最佳方案，但往往更有效的做法是，用 Skills 来呈现上下文，并通过 Tool Search（工具搜索） 来逐步提供可用工具。

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

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

（我看到这其实不太理解，于是我研究了下。）

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

Tool Search（工具搜索），解决的是先发现、再加载的问题。它和 Tool Use 可以搭配起来：

1. 起步只放少量内容：Skills 可以先提供简短描述；对于工具，则先让模型拿到 Tool Search 和少量常用工具，其他工具的完整定义暂不进入模型上下文。

2. 需要时再搜索和加载：模型发现要查订单，先通过 Tool Search 搜索工具目录，命中后再把对应工具的完整参数规格和说明加载进来。

3. 加载后照常调用：模型再通过 Tool Use 调用订单工具，结果继续返回同一个上下文。

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

工具全量加载与 Tool Search 按需加载对比：发现工具、加载定义、Tool Use 执行、返回结果

图：本文补充示意，机制参照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 的话，很容易陷入三人成虎，问题失真的情况。

官方图中文版：按问题类型拆分会连续交接，按上下文拆分让 Agent 保留实现与测试信息，Verifier 独立验证

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

如何将 subagent 合并进 Main Loop 中

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

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

那 A 社推荐使用的单循环到底长啥样？它凭什么能干掉一群 subagent ？

A 社给出了一个非常清晰的单循环核心设计蓝图：

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

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

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

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

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

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

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

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

Main Agent Loop 动画：写计划、并行调用工具、接收原始结果、修订计划、继续查询、回答与可选验证

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

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

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 和工具来替代它们。

官方迁移动图中文版：合并 subagent、将其作为 Tools 调用、把 prompts 和 API 调用并入 Skills 与 Tools

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

整合领域智能体

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

有些 Agent 是交互性的，把各自的输出作为彼此的输入，或者同时调用的专用 Agent，首先应该将其合并。存在紧密耦合关系的 Agent 适合合并为一个统一的 Domin Agent（领域内智能体）。

subagent 作为 tools

如果你的 subagent 适合上述三种情况之一的话，你就可以考虑把 subagent 作为工具来让 Main Loop 调用了，让 Main Agent 掌控 subagent 和用户的对话过程。

当 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 最后有没有把事做成。

Emmm ，最后 A 社竟然给它的工具打起了广告也是，它说的 Claude API 工具也是帮忙协助完成上面我们讨论的大部分工作。

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

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

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

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

如果这篇文章你觉得还不错，谢谢你的三连，也希望可以转发给同样关注 AI / 科技 / 开发效率的朋友。 我是 cxuan，我们下期再见。