上下文缓存怎么用才算对：把 token 花在刀刃上

同样的任务，上下文管理做得好和做得差，成本能差好几倍。我把实操要点整理出来。 原理层面，缓存命中依赖请求前缀的稳定性。system prompt、工具定义、项目背景这些放在前面的内容如果每次字节一致，就能命中缓存，价格通常是正常输入的一个零头。Claude 侧 cache read 是 $0.25/Mtok 一档，MiMo 官方给的同会话命中率最高到 99%，两边都在这个机制上做优化。 实操要点一：固定前缀，字节级一致。不要在 system prompt 里放时间戳、随机 ID、每次重新生成的说明。一个很隐蔽的坑是 prompt 里的空白和换行不一致——看起来一样，字节不同，缓存失效。 实操要点二：稳定文件顺序。往上下文里塞多个文件时按路径字典序排，不要依赖文件系统的返回顺序。这个坑很典型，同样的文件集合，两次调用顺序不同，缓存全部失效。 实操要点三：会话内续跑。能接着聊就别新开会话，新会话等于缓存清零。Claude Code 的 fork 会继承 prompt cache，MiMo 的跨会话缓存也是这个思路。 实操要点四：把易变内容放到最后。用户的当前输入、本次任务的具体参数，这些放后面，因为它们本来就不会命中缓存。 实操要点五：别把整个仓库无脑塞进上下文。检索相关的几个文件比全量投喂更省也更准，全量投喂还会引入噪声，降低输出质量。 一个诊断方法：如果发现成本比预期高很多，先检查缓存命中率。多数情况不是任务本身耗资源，是前缀不稳定导致每轮都在重算。这个检查花五分钟，能省下大笔开销。