当AI学会「记笔记」：提示词缓存如何让大模型从「每次重抄」变成「直接快进」

来源 commit: 515b759 你有没有想过，每次你跟 ChatGPT 或 Claude 聊天，后台到底在干什么？ 不是它「在思考」那么简单。实际上，你每发一条新消息，服务器都要把你之前说的所有话——系统指令、工具定义、历史对话、加上你这条新的——从头到尾重新编码一遍。这个过程叫 prefill，是延迟和花钱的大头。 更离谱的是：你跟它聊了 20 轮，第 20 轮的请求里，前 19 轮的内容跟上一次一模一样。但模型还得从第一个字重新算一遍。就像你每次写论文都要重抄目录和前几章，再接新内容。白白做了 19 轮重复劳动。 提示词缓存（Prompt Cache）就是来解决这个的。 ## 一、原理：前缀匹配，像抄书时的「快进」 机制一句话：你在请求里标一个断点，后台就把从开头到这个断点之间的编码结果存下来。下次前缀完全一样，直接复用，跳过重复计算。 打个比方：你每次写论文都要重抄目录和前几章再接新内容。有了缓存，相当于抄过的部分直接快进，只写新的那一段。 这是 Anthropic 在 Claude Code 里广泛使用的技术。Claude Code 是什么？它是 Anthropic 出的 AI 编程助手，一个会话能聊几十轮。每一轮都要把上文全带上重新发。没有缓存，延迟和成本会爆炸。 Anthropic 内部甚至把缓存命中率当基础设施级别的指标来看——地位跟服务器在线率差不多。命中率一掉，触发值班告警，工程师得当线上事故处理。原文用的词是「宣布分级事故」，比普通告警严重多了。 更关键的是：命中率高，不光省钱，还直接影响用户体验——它让 Anthropic 能给付费用户更宽松的使用额度。缓存命中率越高，你在同样的价格下，能用得越多。 所以对 Claude Code 来说，缓存不是锦上添花的优化。是整个系统能跑起来的前提。没有缓存，就没有 Claude Code。 ## 二、数字：打一折的魔法 几个关键数字： - 命中缓存的部分，价格打一折（基础输入价的 10%） - 首次写入要 1.25 倍——多花 25% - 后面每次省 90% 默认缓存存 5 分钟。5 分钟内有请求就自动续期，不额外收钱。也可以选 1 小时的付费版本。 不过有个门槛——内容太短缓存不上。一般至少要 1024 个 token，新一点的模型要 4096 个。短 prompt 没缓存的份。 举个实在的例子：10 万字的长对话，用 Claude Sonnet。 - 不开缓存：每轮 0.30 美金 - 开了缓存：首次 0.375，之后每轮只要 0.03 聊 10 轮，省下大约 90% 的输入成本。而且不光省钱——延迟也降下来了。不用重算的部分越多，第一个字出来得越快。 ## 三、排好队形：越稳的越靠前 既然缓存靠前缀匹配，那提示词里东西的排列顺序就至关重要了。 Anthropic 的最佳实践是这样排的： 1. 最前面：系统指令和工具定义。这些是固定的，所有会话共享。 2. 第二层：项目文档（CLAUDE.md）。同一个项目内共享。 3. 第三层：当前会话的上下文。只在这一次对话里有效。 4. 最后：聊天消息。逐轮增长，每轮只新增最后一条。 一句话总结：越不容易变的东西，越往前放。 就好比收拾书桌。常年不动的参考书放最底层。这周要看的资料放中间。今天写的草稿放最上面。这样你每天坐下来才不用把整张桌子翻一遍。 ## 四、三个坑：一个小细节，整条缓存链就断了 坑一：在固定指令里嵌了当前时间。每秒都在变，缓存直接废掉。 坑二：工具定义用无序容器来装。比如 Python 的 dict 或 set，每次发请求顺序都不一样，前缀对不上。 坑三：工具参数改了。哪怕只动一个字段，整条前缀的缓存全失效。 一个小细节没注意，整条缓存链就断了。 ## 五、想更新信息？别动提示词，发条消息就行 执行任务时，信息很容易过时。比如系统里内置的时间不对了，或者用户修改了文件。一个直接的念头是去更新系统提示词里的内容，但这会立即引发缓存失效，对用户来说成本高昂。 Claude Code 的做法是把这些更新当作下一轮对话的消息传递进去，而不是修改原有的提示词前缀。他们会在下一条用户消息或工具返回的结果里，悄悄加入一个 <system-reminder> 标签，把最新的信息告诉模型。 这个小小的技巧，完美地保住了珍贵的缓存。 ## 六、别换模型，别动工具 你可能会想：对话中遇到简单问题，切到 Haiku 省点钱，遇到难题再切回 Opus，多合理啊？ 但实际情况是：缓存是跟模型绑定的。换模型就意味着之前积攒的所有缓存全部作废，得从头重建。重建缓存的成本，往往比让 Opus 直接回答那个简单问题还要高。 所以 Claude Code 的策略是：主对话自始至终用同一个模型。 需要用小模型干活的时候怎么办呢？派子任务。 子任务有自己独立的上下文和缓存，不会污染主对话的缓存链。具体做法是：让主模型先写个任务交接说明，把上下文浓缩好。然后传给子任务去执行，做完只把结果传回主对话。 打个比方：你不会为了省事让实习生坐到你工位上用你的电脑。而是给他分配一台独立的机器，把任务说明写清楚发过去，做完把结果发回来。 这里还要给搞中转的朋友提个醒——缓存是按账号隔离的。有人想用账号池搞中转，账号池一混，命中率过低，钱没赚到反而把号搞没了。还有教你咔咔切账号的，也要留意。别聊两句就来回切。 ## 七、压缩上下文，也要缓存安全 长对话跑久了，上下文窗口会被填满。这时候需要把之前的对话压缩成一个摘要，腾出空间继续聊。 但问题来了：如果你另起一个 API 调用来做压缩，用了不同的系统提示、没带工具定义……那从第一个 token 开始就跟主对话的缓存完全对不上了。两条缓存链，互相不复用，白白多花一份钱。 Anthropic 的解决方案叫「缓存安全分叉」（Cache-Safe Forking）： 压缩请求必须用跟主对话完全一样的系统指令、用户上下文、工具定义，把主对话的消息作为历史带上。然后在末尾追加一条压缩指令，作为新的用户消息。 从后台视角看，这个请求和上一次几乎一模一样。相同的前缀，相同的工具，相同的历史，所以前缀缓存可以直接复用。新增成本，只有最后那条压缩指令本身。 同时还要预留一个压缩缓冲区，给摘要输出留够空间。不能等窗口填满才开始压缩，要提前留余量。 一个压缩操作，能复用主对话积攒的全部缓存。几乎不多花钱。 ## 八、Plan 模式与延迟加载 Claude Code 还有一个巧妙的设计叫 Plan 模式。 当用户要求做一件复杂的事时，模型先不直接动手，而是进入「规划状态」——分析任务、拆解步骤、列出需要调用的工具。这个状态切换不是通过修改系统提示词实现的（那样会打破缓存），而是通过工具调用来模拟。 模型调用一个特殊的 plan 工具，表示「我现在要进入规划模式」。系统识别到这个工具调用后，在回复中展示规划界面。整个过程中，系统提示词一个字都没改，缓存完好无损。 类似地，延迟加载（Lazy Loading）也是缓存友好的设计：不是一开始就加载所有工具定义，而是按需要逐步加载。这样静态前缀保持最小化，缓存命中率更高。 ## 九、给你的启发 无论你是用 Claude Code 还是从头构建自己的 Agent，这些规则同样适用： 1. 按顺序构建提示词：系统指令 → 工具定义 → 参考文档 → 对话历史 2. 用消息更新信息，别改系统提示词 3. 中途坚决不换模型和工具 4. 用子 Agent 处理需要不同模型的任务 5. 压缩上下文时用缓存安全分叉 6. 像监控在线率一样监控缓存命中率 Claude Code 从第一天起就被设计成围绕提示缓存来构建。如果你也打算动手打造下一个伟大的智能体，不妨也从这条规则开始。 参考资料： - Anthropic 官方博客：Lessons from building Claude Code: Prompt caching is everything - easy-learn-ai 项目：prompt-cache 交互式演讲站点 #easy-learn-ai #每日更新 #记忆 #小凯 #提示词缓存 #PromptCache #ClaudeCode #AIAgent #成本优化