GPT-6 Astra 提示缓存指南：如何降低重复上下文成本
了解GPT-6 Astra提示缓存的工作原理，如何构建可重用的前缀、设置缓存断点、测量命中率以及避免代价高昂的缓存未命中。
大型智能体提示通常重复相同的系统策略、工具定义、产品文档、示例和对话历史。重新发送这些内容有时不可避免；但为完全相同的前缀支付完整的输入成本和延迟则没有必要。GPT-6 Astra 在响应 API 中支持提示缓存，以便重复的前缀可以被复用。
缓存是一种优化手段，而非记忆功能。它不会让模型在多次请求之间记住某个客户，也不会改变模型所看到的内容。请求仍然需要提供相关的输入。区别在于，符合条件的相同前缀可以从缓存中以更低的缓存输入费率提供服务。
GPT-6 Astra 缓存的内容
缓存是基于前缀的。当后续请求的开头内容与先前提示匹配时，OpenAI可以复用提示起始部分的令牌。一个有用的理解模型是：将文档中稳定的章节放在前面，而与特定请求相关的附录放在末尾。
把这些放在前面：
- 稳定的开发者说明；
- 稳定顺序中的工具模式；
- 跨请求使用的长参考文档；
- 规范示例与输出规则。
把这些放在末尾附近：
- 当前用户消息；
- 时间戳、请求ID和临时状态；
- 每次调用都会变化的检索段落；
- 不共享的逐用户偏好。
在顶部附近插入一个时间戳可能会使其后的所有内容失效。同样，从无序映射生成工具数组可能会产生语义相同但字节不同的前缀。请以确定性方式构建提示词。
隐式与显式缓存
GPT-5.6及后续版本暴露了prompt_cache_options。在隐式模式下，服务会自动识别可复用的断点。这是最简单的起点，适用于提示词包含一个大型稳定前缀的情况。
import OpenAI from "openai";
const client = new OpenAI();
= await client.responses.create({
model: "gpt-6-astra",
prompt_cache_key: "support-agent:v4",
prompt_cache_options: { mode: "implicit", ttl: "30m" },
input: [
{ role: "developer", content: "稳定的政策和操作说明..." },
{ role: "user", content: "为什么我的发票被重复了？" }
]
});
当前文档记录的TTL值为30m，30分钟是默认值。请勿基于未记录的时长进行设计。OpenAI还将旧的prompt_cache_retention字段标记为已弃用。
显式模式赋予应用更多控制权。你可以在需要保留的边界处添加 prompt_cache_breakpoint 内容项。当提示词由多个稳定模块后接易变内容组成时，此功能尤为实用。每个请求最多可写入四个断点，服务最多考虑最近80个断点。断点并非越多越好：每次写入都有成本，且碎片化的前缀可能更难以推理。
一种实用的前缀架构
对于生产级代理，使用四层架构：
1. 身份与安全
将持久角色、安全约束和响应合同放在首位。有意对此模块进行版本控制。策略编辑应创建新的缓存键，而不是静默混合两个版本的测量结果。
2. 工具定义
工具模式通常较大且重复。请保持名称、描述、属性和顺序的稳定。尽可能移除未使用的工具；这既能减少未缓存和已缓存的上下文，也能降低工具选择的歧义。
3. 共享知识
添加持久性手册、分类法、风格指南或产品文档。如果知识频繁变化，文件搜索可能比将其全部嵌入每个提示中更好。缓存稳定的操作知识；检索变化的事实。
4. 动态请求状态
追加用户输入、当前记录、实时搜索结果和临时状态。此位置保护可复用的前缀免受常规更改的影响。
在创意工作流中，稳定层可能包含动画制作规则和工作室风格，而动态尾部则包含当前场景。像 Elser AI 这样的平台可以将相同原则应用于重复的故事圣经或角色一致性上下文，而不暗示缓存本身就能创造一致性。
衡量节省而非假设节省
检查 usage.input_tokens_details.cached_tokens 和 cache_write_tokens。高缓存令牌数表明部分前缀被重复使用。缓存写入令牌则揭示了创建或刷新条目的成本。
对于GPT-6 Astra，在验证日期发布的模型定价中，缓存输入低于正常输入，而缓存写入高于正常输入。这就产生了一个盈亏平衡问题：重复使用的前缀可以节省成本；而仅写入一次且从未重复使用的前缀则可能增加成本。定价会发生变化，因此请根据当前模型页面进行计算，而不是将固定数字硬编码到规划电子表格中。
至少追踪：
- 按提示版本划分的缓存命中率；
- 缓存、写入和总输入令牌数；
- p50 和 p95 首次令牌生成时间；
- 每完成一项任务的成本，而不仅仅是每次请求的成本；
- 由发布引起的缓存未命中。
仅按模型分组的仪表盘会隐藏未命中的原因。请在您自己的遥测中包含缓存键或提示版本维度，但切勿将个人数据或机密信息放入缓存键中。
七种常见的缓存未命中原因
动态内容出现过早
将日期、用户ID和检索到的材料移至可重用内容之后。
工具模式变更顺序
在应用构建步骤中确定性排序工具和模式属性。
提示词“等价”但不完全相同
空白、示例或序列化方式可能有所不同。请从版本化的构件生成共享块，而非临时拼接的字符串。
前缀太短
最小可缓存长度因模型而异。非常短的提示可能不会受益。请通过使用数据确认。
压缩更改了前缀
压缩有助于容纳长对话，但会产生不同的上下文表示。请注意压缩后复用模式的变化，并在里程碑边界附近进行测量。
低价值断点过多
断点应对应于有意义的可复用层。允许的四次写入是上限，而非目标。
缓存键过于宽泛或过于狭窄
每个不相关的工作流使用一个键会导致分组薄弱；每个请求使用唯一键会阻止复用。建议使用语义键，例如 legal-review:v3:us。
安全发布计划
从一个高流量工作流开始，启用隐式模式。稳定提示构建，记录令牌详情，并比较两周的成本和延迟。如果提示具有多个可复用层或频繁的动态尾部，则考虑显式断点。在评估节省的同时也要评估质量：激进地移除上下文并非缓存，且可能降低回答质量。
仅缓存您已被允许发送到API的内容。缓存不能替代数据分类、租户隔离、访问控制或保留决策。只要工具能够即时获取机密信息，就应避免在提示中包含这些内容。
常见问题解答
提示缓存会降低输出令牌的成本吗？
不适用。它适用于符合条件的重复输入。输出正常生成并按输出费率计费。
previous_response_id 是否让之前的轮次免费？
不。OpenAI 指出，响应链中较早的输入令牌仍按输入计费。提示缓存可能会降低符合条件的重复前缀成本，但对话链和缓存是独立的机制。
我应该缓存检索到的搜索结果吗？
只有当它们稳定且真正被复用时。实时结果通常属于动态尾部。对于受控语料库，文件搜索可以避免在每个提示中嵌入整个集合。
我能依赖缓存命中吗？
将缓存视为一种机会性优化。您的应用程序在未命中时必须保持正确。
结论
最高价值的GPT-6 Astra缓存策略是架构性的：稳定的指令和工具优先，易变状态最后，确定性序列化，审慎的版本控制，以及通过令牌细节进行测量。从隐式缓存开始，仅在数据支持时添加显式断点，并优化每个成功任务的成本，而不是追求单一的
