Anthropic 官方指南：多智能体不等于更强大

Anthropic 官方指南：多智能体不等于更强大

• 多智能体不等于更强大：Anthropic 官方指南完整中译

• 子智能体该留还是该合并？Anthropic 给了一套判断标准

• 从协调器回到单循环，Anthropic 的企业级智能体架构指南

最近 AI 智能体领域正在发生一场观念上的转向，过去一两年「多智能体协作」几乎成了行业默认解法，团队习惯通过一个协调器，拆出大量子智能体分工完成复杂任务，默认分工越细、数量越多，能力就越强。

可大量企业进入真实生产之后，很多团队发现这套架构能够暴露不少现实问题，上下文反复交接带来信息损耗，延迟与 Token 成本往上飙，系统复杂度居高不下，问题到底出在哪？

问题的根子在架构设计，它跟着组织架构走，像「康威定律」那样把部门结构直接复刻成智能体结构，不少 POC 原型看着漂亮，上线之后却很难维护迭代。

就在这个节点上，Anthropic 应用 AI 团队发布了一篇工程实践文章，标题是《Building agents：When to fold subagents into your main agent loop》，一反「越多 Agent 越好」的惯性思路。

PS：后台回复 261026 ，获取这篇文章的中英文版。

文章提出单智能体循环加技能工具渐进披露的新思路，同时开源了迁移工具包，指导企业审慎对待子智能体，判断哪些应当合并进主循环，哪些场景才真正需要保留多子智能体模式。

这篇文章不是实验室里的理论推演，是 Claude 平台上大量企业项目踩坑沉淀出来的落地经验，它面向 AI 开发者与技术架构师，也给企业管理层留了一份架构选型的参考。

下面是完整中文翻译。

构建智能体：何时应将子智能体合并入主智能体循环 Building agents: When to fold subagents into your main agent loop

如果你已经在 Claude 平台搭建过包含多个子智能体的智能体系统，可以参考本文，判断哪些子智能体适合借助我们的迁移工具包合并到主智能体循环当中。该工具包提供引导式工作流，可以识别你的系统模式、评估替代方案并验证最优实现方案，还附带演示案例，你可以在模拟系统上完成测试，再应用到实际智能体项目中。

子智能体拥有独立的上下文窗口、工具集与指令集，由协调器统一调度，是智能体设计里实打实的核心组件，校验复核、并行任务处理、模块化权限管控这些场景都非常合适。

Anthropic 内部基于 Claude 平台开发的多款智能体，例如我们的多智能体研究系统，都大量使用了子智能体。

不过 Anthropic 应用 AI 团队在企业落地实践中发现了一种趋势，不少企业级智能体项目把路由模块、规划模块、领域子智能体合并进主智能体循环之后，整体表现反而更好。

对比了大量企业落地案例之后，我们发现具备多技能的单智能体方案，在输出质量上往往优于「万能单提示词」方案与多子智能体方案，多数场景下还能够降低单任务成本、减少响应延迟。

举个实例，某企业面向用户的智能体内部部署了十多个专业子智能体，统一的品牌交互体验很难维持，还平白多出额外延迟，用户体验跟着受损。

我们还经常见到一类固化的智能体设计，意图分类器、固定多步推理流水线、用户分群模块、独立推荐分支，最外层再加一层多智能体协调器。

这类项目落地之后的反馈高度一致，架构里大部分工作大模型本身就有能力执行，一套清晰的系统提示词配上 4-5 个轻量化数据工具，再加上严格的输出防护规则，就能够覆盖绝大多数业务场景。

注：子智能体依然有其适用场景，尤其在前沿研究领域。满足以下三个条件时，应当保留子智能体。

1. 单智能体循环因为上下文膨胀，出现可量化的性能下滑；

2. 需要并行处理多项任务，每项任务都需要全新独立上下文，任务结束后即可丢弃该上下文；

3. 单智能体难以选择合适工具，或是系统提示词内存在互相冲突的指令。

但现实中很多企业会按团队、按业务类型直接拆出一个个子智能体，智能体架构完全复刻企业组织架构，这就是康威定律的典型体现。

