把上下文当缓存来管：前缀稳定与命中率

前缀缓存能把成本与延迟显著降下来。本文给出前缀缓存的基本规律、四个落地技巧、该观测的三个指标、三个常见坑与一份检查清单。

上下文也是"缓存"

多轮对话里，每轮都要重发历史 ✔ —— 这是最大的成本与延迟来源之一 ✔。

现代模型服务普遍支持**前缀缓存** ✔（相同前缀命中缓存后，计费与延迟都显著降低 ✔）。

**把上下文按缓存的思路管理** ✔：让前缀稳定、把变化放后面 ✔。

**前缀稳定 → 命中率高** ✔（系统提示、工具说明、示例放最前 ✔）；

**变化内容放后面** ✔（用户输入、检索片段、时间戳放尾部 ✔）；

**时间戳/随机 id 会破坏缓存** ✗（放在前缀里 = 永远不命中 ✔）。

**这条最容易踩** ✗→✔：在系统提示里写"当前时间：{{now}}" ✔，

会让**每次请求的前缀都不同** ✔ —— 缓存命中率直接归零 ✔。

1. **把动态信息移到末尾** ✔（时间、用户信息、检索结果 ✔）；

2. **固定顺序**（工具说明、示例、约束的顺序别乱改 ✔ —— 顺序变了前缀也变了 ✔）；

3. **长文档前置复用**（多轮里反复用同一份文档 → 放在前缀位置 ✔）；

4. **观测命中率**（没有指标就不知道有没有生效 ✔）。

**前缀缓存命中率**（按功能看 ✔ —— 突然下降说明有人往前缀里加了动态内容 ✔）；

**单位成本变化**（命中率上升通常成本显著下降 ✔）；

**首 token 延迟**（缓存命中会明显更快 ✔）。

**把时间戳写进系统提示** ✗（最常见的命中率杀手 ✔）；

**每轮重排提示结构** ✗（动态拼装顺序不一致 ✔）；

**把检索片段放前缀** ✗（每轮都不同 ✔）→ 应放尾部 ✔。

```

□ 系统提示与工具说明在前，内容稳定

□ 时间/用户信息等动态字段在末尾

□ 组装的段落顺序固定

□ 检索片段放尾部（或固定在一个稳定位置之后）

□ 有前缀缓存命中率指标与告警

```

> 连续两次请求（内容只改最后一句）✔，第二次的**成本与首字延迟**是否明显更低 ✔？

> 没有差别，说明缓存没被命中 ✗（大概率前缀里有动态内容 ✔）。