OpenAI改进GPT-6提示词缓存

OpenAI在9月22日发布的GPT-6提示词缓存更新，把长上下文Agent的账本拆成了可观测项目。官方把更高默认命中率、30分钟共享前缀复用、最高90% cached input token折扣、Prompt Caching Dashboard和诊断工具放在同一篇公告里，说明缓存不再只是计费脚注。

账本里的第一项是读取折扣：符合条件的共享前缀在窗口内复用时，可以让cached input tokens享受最高90%折扣。第二项是可观测性：开发者可以用仪表盘看命中率和cached/uncached token构成；诊断工具可以比较模型、工具、设置或输入变化造成的cache miss。OpenAI Developers同日在X上用更短版本重述了这组更新。

适用范围决定这组数字能不能用于成本预测。90%只覆盖cached input tokens，不覆盖整体请求或输出token。GitHub Copilot案例里的“超过50%”指过去几个月中，需要fresh processing的prompt token占比相对旧基线下降超过一半；Strawberry Browser的20%成本下降则来自客户自报案例。

长期保留系统提示、工具schema、仓库上下文和多轮任务历史的Agent产品最先受影响。对这些团队来说，缓存命中率会和延迟、token预算、工具加载策略一起进入架构评审。

这次新增的不是缓存概念

Prompt caching在OpenAI平台上不是新概念。OpenAI文档早已把它解释为复用请求开头相同前缀的KV状态：模型不需要重新处理已经见过的稳定前缀，但仍会处理新增输入并生成新的输出。文档也明确说，缓存保存的是key-value tensors，不是原始tokens。

9月22日的news peg在于OpenAI把GPT-6的缓存能力向产品化推进了一步。官方文章的标题是“Better prompt caching for GPT-6”，副标题强调更高cache hit rates以及让persistent agents更快、更便宜的新工具。采集阶段拿到的正文显示，OpenAI新增了30分钟窗口内eligible shared prefixes的缓存折扣，并把Dashboard和diagnostics作为开发者工具重点推出。

这组变化对Agent尤其敏感。一个编码Agent常常在每轮请求里带上固定系统提示、仓库规则、工具定义、历史消息和最近的文件上下文。只要前缀稳定，后续回合就可能减少重复处理。反过来，若每轮都重写早期消息、改变工具顺序或把动态内容塞到前缀开头，表面上上下文相似，底层也可能无法命中。

数字口径要分开看

OpenAI这次公告和平台文档里至少有五类数字，含义不同。最容易误写的是把“cached input tokens折扣”说成“总成本下降”。实际账单要同时看普通输入、缓存读取、缓存写入和输出token。

指标	原文或文档口径	中文应写成	风险边界
最高折扣	up to 90% on cached input tokens	cached input tokens最高享90%折扣	整体请求成本下降90%
复用窗口	eligible shared prefixes reused within a 30-minute window	共享前缀在30分钟窗口内复用	缓存永久有效
读取费率	cache read charge is 0.1x	缓存读取按未缓存输入的0.1倍计	所有输入都按0.1倍计
写入费率	cache writes cost 1.25x	写缓存按未缓存输入的1.25倍计	写缓存免费
Copilot案例	reduced by more than 50% the share of prompt tokens requiring fresh processing	fresh processing token占比相对旧基线降超50%	缓存命中率再次提高50%
Strawberry案例	reducing costs by 20%	客户称成本下降20%	OpenAI保证所有客户省20%

文档里的经济模型也值得保留。对GPT-5.6及以后模型，一次写入加一次完整复用的成本是1.35倍普通输入处理成本，而两次都不缓存是2倍。如果一次写入后复用九次，文档例子给出的合计是2.15倍，对照不缓存的10倍。这解释了为什么高频复用场景会在缓存上得到更明确收益。

这个模型也说明反面风险。缓存写入本身不是免费动作，短前缀、低复用、频繁变化的请求可能得不到明显节省。文档还提醒，cached input tokens仍计入tokens-per-minute限额，缓存也不会让相同请求保证输出一致。它降低的是重复前缀处理成本和响应前等待时间，不是模型行为确定性。

工程变化在前缀稳定性

Prompt caching的核心条件是“整个渲染前缀匹配”。OpenAI文档列出的渲染上下文包括OpenAI提供的隐藏指令、developer messages、tool definitions、用户消息、工具输出以及图片、音频等输入。只要相关设置或前缀中的内容变化，变化点之后就无法复用旧缓存。

这就是为什么OpenAI在公告里强调工具schema和工具顺序。多工具Agent通常会根据任务动态加载工具，若每轮请求都重新排列、改名或改schema，缓存前缀就会被打散。文档中的工具页说明，开发者可以通过tools参数、function calling、tool search和remote MCP等方式扩展模型能力；在缓存语境下，工具定义本身也成了成本结构的一部分。

OpenAI还提到allowed_tools和tool_choice这类控制项。采集摘要保留的关键措辞是“Both controls now preserve earlier context for cache reuse”。中文应理解为：控制可调用工具时，尽量保留早期上下文用于缓存复用。它不是说随意改变工具列表也一定命中，而是把“工具可见性”和“工具定义稳定性”分开处理。

另一个变化是reasoning effort。OpenAI文章强调GPT-6可以在不破坏缓存的情况下调整reasoning effort；平台文档进一步说明，支持模型可通过追加configuration_update输入项改变推理努力，同时保持顶层reasoning.effort不变。若直接改顶层设置，可能重写模型侧隐藏指令，从而破坏前缀。

