如何提高缓存命中率：提示词结构写法指南

缓存命中率低，99% 不是模型的问题，是提示词结构的问题。

这篇讲清楚一件事：缓存到底缓存的是什么，以及提示词该怎么摆，才能让它稳定命中。

前置知识：先看日志怎么看：用时、上游首包、缓存命中与计费，知道命中率怎么从日志里读出来。

一、先理解机制：缓存的是「前缀」，不是「内容」

这一点搞错，后面全错。

模型服务端的缓存是前缀缓存（prefix caching）：它记住的是「从第一个 token 开始，到某个位置为止的这一段」，而不是「你问过什么、它答过什么」。

命中规则只有一条：

从第 1 个 token 开始，逐字比对，能对上多长就复用多长；一遇到不一样，后面全部作废。

举个直观的例子。假设你的请求是：

[系统提示词: 你是资深法务...] [知识库片段: 合同模板A...] [用户问题: 第 3 条怎么改？]

第二次请求，如果系统提示词和知识库完全没变，只有用户问题变了 → 前面两大段全部命中，只有最后一句是新的，命中率很高；

如果系统提示词里多加了一个今天的日期 → 从日期那个位置开始全变了，后面知识库再长也用不上，命中率接近 0。

💡 一句话：缓存像一条链子，从最前面开始串，哪里断了，后面全不算。所以你要做的全部事情就是——让「断点」尽量靠后。

二、三条铁律

铁律 1：越稳定的内容，越往前放

按「变化的频率」从低到高排序，就是从前往后排：

位置	放什么	变化频率
最前	系统提示词（角色、规则、输出格式）、工具定义（tools）、few-shot 示例	几乎不变
中间	知识库、长文档、代码仓库上下文	偶尔变
稍后	对话历史（多轮累积）	每轮增长
最后	用户当前的问题	每次都变

铁律 2：任何「每次都不同」的东西，禁止出现在开头

这是命中率杀手榜第一名。常见的隐形变量：

当前时间戳 / 日期（现在是 2026-10-30 14:02:13）

随机 ID / 会话 ID / trace ID

用户名、订单号之类每次不同的业务字段

未排序的 JSON（序列化顺序可能每次不同）

动态拼接的「今日推荐」之类运营内容

正确做法：这些内容要么挪到最后，要么放进 user 消息里，绝对不能进 system 的开头。

铁律 3：稳定内容内部，顺序也要固定死

即使内容没变，顺序变了也算前缀不同。最容易踩的是这几处：

场景	坑
工具定义	用无序 map / set 拼 tools 列表，序列化顺序每次不同
知识库检索	召回的文档没有稳定排序，同样几条内容顺序抖动
few-shot 示例	从示例池里随机抽，而不是固定取前 N 条
多轮历史	中途对历史做了摘要压缩，压缩后的文本和原来不一致

⚠️ 只要顺序变了，哪怕内容一模一样，缓存也认不出来 —— 它是逐字比对，不是语义比对。

三、反面写法 vs 正面写法

反面 1：把时间塞进系统提示词开头

{
  "messages": [
    {
      "role": "system",
      "content": "当前时间：2026-10-30 14:02:13。你是一位资深法务顾问，负责审阅合同……"
    },
    { "role": "user", "content": "第 3 条怎么改？" }
  ]
}

❌ 每次请求时间都不同 → 第 1 个 token 就断了 → 后面几百字的规则全部无法命中。

改法：把时间挪到最末，或用相对表述。

{
  "messages": [
    { "role": "system", "content": "你是一位资深法务顾问，负责审阅合同……" },
    { "role": "user", "content": "[当前时间 2026-10-30 14:02] 第 3 条怎么改？" }
  ]
}

✅ 系统提示词完全稳定，可以长年命中。

反面 2：把用户问题拼进系统提示词

改法：system 只放规则，问题走 user 消息。

反面 3：检索结果顺序不稳定

改法：加稳定排序键。

反面 4：工具定义顺序抖动

改法：显式排序。

四、推荐的分层结构

把一次请求拆成四层，从稳定到易变依次排列：

┌─────────────────────────────────────┐
│ 第 1 层：系统提示词 + 工具定义         │  几乎永不变 → 命中率最高
├─────────────────────────────────────┤
│ 第 2 层：知识库 / 长文档 / 代码上下文   │  偶尔更新 → 更新后重建一次，之后长命中
├─────────────────────────────────────┤
│ 第 3 层：对话历史                      │  逐轮累积 → 只追加，不修改
├─────────────────────────────────────┤
│ 第 4 层：用户当前问题                   │  每次不同 → 不指望命中
└─────────────────────────────────────┘

关键：第 3 层「只追加，不修改」

多轮对话是命中率最容易崩的地方。只要中途改了历史消息（哪怕是「把前 5 轮压缩成一句摘要」），第 3 层的前缀就断了。

做法	对缓存的影响
追加新一轮问答	✅ 前面全部保留命中
给历史做摘要压缩	❌ 整个第 3 层重建
中途修改前面的消息	❌ 从修改点开始全部失效
删除早期消息（滑动窗口）	❌ 前缀从删除处断裂

💡 上下文太长必须压缩时，尽量在会话切换点做，而不是每几轮做一次。压缩一次的成本远高于命中一次省下的钱。

