构建智能体：何时将子智能体并入主智能体循环

如果你在 Claude Platform 上构建的智能体包含多个子智能体，可以借助我们的 迁移工具包来看看哪些子智能体适合并入主智能体循环。它会运行一个引导式工作流，识别你的架构模式、评估替代方案并验证最佳方案。它还包含一个演示，可先在模拟系统上试用，再运行于你自己的智能体。

子智能体——拥有独立上下文窗口、工具和指令的智能体—— 由协调器进行编排 ——是智能体设计的核心组件。它们在验证、并行工作和模块化权限控制方面非常有效。在我们用 Claude Platform 构建的许多智能体中都会用到它们，例如我们的 多智能体研究系统.

不过，应用 AI（Applied AI）团队最近发现，有一类企业智能体部署正是通过将路由器、规划器和领域子智能体并入主智能体循环而受益。在 我们对多个企业部署的对比, 配备技能的单智能体 在质量上经常同时优于“一条提示词包打天下”的设计和子智能体设计，而且往往单任务成本和延迟更低。

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

我们还经常看到一些提出的智能体设计遵循一条熟悉的演进路径：意图分类器、固定的多步推理流水线、用户分群桶、彼此独立的推荐分支，最上面再套一个多智能体编排器。

在这些情况下，反馈往往是：这些结构中的大部分都在做模型已经不再需要替它做的事，而一份清晰的系统提示词、4–5 个轻量数据工具，再加上严格的输出护栏，就能覆盖大部分用例。

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

• 单个智能体循环因上下文膨胀而出现可衡量的性能下降；或者
• 多个任务需要并行处理，且各自使用任务完成后即可丢弃的全新上下文窗口；或者
• 单个智能体难以选择合适的工具，或者系统提示词中存在相互冲突的指令。

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

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

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

企业常常希望构建一个智能体，把多个产品和能力整合到单一的客户界面中。

通常每项能力都由一个独立团队负责，于是企业先让各团队构建自己的智能体，然后由一个中央平台团队在上面搭建编排器。这会形成多种结构，包括“编排器-子智能体”，或者一个单智能体并把特定智能体以 MCP 工具的形式暴露出来。

这看起来是最简单的方案，但立刻会带来以下几方面的复杂性：

• 上下文管理： 你必须决定各智能体之间交换哪些上下文，而在来回传递中往往会丢失细节。
• 子智能体蔓延：每个团队都发布自己的子智能体，最终公司会得到数百个功能重叠的子智能体，既没有强制标准，也没有明确的主人。
• “科学怪人”提示词（Frankenprompt）：每个团队都往系统提示词里加一句话，结果规则相互冲突，语气无法统一。
• 未经审核、过度局部化的评估：每个人都添加针对自己子任务过度优化的评估。没有人负责维护整套评估，管理层却要根据这些被稀释、过度局部化的分数做决策。
• 延迟：多智能体架构的复杂性会增加延迟。一位客户将其多智能体运行框架与单智能体循环做过对比，后者的运行时间大约快了 2 倍。

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

上面描述的“编排器-子智能体”设计是协调跨团队构建的专家智能体的合理方案，但往往更有效的做法是 通过技能渐进式披露上下文 以及 通过工具搜索渐进式披露工具。换句话说，智能体只看到技能和工具的简短描述，只有在需要时才会完整加载。

这种方案之所以可行，有三个原因：

• 共享上下文带来更好的答案： 对于运行时间较长的智能体，我们希望多个不同任务的上下文都留在主上下文窗口里。一个看过此前每一步结果的智能体能够把它们联系起来，相比由子智能体交回的一组摘要，这会产生更丰富的输出和更好的洞察。这也意味着 更少的上下文窗口和更少的有损交接.
• 渐进式披露防止上下文膨胀： 这一技术 让团队可以构建能完成多种任务的单智能体，而不需要把所有上下文立即塞进一份冗长的系统提示词。这消除了团队以往把工作拆分到多个子智能体的主要原因。事实上，我们 将 Claude Code 面向更先进模型的系统提示词缩减了 80% 以上 其中就包括与渐进式披露技能和工具相关的削减。
• 模型能力更强： 从 Opus 4.5 开始，模型在单个循环中能管理的东西就远超大多数团队的预期。在 Opus 5.5 和 Fable 5.1 上你无法关闭思考，而且近期的模型越来越多地边做边叙述自己的进展、检查自己的工作，这让运行框架中的一些环节变得多余。每一个新模型都让你可以把更多决策从运行框架移交给模型本身。更简单的循环也更容易迁移到下一个模型；在我们协助客户完成的迁移中，僵化的多智能体结构往往是阻碍新模型承担更多工作的元凶。

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

应该由一个中央团队负责端到端质量和系统提示词，在每个新工具和评估上线前进行审核。保持这个中央团队精简，有助于加快迭代速度，并降低大型组织中的协调成本。

如果你选择多智能体路线，请从可行的最简模式（生成器-验证器、编排器-子智能体或其他）开始。通过以下方式有效划分边界： 按上下文切分：给每个子智能体分配一块几乎不依赖系统其余部分的工作，并让它交回一份紧凑的结果 （理想的候选包括相互独立的研究路径、接口清晰的独立组件，或黑盒验证）。当智能体按问题类型切分时，它们就会陷入一场“传话游戏”， 信息来回传递，每一次交接都在损耗保真度。

