把子代理折叠进主循环：用 Skills 与 MCP 工具重构 Claude 代理

当一个代理系统从单个循环长成一张组织架构图，问题往往不是某个子代理写错了，而是子代理之间的边界本身在漏信息。这篇教程讲的是反向操作：把子代理逐个折叠（fold）回主代理循环，让一个循环同时持有 Skills（按需加载的流程与知识）和 MCP 工具，并用一套端到端评测集来判断每一次折叠到底该不该保留。适合已经在 Claude 平台上搭过带子代理的业务代理、现在遇到质量或延迟瓶颈的开发者，也适合在 Claude Code 里维护 .claude/agents/ 目录的团队。

准备工作

先确认你处在哪种状态

折叠不是从零搭建，而是对已有结构做减法。动手之前，先把现状盘清楚：

列出当前所有子代理，以及每个子代理被调用的频率。调用最频繁的那几个是折叠的首选起点。
标出哪些子代理之间存在固定的先后调用关系，比如 A 跑完总是接着调 B。
标出哪些子代理共享同一份数据源。
记录每个子代理各自的提示词、上下文、归属团队和评测集分别放在哪里。

这份清单本身就是折叠顺序的草稿：互相衔接、共享数据、经常被一起调用的子代理，是最先该合并的对象。

准备评测集

折叠能不能做，最终由评测集说了算，所以它必须先于任何结构改动存在。评测集分两层：

中央团队维护的端到端评测集：覆盖完整业务流程，是判断整体质量的基准。
每个 Skill 对应的小型评测集：粒度更细，用来定位是哪一步退化。

起步规模不需要很大，十个带标准答案的样例就足以开始。但有三条纪律必须遵守：

评测集里要包含生产环境中会一起运行的那条代理链，以及代理绝对不能违反的规则。
同一个任务不要只跑一次，要跑多次。有些失败只在部分运行中出现。
给关键事件打时间戳。这样生产环境的真实交互可以回放，转成有针对性的评测用例。

明确要观测的指标

指标随阶段变化。编排器（决定把请求分派给哪个子代理的那一层）还在的时候，关注路由准确率；折叠完成之后，关注是否调用了正确的 Skill 和工具。延迟和单任务成本要一并记录，它们是折叠的主要收益来源之一。

操作步骤

第一步：判断哪些子代理值得保留

折叠不等于全删。只有满足下面三个条件之一的子代理才值得作为独立子代理保留：

条件	判断依据
上下文膨胀	在单一循环里，上下文变长导致的性能下降已经被测量出来。注意是测量，不是预感。
并行与一次性上下文	确实需要并行推进多个任务，且每个任务结束后上下文可以整体丢弃。
工具选择混乱	单个代理在工具选择上明显吃力，或系统提示词里存在互相矛盾的指令。

第一条里的「测量」是关键。仅仅预计上下文会变长，不构成拆分的理由；要先看到可量化的退化，再考虑拆。

另外，把整段处理交给另一个代理的「交接」模式，只在那个代理需要直接与用户对话时才成立。其余情况下，给主循环配上 Skills 和工具就够了。

至于子代理该承担什么样的工作，有一条实用的切分原则：交给子代理的任务，应当是几乎不需要系统其他部分信息的任务。反过来说，越是依赖前后文脉的任务，越应该折叠回主循环。

第二步：合并经常协同的子代理

第一轮减法是合并，不是删除。找出互相消费对方输出、操作同一份数据、或者总被连续调用的子代理，把它们合成一个。如果某个子代理之后总是紧接着调用另一个，这两个就是合并候选。从调用频率最高的子代理开始动手。

第三步：把子代理改成工具调用

这一阶段子代理本身不动，只是改由主代理以工具的形式调用它。好处很直接：

主代理继续持有与用户的对话，不会在交接处丢掉上下文。
子代理不需要重写。
可以统一子代理的响应格式。
能在正式折叠之前，先拿到评测集的基线分数，作为后续比较的参照。

但这一步只是中间站，遗留问题依然存在：每个子代理仍有各自的提示词、上下文、归属团队和评测集；每次调用返回的都是经过压缩、信息有损的摘要；每次调用都会跑一层嵌套的模型循环，延迟随之上升。

第四步：逐个迁移到 Skills 与 MCP 工具

最后一步才是真正的折叠，而且必须一个一个来。每个子代理的提示词改写成 Skill，它调用的 API 改写成通过 Model Context Protocol 暴露的 MCP 工具。

在 Claude Code 的目录结构下，对应关系大致如下：

