当AI学会了「记住你说过的话」——Prompt Cache 背后那笔你正在悄悄多付的账

来源 commit: 515b759 | easy-learn-ai 项目每日更新
灵感来自 Anthropic 工程师关于 Claude Code 提示词缓存设计的最佳实践分享

一、那个让你多花了九成钱的隐形动作

想象一下这样的场景。

你是一名律师，正在跟一位极其聪明的助手讨论一份复杂的合同。你们已经聊了整整十九轮——从合同背景聊到条款细节，从风险分析聊到修改建议。到了第二十轮，你只补充了一句话：「第三条里的违约金比例，能不能改成百分之二？」

然后你眼睁睁看着这位助手——把前十九轮的所有内容，从头到尾重新读了一遍。

一个字不落。一页不差。从「你好，我是你的法律助手」开始，到「第十九条争议解决条款」结束。就为了你最后那句只占全部对话千分之一的提问。

你会不会觉得这个人疯了？

可这正是今天绝大多数大语言模型在做的。你跟 Claude、GPT、Gemini 聊得越多，它重复劳动的比例就越高。聊二十轮，有十九轮的内容是完全重复的，但它每一轮都要重新「读」一遍。不仅浪费时间——在 API 计费的世界里，时间直接等于金钱——而且那笔钱，是你一分不少地在付。

Anthropic 的工程师算过一笔账：一个十万字的长对话，不用缓存的情况下，Claude Sonnet 每轮要烧掉 0.30 美金。二十轮下来就是 6 美金。而开了缓存之后，首次多花一点（0.375 美金），之后每轮只要 0.03 美金。十轮省九成。

这不是优化。这是你在用还是不用之间，差了整整一个数量级的成本。

二、缓存不是什么高深魔法，它只是一次聪明的「断章取义」

现在让我们把镜头拉近，看看后台到底在发生什么。

每次你给大模型发消息，它要做的第一件事叫做 prefill——把你发过来的所有文本，从第一个字到最后一个字，全部编码成一种叫做 KV Cache 的内部表示。这个过程占了整个推理成本的绝大部分，也是延迟的主要来源。

问题就在这里：你跟它聊了二十轮，第二十轮的请求里，前十九轮的内容和上一轮一模一样。系统指令没变，工具定义没变，历史对话一个字都没改过。可模型还得从第一个字重新算一遍，就像那个把前十九轮重读一遍的律师助手。

提示词缓存（Prompt Cache）的解法，说穿了极其简单——

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

就这么一句话。没有神经网络架构的改动，没有新算法的发明。只是工程师发现：既然前缀不变，那干嘛不直接把算过的结果存着？

打个比方。你每次写论文都要重抄目录和前几章再接新内容。有了缓存，相当于抄过的部分直接快进，只写新的那一段。这就是 Prompt Cache 的本质——一次工程层面的「断章取义」，却带来了数量级的效率提升。

三、那笔账，我们重新算一遍

几个关键数字，值得你记在脑子里。

命中缓存的部分，价格打一折。也就是说，如果正常输入价格是每千 token 三美分，缓存命中的部分只要零点三美分。首次写入确实贵一点——要 1.25 倍，多花百分之二十五——但后面每次省百分之九十。这笔买卖，只要你的对话超过一轮，就稳赚不赔。

默认存五分钟。五分钟内有请求就自动续期，不额外收钱。也有付费的一小时档位，适合那种需要长时间保持上下文的场景。

不过有个门槛：内容太短缓存不上。一般至少要 1024 个 token（大约等于七百多个汉字），新一点的模型要 4096 个。短 prompt 确实没缓存的份，这也是为什么这项技术主要服务于长对话和复杂 Agent 场景，而不是简单的问答。

延迟收益同样显著。不用重算的部分越多，第一个字出来得越快——也就是业界说的 TTFT（Time To First Token）。在多轮对话里，用户感受最明显的不是总时长，而是「我发完消息，它什么时候开始回复」。缓存直接把这个等待时间砍掉一截。

四、排好队形——缓存友好的提示词长什么样

现在你知道缓存是前缀匹配了。这意味着一件事：提示词里东西的排列顺序，直接决定你能命中多少缓存。

Anthropic 的最佳实践把提示词里的内容分成四层，从前往后依次是：

第一层：系统指令 + 工具定义。 这些是固定的，所有会话共享。你是谁、你有什么能力、你能调用什么工具——这些打死都不要动。

第二层：项目文档。 比如 CLAUDE.md，同一个项目内所有对话共享。代码规范、项目结构、技术栈——这些都是相对稳定的。

第三层：当前会话的上下文。 只在这一次对话里有效，比如当前打开的文件、今天的目标。

第四层：聊天消息。 逐轮增长，每轮只新增最后一条。

一句话总结：越不容易变的东西，越往前放。

这个比喻我特别喜欢——就像收拾一张书桌。常年不动的参考书放最底层。这周要看的资料放中间。今天写的草稿放最上面。这样你每天坐下来，才不用把整张桌子翻一遍。

