Prompt Caching 實戰：AI Agent 的快取為何沒命中？

同一套規則每輪重送，為什麼還會重新計費？

想像一個正在追查 Selenium 測試失敗的自動化代理。每輪請求都帶著測試規範、工具定義、元素定位原則，以及幾份長期參考資料。第一輪遇到登入逾時，下一輪改成列表元素等待失敗。任務內容已經換了，前段共用規則卻幾乎原封不動。

Prompt Caching 在這裡派得上用場：當輸入前綴符合條件，服務端便有機會重用先前計算的中間狀態，省去部分重複處理。這份便利自有邊界。可快取的長度、保存期限與匹配條件仍由模型及服務規則決定；留下的內容也依舊占據上下文。過時的 log，即使命中快取，也不會因此重新變得有用。

眼睛看著兩份提示詞，覺得「明明大半都相同」，仍不足以判定快取應該命中。值得仔細追問的是：服務端究竟保存到哪個分界？第二次請求的共同前綴，是否確實符合重用條件？

以下是兩次請求的概念結構：

第一次：固定工具 + 固定規則 + 參考資料 | 快取分界 | 案例 A
第二次：固定工具 + 固定規則 + 參考資料 | 快取分界 | 案例 B
                                          ↑
                                  期望重用的共同前綴

上圖為概念示意。實際 API 的分界欄位及可快取門檻依模型而定。

即使前後次序安排妥當，前綴長度若未達所選模型的最低要求，也無法得到可讀取的快取。參考：OpenAI Prompt caching。

快取分界需要落在真正穩定的內容之後

以 OpenAI 的 GPT-5.6 後續模型為例，官方文件提供預設隱式快取，也允許在輸入內容設定明確分界。預設分界可能落在最後一則合格訊息的末端。倘若那則訊息裡恰好放了每輪都變動的任務編號、時間戳或測試結果，下一輪的前綴便可能與先前保存的內容對不上。

遇到這類請求，可以先把固定規則與當輪資料分清楚，再評估將 prompt_cache_breakpoint 放在最後一段穩定內容之後，讓動態資料留在尾端。若使用 prompt_cache_options.mode="explicit"，便可避免將變動尾端當成新的隱式快取分界。

分界安排妥當，只代表有了重用的機會，帳單仍得算清楚。首次保存快取可能產生寫入費，請求間隔過久也可能讓它失效。即使第二次的快取讀取量增加，尚不足以判定整個任務更省錢。來源：OpenAI Prompt caching。

三家 API 的快取操作方式各有差異

同樣叫提示快取，真正決定能否重用的條件仍須逐家確認。若要把它納入 AI Agent 的基礎設計，可以先看三家目前的操作條件：

這張表整理的是 2026 年 10 月 10 日官方文件所載的條件。Gemini 的兩種 API 機制與用量欄位應分開閱讀：新一代 Interactions API 只有隱式快取；需要手動建立快取物件時，須使用仍受支援的 generateContent API。最低快取長度、讀取倍率與功能會隨模型不同而變。實作時仍須依各家的文件設定參數；不同供應商的快取比例，也不宜直接拿來當成公平的效能排名。

來源：OpenAI Prompt caching、Claude Prompt caching、Gemini Interactions API 快取與generateContent API 快取。

快取沒命中時可以依序查哪些項目

排查快取時，先弄清第一輪究竟有沒有建立快取，再確認下一輪是否讀到同一段前綴。把這兩個問題分開檢查，往往較容易縮小原因：

OpenAI 提供專門的 Cache Diagnostics，可透過 prompt_cache_options.comparison_response_id 比對先前回應，查看像 tools_changed、model_changed、input_changed 或 context_compacted 這類原因。這個欄位用來診斷差異，不會代替使用者管理本輪上下文，也不保證一定命中。

OpenAI 官方 Cache Diagnostics

用 Python 建立最小可重現的快取測試

快取設定究竟有沒有起作用，單看設定檔還難以確定。可以讓同一段共用規範連續使用兩次，只更換最後的虛構測試案例，再觀察實際用量。以下以 OpenAI Responses API 示範明確分界；程式碼供讀者自行操作，作者尚未持付費 API 執行實測。

