Anthropic 建议把不少子智能体折回主循环：用 Skills 和工具搜索替代，并放出迁移工具包

01官方的判断和条件

Anthropic 应用 AI 团队说，他们在多个企业部署的对比里发现，带 Skills 的单个智能体经常在质量上胜过“一个提示词包办”和“多子智能体”两种设计，成本和延迟也常常更低。这是官方的经验总结，文中没有给出统一的测试集或完整数字。

文中举到的具体数字有两个：一家客户把自家多智能体框架与单智能体循环对比，后者运行时间约快一倍；Claude Code 面向较新模型的系统提示词被缩短了 80% 以上，其中一部分来自把 Skills 和工具改成渐进披露。

原因文章归为三点：共享上下文让后面的步骤能看到前面的完整结果，而不是子智能体交回的摘要；渐进披露让系统提示词不必一次塞满；模型本身能在单个循环里管理更多事情。

02什么时候仍该用子智能体

• 单个循环已经因上下文膨胀出现可测量的性能下降；
• 多个任务需要并行，各自用全新的上下文窗口、做完即丢；
• 单个智能体选不准工具，或系统提示词里的指令互相冲突。

文章特别批评一种做法：每个团队、每类问题各配一个子智能体，架构最后成了公司组织图的复刻。它列出的问题包括上下文交接丢细节、子智能体泛滥、系统提示词被各团队一句句加成“拼凑提示词”、评测只围绕各自子任务、延迟变高。

03怎么折：先测，再一个个来

1. 先建一套端到端评测，哪怕只有 10 个标准样例；每条真实流程链和每条“绝不能违反”的规则都要有对应任务，每个任务多跑几次。
2. 把经常前后串联、碰同一份数据的子智能体先合并成一个领域智能体。
3. 把保留的子智能体改成主智能体可调用的工具，先拿到评测基线，不用重写它们。
4. 逐个把子智能体的提示词改成 Skills，把接口调用改成 MCP 工具，对比折叠前后的评测，保留表现更差的那些。

文中给了一个提醒：在一个客服样例里，把一个子智能体折进另一个后延迟下降了，却弄坏了原本通过的流程——主智能体自己握着订单查询工具作答，没再向物流专员询问送达日期。这个问题在两次运行里只出现了一次，所以评测要重复跑。

工具数量上，文章建议按用户意图分组而不是一个接口一个工具，超过 30 到 50 个工具定义后选择质量会下降；工具多时用工具搜索延迟加载。

04迁移工具包

single-agent-loop-kit 是配套的参考实现，Apache-2.0 许可。流程是：把其中的 skill 复制到自己仓库的 .claude/skills/ 下，在 Claude Code 里说“Run the single-agent-loop skill”，它会先审计、给每个子智能体判定“折叠、合并、改为工具或保留”，每次改动单独跑评测并对比，每一步都停下来让你确认。仓库的 examples/support-desk 是带路由器和 6 个子智能体的演示，不要 API Key 的离线检查命令是 KIT_MODEL=fake python3 evals/run_eval.py --variant smoke；本站在沙箱里跑过，19 个任务全部跑完、0 个运行错误。离线替身模型只按关键词规则回答，这次运行没有评分意义。

文章同时提到近期发布的 /claude-api 系列命令：build-eval、prompt-audit、hillclimb、cost-optimize，分别用来建评测、找出为旧模型写的多余指令、按评测迭代优化、以及压缩成本。