诊断工具改变团队分工

此前很多团队处理缓存，依靠经验和账单回看：把系统提示放前面，把用户变量放后面，尽量不要改工具schema，然后等账单下降。OpenAI这次把Prompt Caching Dashboard和Prompt Cache Diagnostics推出，意味着缓存优化开始有更明确的观测面。

Dashboard的价值是把命中率从“猜测”变成可监控指标。团队可以按用户、workspace、日期或产品线聚合cached_tokens、cache_write_tokens、普通input tokens和延迟，再计算真实输入成本。若某个Agent版本上线后缓存命中率下降，平台团队能把它当成回归，而不是等月底账单才发现问题。

Diagnostics的价值在于定位破坏复用的具体差异。官方摘要说它可以比较模型、工具、设置或输入变化造成的cache miss。对工程团队来说，这相当于给长上下文请求提供diff视角：究竟是模型切换、工具顺序、developer message变了，还是compaction改写了历史。

GitHub Copilot和Strawberry Browser两个案例说明OpenAI想讲的不是单次请求节省。Copilot引用的是数十亿请求上的fresh processing token占比下降，Strawberry Browser提到dashboard和diagnostics让命中率提高几个百分点并带来20%成本降低。两者都指向持续运营后的指标优化，而不是一次改prompt就得到固定折扣。

对开发者的设计含义

最直接的策略是把稳定内容尽量前置。developer instructions、共享参考材料、工具定义和较稳定的会话历史应该靠前，时间戳、用户私有变量、一次性输入和动态检索结果应尽量后置。这样做不是为了美观，而是为了让最长可复用前缀更稳定。

第二个策略是少重写历史，多追加新消息。文档明确说，preserve conversation history通常比只缓存初始说明更省输入token。摘要、compaction或上下文截断会改变前缀，可能让后续请求少复用上一轮缓存。减少上下文长度和保持缓存命中之间，需要用真实账单数据权衡。

第三个策略是明确缓存断点。GPT-5.6及以后模型支持implicit和explicit caching。隐式模式方便多轮会话，但如果稳定前缀后面跟着动态用户内容，完整请求被写入缓存后，下一次动态内容变化可能无法复用较短的稳定前缀。显式断点可以放在稳定内容末尾，让变化后缀不进入不必要的cache write。

第四个策略是谨慎预热。文档说明，prompt_cache_options.prewarm可以在正式请求前准备已知上下文，以降低后续请求的首token等待时间。但预热写入按标准cache-write费率计费。对客服、IDE和浏览器Agent这类即将发生高频交互的产品，预热可能有价值；对大量一次性会话，它可能只是提前花钱。

适合立即检查的缓存账本

这次公告对平台团队的操作建议可以压成一张账本。它不是一次性迁移清单，而是每次Agent版本发布后都应该回看的指标组。

检查项	看什么	为什么重要
shared prefix长度	是否超过1024 visible tokens	太短的稳定前缀无法进入缓存收益区
cached token占比	cached_tokens / input_tokens	衡量真实复用，而不是只看总tokens
cache write占比	cache_write_tokens / input_tokens	写入过多可能吞掉读取折扣收益
工具schema稳定性	名称、顺序、参数是否频繁变化	工具定义属于渲染前缀，会影响命中
reasoning effort变更	是否用configuration update	直接改顶层设置可能破坏前缀
compaction时机	摘要是否改写早期上下文	省tokens和丢缓存需要一起算
区域边界	是否跨组织或区域处理	缓存不跨组织，也不跨区域复用

这张表也解释了为什么这条新闻值得单独成深度页。它不是OpenAI又给了一个折扣按钮，而是把长上下文Agent的成本结构拆开：稳定前缀、变化后缀、工具定义、推理设置、路由位置和可观测性，都会影响最终账单。

接下来真正要验证什么

OpenAI自己的工具要先经受团队级使用。Prompt Caching Dashboard能否把缓存命中率按项目、客户、用户或workspace切开，决定它能不能用于企业成本归因。若只能给全局平均数，它对大型团队的价值会打折。

诊断粒度会决定它是不是调试基础设施。复杂Agent里的cache miss常常不是一个原因造成的，可能同时来自模型切换、工具schema改动、消息重写、compaction和区域路由。诊断工具如果能定位到具体断点，会进入发布回归流程；如果只能给粗粒度提示，它仍需要团队自建日志补齐。

客户案例需要看可复现性。GitHub Copilot的“fresh processing token占比下降超过50%”非常有分量，因为它来自数十亿请求规模。但这个数字依赖Copilot自身会话结构、工具链和流量密度。其他编码Agent、浏览器Agent或企业知识助手不一定能得到同样比例。

产品形态会改变收益曲线。30分钟TTL天然偏向高频、多轮、并发会话。IDE、客服和浏览器自动化可能受益明显；低频审批、长间隔研究任务和跨时区协作则需要看缓存是否常在下一轮前失效。若企业工作流间隔超过窗口，最优策略可能不是预热，而是减少稳定前缀本身的体积。

最后要看的是OpenAI是否把缓存诊断接入更完整的Agent observability。对开发者来说，最终问题不是“有没有缓存”，而是“哪一次产品变更让缓存消失”。如果这层可观测性成熟，提示词缓存会从平台优惠变成Agent工程的标准SLO之一。