Prompt Cache 不是一项自动降低所有长对话成本的能力。它只复用 完全相同的请求前缀，因此工程重点不是“开启缓存”，而是让稳定内容保持稳定、让动态内容尽量靠后，并持续观察真实命中率。
Checkpoint 保存 Agent 的执行状态，Prompt Cache 复用模型对输入前缀的计算结果。两者都与历史有关，但一个解决恢复问题，一个解决推理成本和延迟，不能互相替代。
前缀规则决定内容顺序
模型请求通常按工具定义、系统提示和消息历史排列。当前缀中任一部分发生变化，其后的缓存都无法继续复用：
| 变化位置 | 主要影响 |
|---|---|
| 工具定义或模型 | 工具、系统提示和消息前缀全部失效 |
| 系统提示 | 系统提示之后的消息前缀失效 |
| 追加消息 | 已有前缀保留，只计算新增部分 |
由此可以直接推出布局原则：固定工具与长期规则放前面，会话输入和临时材料放后面。
时间戳、随机标识和无序集合若被写入系统提示，会让内容每次都不同；动态增减工具则改变最靠前的部分。这些请求仍然能够正常返回，所以失效往往表现为成本和延迟上升，而不是功能错误。
确定性比“内容看起来相同”更重要
缓存匹配面对的是最终序列化结果。两个语义相同的工具列表，如果顺序不同、默认字段不同或 JSON 序列化不稳定，仍可能形成不同前缀。
我会保证：
- 工具按稳定键排序，参数结构使用确定性序列化；
- 系统提示不包含请求级动态信息；
- 会话中途不无理由切换模型或工具集合；
- 大块共享材料固定在稳定边界，用户输入继续追加在后面。
手动缓存断点只能声明“这一段值得缓存”，不能让变化的前缀自动变成相同内容。机制仍然受前缀一致性约束。
失效必须通过指标发现
缓存失效通常不会产生异常，因此需要观察：
- 缓存读取 Token 与输入 Token 的比例；
- 同类请求的首 Token 延迟；
- 工具集合、系统提示版本与命中率的对应关系；
- 发布前后单位任务的推理成本。
如果命中率突然下降，优先比较最终请求前缀，而不是只检查业务配置是否“看起来没改”。prompt_cache_key 一类参数也可能参与路由，而不改变前缀匹配本身；不能把路由键理解为任意内容的缓存主键。
我的选择：先稳定请求，再优化断点
我会先固定工具顺序、系统提示版本和序列化方式，再根据指标决定是否调整缓存断点或路由。这样能够把“内容变化”和“缓存策略变化”分开排查。
代价是动态工具面会受到限制，并需要维护请求版本。若任务本身很短、前缀复用率低，缓存治理可能得不偿失；只有长会话、共享前缀较大或调用频率较高时，才值得为稳定性投入额外工程成本。
下一篇讨论缓存之外的可靠性问题：Harness 如何把语义目标转换为可验证信号。