每一個 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 的相對成本；而移動單一斷點則會阻止緩存複用，並導致重複寫入。