下面结合大型企业智能体建设的实际经验，讲清楚什么场景适合把子智能体合并进主循环，以及对应的实践细节。

大型企业搭建智能体的常见失败模式 Agent building failure modes for large organizations

企业常常希望搭一个智能体，把多款产品、多项能力整合到统一的用户交互入口，让用户在一个界面里把问题解决完。

现实中每一项业务能力分属不同业务团队，于是企业让各个团队各自开发专属智能体，再由平台中心团队搭一层协调器，把所有子智能体串联起来。

常见架构分为两种，协调器加子智能体的分层结构，或者主智能体把其他智能体封装成 MCP 工具调用，看着简单省事，却会立刻催生一系列复杂度问题。

• 上下文管理难题。需要定义不同智能体之间传递哪些上下文，多轮交互过程中信息细节极易丢失。
• 子智能体泛滥。每个业务团队都上线自己的子智能体，企业内部最终会出现数百个功能重叠的子智能体，缺少统一规范，也没有明确责任人。
• 「拼接提示词」乱象。各个团队都往系统提示词里增加规则语句，最终指令互相冲突，交互输出风格无法统一。
• 缺乏全局视角的评估体系。每个团队自建评估指标，指标只针对自身子任务做优化，没有人维护完整的全局评估集，管理层却依靠这些片面的评估分数做决策。
• 响应延迟高。多智能体架构本身会带来额外开销，有客户做过对比，同样业务下，单智能体循环的运行速度大约是多智能体方案的 2 倍。

采用渐进式信息披露的智能体循环 Using an agent loop with progressive disclosure

虽然「协调器 + 子智能体」能够实现跨团队专业能力协同，但往往还有更优思路，通过技能实现上下文渐进披露，通过工具检索实现工具集渐进披露。

直白讲，智能体只看得到技能、工具的简要描述，真正需要的时候才加载完整详情，这套方案的优势有三点，而且都指向同一个结果：

1. 共享上下文，输出质量更高。对于长会话智能体，多项任务产生的全部信息保存在同一个主上下文窗口，智能体能够看到前面每一步的执行结果，串联全部信息，产出更丰富的回答、更深度的洞察，远优于子智能体返回一堆摘要片段的模式，也减少了多次切换上下文带来的信息损耗。

2. 渐进披露规避上下文膨胀。通过该模式，单智能体就能够处理五花八门的任务，不用一开始就把全部信息塞进超长系统提示词，这也消解了企业拆分大量子智能体的主要动因。事实上，针对新一代高级模型，我们把 Claude Code 的系统提示词精简了 80% 以上，其中大量优化就来自技能与工具的渐进披露机制。

3. 大模型能力持续变强。从 Opus 4.5 版本开始，模型在单个循环内可以处理的任务复杂度远超多数团队预期，Opus 5.5、Fable 5.1 等新一代模型会自主记录思考过程、主动校验结果，很多过去需要外部调度代码实现的逻辑，现在模型自身就能够完成。

   模型迭代升级之后，越来越多的决策逻辑可以从调度层下沉到模型内部，简洁的单循环架构也更适配模型升级迁移，不少客户案例中，僵化的多智能体架构反而限制住了新模型发挥能力。

单智能体循环模式对工程管控能力有要求，需要精心维护系统提示词，技能、工具的描述要做到精准触发，同时要妥善管理上下文窗口、记忆模块与笔记记录逻辑。后文会深入讲解迁移与架构设计要点。

建议由一个小型中心团队全权负责最终输出质量与系统提示词，任何新增工具、新增评估用例上线之前都必须经过该团队审核，小团队能够加快迭代速度，也可以降低跨部门协作成本。

如果依然选择多智能体路线，请优先挑能满足业务的最简单架构，生成校验模式、协调器加子智能体模式都算。

拆分子智能体要守住一条原则，按上下文边界拆分，分配给子智能体的任务尽量少依赖系统其他部分的信息，子智能体只返回精简结果。

适合交给子智能体的任务有几类：独立调研分支、接口清晰的独立组件、黑盒校验复核。

