• 重复计算：LLM 最贵的隐性开支
• 静态前缀与动态后缀：缓存的关键分界
• KV 缓存：把计算结果存下来
• 哈希敏感性：顺序换了就是缓存未命中
• 三条铁律
• Claude Code 的 92% 命中率
• 监控你的缓存效率
• 总结：缓存不是开关而是架构纪律

每次 AI 代理执行一步操作，都会把整个对话历史重新发给大模型。这段历史里有系统指令、工具定义，还有三个回合前就处理过的项目背景。所有这些内容在每个回合都被重新读取、重新计算、重新收费。

这笔账算起来很惊人：一个 2 万 token 的系统提示词，跑 50 个回合，就是 100 万 token 的重复计算，按全价收费，但没产生任何新价值。prompt caching 就是来解决这个问题。

要用好缓存，先要搞清楚请求里哪些东西会变、哪些不变。每个代理请求都包含两部分：

• 静态前缀 ：系统指令、工具定义、项目背景、行为规则。这些在各回合之间完全不变。
• 动态后缀 ：用户消息、助手回复、工具输出。这些随每个回合不断增长。

缓存之所以可行，就是因为静态前缀不变。推理服务器把静态前缀的计算结果存下来，后续请求如果带着相同的前缀，直接从内存读取，跳过整个计算过程。

这个分界线是理解后续所有规则的基础。缓存只对不变的部分有效，所以你的架构设计必须确保前缀稳定。

稍微深入一点技术细节。Transformer 处理输入时分两个阶段： 预填阶段 * (prefill) 处理整个输入，做大量矩阵运算，计算密集所以贵； * 解码阶段 (decode) 逐个生成 token，主要读取历史状态，内存密集但计算量小。

在预填阶段，模型为每个 token 计算一对"键"（key）和"值"（value）向量。这些向量一旦算完就不会变。如果没有缓存，每个请求都丢弃这些向量重新算；有缓存的话，它们被持久化在推理服务器上，通过 token 序列的哈希值索引。新请求带着相同前缀到来，哈希匹配，向量从内存加载，预填计算直接跳过。

从计费角度看：缓存读取的价格是基础输入价格的十分之一（0.1 倍），缓存写入要付 1.25 倍的溢价（因为要存储计算结果）。这套定价意味着缓存只有在命中率够高时才划算。

prompt caching 最反直觉的一点： 顺序敏感 。基础设施对整个 token 序列做哈希计算。序列中任何变化，哪怕只是两个元素的顺序互换，哈希值就变了，整个前缀按全价重新计算。

原文给了几个生产环境中破坏缓存的真实案例：

• 系统提示词里注入了时间戳，导致每个请求的哈希值都不同
• JSON 序列化器对工具定义的键排序不一致，不同请求之间顺序变了
• 代理工具在会话中途更新了参数，2 万 token 的缓存全部作废

这解释了为什么 Claude Code 在工程上如此小心翼翼。

基于这些教训，原文总结了三条规则：

1. 会话期间不要修改工具定义 。工具定义是缓存前缀的一部分，添加或删除任何一个工具都会让下游所有内容失效。
2. 不要在会话中途切换模型 。缓存是模型特定的，中途换模型意味着从头重建整个缓存。
3. 不要为了更新状态而改变前缀 。Claude Code 的做法是：需要提醒 AI 某件事时，不编辑系统提示词，而是把提醒作为一条新消息追加到用户消息中，前缀保持原样。

这三条规则的共同逻辑是：缓存前缀是"只写一次、反复读取"的资源。任何修改都会导致重新计算，而重新计算的价格是缓存读取的十几倍。

Claude Code 是 prompt caching 的最佳实践案例。它的整个架构围绕一个目标：让缓存保持"热"状态（即始终命中）。

原文描述了一个 30 分钟编码会话的成本账本：

• 第 0 分钟：加载系统提示词、工具定义和 CLAUDE.md，超过 2 万 token。这是整个会话中最贵的时刻，但只需付一次。
• 第 1 到 5 分钟：用户开始给指令，Claude Code 派出子代理浏览代码库。2 万 token 的静态前缀从缓存读取，每百万 token 0.3 美元而非 3 美元。
• 第 6 到 25 分钟：计划子代理收到的是摘要而非原始输出（避免膨胀动态后缀），每个回合都从缓存读取前缀，命中率攀升到 90% 以上。每次访问重置缓存的存活时间，保持缓存温热。
• 第 28 分钟：会话结束。总处理量约 200 万 token，其中 184 万是缓存读取。按 Sonnet 4.5 费率，无缓存要 6 美元，有缓存只要 1.15 美元，省了 81%。

要验证缓存是否正常工作，看每个 API 响应中的三个字段：

• cache_creation_input_tokens ：写入缓存的 token 数
• cache_read_input_tokens ：从缓存读取的 token 数
• input_tokens ：未经过缓存处理的 token 数

缓存效率公式： cache_read_input_tokens 除以 cache_read_input_tokens 加 cache_creation_input_tokens 。像跟踪系统可用性一样跟踪这个指标。

prompt caching 不是一个可以随意开关的功能。它需要你围绕它来设计架构：静态内容放顶部、动态内容放底部、前缀在会话中保持不变、动态后缀尽量精简。

Claude Code 展示了这种纪律在大规模下的效果：92% 命中率，81% 成本节省。如果你在构建基于 LLM 的系统却没有围绕 prompt caching 来设计，那你就是在把大部分利润空间白白扔掉。