事件概述

OpenAI 于 2026 年 9 月 22 日发布产品更新，宣布随 GPT-6 系列一同推出改进后的提示词缓存（prompt caching）系统。官方给出的核心变化有三类：

一是默认缓存命中率提升，对在 30 分钟窗口内被复用的「合格共享前缀」给予缓存折扣；二是新增可观测与诊断能力，包括 Prompt Caching Dashboard 和提示词缓存诊断工具；三是提供更细粒度的控制手段，例如显式缓存断点、在不破坏缓存的前提下调整推理强度、以及缓存预热。

OpenAI 在文中给出的背景是：GPT-6 被用于支撑「持久化 Agent」，这些 Agent 需要在复杂任务上连续工作数小时，例如重构代码库、产出经过充分调研的文档和演示稿。这类应用会发出一连串相互叠加的 API 请求，往往反复携带相同的指令、工具定义和历史上下文。缓存这部分共享上下文即可复用计算，从而降低响应时间。原文提到，缓存输入 token 的折扣最高可达 90%。

关键技术点

1. 默认更高的命中率与 30 分钟复用窗口

原文表示，GPT-6 系列随附的新缓存系统「默认提供更高的缓存命中率」，并对在 30 分钟窗口内复用的合格共享前缀给予缓存折扣。需要注意的是，原文只说明了窗口长度与「合格前缀」这一限定，具体判定规则（例如最小前缀长度、哈希匹配的精确条件）原文未说明。

2. Prompt Caching Dashboard

新上线的 Prompt Caching Dashboard 用于展示应用输入中有多少来自缓存。开发者可以：

  • 跟踪随时间变化的命中率；
  • 通过输入构成图（input composition chart）对比已缓存与未缓存的 token。

官方称这些视图有助于发现命中率下滑，并评估应用改动对缓存表现的影响。

3. 缓存未命中诊断工具

当出现意外未命中时，可以使用提示词缓存诊断工具，把一次请求与最近一次响应进行对比，找出导致无法复用的变化点——原文列出的可能原因包括模型、工具、设置或输入的变更。工具还会给出「受影响 token 的估算数量」，帮助评估影响规模。

原文给出的诊断输出示例为：

1
2
3
4
5
6
7
8
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

4. 显式缓存断点

显式缓存断点（explicit cache breakpoints）允许开发者自行选择哪些提示词前缀需要复用。官方指向了更新后的提示词缓存指南，其中说明了断点的用法、缓存前缀保持合格状态的时长，以及工具与输入变更如何影响复用。指南的具体内容原文未展开。

5. 调整推理强度而不破坏缓存

在 GPT-6 模型上，开发者现在可以在多次响应之间改变 reasoning effort 而不破坏缓存：通过追加一个 configuration_update（同时保持请求级 reasoning effort 不变），即可在困难任务上提高强度、在常规追问上降低强度，同时保留可复用的上下文。

6. 工具与指令变化时保住缓存

OpenAI 给出的实践建议是：当 Agent 的工具使用需求发生变化时，尽量保持工具定义、schema 与顺序稳定，让更早的上下文仍然可复用。具体做法包括：

  • 用 allowed_tools 只让相关工具可调用；
  • 在不需要工具时把 tool_choice 设为 none，而不是删除工具定义；
  • 使用新的 developer messages 把新指令追加到上下文靠后的位置，用来覆盖较早的指令。

7. 缓存预热

Prewarming 允许提前准备已知上下文，使请求真正到达时模型能更快开始响应。原文举的例子是：应用可以在启动阶段、用户提出第一个问题之前，预热共享指令、工具定义或参考资料，从而把这部分处理移出用户的等待时间。

OpenAI 强调，这些控制项是建立在引擎默认表现之上的可选能力。

早期用户反馈

