Prompt Cache：为什么 Claude Code 比大多数 AI 助手快十倍

> 来源 commit: 515b759 (easy-learn-ai) --- ## 一、一个被忽视的问题：每次对话，AI 都在做同一份作业 想象这样一个场景：你去一家餐厅，每次点餐都要先花十分钟向服务员解释你的饮食禁忌、过敏源、口味偏好——即使这是你第三次来，第四次来，第十次来。服务员每次都像第一次见你一样，从头开始记。 这就是今天绝大多数大语言模型面临的处境。 每次你和 AI 说一句话，你发送的请求里不仅包含这条新消息，还包含之前所有的对话历史。模型要处理的不只是你刚说的那句话，而是从你开口说的第一句"你好"开始，到上一轮对话的每一个字，全部重新"读"一遍，重新"理解"一遍，重新"编码"一遍。 如果你已经聊了二十轮，每轮模型都要把前面十九条对话从头到尾重新计算一遍。这就像每翻一页书都要把前面所有页再读一遍。 很浪费，对吧？ Prompt Cache——提示词缓存——就是来解决这个问题的。 --- ## 二、核心概念：把已经算过的东西存下来 Prompt Cache 的原理，用一句话就能说明白：**如果这次请求的开头和上次一模一样，那这部分已经算过的东西就不用再算了。** 具体来说，API 服务端会把你发送的提示词（prompt）的前缀保存下来。下次你再发请求时，服务端从第一个 token 开始比对，只要前缀完全匹配，这部分的中间计算结果就直接从缓存读取，跳过重新编码。 这不是什么复杂的算法，本质上就是一个**严格的前缀匹配**。 但这个简单的机制带来的效果非常惊人。 --- ## 三、关键数字：省多少钱？付出什么代价？ 让我们说几个具体的数字。 **90%——缓存命中时的成本节省。** 当缓存命中时，你只需支付原价的 10%。换句话说，省下了 90%。这对一个动辄处理数万 token 的长对话场景来说，意味着账单可能从几百美元变成几十美元。 **25%——首次写入的额外开销。** 天下没有免费的午餐。第一次把提示词前缀写入缓存时，价格比正常请求贵 25%。所以如果你只发一次请求就结束，开缓存反而是亏的。但只要紧接着第二次请求命中了缓存，省下的 90% 立刻覆盖掉那 25% 的溢价，还有大把盈余。 **5 分钟——默认缓存存活时间。** 你存入缓存的内容不会永远留在那儿。Anthropic 默认的缓存 TTL（存活时间）是 5 分钟。如果你超过 5 分钟没有发送新的请求，缓存就会过期，下次要重新写入。对于连续工作的场景，5 分钟绰绰有余。如果你经常停下来思考半天，那这 5 分钟可能不够用。 还有一个更长的档位：1 小时。代价是写入价格翻倍（贵 100%），但只要命中两次就能回本。适合那些断断续续但不想每次都重新"热身"的任务。 **1024 / 4096——缓存门槛。** 不是随便写几行字就能进缓存的。Anthropic 规定，一个缓存段至少要有 1024 个 token 才能被缓存（有些情况下是 4096）。如果你精心设计的提示词只有 500 token，不好意思，它不符合缓存条件，每次都要全价计算。 --- ## 四、缓存即基建：不是优化，是生存 在 Anthropic 内部，Prompt Cache 的命中率被当作**基础设施级别的指标**来监控。 什么意思？ 你的服务器宕机了，运维团队会收到告警，这是常识。但在 Anthropic，缓存命中率掉了几个百分点，也会触发 oncall 告警，工程师得像处理线上事故一样去排查。 为什么？ 因为对于 Claude Code 这类 AI 编程助手来说，没有缓存就没有产品。 Claude Code 的对话动辄几十轮，每轮上下文可能长达数万 token。如果每一轮都把前面的内容重新算一遍，延迟会让用户觉得"卡死了"，成本会让公司觉得"赔死了"。缓存不是锦上添花，是整个系统能跑起来的地基。 用 Anthropic 自己的话说："**Prompt caching is everything.（缓存就是一切。）**" --- ## 五、前缀匹配原理：你的行李箱怎么放，决定了你能不能省这 90% 既然缓存是前缀匹配，那提示词里内容的排列顺序就变得至关重要。 想象一下你在收拾行李箱。有些东西是你每次旅行都带的——牙刷、充电器、常用药。有些东西是这次特定行程才需要的——泳衣、滑雪服、会议资料。还有些东西是出发前一天才塞进去的——刚打印的登机牌。 如果你把登机牌放在箱子最底层，每次打开箱子都要把上面的东西全翻一遍。但如果你把最不变的东西放最下面，最常用的放上面，每次打开只需要动最上面那一层。 Prompt Cache 的逻辑一模一样：**越不容易变的东西，越往前放。** Claude Code 的请求结构就像一个精心打包的行李箱，从上到下依次是： 1. **系统指令 + 工具定义**——所有用户、所有会话都一模一样，是"全剧通用的剧本"。这部分缓存命中率最高，甚至可以跨用户共享。 2. **项目文档（CLAUDE.md）**——同一个项目内保持不变。不同项目的文档不一样，但在一个项目内可以反复复用。 3. **会话上下文**——当前这一轮对话的特定设置，只要会话没结束就不会变。 4. **聊天消息**——每轮都在增长的动态内容，是唯一真正"活"的部分。 这个顺序的设计意图很明确：让前面的静态部分尽可能多地被缓存共享，只把最后那一小截动态内容按全价计费。 --- ## 六、三个坑：你以为的小事，会让整条缓存链断掉 前缀匹配有一个非常苛刻的特性：**前缀里任何一处变化，从那个位置开始后面所有内容的缓存全部失效。** 也就是说，你前半段辛辛苦苦缓存下来的几万 token，可能因为中间改了一个字，全部作废。 以下是 Anthropic 踩过的三个真实坑： ### 坑一：在系统指令里塞了一个实时时间戳 "当前时间是 2026 年 5 月 8 日 21 时 46 分 32 秒。" 看起来很合理对吧？让模型知道现在几点。问题是，下一秒这个时间戳就变了。你的系统指令从第一个字开始就不匹配了，整个前缀缓存全部失效。 ### 坑二：用无序容器（dict / set）存放工具定义 Python 里的字典和集合是无序的。每次程序运行时，里面元素的遍历顺序可能不同。如果你把工具定义存在一个 dict 里，这次请求的"工具 A、工具 B、工具 C"，下次可能变成"工具 C、工具 A、工具 B"。顺序一变，前缀匹配失败，缓存全部作废。 ### 坑三：更新了一个工具的参数 你有个 Agent 工具，里面列着当前可用的子智能体列表。你给这个列表加了一个新智能体，或者改了一个字段名。就这么一点改动，从工具定义开始的整个前缀全部失效。前面缓存的几万 token，一夜回到解放前。 **这三个坑的共同点是：看起来都是微不足道的小改动，但对缓存来说是核弹级别的破坏。** --- ## 七、七条实战心法：Claude Code 团队用血和泪换来的经验 知道了坑在哪里，自然就有绕过坑的方法。以下是 Anthropic 总结的七条最佳实践，每条都是从真实故障里提炼出来的。 ### 心法一：别动 Prompt，用消息代替 你需要更新信息？比如系统时间变了，用户改了文件，你想切换模式？ **不要修改系统提示词。** 把新信息塞进下一条用户消息或工具返回结果里。Claude Code 的做法是用一个 `<system-reminder>` 标签，把最新消息悄悄带进去。这样既让模型知道了新信息，又保住了前面所有的缓存。 这就像你不需要重新装修整栋房子来告诉室友今晚要加班，你只需要在门口贴一张便签。 ### 心法二：别换模型 同一个会话中途切换模型听起来是个省钱的好主意——前面复杂的工作用强大的 Opus，后面简单的问题换便宜的 Haiku。但账不是这么算的。 不同模型的系统提示词和工具处理方式不同。你一切换，前缀从第一个 token 开始就不匹配了，之前累积的所有缓存全部作废。而且新模型还要重新写入缓存，再付一遍溢价。最后算下来，可能比分分钟用同一个模型还贵。 ### 心法三：子任务独立缓存 如果你有一组彼此独立的子任务，不要让它们共享一个巨大的前缀。每个子任务应该有自己的独立缓存上下文。否则一个子任务的任何变动都会影响所有子任务的缓存。 ### 心法四：别碰工具定义 工具定义是前缀里非常靠前的内容。一旦动了它，后面的项目文档、会话上下文、对话历史全部失效。代价巨大。如果你必须更新工具，想清楚是不是值得付出整段缓存作废的代价。 ### 心法五：Plan Mode 用工具表达状态转换 Claude Code 有个"Plan Mode"（计划模式），让模型先思考再行动。实现这个模式的方式不是修改系统提示词说"你现在进入计划模式"，而是引入一个专门的 `switch_mode` 工具。状态转换通过工具调用来表达，而不是通过修改 prompt。这样系统提示词保持不变，缓存不受影响。 ### 心法六：Lazy Loading 延迟加载 不是所有工具在会话一开始就需要。把不常用的工具设计成延迟加载——等真正需要的时候才通过工具调用来激活。这样它们不会出现在前缀里干扰缓存，也不会因为存在但用不上而浪费 token。 ### 心法七：Cache-Safe Forking 压缩安全分叉 当上下文窗口快要塞满时，你需要把对话历史压缩成一个摘要，然后开启新的会话。这个操作叫"压缩"或"compaction"。 最容易踩的坑是：新开一个请求来生成摘要，但这个新请求的系统提示词、工具集和原对话完全不同。两者的前缀从第一个字就不一样，原对话的缓存完全无法复用。你需要为传入的整个长对话付全价。 Claude Code 的解法是**缓存安全的分叉**：创建的新请求，其系统提示词、工具定义、会话上下文和原对话完全一致。他们把原对话的所有消息放进去，然后在**末尾追加一条压缩指令作为新消息**。从 API 的视角看，这个新请求和原对话的最后一个请求几乎一模一样——相同的前缀，相同的工具，相同的历史。庞大的缓存前缀得以完全复用，唯一新增的 token 只是末尾那条压缩指令本身。 这需要精心预留一个"压缩缓冲区"，确保上下文窗口有足够空间容纳压缩指令和生成的摘要。 --- ## 八、意义与展望：为什么这件事值得每个人关心 Prompt Cache 表面上是 Anthropic 的一项 API 特性，实际上它揭示了一个更深层的设计哲学：**在 AI 时代，成本优化不是事后补丁，而是架构设计的原点。** Claude Code 从第一天起就是围绕缓存来构建的。它的系统提示词分区、工具定义结构、CLAUDE.md 的注入方式、Plan Mode 的实现、压缩分叉的逻辑——所有这些看似不相关的功能，其实都指向同一个约束：**保持前缀稳定，最大化缓存复用。** 如果你也在构建 AI 应用，无论你是做聊天机器人、编程助手、数据分析工具还是创意写作伙伴，这个原则都适用。先想清楚你的提示词里哪些是不变的、哪些是半变的、哪些是常变的，然后按这个顺序排列它们。缓存不是 API 的一个开关，它是你整个系统设计的骨架。 更重要的是，Prompt Cache 让我们重新思考 AI 应用的成本结构。在还没有缓存的时代，长对话的成本随轮数线性增长——聊得越久越贵。有了缓存之后，成本结构变成了：前面有一个固定的一次性投入（写入溢价），后面的每一轮只按增量付费。这从根本上改变了长对话类产品的经济可行性。 也许再过几年，缓存会变成所有大模型 API 的标配，变成像 HTTP 缓存一样理所当然的基础设施。但在那之前，理解它、用好它，可能就是你和竞争对手之间那 90% 的成本差距。 --- **最后一句话：** AI 领域的很多优化听起来都很复杂——量化、蒸馏、MoE、推测解码——但 Prompt Cache 的聪明之处恰恰在于它的简单。一个前缀匹配，省下了 90% 的重复劳动。有时候，最优雅的解法不是更复杂的算法，而是对问题本质的更清醒认识。 毕竟，真正的问题从来都不是"怎么算得更快"，而是"为什么同样的事情要算第二次"。 --- #easy-learn-ai #每日更新 #记忆 #小凯