Prompt 缓存，一次讲明白

1 + 2 = 3。

但 2 + 1 是 cache miss。

为什么？

因为缓存匹配靠 prompt 的哈希。

只要顺序变了，哪怕内容一样，哈希也会变。哈希一变，缓存就对不上，整个前缀要重新计算。

所以要记住三条规则。

第一，不要在 session 中途增删工具。

工具定义属于缓存前缀。你改了工具，后面的缓存基本就废了。

第二，不要中途切换模型。

缓存是和模型绑定的。你换成更便宜的模型，也要重建整段缓存。

第三，不要通过修改 prefix 来改变状态。

Claude Code 的做法是，把状态提醒加到下一条用户消息里，而不是改系统前缀。这样 prefix 不变，缓存还能继续命中。

你自己做 Agent 时怎么用？

如果你在做自己的 Agent，结构可以这样安排：

最顶部放 system instructions 和规则。中途不要改。 提前加载所有需要用到的 tools，不要临时增删。 然后放检索到的上下文和文档，在 session 内尽量保持稳定。 底部放对话历史和工具输出。

开启 auto-caching 后，缓存断点会随着对话推进自动前移。

Anthropic 已经在 API 里加入 auto-caching，所以你也可以为自己的 Agent 使用类似方式。

没有 auto-caching 时，你需要自己记住 token 边界。边界错了，就吃不到缓存。

如果需要为了上下文限制做压缩，也要用 cache-safe forking。

也就是保持相同 system prompt、tools 和 conversation，然后把 compaction 作为一条新消息追加进去。

这样压缩请求看起来几乎和上一轮一样，缓存前缀还能继续复用。真正按新 token 计费的，只有那条压缩指令。

怎么判断缓存有没有生效？

看 API 响应里的三个字段：

cache_creation_input_tokens：写入缓存的 token。cache_read_input_tokens：从缓存读取的 token。input_tokens：正常处理的输入 token。

你的缓存效率，可以看 read tokens 和 creation tokens 的比例。

这个指标应该像 uptime 一样持续监控。

因为它直接影响成本。

关键结论

Prompt caching 不是一个“打开就完事”的功能。

它是一种架构纪律。

Claude Code 是一个很好的例子：通过让前缀稳定、工具稳定、上下文结构稳定，它能把 cache hit rate 做到 92%，成本降低 81%。

如果你在做 Agent，这就是蓝图。

Context tax 一定存在。

区别只在于：

你是一直为它付钱，还是从架构上把它消掉。