如何将子智能体并入主智能体循环

许多团队已经在生产环境中部署了编排器和一组专家智能体。以下是我们建议逐步演进到的单循环设计：

• 一个模型、一个上下文窗口，运行一个开放式的工具循环，限制条件（轮次与成本预算、写入门禁）由运行框架设定。
• 每一轮，模型发出一批工具调用。运行框架并行执行它们，并把原始结果返回给同一个模型，由它决定下一步：再发一批调用、向用户提问，还是给出答案。
• 当模型给出答案或触及 预算时，循环停止。还可以选择在给出答案后运行一次目标检查或验证器检查。
• 模型在第一轮就把计划写入上下文，并随着结果到来不断修订。这是与“编排器+专家智能体”架构的主要区别：写计划的模型同时就是执行计划的模型，因此它可以在一轮中途修改计划。
• 上下文依然会被加载，但改由智能体自己管理：
  • 不再需要根据规则目录改写计划的那段代码步骤，因为每一步都由模型自己决定。
  • 顺序编排与领域流程移入 技能。
  • 硬性限制（校验、审批门禁）以及对话过程中出现的其他事项（例如记忆查询）则移入 工具。
  • 代码仍然可以用来加载那些成本低廉且几乎总是相关的内容（例如实体解析步骤），也可以把机械性部分（构造载荷、解析流、恢复澄清问答）放进循环调用的工具里处理。

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

下面的建议说明了团队如何分阶段从多智能体系统演进到单智能体循环，以及多个团队如何在这一路上持续为该智能体做贡献。

任务完成度评估

第一步是建立一套评估集，帮助你判断是否应该把某个子智能体并入主智能体循环。我们见过行之有效的评估结构是：一套由中央团队负责的共享端到端评估集，加上随每个技能附带的小型评估集（由负责该技能的团队提供）。哪怕只有 10 个黄金示例也足以起步。

按照评分标准（rubric）给智能体的最终回复打分，是追踪回答质量的良好起点。在你还保留编排器期间，还应追踪路由准确率（它是否选对了子智能体？）。一旦某个子智能体被并入，就改为检查智能体是否加载了正确的技能或调用了正确的工具。随着时间推移逐步建设任务完成度评估是有益的，因为在比较不同架构时这一点最为关键。

在内部系统难以重放、用户行为难以模拟的环境里，这件事可能会很复杂。我们内部行之有效的一种做法是给重要事件记录时间戳，以便日后重放、作为有针对性的评估来运行。

逐步减少子智能体

向单智能体循环演进，意味着把子智能体收编为工具和技能。具体做法可以是合并领域子智能体、把它们当作工具调用，或者用技能加工具取而代之。

合并领域智能体

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

要合并的是这类专家智能体 ——它们的输出相互衔接、操作同一份数据、或经常被先后调用。例如，如果生产流量中有相当大比例是“专家 A 之后紧跟专家 B”，那这就是一对紧耦合，适合合并成一个领域智能体。

以工具形式调用子智能体

当上述三个条件之一成立且你保留某个子智能体时，让主智能体把子智能体当作工具来调用会很有效，这样它就能继续持有与用户的对话。

只有在子智能体需要直接与用户对话时，我们才建议完全移交（即由子智能体接管对话）。其余一切都可以是主循环中的技能加工具。

这样你就可以为子智能体定义统一的响应结构、用主智能体对照真实数据核验结论，并精简最终综合环节的输入。这是很好的第一步，因为你不必 重写 这些子智能体。它还能在决定把任何子智能体并入主智能体之前，为任务完成度评估留下一个 基线 。

不过，一些失败模式依然存在：

• 每个专家智能体仍各有自己的提示词、上下文、负责团队和评估
• 每次调用仍然交回一份有损摘要
• 每次调用都是一个嵌套的模型循环，会累积延迟

通过技能和工具把子智能体并入主智能体

每次把一个子智能体并入主智能体：把它的提示词变成技能，把它的 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: 能针对现有评估迭代改进一个应用。它可用于“并入 vs 保留”的对比（把一个子智能体并入为技能加工具后，让它迭代技能和工具描述，看并入版能否追平或胜过原子智能体），也可以用来优化你的系统提示词。
• /claude-api cost-optimize: 会分析你的调用都花在了哪里，并逐一提出节省方案，例如提示词缓存、裁剪不必要的输入输出 token、调整努力程度和模型选择。这能帮助在给定设计上压低成本和延迟。

随着模型演进，我们对如何用好它们的理解以及最佳实践指南也在演进。这让任何一种具体架构都不如其背后的原则重要：测量、一次只改一处、留下经得起验证的东西。

本文讨论的正是这样一类情况。随着模型能力越来越强、智能体运行时间越来越长，你的子智能体中会有越来越多可以变成技能和工具。不过你不必一步到位：先建一个小型端到端评估，并入一个子智能体，只有当并入版得分更差时才把它保留为子智能体，然后如此往复。