Anthropic 分享何时把子智能体折叠进主智能体循环

在 Claude 平台中构建智能体时，减少子智能体的使用、转而采用渐进式披露的上下文和工具，可以提升质量，同时降低成本和延迟。以下是迁移的时机与方法。

类别：最佳实践、观点

如果你在 Claude 平台中构建的智能体包含多个子智能体，可以看看哪些适合用我们的迁移工具包折叠进主智能体循环。它会运行一套引导式工作流，识别你的模式、评估替代方案，并验证最佳方案。其中包含一个演示，你可以先在模拟系统上试用，再应用到你的智能体上。

子智能体——拥有自己的上下文窗口、工具和指令，并由协调器编排的智能体——是智能体设计的核心组成部分。它们在验证、并行工作和模块化权限管理方面很有效。我们在自己用 Claude 平台构建的许多智能体中都会使用它们，例如我们的多智能体研究系统。

不过，最近应用 AI 团队发现了一类企业智能体部署模式，它们从把路由器、规划器和领域子智能体折叠进主智能体循环中获益。在我们对多个企业部署的对比中，一个带技能（skills）的单一智能体在质量上常常优于“一个提示词包打天下”的设计和子智能体设计，而且每个任务的成本和延迟往往更低。

例如，一家公司发现，其面向客户的智能体中那十几个专家子智能体使得维持一致的品牌体验变得困难，还增加了延迟，损害了用户体验。

我们还经常看到一些提议的智能体设计遵循一种熟悉的演进路径：一个意图分类器、一条固定的多步推理流水线、用户分群桶、独立的推荐分支，以及顶层的一个多智能体编排器。

在这些情况下，反馈往往是：这套结构中的大部分工作，模型已经不再需要它来完成了；一个清晰的系统提示词、4-5 个轻量数据工具和严格的输出护栏，就能覆盖大多数用例。

需要说明的是，子智能体仍有其用武之地，包括在研究前沿。在以下情况下使用它们：

单个智能体循环因上下文膨胀而出现可测量的性能下降，或

多个任务需要并行处理，且各自使用全新的上下文窗口，任务完成后即可丢弃，或

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

但我们常常看到企业为每个团队或每类问题各配一个子智能体，结果智能体架构变成了其组织架构图的翻版（康威定律在起作用）。

本文说明何时应考虑把子智能体折叠进主智能体循环，并分享我们在大型组织中构建智能体时总结的最佳实践。

大型组织中的智能体构建失败模式

公司常常希望构建一个智能体，把多个产品和能力统一到单一的客户界面中。

通常，每项能力由不同的团队负责，因此公司一开始让各个团队分别构建自己的智能体，再由一个中央平台团队在其上构建编排器。这可以采取多种结构，包括编排器-子智能体，或单个智能体把特定智能体作为 MCP 工具暴露出来。

这看起来是最简单的方案，但会立即引入以下复杂性：

上下文管理：你需要决定智能体之间交换哪些上下文，而且往往在来回传递中丢失细节。

子智能体泛滥：每个团队都发布自己的子智能体，于是公司最终拥有数百个相互重叠的子智能体，既没有强制执行的标准，也没有明确的负责人。

拼凑式提示词（Frankenprompt）：每个团队都往系统提示词里加一句话，导致规则相互冲突，语气也不统一。

未经审核、过度本地化的评估：每个人都添加自己的评估，且过度针对自己的子任务进行优化。没有人负责或维护整套评估，而管理层基于被稀释、过度本地化的分数做出决策。

延迟：多智能体架构的复杂性会增加延迟。一位客户将他们的多智能体框架与单一智能体循环进行了对比评估，发现后者的运行速度大约快 2 倍。

使用带渐进式披露的智能体循环

上文描述的编排器-子智能体设计是协调跨团队构建的专家智能体的一种合理方法，但通常更有效的方法是：通过技能（skills）渐进式披露上下文，并通过工具搜索（tool search）渐进式披露工具。换句话说，智能体只看到技能和工具的简短描述，只有在需要时才完整加载。

这种方法之所以合理，有三个原因：

