土拨鼠之日：每步都重读全部历史
AWS 在 10 月 26 日发布一篇技术博客，借电影土拨鼠之日的比喻讲清了一件被很多团队忽略的事：智能体每执行一步——调一次工具、读一次结果、决定下一步——都要把模型在整个会话里到目前的所有内容重新发给模型，包括工具定义、指令、每一次历史工具调用和每一次结果。原因是大模型在请求之间没有记忆，它只根据这次收到的输入预测下一个 token。到了第 20 步，模型要把第 1 到 19 步全部重读一遍，而每一遍的 token 都得你付费。
提示缓存要打破的就是这个循环。服务把输入的键值状态在预填充阶段存下来，后续请求若以相同文本开头，就直接加载已存的状态，只处理新增内容，价格只是输入的一小部分。博客区分了两种模式：隐式缓存由 Bedrock 自动选择可复用的前缀，显式缓存则由代码通过断点标记边界，并建议两者结合——静态的工具与指令用显式断点跨会话和子 Agent 复用，增长的对话交给隐式缓存自动管。
两种缓存模式，合起来用
这里有几个落地细节值得记。可复用前缀必须达到 1024 token 才符合条件，且文本要逐字一致，所以指令与工具列表需要一致地序列化，把日期、用户名、请求 ID 这类变化内容放在缓存边界之后。新增工具可以在会话中途通过附加字段接入而不使已有缓存失效，子 Agent 也能共享一个预热过的前缀再各自分支。博客在一个六轮测试里报告：在 GPT-6 Astra 上，隐式缓存把输入成本降约 62%，显式滚动断点降约 61%。
但它的定位是工程指南，不是发布或政策变动。作者也坦承数字来自单一工作负载，读者应当测量自家 Agent 的节省。常见陷阱也被点名：只开显式、只放一个静态断点时，增长的对话历史仍会在每一步被重处理；关掉响应存储并不等于关掉缓存。
缓存不是银弹，但是循环里的实在账
冷水照例。提示缓存降的是输入成本，不解决智能体到底有没有做对事；62% 是人家一个工作负载的数字，不是你家的承诺。更微妙的是，缓存生效的前提是前缀稳定，而很多真实 Agent 的上下文是动态拼出来的，序列化和断点设计本身就要花心思。但方向很清楚：多智能体、长会话、子 Agent 扇出，越是这种「同样背景反复发」的循环，缓存的杠杆越明显。
对工程的意思是直接的——先把那份不变的系统提示、工具清单和背景知识用显式断点钉成可复用前缀，再把增长的对话交给隐式缓存，新工具用附加字段接入，子 Agent 共享预热前缀。这几步不挑模型、不挑框架，却能在循环里把一笔反复付费的账实实在在地压下来。它和本站此前写的协调税、中继协作是同一件事的不同切面：前者算清多 Agent 的隐性开销，后者给出一种压住循环重复付费的具体手段。