如果单纯按业务问题类型切割子智能体，就会陷入「传话游戏」，每一次子智能体之间传递数据都会损耗信息保真度。

如何将子智能体合并入主智能体循环 How to fold subagents into the main agent loop

不少企业已经上线了协调器加一系列专业子智能体的生产系统，我们建议朝着下面这套单循环架构演进：

1. 单个模型、单个上下文窗口，运行开放式工具调用循环，调度层设置各类上限，轮次预算、成本预算、写入权限管控。

2. 每一轮，模型批量发起工具调用，调度层并行执行全部工具，把原始返回结果交还给同一个模型，由模型决定下一步执行动作，继续调用工具、向用户提问，还是直接输出最终答案。

3. 当模型输出回答，或是触发任务预算上限，循环终止，回答输出之后，可以额外可选执行目标校验、结果复核逻辑。

4. 模型在首轮就会写下执行计划，拿到工具返回结果后随时修改计划，这是和「协调器 + 专业子智能体」模式最大的区别，写计划的模型同时负责落地执行，可以中途动态调整方案。

5. 上下文依旧会按需加载，由智能体自身管理。

• 不再需要额外代码，从规则库改写生成执行计划，全部步骤交由模型自主决策。

• 业务流程、领域专属规则，封装进技能（skills）。

• 校验规则、审批拦截，会话过程中需要的记忆查询等逻辑，封装进工具（tools）。

• 调度代码依然可以承担轻量通用预处理（例如实体解析），以及工具内部的机械性执行，请求报文组装、流式解析、澄清会话恢复。

单循环架构也更贴合很多团队的终极目标，即打造能够理解用户高层诉求、自主替用户执行任务的智能体，所有会话学习到的信息全部保存在同一个上下文。

下面按阶段介绍从多智能体系统迁移到单智能体循环的落地路径，同时兼顾多业务团队协同开发的问题。

构建任务完成度评估集 Task-completion evals

评估集是整场迁移的地基，缺了它，架构改动的好坏只能靠主观感受。迁移的起点就是搭这样一套评估集，用来判断某个子智能体是否适合合并进主循环。

实践中效果最优的方案，是一套由中心团队维护的全局端到端评估集，各个业务团队再为自己负责的技能配套一套小规模专项评估集，哪怕只有 10 条高质量基准样例，评估工作就可以启动。

可以对照评分标准给智能体最终输出打分，以此追踪回答质量，还保留协调器的阶段要额外追一项路由准确率，看协调器有没有选对子智能体。

子智能体合并完成之后，这一项换成校验环节，看智能体是否正确唤起技能、调用了哪些工具，持续完善面向任务完成度的评估体系，这是不同架构之间做对比的最重要依据。

如果内部系统难以复现线上环境、用户交互难以模拟，评估会变得很复杂，我们内部实践的一个可行方案是记录关键事件的时间戳，后续复现回放，执行定向评估。

逐步缩减子智能体数量 Reducing subagents over time

缩减的方向很清楚，向单智能体循环演进，本质就是把子智能体的能力转化为技能和工具。

具体可以走几条路径，合并领域子智能体、把原有子智能体封装为工具调用，或是直接改写为技能加工具。

合并领域子智能体 Combining domain agents

正式合并之前，先搭建端到端评估集，优先合并调用频次最高、上下文高度重合的子智能体，这条顺序比架构图画得细不细更重要。

如果多个专业子智能体之间存在调用依赖、读写同一批数据、经常被串联调用，就适合合并。

举个例子，线上大量请求流程都是先调用 A 子智能体，紧接着调用 B 子智能体，两者强耦合，就可以合并为一个领域智能体。

将子智能体作为工具调用保留 Subagents called as tools

当满足前文提到的适用条件、需要保留原有子智能体时，可以让主智能体把它当作工具调用，主智能体持续维护和用户的会话，这是三种处理方式里风险最低的一种。

只有子智能体需要直接跟用户对话交互，才把会话完全移交子智能体处理，其余场景都改在主循环内部通过技能加工具实现。

