代码 Agent 的大部分 Token 并没有用在困难推理上，而是消耗在 I/O：为了回答一个方法的问题读取五个大文件，照着已有模式生成测试，或者把会议结论整理成文档。如果所有工作都交给前沿模型，团队是在用最贵的推理能力搬运上下文。
Spotify 的 Dimitri Mazmanov 做了一个很小但很实用的实验：为 Claude Code 增加两个低成本 Worker，并用 Hook 强制把适合的任务路由出去。在一个 Java 单体仓库的四类场景中，大文件读取类任务的 Token 消耗平均下降约 90% 。
#两个 Worker，只负责确定性工作
第一个模式是 bulk-reader。它接收多份文件和一个明确问题，只返回结构化摘要。第二个是 code-writer，用参考文件约束风格，生成测试、配置骨架和类型定义等可预测内容，并可把结果直接写入目标文件。
示例中两者都使用更便宜的 Gemini 2.5 Flash，Claude 不需要看到完整语料，也不必消费 Worker 生成的大段代码。真正需要架构判断、调试和安全推理的部分仍留给强模型。
这个设计的重要之处不在于具体模型，而在于把 Worker 定义成可复用的声明式 Mode：指令、模型、温度和工具配置彼此解耦。更换低成本模型不需要重写主 Agent 的编排逻辑。
#仅写路由规则不够
第一版方案只是把“何时委派”写进项目说明，效果并不稳定：规则是建议，Claude 可以忽略，而且每个仓库都要复制一份。
后来的实现分成三层。Hook 在每次读取前检查文件大小，超过阈值就阻止整文件进入主模型上下文，并提示改用 bulk-reader；Shell 脚本封装 Worker 调用、错误和 Token 统计；Skill 再告诉 Claude 什么任务适合走这些脚本。
这形成了一条很清楚的控制链：Hook 负责强制边界，脚本负责稳定接口，Skill 负责语义路由。 即使 Agent 没主动想起 Skill，成本边界仍然会生效。
#便宜模型有明确禁区
实验也暴露了三条边界。
首先，Worker 不适合编辑。摘要通常缺少可靠行号，真正修改前，Claude 仍需定向读取相关片段。其次，Worker 不适合承担关键推理：低成本模型能找到表层模式，却在测试中漏掉了一个线程安全问题。最后，委派有 10 到 30 秒的额外网络延迟，小文件直接读取反而更快，因此必须设定规模阈值。
这说明模型路由不能只看单 Token 价格，还要同时衡量上下文体积、任务可验证性、错误成本和往返延迟。最适合下沉的，不是“简单任务”这个模糊集合，而是输出能够由现有模式约束、失败能够被主 Agent 快速发现的任务 。
#成本控制正在变成 Harness 能力
当 Agent 开始长期运行，成本问题不会靠提醒模型“节省 Token”解决。系统需要知道哪些信息必须进入主上下文，哪些工作可以在外部完成，以及哪些判断不能委派。
Spotify 的方案没有证明所有项目都能节省 90%，其测试只覆盖一个 Java 仓库和四种场景；但它验证了一条更普遍的路径：让前沿模型承担决策，把批量读取和样板输出变成可替换的 Worker 服务。成本优化由此从 Prompt 技巧升级为 Harness 的调度策略。