来源 Commit: 515b759 项目: easy-learn-ai / 轻松理解 Prompt Cache 发布时间: 2026-05-06

当 AI 学会「过目不忘」：Prompt Cache 是怎么帮你省钱的

你有没有想过，每次跟 ChatGPT 或者 Claude 聊天，后台到底在发生什么？

不是那种玄学式的「AI 在思考」，而是实打实的工程细节——你发过去的每一个字，服务器都要重新过一遍。系统指令、工具定义、聊天记录、你刚打的这条新消息，全部混在一起，从第一个字开始算到最末尾。这个过程叫 prefill，是延迟和账单里最大头的那一部分。

那你跟 AI 聊了 20 轮，第 20 轮的请求里，前 19 轮的内容跟上一次一模一样。模型还是得从头算。就像你每次写论文都要重抄一遍目录和前几章，再接新写的那一段。

这听起来很蠢，对吧？确实是。于是有人想了一个办法：把已经算过的部分存下来。这就是 Prompt Cache。

一句话原理

你在请求里标一个断点。后台把从开头到这个断点之间的「编码结果」存下来。下次前缀完全一样，直接复用，跳过重复计算。

这就好比你抄论文抄到第三章，标记一下。下次再写的时候，前面三章直接快进，只写新的内容。

省多少钱？Anthropic 给了一个实在账

几个关键数字，记一下：

• 命中缓存的部分，价格打一折（省 90%）
• 首次写入要 1.25 倍——多花 25%，但后面每次省 90%
• 默认存 5 分钟，5 分钟内有请求就自动续期，不额外收钱；也可以选 1 小时的付费版本
• 门槛至少 1024 个 token，新模型可能要 4096，短 prompt 没资格玩缓存

举个实在的例子：10 万字的长对话。不开缓存，Claude Sonnet 每轮要花 0.30 美金。开了缓存，首次 0.375，之后每轮只要 0.03。聊 10 轮，省下大约 90% 的输入成本。

而且不光省钱。延迟也降下来了——不用重算的部分越多，第一个字出来得越快。这个指标叫 TTFT（Time To First Token），对交互体验影响极大。

Anthropic 把缓存命中率当成「在线率」来监控

这是最让我意外的一点。

在 Anthropic 内部，缓存命中率是跟服务器在线率同等地位的基础设施级指标。命中率一掉，触发值班告警，工程师得当线上事故处理——原文用的词是「宣布分级事故」（declare SEVs），意思是走完整的事故响应流程。

为什么看得这么重？因为没有缓存，就没有 Claude Code。

Claude Code 这种 AI 编程助手，一个会话几十轮。每一轮都要把上文全带上重新发。每次都从头算，延迟和成本会爆炸。缓存不是锦上添花的优化，是整个系统能跑起来的前提。

更关键的是，命中率高，不光省钱，还直接影响用户体验——它让 Anthropic 能给付费用户更宽松的使用额度。缓存命中率越高，你在同样的价格下，能用得越多。

核心原理：前缀匹配

缓存的核心逻辑就四个字：前缀匹配。下一次请求的前缀跟上次一样，就能复用之前的计算。

这看起来简单，但限制极其严苛——前缀里任何位置的变化，都会让其后所有内容的缓存失效。就像多米诺骨牌，前面一块倒了，后面全部重来。

所以接下来所有「最佳实践」，本质上都在做同一件事：让前缀尽可能多地保持不变。

排好队形：越不容易变的东西越往前放

Anthropic 的最佳实践里，提示词的排列顺序有讲究：

1. 最前面：系统指令 + 工具定义（所有会话共享，固定不动）
2. 第二层：项目文档（同一个项目内共享，相对稳定）
3. 第三层：当前会话的上下文（只在这一次对话里有效）
4. 最后：聊天消息（逐轮增长，每轮只新增最后一条）

一句话——越不容易变的东西，越往前放。就像收拾书桌：常年不动的参考书放最底层，这周要看的资料放中间，今天写的草稿放最上面。这样你每天坐下来才不用把整张桌子翻一遍。

三个特别容易踩的坑

坑 ①：在固定指令里嵌当前时间

系统指令里写了「今天是 2026 年 5 月 6 日」。下一秒就变成 5 月 7 日，缓存直接废掉。要把时间塞进对话消息里，别去动系统指令。

坑 ②：工具定义用无序容器装

HashMap、Set 这些东西每次遍历顺序可能不一样。请求发过去，工具定义的顺序变了，前缀对不上，缓存失效。必须用有序列表。

坑 ③：工具参数改了哪怕一个字段

加了一个新参数，改了一个类型，删了一个字段——整条前缀的缓存全失效。因为工具定义变了，前缀就不再一样了。

