Anthropic 官方劝你删 subagent 了：单循环快约一倍，但这三类先别动

过去两年，agent 架构越搭越像组织架构图：上面一个总调度，下面退款、物流、账单各一个 subagent，每个都有自己的提示词、工具和上下文。Anthropic 10 月 22 日发布的指南加 10 月 25 日上 GitHub 的迁移工具包，把这个习惯直接叫停了——主张是：能用一个主循环干的活，别拆成一群 subagent。

核心理由有三条。第一，每次交接都是一次“摘要的摘要”，信息在交接里丢；共享上下文的主循环答得更好。第二，渐进式披露：主循环先只看技能和工具的简短描述，需要时才加载完整版，上下文不被一次灌爆。第三，模型本身变强了，从 Opus 4.5 起，单个模型已经能独立扛复杂任务；Anthropic 称给新模型用的 Claude Code 系统提示词因此砍了 80% 以上。

最值得抄作业的是迁移工具包的设计：它不预设“单循环一定赢”，而是先测再合。流程是先评估现有架构，把总是一起跑的 subagent 先合并，剩下的能力迁进主循环的技能集，每一步前后都量任务完成率、耗时和成本，数字说了算再决定合不合。Anthropic 援引的某企业对比里，单循环比多 agent 快约一倍——但客户名字和对比条件都没有公开，这个“一倍”只能当成“有此可能”的信号，不能当成你的预期收益。

三类先别动，Anthropic 自己也留了口子：上下文膨胀已经能被量出来拖慢主循环的；需要并行跑、且用完即弃的任务；工具或指令本身互相冲突、塞进一个循环会选错工具的。落地顺序建议是：先给现有系统做一次基线测量，再从“总是一起跑”的那一对开始合，合完复测一次；独立上下文、并行一次性任务、冲突工具这三类留在原地。未经实测，个人判断：多数小团队的问题不是 subagent 太少，而是拆得太早——先把“为什么拆”写下来，答不上来就先合。

可信度：Anthropic 官方指南口径（10 月 22 日）+ The Decoder、dev.to、madrobot 多方交叉；“快约一倍”为未具名客户单次对比，条件未公开。