Prompt Caching 指的是把模型请求里那段反复出现的提示前缀缓存下来，后续再遇到同样或高度一致的前缀时，尽量直接复用处理结果，而不是每次都从头算一遍。它这两年之所以越来越热，不是因为名字高级，而是因为越来越多产品终于意识到：固定 system prompt、工具定义、长规则、长文档背景，才是很多 AI 成本和延迟的真正大头。
很多人会把 Prompt Caching 和 Context Caching 混着说，二者确实很近，但侧重点不完全一样。Prompt Caching 更强调“提示前缀”这件事，尤其适合那种每次请求前半段都差不多、后半段才变化的场景。比如客服 Agent、代码助手、企业知识助手，往往前面都要先塞进固定的系统规则、工具描述、格式约束，真正变化的只有用户问题。
它为什么特别适合多轮 Agent？因为 Agent 一旦进入工具调用和多步推理，就会携带大量重复上下文。你如果每走一步都把完整工具清单、长系统提示、固定工作流说明重新喂给模型，速度会慢，账单也会很难看。缓存机制的价值，就是把这些重复成本尽量摊薄。
但 Prompt Caching 不是“开了就自动省很多”的银弹。它非常依赖前缀稳定性。只要你每次都随手改 system prompt 的一两个位置、把示例顺序打乱、让工具定义来回变化，命中率就会掉得很厉害。很多团队缓存效果差，不是模型不支持，而是提示工程本身写得太散，根本没有可复用的稳定前缀。
真正适合 Prompt Caching 的内容，一般有三类。第一类是长期不变的系统规则，比如角色、口吻、边界、安全约束。第二类是高复用的大块说明，比如知识库索引说明、格式 schema、工具列表。第三类是跨会话也会反复出现的模板化任务。相反，那些用户个性化字段、实时数据、每次都变化的检索结果，不适合放在前面抢缓存位。
它还有一个容易被误解的点：缓存省的是预处理和前缀计算成本，不代表结果就会完全一样，也不代表模型“记住了所有历史”。回答质量仍然取决于后续输入、采样参数、工具返回和上下文是否正确。缓存解决的是重复劳动，不是推理正确性。
所以你现在看到 OpenAI、Anthropic 这类 API 文档都开始强调 prompt caching，本质上是在告诉开发者一件事：提示词已经不是一次性文本，而是可优化的系统资产。谁能把静态部分稳定下来、把动态部分后移、把命中率做上去，谁就更可能把长提示和 Agent 场景跑得又快又省。