进阶技巧 ①：Plan Mode 的规划模式

Claude Code 有个「规划模式」。进入后模型只思考、只规划，不执行操作。

直觉的做法是：进规划模式就把执行类工具移走，退出来再加回来。但 Anthropic 没这么干。他们的做法是保留所有工具不动，另外加了两个特殊工具——「进入规划」和「退出规划」。

模型调用「进入规划」就切到思考模式，调用「退出规划」就回来。那「规划模式下不能执行」这个约束怎么传达？通过在对话中插入一条系统消息，告诉模型你现在在规划。

注意——是在对话流里插一条消息，不是去改系统指令。这两个东西要分清：

• 系统指令：固定的，在缓存前缀里
• 系统消息：流动的，不影响前缀

这样工具集始终不变，缓存始终有效。而且还带来一个额外好处：模型可以自己判断什么时候进规划模式——遇到复杂任务，它自己先想清楚再动手，不用你手动切换。

进阶技巧 ②：延迟加载（Lazy Loading）

Claude Code 可能要接入几十个外部工具。全部完整定义塞进去？太占空间。按需加减？又破坏缓存。

Anthropic 的折中方案叫延迟加载。一开始只放一个轻量的占位符，模型看到的只是工具名字，不含完整的参数定义。等模型真要用某个工具了，再通过「工具搜索」功能去拉取完整定义。

好处是前缀始终只包含那些轻量占位符，不会因为加载了某个工具就变化。缓存稳稳的。

相当于图书馆的书目索引。你先翻目录，找到想看的书再去书架取，不用把所有书都搬到桌上。

进阶技巧 ③：缓存安全分叉（Cache-Safe Forking）

长对话跑久了，上下文窗口会被填满。这时候要把之前的对话压缩成摘要，腾出空间继续聊。

但问题来了。如果你另起一个请求做压缩，用了不同的系统指令，没带工具定义——那从第一个字开始，就跟主对话的缓存对不上。两条缓存链，互相不复用。而且你要把整段对话发过去做摘要，这时候你付的是完整的、没有缓存折扣的费用。对话越长越贵。

Anthropic 的解决方案叫「缓存安全分叉」。压缩请求必须用跟主对话完全一样的系统指令、用户上下文、工具定义，把主对话的消息作为历史带上。然后在末尾追加一条压缩指令，作为新的用户消息。

从后台视角看，这个请求和上一次几乎一模一样。相同的前缀，相同的工具，相同的历史，所以前缀缓存可以直接复用。新增成本，只有最后那条压缩指令本身。

同时还要预留一个压缩缓冲区，给摘要输出留够空间。不能等窗口填满才开始压缩，要提前留余量。

Sub-Agent：别把实习生拉到你工位上

有时候需要用小模型干活——比如 Claude Code 的探索模式，用小模型在独立上下文里执行搜索任务。

正确做法：子任务有自己独立的上下文和缓存，不会污染主对话的缓存链。让主模型先写个任务交接说明，把上下文浓缩好。然后传给子任务去执行，做完只把结果传回主对话。

打个比方。你不会为了省事让实习生坐到你工位上用你的电脑。而是给他分配一台独立的机器，把任务说明写清楚发过去，做完把结果发回来。

这里要给搞中转的朋友提个醒——缓存是按账号隔离的。有人想用账号池搞中转，账号一混，命中率过低，钱没赚到反而把号搞没了。

回头看：所有的经验都在说同一件事

7 条经验，总结一下：

1. 前缀匹配决定一切。前缀里任何位置的变化，都会让其后所有内容的缓存失效。
2. 用消息代替指令修改。要切换模式、要更新时间，把这些塞进对话消息，别去动系统指令。
3. 不要在对话中途切换工具或模型。用工具来表达状态转换，用延迟加载代替工具的增删。
4. 像监控在线率一样监控缓存命中率。Anthropic 对缓存中断发告警，当线上事故处理。
5. 分叉操作必须共享主对话的前缀。压缩、摘要、子任务，全部用相同的参数。

所有的设计，都要围绕这一个约束来展开。别改指令，别动工具——一碰，整条缓存链就断。换模型、切账号、另起炉灶，同一个道理。

最后

这看着像缓存优化。但讲的也是一种思路——先认死那条绕不开的限制，再围着它把整个系统搭起来。

Prompt Cache 的故事，本质上是工程直觉的胜利。当所有人都在讨论模型越大越好、参数越多越好的时候，有人回头看了看账单说：等等，我们是不是在重复做同一件事？

答案是肯定的。而且这个问题，用一个简单的「前缀匹配」就解决了。

#easy-learn-ai #每日更新 #记忆 #小凯