每一个 AI 代理（agent）在采取行动之前，都必须重新阅读自己的全部上下文。它调用工具、读取结果、决定下一步，然后把这整段“身世”再次发给模型：工具定义、开发者指令、此前每一次工具调用和每一条返回结果。模型本身在两次请求之间没有记忆，只根据本次输入预测下一个 token，因此上下文必须反复重发，而每一次的 token 费用都由你承担。到了编码会话的第 20 轮，模型要把第 1 到第 19 轮全部重读一遍。这就像电影《土拨鼠之日》里比尔·默里饰演的角色，每天醒来都回到同一个 2 月 2 日，昨天的一切成果都不会自动延续，除非从头再做一遍。
提示缓存（prompt caching）正是打破这一循环的手段。服务会把你的输入提示——包括指令、工具和内容——保存下来，在下一次请求中复用，并按远低于正常输入的价格计费。模型读取提示时首先要做一次称为 prefill 的处理，逐 token 计算出键值向量（KV），构成模型的工作状态。提示缓存保存的正是这份状态。当后续请求以完全相同的文本开头时，缓存服务直接加载已保存的状态，只处理新增部分，从而显著降低输入成本和延迟，同时让代理的响应更稳定、更一致。
缓存分为两种。隐式缓存由 Amazon Bedrock 自行决定可复用前缀在哪里结束，适合随着对话增长而不断扩展的代理负载。显式缓存则由代码通过 prompt_cache_breakpoint 明确标记断点，适合跨会话复用共享内容，例如工具和指令，也适合在派生子代理时复用。两种方式可以同时使用，官方建议组合使用：显式断点提供可复用的起点，隐式机制则由 Bedrock 自动管理不断增长的对话。新会话可以复用这个共享起点，而每段对话在此基础上各自构建自己的缓存历史。
第一个收益点是缓存静态部分。工具列表和开发者指令在多次请求间保持不变，可以显式设定缓存终点。示例使用 prompt_cache_key 告诉服务哪些请求共享同一缓存，并用 store=False 把会话历史保留在应用侧——注意这并不影响缓存本身。在一次测试中，约 4000 token 的工具加指令前缀在首次请求时写入 4120 token，后续请求读取同样的 4120 token；而位于缓存边界之后的用户任务不会触发缓存写入。可复用的前缀必须达到 1024 token 才有资格被缓存。
关键前提是：只有传入完全相同的文本，缓存才会命中。因此指令和工具列表必须每次以相同方式序列化，MCP 服务器等工具投递形式也需要索引化以保证一致性。日期、用户名、请求 ID 等会变化的内容必须放在已缓存的指令之后。
随着内容增长和变化，可以改用隐式模式，让服务自动跟随对话。首个请求没有显式标记时，最新的合格消息（即用户任务）之后会成为自动断点，把工具、指令和任务一起覆盖。但要注意，换一个任务后前缀不再匹配旧的自动写入点，此时若仍希望复用较短的共享前缀，就应当加显式标记。最稳妥的做法是两者结合：在开发者块上加显式断点，同时保持请求级为隐式模式，这样既保留共享前缀，又能让服务继续保存到最新的合格消息。
在多轮工具调用循环中，应用需要执行模型请求的函数并把结果追加到历史里。隐式模式下，Bedrock 可以复用未变的前缀，并把新增内容缓存到最后一个工具结果为止。后续追加新的用户消息时，应保持较早消息不变，以便其缓存端点继续可用。若采用纯显式模式，则可在每批工具结果中把最后一条结果标记为新的滚动断点，同时保留所有更早的标记。
在一项六轮工作负载测试中，GPT-6 Astra 的隐式缓存取得了最佳结果之一，输入成本比不开缓存低约 62%；同一模型使用显式滚动断点节省约 61%。两者都随着对话增长复用了更多历史。这些只是特定工作负载的结果，你应当根据自己的代理实测节省幅度。需要警惕的陷阱包括：纯显式模式下只设一个静态断点，工具和指令被缓存，但增长的历史每轮都要重新处理，只能达到约 0.61 的相对成本；而移动单一断点则会阻止缓存复用，并导致重复写入。