五、按厂商的触发方式不同

不同上游的缓存机制不一样，写法不能直接照搬。

类型	代表模型	怎么触发	要不要标记
显式标记	Anthropic（claude-opus-5-5、claude-sonnet-5-5 等）	在内容块上加 `cache_control` 标记，告诉服务端「这段可以缓存」	✅ 需要
自动前缀缓存	OpenAI（gpt-6-astra、gpt-6-luna 等）	前缀够长就自动命中，无需任何参数	❌ 不需要
自动（无写入费）	Gemini（gemini-4-argon）、Qwen（qwen3.8-flash）、GLM（glm-5.3）	自动命中，只对命中部分打折	❌ 不需要

Anthropic 原生协议的写法参考

在需要缓存的内容块末尾加标记（通过 anthropic 端点调用时）：

{
  "model": "claude-opus-5-5",
  "system": [
    {
      "type": "text",
      "text": "你是一位资深法务顾问……（此处是长篇稳定规则）",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "第 3 条怎么改？" }
  ]
}

要点：

标记打在稳定内容的末尾，表示「从这里往前都可以缓存」；

一次请求可打的断点数量有上限，一般只需为最长的那段稳定内容打一个即可；

部分模型有最小可缓存长度要求，内容太短不会生效 —— 具体阈值以该模型官方说明为准。

💡 通过 OpenAI 兼容协议调用同一模型时，是否生效取决于上游对该协议的支持情况。要稳定吃到缓存，优先用该厂商的原生协议端点（Claude 系列用 anthropic 端点）。

六、TTL：5 分钟还是 1 小时

缓存不是永久的，默认 5 分钟不访问就失效。

场景	建议
连续对话、代码补全、Agent 循环调用	5 分钟档够了，写入便宜（1.25 倍）
间隔较久的定时任务、每天多次同一套长文档	1 小时档，写入贵（2 倍）但不用反复重建

判断方法很简单：算一下两次请求的平均间隔。间隔远小于 5 分钟，用默认档；间隔在 5~60 分钟之间且不想重建，才考虑 1 小时档。

⚠️ 别为了「保活」去发无意义的空请求。空请求本身也计费，很可能比重新建一次缓存更贵。

七、怎么验证真的生效了

改完结构后，必须回日志验证，别凭感觉。

看什么	健康表现
「缓存读」数值	第二轮起应显著大于 0，且随对话推进单调增长
「缓存写」数值	只在首轮或缓存过期后出现较大值，平时很小
命中率	同一会话内应稳定在高位（常见 90% 以上；前缀短的场景会低一些）

如果改完还是 0%，按这个顺序查：

模型支持缓存吗 —— 不支持的话改什么都没用；

是不是同一会话 —— 新会话天然 0%；

开头还有没有变量 —— 时间戳、随机 ID 是头号嫌疑；

顺序稳不稳 —— 工具定义、检索结果有没有排序；

内容够长吗 —— 部分模型有最小可缓存长度；

是不是显式标记型模型但没打标记 —— Anthropic 系列需要 cache_control。

八、常见误区

误区	事实
「我把整个对话都存下来，命中率就高了」	缓存不用你存，它自己会记。你要做的是别打断前缀
「内容一样就能命中」	不一样。顺序不同也算不同，逐字比对
「命中率高就一定省钱」	不一定。省的是「缓存读」那一部分，输出和写入不打折。输出占比高时，整单只省一半
「所有模型都能缓存」	不是。只有部分模型配置了缓存能力，其余模型没有这个概念
「命中率高就一定更快」	不必然。首包快慢主要看上游排队，缓存不是主导因素
「缓存要自己写存储」	不用。服务端自动维护，你只影响「能不能命中」

九、上线前自检清单

改完代码，照着过一遍：

系统提示词里没有任何时间戳、随机 ID、用户名等变量

用户问题没有拼进 system，走的是 user 消息

工具定义（tools）按固定顺序输出

知识库/检索结果有稳定的二次排序键

对话历史只追加，没有中途改写或压缩

用的是该厂商的原生协议端点（尤其 Claude 系列）

显式标记型模型（Anthropic）已加 cache_control

改完在日志里确认「缓存读」确实从 0 变成了正数

用连续 5~10 条日志算命中率，而不是看单条

十、一句话总结

把不会变的东西堆在最前面，把会变的东西挪到最后面，中间的顺序别乱动。
做到这三件事，命中率自然会高；做不到，换什么模型都没用。

如何提高缓存命中率：提示词结构写法指南

一、先理解机制：缓存的是「前缀」，不是「内容」#

二、三条铁律#

铁律 1：越稳定的内容，越往前放#

铁律 2：任何「每次都不同」的东西，禁止出现在开头#

铁律 3：稳定内容内部，顺序也要固定死#

三、反面写法 vs 正面写法#

反面 1：把时间塞进系统提示词开头#

反面 2：把用户问题拼进系统提示词#

反面 3：检索结果顺序不稳定#

反面 4：工具定义顺序抖动#

四、推荐的分层结构#

关键：第 3 层「只追加，不修改」#

五、按厂商的触发方式不同#

Anthropic 原生协议的写法参考#

六、TTL：5 分钟还是 1 小时#

七、怎么验证真的生效了#

八、常见误区#

九、上线前自检清单#

十、一句话总结#