共享上下文能产生更好的答案：对于运行时间较长的智能体，我们希望来自多个不同任务的上下文都保留在主上下文窗口中。一个已经看到每个先前步骤结果的智能体能够将它们联系起来，从而产生比子智能体交回的一组摘要更丰富的输出和更好的洞察。这也意味着更少的上下文窗口和更少的有损交接。

渐进式披露可防止上下文膨胀：这项技术让团队能够构建单一智能体，完成各种各样的任务，而无需把所有上下文都立即加载进一个很长的系统提示词中。这消除了团队此前把工作拆分给子智能体的主要原因。事实上，我们把 Claude Code 面向更先进模型的系统提示词缩减了超过 80%，其中就包括与渐进式披露技能和工具相关的删减。

模型能力更强了：从 Opus 4.5 开始，模型在单个循环中能处理的事情远超大多数团队的预期。在 Opus 5.5 和 Fable 5.1 上无法关闭思考功能，而且近期的模型会越来越多地叙述自己的进展，并在过程中检查自己的工作，这使得某些 harness 元素变得多余。每一个新模型都让你能把更多决策从 harness 移到模型本身。更简单的循环也更容易迁移到下一个模型；在我们帮助客户完成的迁移中，僵化的多智能体结构往往是阻碍新模型承担更多工作的原因。

单一智能体循环的设计需要纪律：精心管理的系统提示词、能在恰当时机触发的技能和工具描述，以及对上下文窗口、记忆和笔记的审慎处理。本文将在后续章节深入探讨迁移和设计方面的考量。

应由一个核心团队负责端到端质量和系统提示词，在每一项新工具和评估上线前对其进行审核。保持这个核心团队规模较小，有助于快速迭代，并降低大型组织内的协调成本。

如果走多智能体路线，就从能起作用的最简单模式开始（生成器-验证器、编排器-子智能体或其他模式）。通过按上下文划分来有效分解边界：给每个子智能体分配一项几乎不需要系统其余部分参与的工作，并让它交回一个紧凑的结果（合适的候选包括独立的研究路径、接口清晰的独立组件，或黑盒验证）。当按问题类型拆分智能体时，它们会陷入“传话游戏”，信息来回传递，每次交接都会降低保真度。

如何把子智能体折叠进主智能体循环

许多团队已经在生产环境中拥有一个编排器和一组专家智能体。以下是我们建议逐步采用的一种单一循环设计：

一个模型和一个上下文窗口运行一个开放式工具循环，并在 harness 中设置限制（轮次和成本预算、写入闸门）。

每一轮，模型发出一批工具调用。harness 并行运行它们，并把原始结果返回给同一个模型，由它决定下一步：再发一批调用、向用户提问，还是给出答案。

当模型给出答案或触及预算时，循环停止。答案之后可以选择运行目标检查或验证器检查。

模型在第一轮把计划写入上下文，并在结果到达时修订计划。这是与编排器和专家智能体设置的主要区别：写计划的模型也是执行计划的模型，因此它可以在轮次中途更改计划。

上下文仍然会被加载，并由智能体自身管理：不再需要从规则目录重写计划的代码步骤，因为模型会决定每一步。

排序和领域流程移入技能。

硬性限制（校验、审批关卡）以及对话中途出现的其他任何事项（例如记忆查找）都移入工具中。

代码仍可用于加载任何成本低廉且几乎总是相关的内容（例如实体解析步骤），以及在循环调用的工具内部处理任何机械性部分（载荷构建、流解析、恢复澄清）。

这种单一循环设计也有助于实现许多团队正在努力达成的最终状态（一个理解用户高层目标并代表用户行动的智能体），因为它把智能体学到的一切都保留在同一个上下文中。

以下建议说明了团队如何分阶段从多智能体系统过渡到单一智能体循环，以及多个团队如何在此过程中持续为该智能体做出贡献。

任务完成度评估

第一步是创建一个评估集，帮助你判断是否应将某个子智能体折叠进主智能体循环。我们见过的有效评估结构是：一个由中心团队负责的共享端到端评估集，加上由各技能所属团队随每项技能交付的较小评估集。即使只有 10 个黄金示例，也足以起步。

