提示缓存正在从「省钱小技巧」变成大模型应用的基础设施，GPT-6 的这次更新是这一趋势的又一个注脚。

发生了什么

OpenAI 发布了一篇面向开发者的说明，介绍 GPT-6 在提示缓存（prompt caching）上的改进。按官方摘要，改动集中在四个方向：更高的缓存命中率、新增的诊断能力、显式的缓存断点（explicit breakpoints），以及用于降低延迟和成本的控制项。

需要说明的是，官方摘要没有给出具体的命中率数字、定价变化或延迟降幅，因此这些改进的实际幅度仍需开发者自行在真实负载上验证。

为什么重要

提示缓存解决的是一个非常具体的工程问题：在多轮对话、长系统提示、RAG 检索上下文和 Agent 循环中，请求的前缀往往高度重复。如果每次调用都重新计算这部分 token，既费钱又费时。缓存命中后，重复前缀可以复用已有计算结果，从而压低成本与首 token 延迟。

过去这类机制的主要痛点是「不可控」——开发者很难知道哪一段被缓存了、为什么没命中、该怎么调整提示结构。GPT-6 这次补上的三块拼图恰好对应这些痛点：

  • 显式断点：让开发者主动标记缓存边界，而不是依赖系统自动推断。这意味着提示的哪些部分值得复用，可以由工程侧决定。
  • 诊断能力：把缓存行为从黑盒变成可观测对象，便于定位命中率低的原因。
  • 控制项：在命中率、延迟、成本之间做取舍时提供调节手段。

换句话说，这更像是一次「可运维性」升级，而非单纯的性能数字提升。

影响与看点

对开发者而言，最直接的变化是提示工程的重心可能发生迁移。以往优化提示主要围绕措辞和结构，现在「如何组织前缀以便被缓存」会成为同等重要的设计约束——静态内容前置、动态内容后置、用断点显式切分，这些做法会逐渐成为默认实践。

对 Agent 与长上下文类应用，收益可能更明显。这类场景的请求前缀天然稳定且体积大，缓存命中率对单位任务成本的影响是乘数级的。诊断能力的加入，也让团队可以在 CI 或线上监控中把缓存命中率当作一个可跟踪的指标。

值得关注的还有竞争维度。提示缓存已是主流厂商的标配能力，差异正在从「有没有」转向「控不控得住」。谁能让开发者更精确地预测和控制缓存行为，谁就更容易被选为生产环境的底座。

一个独立判断：这次更新的价值不在宣传口径里的「更快更便宜」，而在于它把缓存从自动优化变成了可编程的工程接口。对认真做成本控制的团队来说，后者的长期意义更大。