夜雨聆风一句话：AI Coding 工具下一轮竞争，不只是“谁接入了更强模型”，而是谁能把上下文、工具和模型路由做成一套更省、更稳的系统。
很多团队评价 AI Coding 工具时，仍然会先问一个问题：它背后用了哪个模型？
这个问题当然重要，但已经不够了。
当 Copilot、Claude Code、Codex、Cursor 这类工具从“补全一段代码”进入“规划、修改、调试、评审、调用工具”的阶段，真正决定体验的，往往不是单次调用里模型有多聪明，而是整个执行系统有没有减少浪费。
GitHub 最近写了一篇关于 Copilot token 效率的文章。表面看，它在解释 Copilot 如何让用户的额度更耐用；但更值得关注的是：AI Coding Agent 的成本战，正在从模型层转向系统层。
以前省 token，是少说话；现在省 token，是少做无效功
早期的 token 优化很直观：提示词短一点、上下文少一点、输出克制一点。
但 Agent 形态出现后，token 的浪费方式变了。
一次长会话里，系统可能要反复携带：
仓库结构和任务状态 项目指令和风格约束 历史对话 可调用工具的 schema 当前文件、错误日志、测试结果
这些东西有一部分是必要上下文，另一部分只是“每一轮都顺手塞进去”的固定开销。
真正的优化，不是让模型少看信息，而是让它只在必要的时候看必要的信息。
这也是 Copilot 文章里最值得拆开的两个方向：prompt caching 和 deferred tool loading。
缓存：让稳定上下文不要每轮重算
Prompt caching 的核心很简单：如果每一轮请求的前缀高度相似，就不要让模型每次重新处理同一大段内容。
对编程 Agent 来说，这尤其重要。
一个稍微复杂的任务，可能持续十几轮。仓库说明、编码规范、工具约束、会话历史中的稳定部分，并不会每轮都变化。如果每次都完整重算，系统实际上把大量预算花在“复读背景信息”上。
缓存带来的价值，不只是省钱。
它还会改变产品设计：
长任务不一定天然昂贵 多轮协作可以更自然 Agent 可以保留更多稳定背景 用户不需要频繁重新解释上下文
但这里也有一个容易被忽略的反直觉点：模型路由不能随便切。
如果系统频繁在不同模型之间切换，缓存可能被打断。看似从一个更便宜的模型省了成本，实际可能因为缓存失效，把前面省掉的又花回去了。
所以，成熟的路由不是“便宜就切”，而是要把缓存命中率也纳入决策。
工具加载：Agent 不该每次背着整个工具箱跑步
第二个关键变化，是工具定义的延迟加载。
今天的 AI Coding Agent 往往连接了越来越多工具：文件读写、终端、搜索、测试、MCP、GitHub、Issue、CI、数据库、内部服务……
如果每一轮都把所有工具说明完整塞进上下文，模型还没开始干活，就已经背上了一个很重的工具箱。
更好的方式是：先让模型知道“可以查找工具”，再在需要时加载相关工具。
这件事的意义不只在节省 token。
它意味着 Agent 平台可以同时支持更大的工具生态和更低的每轮负担。工具越多，不一定每轮越贵；关键在于系统有没有工具搜索、权限边界和按需暴露机制。
对企业内部 AI 工程来说，这一点尤其关键。
很多公司想让 Agent 接入内部系统，但一接入就会遇到两个问题：上下文爆炸和权限风险。按需工具加载，正是把“可用工具很多”和“本轮只暴露少量能力”分开的基础设施。
模型路由：不是让最大模型做所有事
Copilot 的 Auto model selection 也值得关注。
它试图回答的不是“哪个模型最强”，而是“这个任务此刻该交给哪个模型”。
不同任务需要的推理强度不同：
解释一段代码，不一定需要最强模型 修改单文件 bug，可能需要中等推理和快速反馈 跨多个模块重构，才更需要强推理模型 测试失败后的定位，还要看工具调用和日志分析能力
GitHub 的判断是，没有一个模型在所有任务上都持续最好。
这其实是 AI 产品经理需要记住的一句话：模型能力不是一个静态排行榜，而是一组随任务变化的成本、速度、稳定性和推理能力组合。
真正的产品护城河，正在变成“调度能力”
如果把这篇文章放进更大的趋势里看，会发现 AI Coding 的竞争正在分层。
第一层是模型。
第二层是 IDE、CLI、代码托管平台里的入口。
第三层，是越来越重要的 agent harness：它决定如何组织上下文、什么时候调用工具、如何恢复失败、怎样选择模型、如何压缩会话、如何控制权限。
用户最终感知到的“聪明”，往往是这三层叠加后的结果。
同一个模型，放在不同 harness 里，效果可能差很多。同一个 Agent，如果上下文管理和工具暴露做得差，也会表现得又贵又慢又不稳定。
对开发团队的三个启发
第一，不要只按模型名评估 AI Coding 工具。
更应该问：它如何管理长会话？如何复用上下文？工具 schema 是否按需加载？失败后能不能恢复？模型切换是否破坏缓存？
第二，企业自建 Agent 时，要先设计“上下文预算”。
哪些信息必须常驻？哪些可以按需检索？哪些工具只在特定任务开放？这些问题如果一开始不设计，后面会以成本、延迟和安全问题的形式回来。
第三，把路由当成产品能力，而不是基础设施细节。
模型路由不是简单的成本优化。它影响响应速度、任务质量、用户信任和额度消耗。好的路由应该像一个隐形调度员：用户不必关心每一步用了谁，但能感觉到系统既不吝啬，也不浪费。
结尾：AI Coding 的下一场仗，是有效工作量
AI Coding 工具不会因为接入更强模型就自动变好。
随着 Agent 会话变长、工具变多、任务变复杂，真正稀缺的不是 token 本身，而是每一个 token 被用在了多少有效工作上。
能把缓存、工具加载、模型路由和权限控制串起来的团队，才会在下一轮 AI Coding 竞争里占到便宜。
参考资料
GitHub Blog: Getting more from each token: How Copilot improves context handling and model routing VS Code technical deep dive: token efficiency and tool search