原来的部分	折叠后的位置
子代理的提示词	Skill 正文，即 `.claude/skills/<name>/SKILL.md`
子代理调用的 API	MCP 服务器提供的工具
子代理引用的资料	Skill 目录下的文件，或检索类工具
仍然保留的子代理	`.claude/agents/`，仅限满足前述三个条件的

每迁移一个，就对比一次「有这个子代理」和「没有这个子代理」两种情况下评测集的分数。比较时不能只看总分，还要看哪些任务的结果发生了翻转。

判断标准可以浓缩成一句话：先建一个小型端到端评测集，折叠一个子代理，只有当折叠后的版本分数更差时，才把它保留为子代理。举证方向由此反转——从「找理由把它折进来」变成「测量它为什么必须留下」。

一个完整示例

假设有一个客服代理，原本把「查询配送日期」这件事交给一个专门的配送子代理。折叠时，先把这段职责写成 Skill：

---
name: shipping-date-check
description: 在回答订单配送日期之前，先确认配送状态的操作流程。当用户询问配送日期或预计到达时间时使用。
---

# 配送日期确认

1. 根据订单号获取配送状态（使用配送状态工具）
2. 回答配送状态中的预计日期，而不是订单信息中的预计日期
3. 无法获取配送状态时，告知用户正在确认中

这个 Skill 里最容易被忽略的是第 2 条：优先采用哪个信息源。在子代理结构下，这条规则由子代理的边界隐式保证——主代理拿不到订单工具，只能去问配送子代理。折叠之后，主代理手里同时有订单查询工具和配送状态工具，这条隐式规则就消失了，必须显式写进 Skill 正文或评测集，否则就会出问题。

折叠之后要跑一遍评测集，并特别留意那些结果发生翻转的任务。一个真实出现过的失败是这样的：折叠后主代理手里有了查询订单的工具，于是它不再去问配送状态，而是直接用订单信息里的日期作答。原本必经的流程被跳过了。更麻烦的是，这个失败在两次运行中只出现了一次。如果只跑一次、只看总分，看到的可能只是延迟下降这个好消息。

所以完整的验证流程是：折叠一个子代理 → 多次运行评测集 → 对比总分与逐任务结果 → 分数变差就回退为子代理，分数不差就保留折叠。

折叠之后：工具与 Skills 怎么摆

工具按意图组织，不按 API 组织

不要为每个 API 建一个工具，而应按用户意图聚合。系统提示词里并列的工具定义一旦超过 30 到 50 个，工具选择就开始失准。应对办法有两条：

使用工具检索，让工具定义在需要时才被加载。
减少严格的前置条件，把仍然需要的前置条件下沉到工具内部去校验。

Skills 承载团队的工作方式

Skills 里写的是团队推进工作的流程与知识。可以为每个团队指定一名负责人（DRI）来维护自己的 Skills。参考材料不要直接贴进提示词，而是放在检索或引用工具的后面。

系统提示词和整体质量由一个小团队统一负责。代理平时只看到 Skills 和工具的简短描述，正文在需要时才加载——这就是渐进式披露（progressive disclosure）。它恰好回应了当初拆子代理的一个理由：上下文膨胀，现在改由加载时机来控制。

还有一点值得注意：随着模型能力提升，原本由外围框架承担的判断可以逐步交还给模型。例如面向高性能模型的系统提示词被削减了八成以上。当写计划的模型同时也是执行计划的模型时，它可以在回合中途修改计划，这本身就是支持单一循环的一个理由。

注意事项

子代理数量会随组织增长而膨胀。 团队各自建代理，结构会逐渐变成组织架构的复印件。随之而来的是五类问题：交接处丢失细节上下文；重复的子代理累积到数百个、归属不清；多个团队的规则堆进同一个提示词并互相冲突；各团队只优化自己那部分任务的评测集，整体质量在分数上体现不出来；延迟上升。有客户案例中，单一代理循环的运行速度约为多代理结构的两倍。
这些问题都是累积型的。 每加一个子代理只恶化一点点，加第一个时几乎看不出来，所以「把子代理折回主循环」必须作为一道独立工序来做，而不是顺手为之。
不要凭预感拆分。 上下文膨胀这一条要求的是可测量的性能退化。
单次运行不足以判断。 同一任务要多次运行，并且逐任务比对结果，而不是只看总分。
隐式规则会随边界一起消失。 折叠时要把子代理边界曾经保证的规则显式写出来，写进 Skill 正文或评测集。
工具化的中间态不是终点。 它保留了每调用一次就多一层嵌套循环的延迟成本，以及每次返回有损摘要的信息损失。
一次只改一处。 测量、一次只改一个东西、保留经得起验证的部分。这是整个流程的节奏。
文中涉及的模型能力、提示词规模、工具数量阈值等具体数字，随版本演进会变化，请以官网当前信息为准。