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