溪溪小店文档站

切换主题

Claude 缓存机制与命中条件 ​

先记住一句话 ​

Claude 的缓存可以理解为：把一段输入从开头到缓存标记处完整保存下来，下次再从头核对一遍。

如果下一次请求的开头与保存内容完全相同，就会命中缓存；只要中间有一个位置不同，匹配就会从那里中断。

不是“意思一样”就能命中

缓存不会理解两段话是否表达了相同意思。它检查的是内容、顺序和位置。增加一句话、删除一句话、修改时间，甚至只是把同一段内容移动到别处，都可能导致未命中。

把缓存想成一枚书签 ​

假设客户端发送了下面这些内容，并在角色卡后面放置缓存标记：

text
[系统预设] → [角色卡] → [世界书] → [缓存标记] → [本轮对话]

Claude 会缓存书签前面的部分：

text
[系统预设] → [角色卡] → [世界书]

下一轮对话虽然变长了，但只要开头仍然是这三部分，缓存就可以命中：

text
[系统预设] → [角色卡] → [世界书] → [缓存命中] → [更长的对话]

这就是正常连续对话容易命中缓存的原因：新消息通常只会追加在最后，前面的稳定内容没有变化。

Tavo 默认预设的问题 ​

部分客户端会在每轮请求的末尾临时加入额外信息，例如：

  • 文风要求
  • 当前时间
  • 临时状态
  • 其他隐藏提示词

为了方便说明，把这些内容统一叫作 临时注入。

问题不在于客户端加入了临时注入，而在于它每轮都会先删除旧的临时注入，再把新的临时注入移动到整段对话的最后面。

第一轮：缓存被创建 ​

用户发送“你好”后，Tavo 实际提交给 Claude 的顺序类似这样：

text
[系统预设]
→ [用户：你好]
→ [临时注入：文风、当前时间等]
→ [缓存标记]

因此，第一轮保存的缓存是：

text
[系统预设] → [用户：你好] → [临时注入]

随后 Claude 返回第一条回复。

第二轮：顺序发生变化 ​

用户继续发送“请继续”。Tavo 会删除上一轮末尾的临时注入，加入新的对话内容，再把临时注入放回最末尾：

text
[系统预设]
→ [用户：你好]
→ [Claude 第一条回复]
→ [用户：请继续]
→ [临时注入：文风、当前时间等]
→ [缓存标记]

现在将两轮请求从头对比：

位置第一轮缓存第二轮请求是否相同
1系统预设系统预设相同
2用户：你好用户：你好相同
3临时注入Claude 第一条回复不同

对比到第 3 个位置时就失败了。第一轮缓存要求这里出现“临时注入”，但第二轮这里已经变成了“Claude 第一条回复”。

所以，即使临时注入的文字一字未改，只是从原来的位置被移动到了末尾，第一轮的完整缓存也无法命中。Claude 只能按照第二轮的内容重新创建一份缓存。

第三轮：相同问题再次出现 ​

第三轮时，Tavo 又会删除第二轮末尾的临时注入，追加新的回复和用户输入，再把临时注入放到最后。

于是第二轮缓存中原本应该出现“临时注入”的位置，又被新回复替代。上一轮缓存再次无法完整匹配，系统只好继续创建新缓存。

最终表现就是：

text
第一轮：创建缓存 1，但第二轮读不到
第二轮：创建缓存 2，但第三轮读不到
第三轮：创建缓存 3，但第四轮仍然读不到

关键原因

不是 Claude 忘记了聊天记录，也不是模型不支持缓存，而是客户端每轮都改变了缓存标记之前的消息顺序。

当前时间会让问题更明显 ​

有些临时注入包含当前时间。即使客户端没有移动它的位置，只要时间发生变化，内容本身也不再相同：

text
第一轮：[当前时间：18:55]
第二轮：[当前时间：18:58]

位置相同但内容不同，缓存仍然无法完整命中。随机值、实时状态和每轮变化的提示词都会产生相同问题。

5 分钟和 1 小时缓存有什么区别 ​

缓存时长只决定一份缓存可以保留多久：

  • 5 分钟缓存：创建后最多保留 5 分钟。
  • 1 小时缓存：创建后最多保留 1 小时。

延长缓存时间不会修复前缀不一致。如果客户端每轮都改变消息内容或顺序，即使缓存保留 1 小时，下一轮仍然无法命中。

怎样提高命中率 ​

核心目标是让缓存标记之前的内容保持稳定：

  1. 把系统预设、角色卡、世界书等不常变化的内容放在最前面。
  2. 把缓存标记放在稳定内容之后，不要把每轮变化的内容包含进去。
  3. 当前时间、随机值和临时状态等动态内容应放在缓存标记之后。
  4. 固定客户端注入内容的位置，不要每轮删除后再移动到末尾。
  5. 不要修改、删除或重新排序已经参与缓存的历史消息。
  6. 排查时查看客户端最终发给 API 的完整请求，而不只是聊天界面中看到的内容。

TIP

“成功创建缓存”和“下一轮命中缓存”是两件事。只有下一次请求能从开头完整复用已保存的前缀，这份缓存才真正发挥作用。

总结 ​

判断缓存能否命中，只需要问一个问题：从请求开头到缓存标记处，下一轮是否还能保持完全一样？

如果答案是“能”，缓存通常可以命中；如果客户端在这段内容中移动了临时注入、修改了时间或插入了新消息，就会创建许多缓存，却很难在下一轮复用它们。