北京
“subagent 更消耗 token”——这个质疑在 AI 圈里流传已久，听起来也很有道理：每个子任务都要重新交代上下文，任务完成后还得交接结果，token 消耗量自然上去了。但宝玉（@dotey）最近的分析给出了一个反直觉的结论：token 消耗更大，实际成本却可能更低。
这笔账的关键，在于“消耗量”和“单价”是两回事。
子模块的固定代价，没那么可怕
先承认代价。subagent 架构下，每个子模块拥有独立上下文，任务开始前需要重新交代子任务背景，完成后要把结果交接回主模块——这部分 token 消耗是跑不掉的。
至于缓存能省多少？宝玉指出，缓存的影响其实有限。初始上下文本身不大，而且每个子模块都有自己的缓存，后续调用并不吃亏。换句话说，固定代价存在，但被高估了。
真正的成本优势在模型路由
核心收益在于：子模块完全可以用便宜模型。token 量大，但单价低，总价反而更划算。主模块则只需要处理子任务的最终结果，不用盯着每个细节，上下文空间大幅节省。
宝玉以 Claude Code 为例：让 Fable 指挥 Opus/Sonnet 子模块，体感差异非常明显。主模型负责调度和决策，子模型干具体活，各司其职。
用“派活”理解扩展性
宝玉用了一个很接地气的比喻：能力强的人把活派给实习生，自己只负责验收结果。这样能同时推进的事情数量，完全不是一个量级。
这个逻辑放到架构里同样成立：
- 主模块聚焦核心任务，不被细节淹没
- 子模块各管一摊，用便宜模型跑量
- 整体扩展能力大幅提升，成本反而可控
当然，这套打法有个前提——主模型本身要足够“耐用”。如果主模型能力不够，复杂编排反而会拖垮整体效率。宝玉的观点很直接：主模型强，就不需要复杂编排；主模型弱，才需要靠调度来摊薄成本。
所以下次再看到“subagent 太费 token”的吐槽，不妨先算算单价。量大了，价格可能更便宜——这笔账，得算总价。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
