[Claude 博客分享] 构建 Agent 时何时把子 Agent 折进主循环：Skills 渐进披露常优于多专家编排

企业里常见的「每团队一个子 Agent + 总编排」常复制组织架构，带来上下文损耗、延迟与 Frankenprompt；在 Claude Platform 上，一个主循环 + 按需加载的 Skills/工具，在多项内部对比里质量常更好，成本与延迟更低；子 Agent 只留给并行、上下文膨胀或工具/指令冲突等确有必要的场景。
https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

问题：大组织建 Agent 的典型失败模式

多家产品能力要进同一顾客入口时，各团队先自建 Agent，平台再盖编排层（orchestrator–subagent，或把子 Agent 当 MCP 工具）。看起来分工清楚，实际立刻碰到：
· 上下文管理：跨 Agent 来回丢细节
· 子 Agent 膨胀：重叠、无统一标准、无明确 owner
· Frankenprompt：人人往系统提示加一句 → 规则冲突、语气不一
· 局部 eval：各优化子任务，无人维护端到端，领导看被稀释的分数
· 延迟：一家客户对比多 Agent harness vs 单循环，后者约 2× 更快

另常见设计路径：意图分类 → 固定多步推理 → 用户分群桶 → 分叉推荐 → 再盖编排——反馈往往是：模型已不需要这么多脚手架，一条清晰系统提示 + 四五个瘦数据工具 + 硬输出护栏就够盖住大半场景。

何时仍要用子 Agent

· 单循环因上下文膨胀出现可测的性能下降
· 多任务需并行，用完即丢的新鲜上下文窗
· 单 Agent 选不好工具，或系统提示里指令互相打架

Frontier 研究、核验、模块化权限等场景仍适用；Anthropic 自家多 Agent 研究系统也在用。但「每个问题类型/每个团队一个子 Agent」往往是 Conway 定律，不是能力上限。

更优默认：主循环 + 渐进披露

用 Skills 渐进披露上下文、用 tool search 渐进披露工具：先见短描述，需要再全量加载。三点理由：

1. 共享上下文更好答：长程任务里，前几步结果留在同一窗，比子 Agent 回传摘要更能串起来。
2. 防上下文膨胀：不必把一切塞进超长系统提示——这也是以前拆子 Agent 的主因；Claude Code 对更强模型把系统提示砍了 80%+（含 Skills/工具渐进披露相关裁剪）。
3. 模型更强：自 Opus 4.5 起，单循环能扛的远超多数团队预期；更新模型会自述进度、自检，部分 harness 变冗余。刚性多 Agent 结构常反而挡住新模型多干活；更简循环也更好迁模型。

目标形态：
· 一个模型、一个上下文窗、开放式工具循环；harness 设轮次/成本预算与写门禁
· 每轮模型可批量调工具，harness 并行执行，原样结果回同一模型
· 写计划的模型也是执行的模型，可中途改计划
· 排序与领域流程进 Skills；校验/审批/记忆查找等硬限制进工具；几乎总相关的廉价步骤仍可用代码预载

端到端质量与系统提示应由一个小而集中的团队把关；新工具与 eval 上线前先 vet。若走多 Agent，从最简可工作模式起步，按上下文边界拆（独立研究路径、干净接口组件、黑盒核验），少按问题类型拆；后者像传话游戏，每传一次保真度掉一截。

如何折进去（迁移路径）

1. 任务完成度 eval：中央一份端到端集 + 各 Skill 小集；哪怕先 10 条黄金例。编排期盯路由准确率；折入后盯是否加载对 Skill/调对工具。难回放的内部系统可用关键事件时间戳做定向回放。

2. 合并领域 Agent：先建小端到端 eval；优先合「链式产出、同数据、常连调」的对。

3. 子 Agent 当工具：主 Agent 继续对用户说话，子 Agent 只当工具回结构化结论；仅当子 Agent 必须直接对用户说话才做全量交接。仍有损：各自 prompt/owner/eval、有损摘要、嵌套循环加延迟——适合当折入前的基线。

4. 折成 Skills + MCP 工具：一次折一个，对比有无子 Agent；看哪些任务翻盘，不只看总分。样例：折入后延迟降了，但主 Agent 自己拿订单查询工具答完，没再问物流专员要送达日——原先能过的流程断了。改前确保 eval 覆盖生产里每条 Agent 链与每条不可破规则，且每条任务多跑几次（上述断裂曾 2 跑里只出现 1 次）。

多团队如何共养一个 Agent

所有权从「各养一个 Agent」转为「养 Skills/工具」；中央小团队守系统提示与端到端质量。

· MCP 工具：动作、实时数据、固定形状结果；按用户意图组工具，勿一 API 一工具（系统提示里工具定义过约 30–50 后选型易劣化）；tool search + 延迟加载；前置条件与权限放进工具内检查并返回可读拒绝。
· Skills：装「团队怎么干活」的步骤、规则与判断；可用 /skill-creator、/skill-doctor 自建、审计、剪枝；各队 DRI 保证 Skill 成形、互不重叠、带 eval。
· 知识库：偶尔才要的政策/指标/规格，放搜索或 Skill 内参考文件；避免代码检索后硬贴进 prompt。

配套工具

Migration kit 串联 guided 流程（可先在 mock 上试）：/claude-api build-eval、prompt-audit、hillclimb、cost-optimize。原则：度量 → 一次改一件 → 留得住的才留。不必一步到位；小端到端 eval → 折一个 → 折入版更差才保留子 Agent → 重复。