Prompt Caching（提示缓存）

Prompt Caching（提示缓存） 是复用相同 prompt 前缀的模型计算结果，以降低长对话和 Agent Loop（智能体循环）推理成本的机制。它和 KV-cache 感知设计密切相关：缓存是否命中，不只取决于内容是否"差不多"，而取决于前缀是否精确一致。

在软件 Agent 中，prompt caching 是生产性能的核心杠杆之一，因为每次工具调用后都要把旧输入、模型输出、工具调用和工具观察一起送回模型。没有缓存，长 turn 会反复处理大量重复历史。

OpenAI 的 Prompt Engineering 指南也把缓存视为 prompt 组织问题：构造消息时，应尽量把多次请求都会复用的内容放在 prompt 开头，并放在请求 JSON 里靠前的参数中。这样 Responses API（响应 API）或 Chat Completions 的重复前缀更容易命中缓存。

精确前缀原则

缓存命中依赖 prompt 中的精确前缀匹配。因此高效 Agent harness 会尽量让新请求以前一次请求作为原样前缀，然后只在末尾追加新的 reasoning item、tool call、tool output 或用户消息。

实践原则：

静态内容放前面：系统指令、开发者指令、工具 schema、示例
变量内容放后面：用户消息、工具输出、当前环境变化
把代码化 prompt 的稳定部分放在 instructions / developer message 中，把每次变化的任务数据放在 input / user message 或后续上下文中
对工具列表、JSON 键顺序、序列化格式保持确定性
中途配置变化尽量追加新消息表达，而不是回头修改早期输入

Harness 中的前缀纪律

一次 Agent Loop（智能体循环）会反复重送指令、历史、工具定义和早期结果。OpenAI 对 Codex 与 ChatGPT Work 的工程说明因此把模型可见历史设计成仅追加（append-only）：新消息、工具结果和环境更新只加在末尾，避免向早期历史插入状态而破坏精确前缀。工具也以确定性顺序呈现；审批策略等运行时设置在执行时应用，而不是混进每个工具定义。这些都是提高命中率的实现手段，不是 API 的普遍语义要求。

缓存并不要求把所有内容都塞进前缀。应让 MCP 工具、插件和 skill 按需发现，并给单个工具输出设上限；OpenAI 的该 harness 默认把工具输出限制在 10,000 token，模型可按需请求不同限制。这样先减少无用上下文，再复用真正稳定的部分，能同时减轻 Context Rot（上下文腐烂）和重复 prefill 成本。

显式缓存边界

GPT-5.6为 prompt cache 增加了显式 cache breakpoint 与至少 30 分钟的缓存寿命。它让调用方可以在一段稳定、值得复用的输入之后明确切分缓存边界，而非完全依赖服务端对前缀的隐式识别。这个能力不改变精确前缀原则：断点之前的内容仍应稳定，断点之后才放更易变化的用户请求、工具观察和检索材料。

OpenAI 公布的 GPT-5.6 计费也说明缓存应作为架构决策而非微优化：cache write 按未缓存输入价的 1.25 倍计费，cache read 享受 90% 的输入折扣。对于只有一次调用的短 prompt，写入成本未必划算；对于会在 Agent Loop（智能体循环）中多次复用的长指令、工具 schema 和历史前缀，复用次数越高越能摊薄首次写入成本。

刷新后的官方指南把这套机制落成了具体参数：显式断点通过在受支持的内容块上设置 prompt_cache_breakpoint 声明；把 prompt_cache_options.mode 设为 explicit-only 后，未显式断点的请求不再写缓存，最后一个断点之后的内容按未缓存价计费且不产生写入费；单个请求最多四次缓存写入。缓存寿命由 prompt_cache_options.ttl 控制（取代旧的 prompt_cache_retention），复用会刷新寿命。注意缓存下限：GPT-5.6 起可缓存输入至少 1,024 token。另有一个常见陷阱——传入 prompt 的公共前缀并不总等于服务端实际识别的缓存前缀，静态内容（工具 schema、指令）之后应主动放一个显式断点，避免动态内容混入前缀。

GPT-6 的缓存升级：可观测、可诊断、可预热

2026 年 9 月的《Better prompt caching for GPT-6》把 GPT-5.6 代的缓存机制升级成一套围绕 GPT-6 Astra 家族的完整工作流：更高默认命中率、30 分钟窗口内复用共享前缀即可享受折扣（cached input 最高 90% off），并新增监控、诊断和预热三类工具。2026-09-22 的 GPT-6 Sol 与 GPT-6 Luna 发布中，这套缓存经济学被直接折算成了价签：API 列表价定为 GPT-5.6 促销价的一半，且是默认价而非促销价——缓存改进从省钱技巧变成了新档位的定价基础。