根据评分标准对智能体的最终消息进行评分，是跟踪答案质量的良好起点。在仍有编排器时，你还应跟踪路由准确率（它是否选对了子智能体？）。一旦某个子智能体被折叠进来，就改为检查智能体是否加载了正确的技能或调用了正确的工具。逐步推进任务完成度评估是有益的，因为在比较不同架构时这一点最为重要。

在内部系统难以重放、用户交互难以模拟的环境中，这会变得复杂。我们在内部行之有效的一种做法是：在重要事件上记录时间戳，以便之后重放这些事件来运行有针对性的评估。

随时间推移减少子智能体

向单一智能体循环演进，意味着把子智能体折叠进工具和技能中。这可以通过合并领域子智能体、将它们作为工具调用，或用技能和工具替换它们来实现。

合并领域智能体

在第一次合并之前，先构建一个小型端到端评估。然后按共享上下文逐步折叠，从使用最多的子智能体开始。

合并那些彼此串联输出、接触相同数据或经常被一起调用的专家。例如，如果生产流量中有相当大的一部分是某个专家之后紧接着第二个专家，那就是一对紧密耦合的组合，因此适合合并为一个领域智能体。

将子智能体作为工具调用

当上述三个条件之一适用、而你仍保留某个子智能体时，让主智能体把子智能体作为工具调用会很有效，这样主智能体就能继续与用户保持对话。

我们只建议在子智能体需要直接与用户交谈时，才进行完全交接，即由子智能体接管对话。其他一切都可以作为主循环中的一个技能加若干工具。

这样你就可以为子智能体定义共享的响应模式，由主智能体对照真实数据验证结论，并精简任何最终综合步骤的输入。这是一个很好的第一步，因为你不需要重写子智能体。它还能在决定是否将任何子智能体折叠进主智能体之前，为你提供任务完成度评估的基线。

然而，一些失败模式仍会存在：

每个专家都有自己的提示词、上下文、负责团队和评估

每次调用仍然只返回有损的摘要

每次调用都是一个嵌套的模型循环，会增加延迟

通过技能和工具将子智能体折叠进主智能体

一次一个地把子智能体折叠进主智能体：将每个子智能体的提示词转成技能，把 API 调用转成 MCP 工具。对比有子智能体和没有子智能体时的评估表现，然后决定保留哪些。

对比时，不要只看最终得分，还要看看哪些任务的结果发生了翻转。我们在一个示例支持智能体上测试时，把一个子智能体折叠进另一个子智能体降低了延迟，但也破坏了一个原本一直通过的流程。主智能体自己持有订单查询工具并直接作答，没有向物流专家询问送达日期。

在每次改动之前，确保你的评估为生产环境中一起运行的每一条智能体链路都设置了任务，也为智能体绝不能违反的每一条规则都设置了任务，并且每个任务都要运行不止一次，因为像这样的破坏只在两次运行中的一次里出现。

多个团队如何共同为一个智能体做贡献

领域推理可以从知识库、技能和 MCP 工具中检索。各个团队可以把归属权从智能体转移到技能和工具上，由一个小型中央团队保留对系统提示词和端到端质量的归属权。这涉及在发布前审核新的技能、工具和评估。

MCP 工具

当智能体需要执行操作、从系统读取实时数据，或以固定格式返回结果时，工具就是合适的选择。你也可以把工具作为迁移期间继续调用子智能体的一种方式。我们建议按用户意图对工具进行分组（而不是每个 API 一个工具），因为一旦系统提示词中的工具定义超过 30-50 个，工具选择往往会退化。

使用带延迟加载的工具搜索，限制硬性前置条件，并将任何需要的前置条件移入工具中。例如，如果 Y 需要 X 的输出，Y 的工具会检查该输出，并返回一条模型可以据此行动的指令。按用户划分的权限也以同样的方式运作。每个工具都会检查调用用户可以看到或做什么，并返回模型可以读取的明确拒绝，因此一个循环就能服务具有不同访问权限的用户，而无需为每个权限级别单独设置一个智能体。

技能

当智能体需要了解一个团队如何开展工作，比如专家子智能体的提示词过去所承载的步骤、规则和判断时，技能就是合适的选择。

