缓存策略：Prompt Caching 和 Context Caching

重复出现的 prompt 开头部分，每次调用都要重新花钱、花时间。Prompt caching（提示词缓存）把它们缓存起来，两者都能省。

问题所在：同样的文字，一遍又一遍

一个 agent 在每次请求里往往都会带上同样长的开头部分：system prompt、工具定义、大段文档。没有缓存的话，模型每次调用都要把这部分完全重新计算一遍——尽管文字根本没变，却仍然要花时间（延迟）和花钱（token 价格）。

Prompt Caching 是如何运作的

为此，Anthropic 和 OpenAI 都提供 prompt caching（提示词缓存）。服务商会记住你已经发送过一次的 prompt 开头部分（前缀）。如果你不久之后又发送了同样的开头——比如同样的 system prompt 加上一个新的用户轮次——模型就只需要处理新增的部分，其余部分都从缓存中取用。

能省下什么

在 Claude 上，一次缓存命中（cache hit）只需要付正常输入 token 价格的一小部分，而一次缓存写入（cache write）会比正常价格稍贵一些。在 OpenAI 上，只要 prompt 足够长，prompt caching 就会自动生效，能明显降低成本和等待时间，完全不需要改代码。

TTL：缓存会过期

缓存不会永远存在。在 Claude 上默认是 5 分钟；过了这个时间，缓存条目就会消失，下一次调用会重新写入缓存。也有一个更长、但更贵的选项。如果你在短时间内连续发送很多请求，从缓存中获益就会最多。

示例

一个 agent 的 system prompt 加工具定义共 6,000 个 token，在 3 分钟内发出了 10 次请求。没有缓存的话，这 10 次调用你都要为这 6,000 个 token 付全价。有了缓存，你只需要付一次全价（写入，1.25 倍），剩下的 9 次只需要付 0.1 倍——只要这些请求都落在 5 分钟的 TTL 之内，就能省下一大笔。

🛠️ 练习——自己动手试试

在你自己的某个 agent 脚本（或者你所用模型服务商的 API 文档）里，找出它是否使用了 prompt caching，以及是怎么用的。

看看你的 agent 的 system prompt / 工具定义：这个固定部分大概有多少个 token？
如果你用的是 Claude，检查 API 返回结果里的 cache_read_input_tokens 和 cache_creation_input_tokens 字段——缓存有没有被命中？
想一想：在哪种使用模式下（短时间内大量请求 vs. 单次、不常见的请求），缓存对你来说最划算？

✅ 自查清单

☐ 你能解释清楚为什么缓存命中比缓存写入更便宜吗？
☐ 你知道 Claude 上默认缓存在过期之前能存活多久吗？
☐ 你有没有在自己的 prompt 里找出一个适合设置缓存断点的具体部分？

小测验

为什么一个 prompt 缓存条目会自己过期？