讲一下这个https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

回复 joye： 这篇是 Anthropic 应用 AI 团队写的，核心结论是：很多企业 agent 里的 router、planner、领域 subagent，合回主循环反而更好，质量不降，成本和延迟还更低。 它讲的失败模式挺典型：每个团队各交一个 subagent，最后架构变成了组织架构的复制（Conway's law），出现 subagent 泛滥、几百个重叠且没人负责、各自的 prompt 往系统提示里加一句凑成“Frankenprompt”、eval 各自为自己的子任务过度优化、多层嵌套调用让延迟翻倍。有个客户把多 agent harness 换成单 loop，运行时间大约快了一倍。 为什么现在能合：一是渐进披露（skill 渐进披露、tool search 延迟加载）解决了当初拆分的主要理由，即上下文膨胀；二是模型本身变强了，从 Opus 4.5 开始单循环能扛的事远超预期，harness 里写死的东西越来越多余。他们顺带把 Claude Code 给强模型的系统提示砍了 80% 以上。 该保留 subagent 的三种情况原文说得很清楚：单循环因为上下文膨胀出现可测量的性能下降；任务要并行、而且需要用完就丢掉的新鲜上下文窗口；或者单 agent 选不准工具、系统提示里有冲突指令。 迁移路径是分步的：先建端到端 eval（10 条 golden 就行），再把常用 subagent 按共享上下文合并，然后把 subagent 作为工具调用（不改代码，先拿基线），最后一个个改成 skill 加 MCP tool，对比 eval 上下两版。注意它提醒别只看总分，要看哪些任务翻转了——他们自己测时合了一个 subagent 延迟降了，但把一个原本通过的流程搞坏了，主 agent 自己查订单却没问物流拿送达日期，而且这个问题两次里只出现一次，所以要重复跑。 工具这边有个具体数字：系统提示里工具定义超过 30 到 50 个后，选择质量会开始下降，所以按用户意图分组工具，而不是一个 API 一个工具。 我觉得值得抄的是那句原则：架构本身没那么重要，测量、一次只改一个、留下扛得住的。以及它明确说 rigid multi-agent 结构经常是阻碍新一代模型发挥的原因——这点和 Joye 你之前讲 harness 该往外扩、通用补丁会被模型吸收是一个意思。