# GPT‑5.6 补上主动缓存：Agent 时代，省钱终于不靠玄学了

最近 GPT‑5.6 预览版发布，很多人第一眼会关注模型能力、价格、推理强度、Coding 表现。

但在我看来，里面有一个对工程侧更关键的变化：OpenAI 开始支持更可预测的主动缓存，也就是显式 cache breakpoint，缓存断点。

这件事看起来只是 API 里多了一个能力，但放到整个大模型行业里看，它其实是一个标志性信号：OpenAI、Anthropic、Google 这三家主流模型厂商，终于都走到了同一个方向——缓存不能只靠平台自动猜，开发者需要主动把握上下文的生命周期。

换句话说，大模型缓存正在从“命中了就省点钱”的隐藏福利，变成 Agent 时代必须认真设计的基础工程能力。

## 先说结论：主动缓存会成为 Agent 产品的标配

以前很多人理解缓存，只会把它当成一个省钱功能。

请求里有一段重复 prompt，服务端刚好命中了缓存，账单便宜一点；没命中，就按原价付费。用户不用做什么，也不用承担额外风险。

但 Agent 产品不一样。

Agent 的一次任务不是一次请求，而是一串 loop：规划、调用工具、读文件、搜索、执行命令、看结果、再规划、再调用工具。每一轮请求都会带上大量重复内容，比如系统提示词、工具定义、项目规则、代码仓库摘要、历史执行轨迹。

这些内容如果每轮都重新计算，成本会越来越高，首 token 延迟也会越来越明显。

所以 Agent 时代真正需要的不是“平台有空帮我省一点”，而是“我明确知道哪些上下文要缓存、缓存多久、读了几次、到底省了多少钱”。

这就是主动缓存变重要的根本原因。

## 一、隐式缓存：好处是免费，问题是不可控

OpenAI 过去很长一段时间主要是隐式缓存。

隐式缓存的体验很舒服：用户不用声明缓存断点，不用写额外参数，也不用承担缓存写入成本。只要 prompt 前缀足够长、足够相似，服务端会自动判断是否可以复用。

命中了，cached input token 更便宜；没命中，也只是正常 input 价格。

所以这类缓存的用户心智非常低：命中是赚到，不命中也不亏。

这也是为什么 OpenAI 早期的缓存机制很容易被接受。它不像一个需要学习的新功能，更像平台自动送的一档折扣。

但隐式缓存的问题也在这里：它太像“平台黑盒优化”了。

缓存能保留多久？什么时候被驱逐？请求会不会被路由到保存过缓存的机器？高峰期会不会降低命中率？这些主要由服务端决定，用户很难完全掌控。

对普通聊天产品来说，这没什么问题。但对高频 Agent、AI Coding、长上下文工作流来说，这就不够了。

因为企业真正关心的不是“平均下来可能便宜一点”，而是“我能不能稳定预测每个任务的成本”。

## 二、主动缓存：麻烦一点，但账算得清楚

Anthropic 更早把主动缓存做成了一个核心能力。

它的思路是：用户明确声明哪些内容要缓存，可以选择 5 分钟或 1 小时的 TTL。写入缓存时要付一笔额外成本，但后续读缓存会便宜很多。

这套机制最大的变化是：钱都摆在明面上。

写缓存，要付钱。读缓存，也计费，但折扣很大。

如果你缓存的是一段稳定的大上下文，比如系统提示词、工具定义、代码仓库说明、长文档背景，并且接下来会被多次复用，那主动缓存非常划算。

但如果你每次请求都不一样，只写不读，那就会变成反向优化：你花钱创建了缓存，却没有吃到缓存读取的折扣。

这也是主动缓存对工程师提出的新要求：你不能只知道“缓存能省钱”，你还要知道“哪些内容值得缓存”。

一个简单判断方法是：

如果一段上下文只用一次，不要主动缓存。

如果一段上下文会在几分钟内被连续复用，5 分钟缓存通常就值得考虑。

如果一段上下文会在一个较长任务、批处理、多人共享上下文里反复使用，1 小时缓存才更有意义。

主动缓存的本质不是“更便宜”，而是“更可控”。

## 三、Gemini 的路线：隐式和显式长期并存

Google Gemini 这边其实比较早就同时提供了两种思路：隐式缓存和显式缓存。

隐式缓存适合默认优化：你不需要额外操作，平台自动尝试复用相似前缀。

显式缓存适合工程控制：你可以明确创建一个缓存对象，把大段上下文放进去，后续请求引用这个缓存对象。

从产品形态看，Google 的路线反而很完整：一边给低门槛自动优化，一边给高要求团队可控能力。

