10 个主要问题 Q&A
-
Q：什么是把子 Agent 折叠入主循环？ A：不再单独启动带独立上下文的子 Agent，将原有子 Agent 逻辑转为主循环里的技能、MCP 工具，由同一个模型统一规划执行。 -
Q：单 Agent 循环相比多 Agent 编排优势是什么？ A：上下文连续不割裂，信息保真度更高，延迟更低、成本更少，保持统一输出风格。 -
Q：哪些场景不适合折叠，必须保留子 Agent？ A：单循环上下文爆炸性能下降；需要大量独立并行任务；系统提示存在冲突指令、工具选择困难。 -
Q：技能（Skill）和 MCP 工具怎么分工？ A：Skill 承载业务流程、规则、判断逻辑；MCP 工具负责读取实时数据、执行动作、固定格式返回结果。 -
Q：企业最常见的多 Agent 架构弊病是什么？ A：子 Agent 蔓延、提示词冲突、跨 Agent 传参丢失细节、评估局部优化、整体延迟翻倍。 -
Q：迁移第一步要做什么？ A：搭建端到端任务评估集，建立质量基线，用来对比折叠前后效果。 -
Q：子 Agent 先作为工具调用是什么作用？ A：低成本过渡方案，不用改写原有子 Agent，拿到基线指标，再决定要不要彻底折叠。 -
Q：多团队如何共建同一个 Agent？ A：各团队维护自有技能、工具；中央小组统一管控系统提示词、整体评估、上线审核。 -
Q：工具数量为什么不能太多？ A：工具定义超过 30–50 个时，模型选择工具的准确率会明显下滑。 -
Q：迁移的核心原则？ A：一次只改动一处，持续对照评估验证，不追求一次性全量改造。
在 Claude Platform 中构建 Agent 时，使用更少的子 Agent、转而采用渐进式披露的上下文与工具，可以在降低成本与延迟的同时提升质量。以下说明何时迁移以及如何迁移。
如果你已在 Claude Platform 中构建了包含多个子 Agent 的 Agent，请查看哪些子 Agent 可能适合整合进主 Agent 循环
—— 可使用我们的 single-agent-loop-kit 工具。它以引导式工作流来识别你的模式、评估替代方案并验证最佳做法，其中附带一个演示，可在真实系统上运行前先在模拟系统上试用。
子 Agent—— 拥有各自的上下文窗口、工具和指令的 Agent—— 是 Agent 设计中的核心组成部分。它们在验证、并行工作和模块化权限管理方面非常有效。我们在自己使用 Claude Platform 构建的许多 Agent 中也采用了这一模式，例如我们的多 Agent 研究系统。
然而，应用型 AI 团队最近发现，在企业级 Agent 部署中，将路由器、规划器和领域子 Agent 整合进主 Agent 循环往往能带来收益。在若干企业部署的对比中，基于技能的 Agent 设计在质量上经常优于 "一 Prompt 通吃" 的设计和子 Agent 设计，而且往往单次任务的成本与延迟更低。
例如，一家公司发现，其面向客户的 Agent 内部十来个专家子 Agent，使得维持一致的品牌体验变得困难，并增加了损害用户体验的延迟。
我们还经常看到一些被提出的 Agent 设计遵循一种熟悉的发展轨迹：一个意图分类器、一条固定的多步推理流水线、用户分群桶、独立的推荐分支，以及顶层的多 Agent 编排器。
在这些案例中，反馈往往是：大部分结构所做的工作，模型已经不再需要人为代劳了。一条清晰的系统提示、4–5 个精简的数据工具，以及严格的输出护栏，就足以覆盖大多数使用场景。
需要说明的是，子 Agent 仍然有其用武之地，包括在研究前沿。当以下情况时使用它们：
-
单 Agent 循环因上下文膨胀而出现可测量的性能退化；或 -
需要以全新上下文窗口并行处理多个任务，任务完成后这些窗口可被丢弃；或 -
单个 Agent 难以选择合适的工具，或系统提示中存在相互冲突的指令。
但我们太常看到企业为每个团队或每个问题类型配置一个子 Agent，使 Agent 架构变成其组织架构的翻版（康威定律在起作用）。
本文解释了何时应考虑将子 Agent 整合进主 Agent 循环，并分享我们从大型组织构建 Agent 中总结出的最佳实践。
大型组织中的 Agent 构建失败模式
企业往往希望构建一个能将多个产品和能力统一到单一客户界面的 Agent。
通常，每项能力由不同团队负责，因此公司会先让各个团队各自构建自己的 Agent，再由中央平台团队在其上构建编排器。这可能演变成多种结构，包括编排器 - 子 Agent，或一个将特定 Agent 以 MCP 工具形式暴露出来的单一 Agent。
这看似最简单的解决方案，却立即引入了围绕以下方面的复杂性：
- 上下文管理
：你需要决定在 Agent 之间交换哪些上下文，往往还会在来回传递中丢失细节。 - 子 Agent 蔓延
：每个团队都发布自己的子 Agent，最终企业会有成百上千个重叠的子 Agent，既没有强制标准，也没有明确负责人。 - Frankenprompt（缝合怪提示）
：每个团队都在系统提示中加一句，最终导致规则相互冲突、声音不一致。 - 未经审查、过度局部的评估
：每个人都在添加自己的评估，这些评估对其子任务过度优化。没有人为整套评估负责或维护，而领导层基于被稀释、过度局部的分数做决策。 - 延迟
：多 Agent 架构的复杂性会带来延迟。一位客户在评估其多 Agent 框架与单 Agent 循环时发现，后者的运行速度大约快 2 倍。
使用渐进式披露的 Agent 循环
上文描述的编排器 - 子 Agent 设计，是协调跨团队构建的专家的一种合理方式，但通常更有效的方法是通过技能渐进式披露上下文，并通过工具搜索渐进式披露工具。换言之，Agent 能看到技能和工具的简短描述，只在需要时才完整加载。
这种方法之所以有意义，有三个原因：
- 共享上下文能产生更好的答案
对于运行时间更长的 Agent，我们希望来自多个不同任务的上下文留在主上下文窗口中。一个已看到前序每一步结果的 Agent，能够将这些结果连接起来，从而产出比子 Agent 交回的一组摘要更丰富、更有洞察力的输出。这也意味着需要考虑整体连贯性。 - 渐进式披露可防止上下文膨胀
这一技术使团队能够构建能够完成多种任务的单一 Agent，而无需将所有上下文立即加载进一条冗长的系统提示中。这消除了团队过去拆分工作、使用子 Agent 的主要原因。事实上，我们在新模型中削减了与渐进式披露技能和工具相关的内容。 - 模型能力更强
从 Opus 4.5 开始，模型在单一循环中能够管理的内容远超大多数团队的预期。Opus 5.5 和 Fable 5.1 无法关闭思考，且新一代模型在推进过程中越来越多地叙述进展并自行检查工作，这使得一些框架组件变得冗余。每一代新模型都让你能把更多决策从框架移入模型本身。更简单的循环也更容易迁移到下一代模型；在帮助客户迁移时，僵化的多 Agent 结构往往是阻碍新模型承担更多工作的元凶。
单 Agent 循环设计需要纪律：精心管理的系统提示、在正确时机触发的技能与工具描述，以及对上下文窗口、记忆和记笔记的审慎处理。本文后续章节将深入探讨迁移与设计方面的考量。
一个中央团队应负责端到端质量和系统提示，在每一项新工具和评估上线前进行审查。保持该中央团队精简有助于快速迭代，并降低大型组织的协调成本。
如果你选择走多 Agent 路线，应从可能可行的最简单模式（生成器 - 验证器、编排器 - 子 Agent，或其他）开始。通过按上下文划分来有效划定边界：给每个子 Agent 一份与系统其余部分关联较少的工作，并让它交回一个紧凑的结果（好的候选包括独立研究路径、接口清晰的独立组件，或黑盒验证）。当 Agent 按问题类型划分时，它们会陷入一种 "传话游戏"—— 每次交接都会在来回传递中降低保真度。
如何将子 Agent 整合进主 Agent 循环
许多团队已经在生产中运行着一个编排器和一组专家 Agent。下面是我们建议努力达成的单循环设计：
-
一个模型、一个上下文窗口，运行一个开放式工具循环，并在框架中设置限制（轮次与成本预算、写入门控）。 -
每一轮，模型发出一批工具调用。框架并行运行它们，并将原始结果返回给同一个模型，由模型决定下一步：再发一批、向用户提问，或给出答案。 -
当模型给出答案或达到任务预算时，循环停止。可选地在答案之后运行一个目标或验证器检查。 -
模型在第一轮就在上下文中写下计划，并在结果陆续到达时修订计划。这是与编排器加专家 Agent 设置的主要区别：写计划的模型也正是执行计划的模型，因此它可以在轮次中途改变计划。
上下文仍然会被加载，但由 Agent 自行管理：
-
不再需要从规则目录中重写计划的代码步骤，因为模型决定每一步。 -
顺序和领域流程移入技能。 -
硬性限制（验证、审批门控）以及对话中出现的其他任何情况（例如记忆查找）移入工具。
代码仍可用于加载任何廉价且几乎总是相关的信息（例如实体解析步骤），并可在循环调用的工具内部处理机械部分（负载构造、流解析、恢复澄清）。
这种单循环设计也有助于许多团队正在努力实现的目标状态（一个理解用户高层目标并代表用户行动的 Agent），因为它将 Agent 学到的所有内容保持在单一上下文中。
下面的建议是团队如何分阶段从多 Agent 系统过渡到单 Agent 循环，以及各团队如何在此过程中持续为该 Agent 做出贡献。
任务完成型评估
第一步是创建一个评估集，帮助你判断是否应将某个子 Agent 整合进主 Agent 循环。我们看到的行之有效的评估结构是：由中央团队拥有的一套共享的端到端评估集，加上由拥有该技能的团队随每个技能发布的小型评估集。即使只有 10 个黄金示例也足够起步。
将 Agent 的最终消息按评分标准进行分级，是追踪回答质量的良好起点。在你仍拥有编排器时，还应追踪路由准确性（它是否选择了正确的子 Agent？）。一旦某个子 Agent 被整合，改为检查 Agent 是否加载了正确的技能或调用了正确的工具。逐步转向任务完成型评估是有帮助的，因为在比较不同架构时，这一点最为重要。
在内部系统难以重放、用户参与难以模拟的环境中，这可能很复杂。一种对我们行之有效的方法是记录关键事件的时间戳，以便日后重放，作为定向评估运行。
随时间减少子 Agent
向单 Agent 循环演进，涉及将子 Agent 整合进工具和技能。这可以通过合并领域子 Agent、将其作为工具调用，或将其替换为技能和工具来实现。
合并领域 Agent
在第一次合并前先构建一个小型端到端评估。然后从使用最频繁的子 Agent 开始，按共享上下文整合。优先合并那些互相依赖彼此输出、接触相同数据、或经常被一起调用的子 Agent。例如，如果生产中很大比例的流量是一个专家 Agent 紧随另一个专家 Agent，那就是一个紧密耦合的组合，适合合并为一个领域 Agent。
将子 Agent 作为工具调用
当上述三个条件之一适用且你保留一个子 Agent 时，让主 Agent 将子 Agent 作为工具调用是一种有效做法，这样它就能继续与用户保持对话。
我们只推荐在子 Agent 需要直接与用户对话时，才进行完整交接（子 Agent 接管对话）。除此之外的一切，都可以是主循环中的技能加工具。
这将允许你为子 Agent 定义共享响应模式，用主 Agent 对照真实数据验证结论，并精简最终综合步骤的输入。这是很好的第一步，因为你无需重写子 Agent。它也为你在决定整合任何子 Agent 前提供了任务完成评估的基线。
然而，一些失败模式仍然存在：
-
每个专家都有自己的 Prompt、上下文、负责团队和评估 -
每次调用仍交回一个有损的摘要 -
每次调用都是嵌套的模型循环，增加延迟
通过技能和工具将子 Agent 整合进主 Agent
通过将每个子 Agent 的 Prompt 转化为技能、将 API 调用转化为 MCP 工具，一次一个地将子 Agent 整合进主 Agent。比较有子 Agent 和无子 Agent 时的评估表现，然后决定保留哪些。
比较时，不要只看最终分数，要看哪些任务发生了翻转。当我们对一个示例支持 Agent 进行测试时，将一个子 Agent 整合进另一个降低了延迟，但也破坏了一个原本正常的流程。主 Agent 拿着订单查询工具自行回答，却没有向物流专家询问发货日期。
在每次变更前，确保你的评估覆盖生产中会一起运行的每一个 Agent 链，以及 Agent 绝不能违反的每一条规则，并且每个任务运行不止一次 —— 因为像这样的破坏只在两次运行中出现了其中一次。
多个团队如何为单个 Agent 做贡献
领域推理可以从知识库、技能和 MCP 工具中检索。各团队可以将其所有权从 Agent 转移到技能和工具，由一个精简的中央团队保留对系统提示和端到端质量的掌控。这涉及在上线前审查新技能、工具和评估。
MCP 工具
当 Agent 需要采取行动、从系统读取实时数据，或以固定形状返回结果时，工具是合适的载体。你也可以在迁移期间用工具作为持续调用子 Agent 的方式。我们建议按用户意图分组工具（而不是每个 API 一个工具），因为一旦系统提示中的工具定义超过 30–50 个，工具选择往往会退化。
使用带延迟加载的工具搜索，限制硬性前置条件，并将任何必要的前置条件移入工具。例如，如果 Y 需要 X 的输出，Y 的工具会检查它并返回模型可执行的指令。按用户权限的管理方式相同。每个工具检查调用用户可以看到或做什么，并返回模型可读取的明确拒绝，这样一个循环就能服务不同权限的用户，而无需为每个权限级别设置单独的 Agent。
技能
当 Agent 需要了解某个团队如何做事时 —— 例如专家子 Agent 的 Prompt 曾经承载的步骤、规则和判断 —— 技能是合适的载体。
我们扩充技能库的做法，是把维护工作交还给编写技能的人。Claude 可以通过能够构建、测试和修剪其他技能的技能来承担繁重工作。
为防止技能蔓延，可以让各团队的 DRI（直接负责人）拥有自己的技能，并确保它们精心编写、彼此区分清晰、并配有适当的评估。
-
/skill-creator 允许你编写从一开始就结构良好的新技能，并审查现有技能以进行修剪、去重和重构。 -
/skill-doctor 允许你查看技能库中每个技能的成本和使用频率，并删除冗余部分。
知识库
当 Agent 只是偶尔需要某些参考资料时，知识库是合适的载体。事实和参考资料（政策、指标定义、产品规格）可以放在模型调用的搜索或查询工具之后，或作为技能内部的参考文件发布。要避免让 Agent 背负过大、过度的上下文负担。
加速这项工作的工具
我们近期发布了一组 Claude API 技能，可以处理上述大部分工作。我们的 single-agent-loop-kit 将这些技能串成一个引导式工作流，用于评估多 Agent 系统并将其迁移到单 Agent 循环。它附带一个演示，可在真实系统上运行前先试用：
- /claude-api build-eval
：帮助创建由中央团队拥有的第一套端到端评估，或每个团队随技能发布的小型评估。 - /claude-api prompt-audit
：可标记你的 Prompt、技能和工具描述中为旧模型编写的指令，并以 diff 形式提出修复建议。可在你的系统提示上运行，找出那些为早期模型添加、如今却使 Agent 变慢或更僵化的规则。各团队的 DRI 也可以在自己的技能和工具描述上运行它。 - /claude-api hillclimb
：针对现有评估迭代改进应用。可用于 "整合后 vs 保留" 的比较（将一个子 Agent 整合为技能加工具后，让它迭代技能和工具描述，看看整合版本是否达到或超过子 Agent 水平），也可用于你的系统提示。 - /claude-api cost-optimize
：分析调用去向，并提出节省方案，例如 Prompt 缓存、修剪不必要的输入输出 token、调整投入度和模型选择，一次只改一项。这有助于降低给定设计的成本和延迟。
随着模型的演进，我们对如何最好地使用它们以及最佳实践的理解也在演进。这使得任何单一架构都不如其背后的原则重要：测量、一次只改一项、保留经受住检验的部分。
这正是此类情况之一。随着模型能力增强、Agent 运行时间变长，更多的子 Agent 可以变成技能和工具。但你不必一步到位。先构建一个小型端到端评估，整合一个子 Agent，只有当整合后的版本表现更差时才将其保留为子 Agent，然后循环往复。