可观测：新增 Prompt Caching Dashboard 展示输入中被缓存服务的比例——命中率随时间的变化曲线、cached 与 uncached token 的输入构成对比图，用于发现命中率下滑、评估应用改动对缓存的影响。

可诊断：遇到意外的 cache miss 时，用 prompt caching diagnostics tool 把这个请求与近期响应对比，定位是模型、工具、设置还是输入的变化阻止了复用，并给出受影响 token 的估计值。响应里的 prompt_cache_diagnostics 对象形如：

{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

推理力度可中途调整而不破缓存：GPT-6 上可以在两次响应之间改变 reasoning effort——追加一个 configuration_update item 即可，保持请求级设置不变。难任务调高、例行追问调低，而可复用上下文前缀不受影响。

工具与指令的变化走 append-only：Agent 的工具需求变化时，保留工具定义、schema 和顺序不变，用 allowed_tools 限定本次实际可调用的工具，或需要时把 tool_choice 设为 none，而不是删掉定义；新增指令用新的 developer message 追加在上下文末尾去覆盖旧指令。这与 Codex harness 的仅追加历史纪律同构，只是现在被官方上升为通用的 API 用法建议（见 Agent Tool Design（Agent 工具设计））。

预热（prewarm）：GPT-5.6 起支持 prompt_cache_options.prewarm: true，在应用启动时、用户提问之前就把共享指令、工具定义或参考资料写入缓存且不生成输出，把处理挪出用户等待时间；预热带写入的 token 按 cache write 价计费。后续请求用相同前缀、省略 prewarm 即可命中。此外，prompt_cache_key 除路由粘性外还用于把不同客户的缓存记账隔离，并防止跨用户的缓存命中探测。

Codex 的缓存风险

OpenAI 介绍 Codex CLI harness 的工程文章列出几类会破坏缓存的变化：

会话中途改变可用工具列表
改变目标模型，导致模型特定 instructions 变化
改变沙箱配置、审批模式或当前工作目录
Model Context Protocol（模型上下文协议）服务器动态改变工具列表，或工具枚举顺序不稳定

Codex 的处理策略是：如果 sandbox、approval mode 或 cwd 在会话中变化，尽量向 input 末尾追加一条新的 developer/user message 来表达新状态，而不是修改原始权限或环境消息。这样可以保留旧 prompt 作为新 prompt 的前缀。

会话路由也会影响命中率

精确前缀一致是缓存复用的内容条件，但分布式推理服务还存在路由条件：即使两次请求的前缀完全一致，后一次若被分配到没有对应缓存的服务器，也可能重新处理完整输入。

SpaceXAI 因此建议调用 Grok 4.5时，在 Responses API 设置 prompt_cache_key，或在 Chat Completions 请求中发送 x-grok-conv-id。这些会话标识用于把同一对话尽量路由到相同服务器，使缓存命中更可靠。它们不是缓存内容本身，也不取消精确前缀要求；工程上需要同时保证“前缀稳定”和“会话粘性”。

与上下文压缩的关系

Prompt caching 解决的是"重复历史如何少算一遍"；上下文压缩解决的是"历史太长放不进窗口怎么办"。二者互补但目标不同。

一旦触发 compaction，旧输入会被较小的摘要或特殊压缩项目替换，缓存前缀结构也会改变。因此优秀 harness 会先尽量利用缓存延长有效上下文寿命，再在超过阈值时压缩。

压缩还有一个容易被忽略的代价：它改变了过去的上下文，会使模型的 KV 缓存（存着此前已处理 token 的注意力键值）失效，重建需要一次新的 prefill，从而引入延迟。OpenAI 在 GPT-Live 的语音系统中为此把压缩做成一次"受管切换"——原模型实例继续对话的同时，系统在另一个预热实例上压缩上下文、用新上下文 prefill，就绪后切过去，媒体流不中断。这把压缩从"就地改写历史"变成"在旁准备好的替换实例上重做 prefill 再切过去"，既绕开了 KV 缓存失效带来的实时延迟，也使长会话可以在必要时反复压缩。

与 TTFT 的关系

Prompt caching 优化的是长上下文重复推理成本；time-to-first-token（TTFT）优化的是用户感知到第一批输出前的等待时间。两者都会被 harness 结构影响，但瓶颈不同。

Anthropic 在 Claude Managed Agents 中把 harness 从 sandbox 容器里移出，使推理可以在 sandbox provision 之前开始；只有任务真的需要文件系统或命令执行时，harness 才通过工具调用初始化 sandbox。该架构让 p50 TTFT 下降约 60%，p95 下降超过 90%。这说明性能优化不只发生在模型调用参数里，也发生在“哪些基础设施必须阻塞第一轮推理”的 harness 边界上。