构建 Agent：何时把子 Agent 折进主循环
很多团队一上来就按「每个能力一个子 Agent + 总编排」搭系统。Anthropic Applied AI 在官方文章里写得很直：在他们对照过的若干企业部署里，带 Skills 的单 Agent 循环，质量和时延、成本常常好过「一提示词包打天下」和「一堆子 Agent」。这篇按那篇文章整理选型与迁移步骤——我们未在生产环境复现他们的评测，标「未实测」。
说明：事实与建议来自 Anthropic 官方文 Building agents: When to fold subagents into your main agent loop。文中「约 2 倍更快」等对比数字是厂商对客户案例的概括，不是我们的实测。
子 Agent 不是废了，是别当默认骨架
官方定义里，子 Agent 有自己的上下文窗口、工具和指令，由协调者编排。他们自己的多 Agent 研究系统也在用。文中明确：验证、可并行丢弃的新鲜上下文、以及模块化权限，子 Agent 仍然合适。
该折回主循环的信号是另一套：按团队/问题类型一人一个子 Agent，最后叠一层总编排——组织架构直接复制成 Agent 拓扑（文中点名 Conway's law）。结果常见是交接丢细节、子 Agent 膨胀、系统提示变成「弗兰肯提示词」、评测被各自局部优化、时延堆高。有一家客户对照后，单循环大约快一倍。
子 Agent 适合验证、并行短任务和权限隔离；别把「每个业务团队一个子 Agent」当成默认设计。
主循环 + 渐进披露长什么样
目标形态可以记成四条：
- 一个模型、一个上下文窗口，开放式工具循环；轮次与费用上限、写操作闸门放在 harness 里。
- 每轮模型可批量要工具；harness 并行执行后把原始结果送回同一模型，由它决定再调工具、问用户，还是给答案。
- 模型在首轮把计划写进上下文，并随结果改写——写计划的人和执行的人是同一个，中途可以改计划。
- 过程与领域规程进 Skills；硬限制与实时动作进工具；几乎总要用、又便宜的实体解析一类步骤，仍可用代码预加载。
为何常比多 Agent 更稳：长任务里各步结果都留在同一窗口，模型能串起来，少做「电话游戏」式摘要交接；Skills 与工具描述先短后全，避免一上来塞满系统提示（文中提到 Claude Code 对更强模型把系统提示砍掉八成以上，其中就包括渐进披露）；新模型能力上来后，硬编码流水线反而卡住升级。
| 保留子 Agent | 优先折进主循环 |
|---|---|
| 单循环已因上下文膨胀可测地变差 | 按团队/问题类型拆出来的路由器、规划器、领域专家 |
| 多条互不依赖的路径，要新鲜上下文，做完即可丢掉 | 前后耦合、常链式调用、摸同一份数据的专端子 Agent |
| 单 Agent 选不好工具，或系统提示里指令互相打架 | 本可用 Skill + 少量数据工具 + 输出护栏覆盖的流程 |
怎么折：先评测，再一个个拆
文章建议的迁移按阶段来，别指望一夜切完：
- 端到端评测。中央团队养一套共享的任务完成评测；各 Skill 自带小评测。哪怕先有 10 条黄金样例也好。有编排器时看路由准不准；折进去之后改看有没有加载对 Skill、调对工具。
- 合并领域 Agent。从用得最多、且互相依赖的一对开始：常串联、摸同数据、或生产里经常「A 完了立刻 B」的，优先合成一个领域 Agent。
- 子 Agent 当工具。还需要保留时，让主 Agent 以工具形式调用它，主对话仍由主 Agent 跟用户聊；只在子 Agent 必须亲自跟用户说话时才做全量交接。这步不用重写子 Agent，也能先拿到评测基线。
- 折成 Skill + 工具。提示词变 Skill，API 调用变 MCP 工具；折叠前后对照评测，看哪些任务翻盘。文中举过支持场景：折掉一个子 Agent 后时延下来了，但主 Agent 自己查订单、没问物流专家要送达日，某条流程反而挂了——所以每条生产链路和「绝不能破」的规则都要有对应样例，而且多跑几次。
多团队往一个 Agent 里塞什么
领域推理从知识库、Skills、MCP 工具里取；各团队的所有权从「自己的 Agent」挪到「自己的 Skill/工具」。系统提示和端到端质量由一个小中央团队盯：新 Skill、工具、评测上线前过审。
- 工具：要动作、读实时数据、要固定形状结果时用。按用户意图分组，不要一 API 一工具；系统提示里工具定义过了大约 30–50 个，选型容易变差。配合工具搜索与延迟加载。
- Skills：管「团队怎么做事」——步骤、规则、判断。用 Skill 创建作者/审计类能力控膨胀，并设 DRI。
- 知识库：偶尔才要的政策、指标定义、规格，放检索工具或 Skill 内参考文件，别用代码往提示词里硬贴。
官方还把若干 Claude API Skills 串成了迁移套件（评估、提示词审计、对着评测爬山、成本剖析），可在模拟系统上先跑再动真系统。具体命令以 Anthropic 当前文档为准。
常见坑
- 组织镜像。每个产品线一个子 Agent，中央再叠编排——交接损耗和时延会一起涨。
- 只看总分不看翻盘任务。折进去后平均分可能差不多，个别关键链路会悄悄坏掉。
- 工具清单无上限。过了文中说的大约 30–50 个定义，模型选型变差；用搜索与延迟加载，而不是全塞系统提示。
- 没有共享评测就开拆。没有端到端样例，你分不清是架构赢了还是某一侧被过拟合了。
完成标准
- 能说出保留子 Agent 的三类条件，以及「按团队拆」为什么常错。
- 能画出「单循环 + Skills + 工具」与「编排器 + 专端子 Agent」的差别，并指出交接损耗在哪。
- 能按「评测 → 合并 → 当工具 → 折成 Skill」四步写一份自己系统的迁移清单（哪怕只有 10 条样例）。
最后
若你正在给编码 Agent 加能力，先弄清 Skill 与 MCP 各自吃多少上下文，再决定要不要上子 Agent。可对照站内 Skill 和 MCP 有什么区别 与 编码 Agent 实战 5 条。
