GPT-6 Astra 提示词缓存：请求为何未命中缓存

初步排查提示词缓存未命中

不要因为后面某次调用看起来更快，就把问题标为“已修复”。网络状况、排队、输出长度和工具执行同样会影响总耗时。

修改提示词前先读用量记录

保存一份安全的诊断记录，标明请求模板、模型、工具集版本和对话历史版本。不要把密钥或私密用户内容写入没有访问限制的日志。哈希或受控比较可以识别变化，而不必暴露每一个值。

同时检查 usage.input_tokens_details.cached_tokens、cache_write_tokens 和总 input_tokens。已缓存 token 表示复用的输入；缓存写入 token 则对应另一项计费组成。第一次请求的缓存 token 为零，本身不代表缺陷：在判断未命中之前，应与后续符合复用条件的请求比较。绝不要只凭响应很快就推断缓存已复用。

然后比较某个已知请求与紧接着那个预期能够受益的请求，找出第一处意外差异。不要一开始就把所有指令重新排列，因为那只会创建一个新实验，却无法解释原先为何失败。

常见的应用层排查对象包括靠近开头且不断变化的时间戳、每次以不同顺序组装的工具列表、被重写的摘要，以及修改过的指令块。这些只是需要检查的项目，不代表它们都曾在你的账户中造成缓存未命中。

相同的问题不等于相同的前缀

官方提示词缓存指南说明，该机制会为匹配的提示词前缀复用中间键值状态。它不是答案缓存：后续请求仍有新输入需要处理，也仍需要生成响应。

这解释了为什么两个不同问题可能从共同的开头受益，而两个几乎一样的问题却可能无法复用你预期的部分。变化内容之前放了什么，才是关键。

诊断时，可以把请求视为由应用组装、有版本记录的文档。指令、工具和历史记录都属于这份文档。只看最后一条用户消息，会遗漏大量相关证据。

开展受控的前缀实验

受控调查应从一个基准请求和一个范围明确的变体开始。保持任务、输出要求和工具可用性稳定。在解释用量之前，先记录预期前缀是否相同。

接着测试一个可能引起变化的因素。如果稳定部分中的某个动态字段并非必需，应先确认移动它不会改变任务含义，再进行调整。不要仅为了改善缓存指标就移除相关上下文。

使用足够的案例重复检查，区分可复现的规律与孤立的观察。在实际执行实验之前，应将更改描述为拟议的修复。

这种方法也便于回滚。如果输出质量下降，你可以定位到具体的请求布局改动，而不用理清多项同时实施的优化。

使用包含三次请求的记录表：A 建立基准，B 用新条目重复相同的稳定内容，C 只修改一个可疑字段。分别记录请求版本、时间间隔、缓存 token 数和输出验收情况。这是实验设计，不是 API 输出示例；下表没有编造命中率。

假设某个团队依据固定的风格指南和 schema 评估拟议的道具描述。指南和 schema 保持稳定，而每个道具的数据会变化。这是适合研究上下文复用的场景。

再假设应用每次调用都会在指南前插入新的运行标识。团队应在归因于模型之前，先检查最终请求如何组装。同时还应确认，任何重组都让道具数据与指令保持明确分离。

为了编写道具描述简报，可以浏览 RPG 游戏，记录自己的观察，看看物品栏标签如何表达用途和约束。这些笔记可以帮助制定风格指南；不要复制游戏文案，也不要把链接中的游戏说成 Astra 缓存的应用示例。

推理设置的变化需要单独检查

推理文档说明了 GPT-6 Astra 的一种配置更新机制，可在响应之间改变推理投入，同时保留原始提示词前缀。其支持条件包括标准单代理模式。

不要假定在请求的任意位置重写配置都会产生相同效果。应遵循所用集成对应的文档机制，并检查实际行为。

当对话在复杂分析与常规追加工作之间切换时，这一点尤其重要。目标不是永远冻结所有设置，而是有意识地调整，同时避免意外重建无关上下文。

区分缓存节省与任务总成本

GPT-6 Astra 模型页面分别列出输入、缓存输入和输出的价格。实施时必须核对当时的价格；本文有意不承诺固定比例的费用降低。

有用的评估应着眼于最终合格的任务结果，而不只是某个打折的组成部分。如果某项优化导致输出变长、重试增加或响应格式损坏，那么即便部分输入得到复用，最终工作流也可能更差。

应并列报告缓存行为和任务质量。至少同时保存验收结果、总耗时和报告用量。只显示命中率上升的仪表板，可能掩盖用户体验的下降。

风格指南评估也需要面向玩家的质量检查：通过验收的标签是否帮助用户理解操作？可以浏览 Elseland AI 上的浏览器游戏作为交互参考，再编写自己的测试案例。该游戏集是游玩的地方，不是缓存性能或所用模型来源的证据。

先保证正确性，再优化复用

有利于缓存的请求，不一定就是好的请求。如果工具定义因应用变化而需要更新，应保证其准确性；如果用户修正了要求，应保留这项修正。复用过时上下文并不是有价值的优化。

调整请求布局前，应设置验收门槛：必需字段必须保留，输出必须符合当前任务，过时指令不得覆盖最新要求。

只有当观察到的效率提升经得起验收检查时，才保留请求布局改动。如果缓存指标改善了，但输出仍在遵循过时指令，就应回滚。目标是在减少重复输入处理的同时得到正确结果，而不是不惜代价追求高命中率。