12 结尾，缓存是长上下文时代的真实账本

这篇文章从 prompt caching 讲起，最后落到的其实不只是一个 API 功能。

缓存决定的是：模型到底有没有反复读取同一批上下文，重复读取时按什么价格算，省下来的钱最后到了谁手里。

在普通聊天里，这个问题没那么明显。用户输入通常很短，成本压力更多来自模型输出。哪怕带一点历史消息，输入侧的重复成本也不一定是最主要矛盾。

Coding 和 Agent 场景完全不同。

这类任务经常是输入远大于输出。模型每轮都要处理大量已有上下文，最后可能只产出几行修改、一次命令结果，或者一个很短的下一步动作。输入侧占比被拉高以后，缓存命中率就会直接影响总成本。

长上下文越常见，缓存就越重要。

以后模型窗口会继续变大，Agent 能读的东西会越来越多，工具也会越来越多。上下文变长本身不一定可怕，可怕的是每一轮都把长上下文按普通输入重新付费。

所以看模型成本，不能只看价格表。

价格表告诉你的是单价。usage 告诉你的是这轮请求怎么计费。账单告诉你的是平台最后怎么收钱。三者对不上，用户就只能看一个总价，完全不知道钱花在哪里。

这也是为什么中转站问题会被放到这篇文章里。

中转站本身没有原罪。很多人用中转站，是因为官方账号、支付、网络、额度、模型聚合都有门槛。问题在于，中转站如果不透传 usage，不说明缓存输入怎么计费，不保证同一会话的路由稳定，用户就很难判断真实成本。

更麻烦的是 Agent 框架。

Agent 框架越强，越容易引入动态上下文。工具定义、MCP、compaction、subagent、运行状态，这些都会影响缓存。框架如果只追求“能做更多事”，不处理上下文稳定性，最后成本会被复杂度吃掉。

一个成熟的 Agent 或 AI Gateway，应该把缓存放进成本治理里。

至少要能回答几个问题：

这些问题听起来细，但它们决定长期成本。

对个人用户来说，最实际的建议很简单：不要只看“几折”“不限量”“超低价”。长上下文和 Agent 场景里，要看 usage 字段，看账单口径，看连续任务里的缓存表现。

对团队来说，更要把缓存当成成本指标。否则预算超了以后，大家只能争论“模型是不是太贵”，却看不到真正的原因可能是上下文组织太乱、工具塞得太多、路由不稳定，或者中转链路把缓存账本抹掉了。

缓存早就不只是省钱小技巧。

它是长上下文和 Agent 工具真正跑起来以后，最基础的一本账。

谁能看懂这本账，谁就能知道自己是在为模型能力付钱，还是在为重复上下文、不透明路由和无效工具调用付钱。