这种方式可以定义统一的返回结果规范，主智能体能够基于真实数据校验子智能体输出，精简后续汇总步骤。

同时不需要改写原有子智能体代码，还可以拿到任务评估集上的基准数据，用来判断后续要不要彻底合并这个子智能体，作为过渡方案很划算。

但该方案依旧遗留了部分缺陷：

• 各个专业模块依然保有独立提示词、独立上下文、归属不同业务团队，配套独立评估；

• 每次调用，依旧只能拿到有损的摘要返回；

• 每一次调用都会启动一套嵌套模型循环去执行，带来额外延迟。

通过技能与工具把子智能体彻底并入主循环 Folding subagents into the main agent via skills and tools

彻底合并要逐个改造子智能体，把提示词转化为技能，API 接口封装为 MCP 工具，改造完再对比开启与关闭原子智能体两种模式的评估表现，才决定是否保留原方案。

对比时不要只看综合分数，要关注哪些任务的结果发生了变化。

我们在一个客服智能体上做过测试，把子智能体合并之后延迟下降，但部分业务流程开始出错，主智能体直接调用订单查询工具给出答复，跳过了物流子智能体确认配送时间的关键一步。

因此每一次架构改动之前，评估用例必须覆盖生产环境所有串联调用链路以及所有业务禁止规则，每个用例还要多次运行，上面那个故障就只在 2 次运行中的 1 次复现。

多团队如何协同开发同一个智能体 How several teams can contribute to a single agent

领域业务逻辑可以存放于知识库、技能库、MCP 工具中，各个业务团队的技术工作重心，从维护独立智能体转向维护技能与工具。

系统提示词与端到端输出质量依旧由小型中心团队把控，新技能、新工具、评估用例上线都要经过该团队审核，这条规矩在多团队协作里最容易被忽略。

MCP 工具 MCP tools

工具适合的场景比较明确，智能体要执行动作、读取系统实时数据、输出固定格式结果的时候都用工具，迁移过渡阶段，也可以通过工具封装调用遗留子智能体。

建议按照用户意图分组管理工具，而不是一个 API 对应一个工具，系统提示词内的工具定义超过 30-50 个之后，模型选择工具的准确率就会下降。

可以开启工具检索加延迟加载机制，减少硬前置条件，把前置校验逻辑下沉到工具内部。

举个例子，工具 Y 依赖工具 X 的输出，就在 Y 工具内部校验前置条件，给模型返回可读指引。

用户权限控制同理，工具内部校验调用者权限，直接返回拒绝提示，单套循环就能够服务不同权限等级用户，不用为不同权限单独搭建智能体。

技能 Skills

技能沉淀的是业务团队的工作方法论，过去写在专业子智能体提示词里的业务步骤、业务规则、人工判断逻辑，现在都应该落在技能这一层。

我们对技能库的管理思路是，维护权归编写技能的业务人员，技能的创建、测试、清理这些机械工作交给 Claude。

为避免技能库无序膨胀，每个业务团队指定直接负责人（DRI），保障技能质量、功能边界清晰，配套对应的评估用例。

• /skill-creator。生成规范的新技能，审计存量技能，做删减、去重、重构。
• /skill-doctor。统计每个技能的调用成本、实际调用频率，清理废弃无用技能。

知识库 Knowledge bases

知识库存放偶尔才会查阅的参考资料，政策条文、指标定义、产品规格文档都属此类。模型通过检索、查询工具读取内容，也可以把参考文件嵌入技能。

但不建议写代码把大段知识库内容直接粘贴进提示词。

提升迁移效率的配套工具 Tools to accelerate this work

我们近期发布了一批 Claude API 技能，可以覆盖上面提到的绝大多数工作。

迁移工具包串联这些能力，提供引导式工作流，完成多智能体系统向单智能体循环的评估与迁移，还支持先跑演示 Demo，再落地到正式业务。

