Prompt Caching 的生效范围是什么？

很多人会以为 prompt caching 只在当前 session 里生效，这个理解太窄了。

它认前缀，不认会话

Prompt caching 的关键，不是 session ID，而是前缀内容本身。

更准确地说，缓存命中的依据通常是前缀内容的哈希值。只要两次请求的前缀一致，系统就有机会复用同一段缓存。

对话 A（用户张三）:
[system][msg1][msg2] -> 写入缓存

对话 B（用户李四）:
[system][msg1][msg2] -> 前缀相同，命中缓存

对话 C（用户张三）:
[system][msg3] -> 前缀不同，未命中

厂商差异主要在缓存是显式还是隐式

不同模型提供商在实现上有差异，但基本逻辑都围绕“前缀复用”展开：

• Anthropic Claude：通常在同一个 organization 范围内，按前缀内容匹配；TTL 常见为 5 分钟，命中后会刷新
• OpenAI：也以自动前缀匹配为核心；TTL 范围相对黑盒，但跨对话命中是常见预期
• Google Gemini：更偏显式缓存对象，由开发者创建缓存并指定 TTL，然后通过对象 ID 复用

实际落下来，prompt caching 往往会同时发生在两个层面：

1. 跨对话复用
2. 同一对话里逐轮增长的历史前缀复用

长 system prompt 往往最值得缓存

如果你的 AI 产品给所有用户都发送一大段相同的 system prompt，例如工具定义、规则说明、行为约束，那么这部分前缀就非常适合被缓存复用。

用户 A: [8000 tokens system][用户消息...]
用户 B: [8000 tokens system][用户消息...]
用户 C: [8000 tokens system][用户消息...]

只要 system prompt 相同，这 8000 tokens 就有机会被多次复用

这也是为什么很多 AI 编程产品即使 system prompt 很长，成本也不一定线性爆炸。关键不在长短本身，而在这段前缀有没有被大量复用。

回到真实对话，这两层复用经常同时存在

在一个多轮对话里，请求会不断把历史消息追加到后面：

请求 1: [system][user1]
请求 2: [system][user1][assistant2][tool3][assistant4]
请求 3: [system][user1][assistant2][tool3][assistant4][user5]

这里既有“同一对话内越来越长的前缀复用”，也有可能出现“跨对话共享同一段 system prompt”的复用。两种情况并不冲突，经常是同时发生的。