Anthropic 自己下场劝你少用子 agent：路由和规划器能折的都折回主循环，工具超过 30 到 50 个就开始变笨
这条最值钱的不是结论，是那个翻车案例。
先说什么时候该保留子 agent
只有三种：
- 单个循环因为上下文膨胀出现了可衡量的性能下降；
- 需要并行处理多个任务，而且每个任务都能用完即弃地开一个新上下文窗口；
- 单个 agent 选不对工具，或者系统提示里有互相冲突的指令。
不在上述三类的路由器、规划器、领域子 agent，官方建议是折回主循环。
怎么折
一次只折一个。把子 agent 的 prompt 变成 skill，把它的 API 调用变成 MCP tool，然后跑同一套 eval 对比，折完的版本更差才把它留着当子 agent。
三条硬规定：
- 先建 eval 再动手。规模上，“10 条黄金样例就够起步”——中心团队维护一份端到端集合，每个 skill 的负责团队再各带一份小的。
- 从用量最大的子 agent 开始。
- 每个任务跑多次。翻车案例里那个 bug 是两次运行才出现一次。
对比的时候不要只看总分，要看哪些任务翻了。这是全文我最认的一句：平均分掩盖的恰恰是你最该知道的东西。
分工别搞混
- Skill 装”怎么做事”：步骤、规则、判断——也就是原来塞在子 agent prompt 里的那部分。
- Tool 装”执行动作”：读实时数据、返回固定结构、以及硬限制和权限校验。工具按用户意图分组，不是一个 API 一个工具。
- Knowledge base 装”不总要用的参考资料”：政策、指标定义、产品规格。放在检索工具后面或作为 skill 内的参考文件，别用代码取出来再贴进提示词。
配套的命令有一组：/skill-creator 写和审 skill，/skill-doctor 看每个 skill 花了多少钱、用了多少次，/claude-api build-eval、prompt-audit、hillclimb、cost-optimize。迁移工具包开源在 github.com/anthropics/single-agent-loop-kit。
翻车案例
Anthropic 拿一个客服 agent 做样本，把一个子 agent 折进另一个。延迟确实降了，但有个原本通过的流程坏了：主 agent 手上握着订单查询工具，就自己把发货日期答了，没去问物流 specialist。而这个失败在两次运行里只出现一次。
这段值得抄下来贴在显示器上。合并之后分数变好、延迟变低、成本变低，然后某个具体环节 quietly 错了。如果只看汇总指标，你永远不会知道。
对我有什么用
一人公司通常不会搭多 agent 架构，但你会遇到同一件事的缩小版：一个 skill 越写越长，把所有情况都塞进去，然后 agent 开始乱用。
折叠这套逻辑反过来用也成立：当一个 skill 里出现”如果是 A 情况就走这段，如果是 B 情况走那段”的分支，那就是两个 skill 了；而那些”每次都要读一遍但其实只有 20% 场景用得上”的条款，该挪进 references/ 而不是留在 SKILL.md 正文。
工具数量那条线同样适用于 MCP：系统提示里的工具定义超过 30 到 50 个，工具选择就开始退化。很多人装 MCP 的时候是一股脑全开，这一步就是具体地告诉你该在哪儿收手。
泼冷水
- “单循环更好”是 Anthropic 在自家客户场景里观察到的，不是普遍规律。文章自己也说保留子 agent 的三种情况包括研究前沿。别把它当成口号。
- 那个”某客户快了 2 倍”的数字来自 Anthropic 转述，样本和方法都没给。当方向看，不要当承诺。
- 工具包是参考实现，官方明确说了不维护、不接受贡献。拿它理解流程可以，别指望它长期可用。
- 30 到 50 是个经验区间，不是阈值。不同模型的表现差很多，你自己的临界点要自己测。
- 迁移的前提是你有 eval。没有 eval 就折，等于闭着眼睛改架构——而一人公司恰恰最缺 eval。这也是这套方法落地最难的地方：它把成本从”搭多 agent”转移到了”先写 10 条黄金样例”。
具体建议
- 今天能做的最小一步：把你最常用的那个 skill 的 SKILL.md 打开，数一下有多少行是”只有部分场景才用得上”的。把这些挪进
references/，正文只留主干。 - 数一下你开了多少个 MCP 工具。超过 30 个就按用户意图合并，或者关掉延迟加载用不上的那些。
- 给你的核心交付流程写 10 条黄金样例：真实请求 + 什么算做对。这是所有后续改动能不能评估的前提，也是这篇文章真正的前提。
- 真要动架构的话，先跑工具包里那个离线冒烟（
KIT_MODEL=fake），它不花一分钱，能先确认管道是通的。 - 每次改动后逐条看哪些任务从通过变成失败，别只看平均分。