只是因为过去一段时间里，Agent 工具链和 AI Coding 市场的注意力更多集中在 OpenAI 和 Anthropic 上，所以 Gemini 的缓存能力没有被讨论得那么多。

但如果只看方向，它其实早就说明了一件事：未来缓存一定会同时存在两层能力。

一层是平台自动做的隐式缓存，用来降低默认成本。

另一层是开发者主动设计的显式缓存，用来保证复杂工作流里的可预测性。

## 四、GPT‑5.6 的意义：OpenAI 也承认缓存需要工程化

GPT‑5.6 预览版加入显式缓存断点，真正值得关注的点不是“又多了一个 API 参数”。

它的意义是：OpenAI 也开始把缓存从平台内部优化，进一步开放成开发者可以设计的工程能力。

这背后有一个非常现实的原因：Agent 越强，上下文越贵。

越强的模型，越适合做长任务；越长的任务，越需要多轮工具调用；多轮工具调用越多，重复上下文越大。

于是你会发现一个悖论：

模型能力提升以后，真正限制产品规模化的，反而可能不是模型聪不聪明，而是每轮 loop 的上下文成本能不能压住。

这也是为什么主动缓存会从“高级优化技巧”变成“Agent 产品基础设施”。

## 五、为什么 Agent 特别依赖缓存？

因为 Agent 的上下文天然有大量重复。

比如一个 AI Coding Agent，一次任务里可能反复携带这些内容：

- system prompt；
- 工具定义；
- MCP schema；
- 项目目录结构；
- 代码规范；
- 已读文件摘要；
- 任务计划；
- 历史工具调用结果。

其中有些内容非常稳定，比如系统提示词和工具定义。

有些内容中等稳定，比如项目背景、代码结构、任务计划。

还有些内容高度动态，比如每轮命令输出、报错日志、搜索结果、临时 patch。

如果你把所有东西都粗暴塞进 prompt，然后每轮都重新计算，成本一定会膨胀。

更好的做法是把上下文分层：

稳定内容放前面，尽量缓存。

中期内容根据任务周期判断是否缓存。

动态内容放后面，尽量不要破坏前缀命中。

这就是所谓的上下文工程。Prompt caching 不是孤立能力，它是上下文工程的一部分。

## 六、给新人看的缓存实践原则

第一，稳定内容放前面。

大多数 prompt caching 都依赖相同前缀。系统提示词、工具定义、固定规则、长文档背景，应该尽量放在 prompt 前部。

第二，动态内容放后面。

用户本轮问题、时间戳、request_id、trace_id、工具返回结果、临时搜索结果，都应该尽量靠后。否则前缀稍微变化，就可能破坏缓存命中。

第三，不要为了缓存而缓存。

缓存不是免费的魔法。尤其是主动缓存，写入本身要付成本。如果某段内容不会被复用，缓存它只会增加开销。

第四，看 cache read，而不只是看 input token。

做 Agent 成本分析时，不能只看总输入 token。你要看 cache write tokens、cache read tokens、cached token ratio、cache hit rate，以及首 token 延迟。

第五，按任务生命周期选择 TTL。

短任务、高频 loop，可以优先考虑短 TTL。长任务、批处理、多用户共享上下文，才更适合长 TTL。

第六，工具结果要谨慎缓存。

很多 Agent 的工具结果每轮都不同。如果你把大量动态工具结果放在可缓存前缀里，缓存命中率可能反而变差。

## 七、主动缓存的真正价值：从省钱，到可预测

隐式缓存解决的是：平台自动帮你省一点。

主动缓存解决的是：工程师能不能主动控制成本、延迟和上下文结构。

这两个能力都重要，但面向的是不同阶段。

当产品还只是单轮问答，隐式缓存就够用了。

当产品进入 Agent loop，特别是 AI Coding、Deep Research、长文档处理、多工具调用这些场景，主动缓存就会变成基础能力。

因为这类产品的核心问题不是“某一次请求多少钱”，而是“完成一个任务的总成本是多少”。

一次 Agent 任务可能包含几十次调用。每一轮省一点，最后就是非常大的差异。每一轮多花一点，最后也会变成非常高的账单。

所以 GPT‑5.6 支持主动缓存，真正说明的是一个行业趋势：

大模型工程正在从 prompt engineering，走向 context engineering。

未来做 Agent，不只是选模型、调提示词、接工具，还要管理上下文生命周期。

而主动缓存，就是上下文生命周期管理里最重要的一环。

一句话总结：

在单轮聊天时代，缓存是平台送的折扣。

在 Agent 时代，缓存是工程师必须掌握的成本控制权。