上下文也是"缓存"
多轮对话里，每轮都要重发历史 ✔ —— 这是最大的成本与延迟来源之一 ✔。
现代模型服务普遍支持前缀缓存 ✔（相同前缀命中缓存后，计费与延迟都显著降低 ✔）。
把上下文按缓存的思路管理 ✔：让前缀稳定、把变化放后面 ✔。
一、前缀缓存的基本规律
- 前缀稳定 → 命中率高 ✔（系统提示、工具说明、示例放最前 ✔）；
- 变化内容放后面 ✔（用户输入、检索片段、时间戳放尾部 ✔）；
- 时间戳/随机 id 会破坏缓存 ✗（放在前缀里 = 永远不命中 ✔）。
这条最容易踩 ✗→✔：在系统提示里写"当前时间：{{now}}" ✔，
会让每次请求的前缀都不同 ✔ —— 缓存命中率直接归零 ✔。
二、四个落地技巧
- 把动态信息移到末尾 ✔（时间、用户信息、检索结果 ✔）；
- 固定顺序（工具说明、示例、约束的顺序别乱改 ✔ —— 顺序变了前缀也变了 ✔）；
- 长文档前置复用（多轮里反复用同一份文档 → 放在前缀位置 ✔）；
- 观测命中率（没有指标就不知道有没有生效 ✔）。
三、该观测的三个指标
- 前缀缓存命中率（按功能看 ✔ —— 突然下降说明有人往前缀里加了动态内容 ✔）；
- 单位成本变化（命中率上升通常成本显著下降 ✔）；
- 首 token 延迟（缓存命中会明显更快 ✔）。
四、三个常见坑
- 把时间戳写进系统提示 ✗（最常见的命中率杀手 ✔）；
- 每轮重排提示结构 ✗（动态拼装顺序不一致 ✔）；
- 把检索片段放前缀 ✗（每轮都不同 ✔）→ 应放尾部 ✔。
五、检查清单
□ 系统提示与工具说明在前，内容稳定
□ 时间/用户信息等动态字段在末尾
□ 组装的段落顺序固定
□ 检索片段放尾部（或固定在一个稳定位置之后）
□ 有前缀缓存命中率指标与告警
一条判据
连续两次请求（内容只改最后一句）✔，第二次的成本与首字延迟是否明显更低 ✔？
没有差别，说明缓存没被命中 ✗（大概率前缀里有动态内容 ✔）。