一份關於 Claude 如何達到 92% 快取命中率的案例分析
每次 AI Agent 採取行動時，都必須付出代價。
它會從頭重新讀取所有內容。
系統指令、工具定義、專案上下文——這些它三輪前就已載入過的資料。全部重讀，每一輪都是如此。
這就是所謂的「上下文稅」。對於長時間運行的代理工作流程來說，這往往是你整個 AI 基礎設施中最昂貴的項目。
來算一筆帳：一個包含 20,000 個 token 的系統提示詞，運行了 50 輪，這意味著 100 萬個 token 的重複計算 以全價計費，卻沒有產生任何新的價值。
解決方法是提示詞快取（Prompt Caching）。但要善用它，你需要了解底層實際發生的情況。
從「什麼會改變」與「什麼不會改變」開始
在優化任何東西之前，你需要清楚地思考 Agent 提示詞（上下文）的結構。
你的 Agent 每次發送的請求都包含兩個根本不同的部分：
靜態前綴： 包含系統指令、工具定義、專案上下文、行為準則。這個內容在會話的每一輪中都是完全相同的。
動態尾部： 用戶訊息、工具輸出、終端機觀察結果。這部分是每個請求獨有的，並且會隨著對話進行而不斷增長。
這個區別至關重要。靜態前綴是你一直在無謂重複計算的昂貴部分。動態尾部才是唯一真正需要全新計算的部分。
提示詞快取的原理是儲存靜態前綴的數學狀態，以便未來的請求可以完全跳過重新計算。你支付一次處理該前綴的費用。之後的每一輪都從記憶體中讀取。
為什麼這樣有效：Transformer 實際做了什麼
要真正理解快取為何如此有效，你需要了解模型在讀取你的提示詞時內部發生的情況。
每個 LLM 推理請求都包含兩個階段：
第一階段：預填充（Prefill）
這是模型處理你完整輸入提示詞的階段。它屬於計算密集型，意味著它會對上下文中的每個 token 執行密集的矩陣乘法運算。模型會讀取所有內容，並建立一個表示。這是緩慢且昂貴的階段。
第二階段：解碼（Decode）
這是模型逐個產生輸出 token 的階段。它屬於記憶體密集型而非計算密集型，因為模型大部分時間花在讀取先前計算好的狀態，而不是執行繁重的計算。
在預填充階段，Transformer 會為每個 token 建立三個向量：查詢（Query）、鍵（Key）和值（Value）。注意力機制利用這些向量來計算每個 token 與序列中其他 token 的關係。
這裡是關鍵洞察：Key 和 Value 向量只取決於它們之前的 token。 一旦為給定的前綴計算完畢，它們就永遠不需要更改。
下圖直觀地解釋了我們剛才討論的內容：
如果沒有快取，這些 Key-Value 張量會在請求完成時被丟棄。下一個請求從頭開始，再次為所有 20,000 個 token 重新計算它們。
KV 快取透過儲存這些張量來解決這個問題。 基礎設施將它們保存在推理伺服器上，並以輸入文字的加密哈希值作為索引。當一個具有相同前綴的新請求到來時，哈希值匹配，張量立即被檢索出來，模型跳過所有這些計算。
這將每個產生 token 的計算複雜度從 O(n²) 降低到 O(n)。對於一個重複 50 輪的 20,000 個 token 前綴來說，這是一個巨大的減少。
經濟學
了解定價結構是讓這個架構決策如此重要的原因。
以下是 Anthropic 在其模型系列中為快取定價的方式：
需要內化的三個數字：
- 快取讀取成本為基礎輸入價格的 10%，每個從快取讀取的 token 可享有 90% 的折扣
- 快取寫入成本比基礎輸入價格高出 25%，這是儲存 KV 張量所需的小額溢價
- 延長至 1 小時的快取成本為基礎價格的 2 倍
只有當你的快取命中率保持在高位時，這個數學公式才成立。這就引出了實踐中最好的實際案例。
Claude Code：30 分鐘會話逐步解析
Claude Code 的整個構建都圍繞一個目標：保持快取處於「熱」狀態。
為了具體理解這意味著什麼，讓我們逐步分析一個典型的 30 分鐘編碼會話如何進行，並追蹤哪些部分被計費，哪些沒有。
第 0 分鐘：會話開始
Claude Code 載入其系統提示詞和工具定義。它還會讀取你專案根目錄中的 CLAUDE.md 檔案，該檔案描述了程式碼庫和慣例。這個有效載荷通常超過 20,000 個 token。
這是整個會話中最昂貴的時刻。每個 token 都是全新的。但你只需要支付這個費用一次。
第 1 到 5 分鐘：第一批指令
你輸入第一個指令，例如「查看 auth 模組並提出改進建議」。
Claude Code 調度一個探索子 Agent（Explore Subagent）。它瀏覽程式碼庫、開啟檔案、執行 grep 指令，並建立相關程式碼的圖景。所有這些都被附加到動態尾部。
那 20,000 個 token 的靜態基礎呢？已經在快取中了。以 $0.30/MTok 而非 $3.00/MTok 的價格讀取回來。你只需要為新的工具輸出和你的訊息付費。
第 6 到 15 分鐘：深度工作
規劃子 Agent（Plan Subagent）接收來自探索子 Agent 的發現。Claude Code 不會逐字傳遞原始結果（這會不必要地膨脹動態尾部），而是傳遞一個簡潔的摘要。這使得後綴部分保持可管理，並維持快取效率。
規劃器產生一個結構化的實作計劃。你審查它、批准它，然後 Claude Code 開始進行更改。這個循環中的每一輪都從快取讀取 20,000 個 token 的前綴。每次快取命中都會重置 TTL，使快取在未來的輪次中保持熱度。
第 16 到 25 分鐘：迭代
你要求調整。Claude Code 修改其方法。更多的工具調用，更多的終端機輸出。動態尾部在增長，但這只代表了這個會話中新的、獨特的內容。
此時，會話總共處理了數十萬個 token。但那 20,000 個 token 的基礎在每一輪都從快取中讀取。
第 28 分鐘：執行 /cost
如果沒有快取，像這樣的會話很容易超過 200 萬個 token。以 Sonnet 4.5 的費率計算，大約是 $6.00。
如果快取以高效率運行：
- 絕大多數 token 以 $0.30/MTok 的價格從快取讀取
- 只有新的動態尾部 token 會進行全新計算
實際上，在單一任務上，你預計可以實現 80% 以上的成本降低。現在，再將這個數字乘以每個用戶、每一天。
總結一下，以下是會話進行過程中系統提示詞佈局的變化：
打破一切規則的規則
關於提示詞快取，最違反直覺的一點是：
1 + 2 = 3。但 2 + 1 會導致快取未命中。
基礎設施對提示詞進行哈希運算。哈希值是一個用於加密學的標識符。如果順序中的任何內容發生變化，即使只是兩個元素的順序不同，哈希值也會改變。快取是空的。整個前綴將以全價重新計算。
由此得出的三條規則：
- 不要在會話期間添加或移除工具。快取的前綴包含工具。更改工具會使之後的所有快取內容失效。
- 切勿在會話中途切換模型。快取是特定於模型的。在對話中途切換到更便宜的模型需要重建整個快取。
- 切勿更改前綴來改變狀態。相反，Claude Code 會在下一個用戶訊息中添加一個標籤來提醒系統。前綴永遠不會改變。
這對你意味著什麼
以上所有內容解釋了 Claude Code 如何處理快取。如果你正在構建自己的 Agent，同樣的規則也適用。
以下是組織提示詞的方法：
- 最頂部是系統指令和規則。不要在過程中更改。
- 提前載入你需要的所有工具。不要添加或移除它們。
- 之後是檢索到的上下文和文件。在持續時間內保持靜態。
- 最底部是對話歷史和工具輸出。
啟用自動快取後，斷點會隨著對話進行而自動向前移動。
Claude Code 負責管理自己的快取。Anthropic 剛剛在其 API 中加入了自動快取功能，因此你也可以為自己的 Agent 做同樣的事情。
如果沒有自動快取，你必須記住 token 邊界在哪裡。錯誤的邊界意味著無法命中快取。
使用快取安全的分叉（cache-safe forking）來壓縮以適應上下文限制。使用相同的系統提示詞、工具和對話，然後將壓縮指令作為新訊息添加進去。
壓縮調用看起來與上一次調用幾乎完全相同。快取的前綴再次被使用。唯一被視為新的並計費的內容是壓縮指令。
要檢查 API 是否正常運作，請密切關注每個回應中的這三個欄位：
- cache_creation_input_tokens: 存入記憶體的 token 數量
- cache_read_input_tokens: 從記憶體讀取的 token 數量
- input_tokens: 照常處理的 token 數量
你的快取效率得分是讀取 token 數量與建立 token 數量的比值。像關注系統正常運行時間一樣關注它。
關鍵 takeaways
提示詞快取不是一個你可以簡單「開啟」的功能。它是一種你需要圍繞它建立的架構紀律。
Claude Code 是最好的例子，展示了在大規模應用時該領域的樣貌。
92% 的快取命中率。81% 的成本削減。
如果你正在構建 Agent，這就是藍圖。你無法忽視那筆稅；它確實存在。唯一重要的是你是在為它付費，還是想辦法消除它。