先準備 stable-reference.txt，內容應是公開或虛構的測試規範，且要足夠長，達到所選模型的最低快取前綴門檻。這段程式採用 GPT-5.6 及後續支援模型的明確分界功能；該類模型的固定前綴至少須達 1,024 個可見輸入 Token。避免放入真實院所、病患、客戶資料或機密設定。安裝支援上述參數的 openai SDK 版本，並以環境變數設定 OPENAI_API_KEY 及有權使用的 OPENAI_MODEL。

import os
from pathlib import Path
from openai import OpenAI

client = OpenAI()
model = os.environ["OPENAI_MODEL"]
fixed_rules = Path("stable-reference.txt").read_text(encoding="utf-8")

for number in (1, 2):
    response = client.responses.create(
        model=model,
        input=[
            {"role": "developer", "content": [{
                "type": "input_text",
                "text": fixed_rules,
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }]},
            {"role": "user", "content":
                f"依固定規範分析虛構的測試案例 CASE-{number}。"},
        ],
        prompt_cache_options={"mode": "explicit"},
        max_output_tokens=120,
    )
    detail = response.usage.input_tokens_details
    print(number, detail.cached_tokens, detail.cache_write_tokens)

第一輪通常先建立可重用的內容；等到第二輪，才有機會看到快取讀取量。觀察 cached_tokens 與 cache_write_tokens，並保留 response.id、總輸入量和執行時間供比較。若兩輪都沒有符合預期的讀取，先核對前綴長度與設定，必要時再使用官方診斷功能。

要分辨哪個改動真正有影響，第二階段可以分組比較：一組沿用預設隱式快取，一組在固定規範之後設定明確分界，再安排一組刻意變更前段工具定義。每次只改一個因素，分批重複執行。模型回覆仍須符合相同驗收標準；倘若輸入費降低，卻換來更多重試，整體流程未必划算。

這個範例尚未在指定模型與 SDK 版本進行線上呼叫，無法保證直接複製後即可命中快取。正式執行前須核對 OpenAI Prompt caching 官方文件，確認支援的模型、SDK、前綴長度及兩次請求是否使用一致設定。本文尚無真實 API usage、延遲或帳單數據可報告。

Debug Loop 的快取策略需要連同上下文一起比較

Selenium 的自動修復流程跑得愈久，歷史紀錄往往也愈厚。先前的錯誤訊息、瀏覽器狀態與修復假設，到了下一個階段未必仍有用處。全部保留，快取讀取量可能增加，模型卻得讀入更多過時資訊；若大量裁切歷史，輸入雖會縮小，既有快取也可能失去重用條件。

這項取捨可以用三組相同的虛構逾時案例逐一比較：

三組都必須沿用相同模型、測試資料、最大重試數與驗收標準。建議記錄每次 API 的一般輸入、快取寫入、快取讀取、輸出、工具費、時間及執行結果，再合計每個成功任務的成本。

例如，假設同一段前綴被使用四次，第一次寫入按一般輸入費的 1.25 倍、後面三次讀取各按 0.1 倍計算，這段前綴的理論費用是 1.25 + 0.1 × 3 = 1.55 單位；若每次完整重新計費則是 4 單位。這是假設條件下共用前綴的局部試算，尚未計入每輪動態輸入、輸出、額外工具與失敗重試，也不能推算訂閱制 Coding Agent 的實際節費比例。

延伸閱讀：AI Agent Token 成本優化實戰。

適合先做快取設計的工作流

多次使用相同工具定義、規範或參考資料的工作，通常值得優先測試。每次請求的內容都很短、變動很大，或請求間隔超過快取有效期限時，預期收益可能有限。對使用 Gemini generateContent 顯式快取的工作流，還要考慮保存時間費用；對 Claude 則要計算較長 TTL 的寫入成本。

實際導入時，可以先選一段會反覆使用的共用規範，做小規模實驗。確認固定前綴、連續兩次請求、讀取用量與答案品質，再決定正式工作流是否值得調整。涉及醫療或公司資料時，各家平台的資料保留政策、使用權限與合約範圍仍須事先確認。

評估快取策略，最終仍要看完成一個通過驗收的任務究竟花了多少成本。 等到累積可重現的 API 記錄，再回頭調整快取分界與上下文管理，會比只看單一命中率更能支撐工程判斷。

官方文件與延伸資料

• OpenAI — Prompt caching
• OpenAI — Prompt cache diagnostics
• Anthropic — Prompt caching
• Anthropic — API pricing
• Google — Gemini Interactions API context caching
• Google — Gemini generateContent API context caching
• Google — Gemini API pricing