• /claude-api build-eval。协助生成中心团队维护的端到端评估集，或是各技能配套的小规模专项评估集。
• /claude-api prompt-audit。扫描提示词、技能、工具描述中为旧版模型编写的指令，输出修改建议，可以用于系统提示词巡检，清理过时规则，避免智能体变慢、逻辑僵化，各团队负责人也可以用来自查本团队的技能与工具描述。
• /claude-api hillclimb。迭代优化智能体，对齐评估标准，用于对比「保留子智能体」与「合并为技能加工具」两套方案，迭代调优技能、工具描述，判断合并之后是否达到甚至超过原有子智能体效果，也可以迭代优化系统提示词。
• /claude-api cost-optimize。分析 API 调用开销，给出降本方案，提示词缓存、裁剪不必要的输入输出 Token、调整推理算力等级、选型模型，逐项落地降低成本与延迟。

随着大模型持续迭代，智能体的技术实践也会不断更新，比起固定架构，更重要的是底层原则，做可量化评估，一次只改动一处，只保留经过验证有效的方案。

本案例就是这条原则的体现，随着模型能力越来越强、会话越来越长，越来越多子智能体的能力可以转化为主循环内的技能与工具。

迁移不需要一步到位，先搭建小规模端到端评估集，合并一个子智能体，如果评估效果变差就继续保留它，循环往复，逐步完成改造。

术语对照表（方便阅读）

文中反复出现的英文术语不少，这里整理成一张对照表，方便随时回看。译名按行业通行译法处理。

英文术语	中文释义
Agent	智能体
Subagent	子智能体
Main agent loop	主智能体循环
Skills	技能，封装业务流程、规则与判断逻辑
Tools	工具，执行调用、数据读取、权限校验等操作
Context window	上下文窗口，模型会话记忆空间
MCP tools	MCP 协议工具，标准化智能体调用外部能力接口
Eval / Evaluation	评估、测试用例集
Orchestrator	协调器，调度多个子智能体的调度模块
Conway's law	康威定律，系统架构会复刻组织沟通结构

后记

这篇 Anthropic 技术文章，本质上给火热的多智能体浪潮做了一次理性降温。它并非全盘否定子智能体与多智能体架构，而是划清了清晰边界。

那么多智能体到底还要不要做？

子智能体适合上下文膨胀、需要并行独立任务、指令互相冲突这几类少数特定场景，但很多企业盲目按照部门、业务模块拆分出大量子智能体，属于典型的过度工程化。

文章传递出几条非常务实的工程启示：

其一，新一代大模型推理、规划能力显著提升，很多原本交给协调器、子智能体完成的任务，现在完全可以交给模型本身在同一个上下文循环内完成，通过技能封装业务流程、MCP 工具处理外部调用、渐进披露机制控制上下文大小，兼顾能力广度的同时避免了提示词无限膨胀，实测案例中，改造后的单智能体循环运行速度甚至可以达到原有多智能体方案的 2 倍。

其二，企业做智能体建设要警惕「康威定律」陷阱，不要把组织架构直接复刻成智能体架构，推荐由小型中心团队统一管控系统提示词与全局评估标准，各个业务团队只负责输出技能、工具与配套评估用例，兼顾多团队协作开发和系统体验一致性。

其三，迁移改造切忌大刀阔斧一次性重构，必须以评估集为底座，逐个合并子智能体，每一次改动都校验任务完成质量，可以先通过工具封装旧子智能体作为过渡，对比基线效果之后再决定是否彻底合并。

其四，架构没有永远的标准答案，模型能力会持续迭代，比固定架构模板更重要的方法论是，可量化评估、小步迭代、只保留经过验证有效的方案。

对不同读者，这份译文的价值不太一样，AI 技术爱好者可以从中理解当下 Agent 行业从「堆数量」走向「重内核」的趋势。

AI 从业者可以把文中的迁移步骤、评估思路直接用于技术项目改造，企业高管则可以用来审视自家智能体项目，避开盲目堆砌子智能体带来的成本、延迟与体验不一致的坑。

扩展阅读

• Building agents：When to fold subagents into your main agent loop ：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

• 单循环迁移工具包（GitHub）： https://github.com/anthropics/single-agent-loop-kit

• Anthropic 多智能体研究系统： https://www.anthropic.com/engineering/multi-agent-research-system

看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。