Prompt-Cache
一句话定义
Prompt Cache（提示词缓存）缓存的不是”答案”，而是稳定前缀的处理结果——如果两次请求前半段几乎一样，服务端就不必每次都从头处理那一大段相同内容，从而显著降低重复请求的输入成本和延迟。
摘要
Prompt Cache 是 AI Coding Agent 一切上下文优化的基础（见 Token成本控制）。很多人第一次听到缓存会以为它缓存的是回答，其实更接近的理解是：缓存稳定前缀的处理结果。最容易被缓存的内容通常是 System Prompt、Tool/MCP 定义、Skill 定义、长文档背景、稳定的 few-shot 前缀。这也是为什么官方文档总强调”静态内容放前面，动态内容放后面”——缓存命中的对象通常是前缀，而不是整段任意位置的拼图。Anthropic 与 OpenAI 都提到，长前缀命中缓存后，输入成本和延迟都可能显著下降。
详情
核心机制 / 工作原理
原理可以粗略理解成：
固定前缀 → 缓存命中 → 不用每次都从头处理
请求结构上把内容分三层：固定前缀（System Prompt、Skill 定义、Tool/MCP 定义、稳定背景文档）、半固定上下文（项目说明、Repo Map、Memory、长期约束）、动态上下文（聊天历史、代码片段、检索结果、工具返回、本轮新问题）。把静态内容前置、变化内容后置，本质都在提升”可复用比例”。
三个关键推论
- 省的不是首次成本，而是重复成本：第一次发送长前缀通常仍要正常付费，价值在第二次、第三次及后续多次复用时才体现。
- 不是”写短”，而是”写稳”：天天改 System Prompt、天天调 Skill Prompt，缓存理论上存在、实践里很难命中。
- 缓存优化和上下文治理是一回事：减少前缀抖动、把稳定内容前置、把变化内容后置，都在提升可复用比例。
缓存链断裂
Prompt Cache 的关键限制是”从头连续匹配”。最省的路径是只追加新消息；如果中途修改 Rules/Memory，修改点之后的历史都要重新计算；如果切换模型，底层 KV-Cache 张量不互通，整段前缀都无法复用。这个机制解释了为什么长会话中途改工具、改规则、换模型会突然变慢、变贵。
工程实践层面，headroom 这类工具内部专门有 CacheAligner 组件来”稳定前缀、帮助 Prompt Cache 命中”。
Agent 会话为什么容易到 90%
多轮 Agent 调用通常是典型的 append-only 负载：第 5 轮请求以前 4 轮完整上下文开头，再追加新工具结果和模型回复；第 6 轮又以前 5 轮完整上下文开头。只要模型、工具 schema、系统提示和前缀顺序稳定，前面的大段内容都会命中缓存。用简化模型估算，T 轮会话的命中率约为 (T-1)/(T+1)，所以 20 轮左右的编码会话就会接近 90%。
这也提醒不要把高命中率误读成“已经足够省”：命中读虽然便宜，但绝对输入量可能仍然很大。真正要压成本，往往要盯那些掉到 50% 左右的流量，排查是否频繁切模型、重置系统提示、改变工具集，或被非 cache-aware 网关打散到不同后端。
应用 / 使用场景
- AI Coding Agent 的长前缀（系统提示词 + 工具定义 + 项目背景）复用
- 多轮、长会话场景下压低每轮重复输入成本
- 与上下文压缩工具配合：先稳前缀（命中缓存）再压动态内容
局限与争议
- 前缀频繁变动会让缓存形同虚设——稳定性是命中的前提。
- 缓存只降低重复成本，不降低首次成本，也不会让模型”更聪明”；本质是”别为同一段前缀反复买单”。
- 不同厂商的缓存粒度、命中条件、计费规则不一，需以各家官方文档为准。
与其他实体的关系
- Token成本控制 —— Prompt Cache 是其五层优化路径中 Context 工程一层的底层依据
- Context-Engineering —— “把稳定内容前置”既是缓存命中条件，也是上下文工程实践
- Anthropic —— 官方《Prompt caching》《Token-saving updates》文档说明长前缀命中后成本与延迟下降
- KV-Cache —— Prompt Cache 是产品层抽象，KV-Cache 是模型/推理引擎内部缓存的张量机制
参考来源
- 一篇搞懂-AI-Coding-Agent的Token成本控制 —— 腾讯技术工程 devinyzeng，§1.4 Prompt Cache
- 一文搞懂Token经济学：同样额度多干3倍活，只需理解消耗机制 —— 腾讯云开发者，缓存链断裂、三档计价与配置层成本
- 为什么大模型的缓存命中率能到90-Percent —— 阿里技术，解释 Agent 式 append-only 调用为何天然适配前缀缓存，以及高命中率的误读风险