原文收录了四段一手反馈，涉及 GitHub Copilot、Manus、Strawberry Browser 以及一家被列为 Wordsmith 的企业：

  • GitHub Copilot（首席产品官 Mario Rodriguez）：称提示词缓存对 Copilot 大规模提供快速体验至关重要。过去几个月相对此前基线，在数十亿次对 OpenAI 模型的请求中，需要全新处理的提示词 token 占比下降了 50% 以上，带来了更高效的推理栈和更快的首响应时间。
  • 一位 CTO（Arian Hanifi）：称诊断工具与 Dashboard 帮助把缓存命中率提升了几个百分点、成本降低 20%；现在缓存意外中断时会收到告警，并用 Codex agents 定位根因。显式断点让他们能缓存稳定上下文、把频繁变化的内容放在提示词末尾，从而使「为后台任务分叉会话、同时复用几乎全部共享上下文」在经济上可行。该反馈对应的公司名称，原文的署名与公司列表存在对应关系不明确之处，此处不作认定。
  • Manus（Agent 团队负责人 Bin Fan）：与 OpenAI 工程团队一起优化了缓存断点位置，将显式缓存与自动缓存结合，并用真实请求定位意外未命中。不到一周，其 OpenAI 模型缓存命中率从约 85% 提升到稳定高于 90%，进一步降低了生产环境推理成本。
  • Strawberry Browser（AI 工程师 Eugene Mikhantyev）：把会话 Agent 迁移到显式缓存断点，不到一周评测中的缓存命中率从 83% 升到 91%；同等负载下缓存写入下降约三分之二，推理成本下降 36%。

对数据科学与 AI Agent 落地的意义

第一，缓存在 Agent 场景里已经从「优化项」变成「成本结构本身」。 原文中的数字很说明问题：Manus 命中率从约 85% 提到 90% 以上、Strawberry Browser 从 83% 提到 91%，对应的是缓存写入减少约三分之二、推理成本下降 36%。对长时间运行的 Agent 来说，上下文在每个回合都被重复携带，命中率哪怕几个百分点的变化，都会在成千上万次调用上放大成可观的账单差异。

第二，可观测性补齐了缓存调优的闭环。 在此之前，缓存未命中往往是隐性的——账单变贵了，但不知道是哪一层变了。Dashboard 解决「有没有变差」，诊断工具解决「为什么变差」，并且直接指出是模型、工具、设置还是输入发生了变化，还给出受影响 token 的估算量。这实际上把缓存调优从凭经验猜测变成了可以定位、可以度量、可以回归验证的工程流程。

第三，「不改工具定义，而是改工具可见性」是一条很重要的工程约束。 用 allowed_tools 收窄可调用范围、用 tool_choice: none 临时禁用工具，而不是删掉定义再重新加回来，这个细节直接决定了前缀能否复用。类似地，把新指令追加到上下文末尾而不是插到开头，也是同一个思路。这类约束在设计 Agent 的 prompt 编排层时就应该被纳入考虑，而不是等到成本超支再回头重构。

第四，缓存的稳定性反过来约束了 Agent 的架构设计。 一个频繁动态拼装 system prompt、每次调用都重新排序工具列表、按需增删工具的实现，会持续制造未命中。也就是说，缓存友好度正在成为 Agent 框架设计的一个新的评价维度。

我的技术点评

这次更新的技术含量，其实不在「缓存」本身——前缀缓存复用是业界已经做了几年的东西——而在于 OpenAI 把它从一个黑盒性能特性推向了一个可运维的工程接口。三类改动里，我觉得价值排序是：诊断能力 > 显式断点 > 默认命中率提升。

理由是这样：默认命中率的提升对开发者来说是白拿的，但它不可控；显式断点把控制权交出来，但前提是你知道该在哪里下断点；而诊断工具解决的是「你根本不知道断点下错了」这个问题。原文那个 tools_changed 的示例输出非常典型——工具定义一变，5629 个本可复用的 token 全部作废，而这种失效在传统日志里几乎是不可见的。把这类信息暴露出来，才是真正降低调试成本的部分。

configuration_update 这个设计也值得一提。过去「调整推理强度」和「保持前缀缓存」在直觉上是冲突的：强度属于请求级配置，一改就等于换了请求形态。现在的做法是把强度变更表达成追加到上下文里的一段配置更新，请求级参数保持不变，缓存因此不受影响。这是一个很聪明的接口设计——把「变更」从元数据层搬到了内容