系统提示里的时间戳为何拖累缓存

system prompt 顶部的一行当前时间，可能让后面几千个不变的 token 都失去缓存复用机会。作者原先把 cached tokens 长期为零当成账单上的陌生数字，直到更新 Hermes、从 OpenRouter 切到 OpenCode 后，这个数字才开始变化。

这篇的价值，在于提醒我们：长对话的成本不只取决于模型单价，还取决于提示词如何排列。不过，作者同时改了两个变量，文中的费用推演也采用了假设价格，不能直接当成你自己项目的结论。

为什么一行时间会影响整段提示词

作者给每个 agent 的 system prompt 都加了当前时间，让模型处理「今天」、截止日期和日程时有时间依据。这段内容解决的是模型缺少时钟的问题：

Current time: 2026-11-04T01:17:00Z

要注意的是 Current time: 后面的值：它每次请求都会变化，而且被放在提示词顶部。

提示词缓存（prompt caching）复用的是已经处理过的输入前缀。可以把它理解为：前面一长段内容完全一样，服务商就可能沿用此前的处理结果。它不是在整段输入里寻找相似句子，也不会因为后面的规则没变，就自动跳过前面的差异。

越靠前的动态内容，越容易缩短能够复用的前缀。

因此，问题不在于 agent 该不该知道时间，而在于时间放在哪里。作者建议把它移到最后一条 user message；如果任务只关心日期，也可以把精度降到天。后者只是减少变化频率，并不能保证跨天继续命中。

缓存命中有门槛，打开功能还不够

原文把命中条件归纳为三个：前缀足够长、内容完全一致，以及缓存标记的位置正确。

按作者引用的文档，OpenAI 至少需要 1,024 个可见输入 token，隐藏的系统内容不计入这个门槛；Anthropic 的部分较新模型从 512 个 token 起步。这里原文没有列出具体模型，不能把 512 当成所有 Anthropic 模型的统一标准。

长度够了，也要保证前缀逐字节一致。工具定义、system prompt，以及被插到前面的检索内容，都应纳入检查范围。即使业务规则一字未改，只要前面塞进了每次不同的信息，后面的稳定内容也可能无法复用。

缓存标记还涉及服务商差异。原文提到，Anthropic 的缓存层级依次是 tools、system、messages，某一层变化会影响该层及之后的缓存。这个顺序也解释了为什么工具定义发生变化时，只盯着 system prompt 排查可能找不到原因。

而在 OpenAI 支持的模型上，缓存默认开启。作者并不是漏开了一个开关，而是请求没有满足可复用条件。两家的机制不能混成一套配置方法，实际接入时仍要按所用模型核对。

为什么缓存不命中还可能更贵

作者最意外的一点是：缓存写入可能比普通输入更贵，读取则便宜得多。于是，反复写入却从不复用，就可能增加费用。

这里必须补上适用范围：写入溢价不能直接套到所有服务商和模型上。 原文没有把这部分计费机制与具体模型逐一对应，接入时需要确认自己的服务是否单独收取缓存写入费。

作者给出了一组费用推演条件：

• 对话共 40 轮，固定内容为 6,000 个 token。
• 每轮追加 1,000 个 token，并输出 300 个 token。
• 输入价格假设为每百万 token 2 美元，输出为每百万 token 10 美元。

在这套假设下，作者称最差情况比完全不用缓存贵约四分之一，成本是正确使用缓存的六倍。

这组数字适合说明方向，不适合直接拿来做预算。提供的原文没有展示缓存读写单价、完整算式，以及每轮累积输入的计算细节，因此无法据此复核这两个倍数。作者也明确说明，价格是他的假设，并非读者账单上的报价。

我的判断

把稳定规则放前面、把当前时间等动态信息放后面，是这篇最值得采用的做法。相比一上来换便宜模型，它保留了原有任务能力，也更容易通过输入和 usage 数据验证效果。

但作者的经历不能证明「切掉 OpenRouter 就能修好缓存」。他同时更新了 Hermes，又迁移到了 OpenCode，没有做单变量对照；他自己也承认无法确定是哪项变化起了作用。路由到不同 provider 只是排查方向，不能据此认定 OpenRouter 就是原因。

缓存也有时间窗口。原文只说保留时间以分钟计，没有给出具体模型的期限。低频调用、前缀太短或工具定义频繁变化的任务，即使布局合理，也未必有很高的命中率。

我认同作者要求关注缓存占比，但账单仍需结合总输入、输出和实际计费判断。高命中率能说明复用情况，不能单独代表总成本最低。

能拿来做什么

• 在 Node agent 的请求组装处，把工具定义和固定规则放在前面，把当前时间、当次任务及动态检索结果放在后面，并检查实际发送出去的消息顺序。
• 在日常 AI 编程工作流里，如果每轮都会插入时间、环境状态或临时上下文，先比较相邻请求的前缀，找出第一个变化位置。
• 在调用记录中保存输入 token、缓存 token 和费用信息；缓存突然归零时，依次核对长度门槛、前缀变化、provider 路由及请求间隔。
• 调整 Hermes 版本、接入渠道或提示词布局时，每次只改一项，再观察同类请求的缓存表现，避免重演作者无法归因的问题。