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 键顺序、序列化格式保持确定性
中途配置变化尽量追加新消息表达，而不是回头修改早期输入

显式缓存边界

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

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

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 会先尽量利用缓存延长有效上下文寿命，再在超过阈值时压缩。

与 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 边界上。