反过来说，如果你在最底层塞了一个每秒都在变的实时时间戳，或者用一个每次顺序都不一样的无序容器来装工具定义，那每次请求的前缀都会变化，缓存就永远命中不了。

五、三个坑——缓存链是怎么断的

这里有几个特别容易踩的坑，每一个都能让整条缓存链瞬间归零。

坑一：在固定指令里嵌了当前时间。 系统指令里写了一句「今天是 {datetime.now()}」。听起来很合理——让模型知道时间嘛。但问题是，这一秒和下一秒，前缀就不一样了。缓存直接废掉。

正确做法是什么？别去改系统指令。把更新塞进下一轮的消息里。 在下一条用户消息里附上一段 <system-reminder>，把要更新的信息夹带进去。这样系统指令纹丝不动，缓存完好无损。地基（系统指令）钉死不动，流水（消息）想怎么改怎么改。

坑二：工具定义用 dict 或 set 这种无序容器来装。 每次发请求顺序都不一样，前缀对不上，缓存失效。解决方案很简单：用 list，按固定顺序排。

坑三：工具参数改了一个字段。 哪怕只动一个字段，整条前缀的缓存全部失效。这就像一条链子，中间一个环裂了，后面的全散。所以在设计工具时，要考虑稳定性——能不改的字段就不要改，能用状态字段代替的就不要增删参数。

六、别换模型——一个反直觉的真相

这里有一条对很多人来说有点反直觉的经验。

你可能会想：简单问题切到小模型（比如 Haiku）省点钱，难题再切回大模型（比如 Opus）。多合理啊。一个十万 token 的长对话，最后一轮只是个简单的格式化请求，干嘛不用便宜模型？

但事实是：缓存是跟模型绑定的。

换模型，等于之前积攒的所有缓存全部作废，从头重建。而重建的成本，往往比让大模型直接回答那个「简单问题」还要高。尤其是在长对话场景里，你省的那点模型差价，可能还不够填补重新 prefill 的代价。

所以 Claude Code 的策略是——主对话自始至终用同一个模型。 如果确实需要小模型干轻活，怎么办？

派子任务。

子任务有自己独立的上下文和缓存，不污染主对话的缓存链。主模型先写一份「任务交接说明」，把上下文浓缩好再发出去。子模型干完活，只把结果带回来，中间过程全留在子任务里。就像你不会让实习生坐到你的工位上用你的电脑——给他一个独立的工位，他干他的，你干你的。

Claude Code 的 Explore agents（探索模式）就是这样跑的：Haiku 小模型独立执行搜索、翻代码、摘要等任务，独立缓存，不污染主对话。

还有一个给中转服务商的警告：缓存是按账号隔离的。 如果你用 account pool 搞中转，不同账号之间缓存不共享，命中率暴跌。钱没赚到，号没了。

七、延迟加载、规划模式、缓存安全分叉

再聊几个进阶技巧。

Lazy Loading（延迟加载）：不要在对话开头就把所有工具都注册上。需要的时候再加载。因为工具定义是前缀的一部分，工具越多，前缀越长，任何工具定义的改动影响面越大。延迟加载相当于把工具拆成按需加载的模块，减少前缀的体积和不稳定性。

Plan Mode（规划模式）：在正式执行前先让模型输出一个执行计划，用户确认后再进入执行模式。但这里有个缓存陷阱——如果从计划模式切换到执行模式时改了系统指令或工具定义，缓存就断了。正确的做法是通过消息来切换状态，而不是改系统指令。

Cache-Safe Forking（缓存安全分叉）：当你需要对对话做压缩、摘要、或者派生子任务时，必须确保分叉后的对话共享主对话的前缀。也就是说，系统指令、工具定义、项目文档这些「地基」层必须完全一致，只有消息层可以变化。否则，分叉就等于断链。

八、总结：前缀匹配决定一切

回头看这十五条经验，都在说同一件事——缓存就是前缀匹配。

前缀里任何位置的变化，都会让其后所有内容的缓存失效。这是 Prompt Cache 唯一的、绕不开的约束。所有的设计，都要围绕这一个约束来展开。

• 用消息代替指令修改
• 不要在对话中途切换工具或模型
• 像监控在线率一样监控缓存命中率
• 分叉操作必须共享主对话的前缀
• 别改指令，别动工具——一碰，整条缓存链就断

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

在 AI Agent 时代，上下文长度动不动就是十万 token 起步，Prompt Cache 已经从「可选优化」变成了「必选项」。不懂缓存的设计，等于在每一笔 API 调用里默默多付九成冤枉钱。而理解了前缀匹配的本质，你就能在写提示词的时候，自然而然地写出缓存友好的结构。

那笔账， Anthropic 已经帮你算清楚了。现在的问题是——你打算什么时候开始省？

参考来源

• Anthropic 工程师关于 Claude Code Prompt Cache 最佳实践的分享
• easy-learn-ai 项目 Prompt Cache 交互演示站（15 章节完整教程）

#easy-learn-ai #每日更新 #记忆 #小凯 #PromptCache #AIAgent #LLM优化