我们扩充技能库的方法是，把维护工作交还给编写技能的人。Claude 可以借助能够构建、测试和修剪其他技能的技能来完成繁重的工作。

为防止技能泛滥，你可以让每个团队的 DRI 负责自己的技能，并确保它们制作精良、彼此区分，并附带适当的评估发布。

/skill-creator 允许你编写格式规范的新技能，并审计现有技能，以对其进行修剪、去重和重构。

/skill-doctor 允许你查看技能库中每个技能的成本以及实际使用频率，并删除无用负担。

知识库

当智能体只是偶尔需要某些参考资料时，知识库就是合适的选择。事实和参考资料（政策、指标定义、产品规格）可以放在模型调用的搜索或查找工具之后，也可以作为技能内的参考文件提供。避免让代码检索这些上下文并将其粘贴到提示词中。

加速这项工作的工具

我们最近发布了一组 Claude API 技能，可以帮助完成上述大部分工作。我们的迁移工具包将这些技能串联成一个引导式工作流，用于评估多智能体系统并将其迁移到单一智能体循环。它还包含一个演示，你可以在将其用于真实系统之前先行试用：

/claude-api build-eval：可以帮助创建第一套由中央团队负责的端到端评估集，或由各团队随其技能一起发布的小型评估。

/claude-api prompt-audit：可以标记出你的提示词、技能和工具描述中为旧模型编写的指令，并以 diff 形式提出修复建议。这可以运行在你的系统提示词上，找出那些为更早的模型添加、如今却让智能体变慢或更僵化的规则。各团队的 DRI 也可以在自己的技能和工具描述上运行它。

/claude-api hillclimb：可以针对现有评估迭代改进应用。这可用于“折叠后与保留”的对比（在把一个子智能体折叠进技能加工具之后，让它对技能和工具描述进行迭代，看看折叠后的版本能否达到或超过子智能体），也可用于你的系统提示词。

/claude-api cost-optimize：分析你的调用都花在哪里，并一次一项地提出节省建议，例如提示词缓存、削减不需要的输入和输出 token、effort 以及模型选择。这有助于在给定设计下降低成本和延迟。

随着模型不断演进，我们对如何最好地使用它们的理解以及围绕最佳实践的指导也在不断演进。这使得任何一种架构都不如它背后的原则重要：衡量、一次只改一处，并保留经得起检验的部分。

这就是其中一种情况。随着模型能力越来越强、智能体运行时间越来越长，你的更多子智能体可以变成技能和工具。不过，你不必一步到位完成这个转变。先构建一个小型端到端评估，把一个子智能体折叠进去，只有当折叠后的版本得分更差时，才把它保留为子智能体，然后反复迭代。

相关文章

探索更多面向使用 Claude 构建的团队的产品新闻和最佳实践。

重新设计 Anthropic 的源代码控制

随着对 Anthropic 单体仓库的合并量从每天约 2,500 次增长到超过 30,000 次，源代码控制成为最大的开发瓶颈。以下是团队如何构建 Scion——一个为始终在线的智能体设计的内部版本控制系统——并在五个月内从 git 迁移出去的故事。

Anthropic 日本的一位 BDR 如何用 Claude Managed Agents 度过他的一天

一位业务拓展代表如何用 Claude Managed Agents 和 Claude Tag 清理他的入站队列并起草双语客户邮件。

Claude Code 团队如何进行代码审查

面对智能体产生的代码量，你该如何审查代码？Claude Code 团队分享了他们的审查流程，从 Claude 验证自己的工作到按风险分级的人工审批，以及一份采用该流程的检查清单。

Uber 的 CISO 谈为 AI 构建内部威胁计划

Uber 的 CISO Philip Martin 谈对 AI 智能体进行监控和可观测性的重要性，以及 Uber 的开源工具如何与 Enterprise Frontier Safeguards 协同工作。

用 Claude 转变你的组织运作方式

产品更新、操作指南、社区聚焦等。每月发送到你的收件箱。

负责任披露政策

数据处理协议：美国 K-12

负责任披露政策

数据处理协议：美国 K-12