為什么99%的AI Agent都在燒錢？

最近，關于 token 比人力貴的吐槽多了起來，有些公司發現，AI Agent 并不一定省錢。

就此，國外AI博主 Avi Chawla 拿 Claude 的真實數據算了筆賬，結果嚇人一跳。

一個30分鐘的編碼會話，92%的token走的都是緩存，直接干掉 81% 成本。

因為每次跟Agent對話，前面那些系統指令、工具定義、上下文，幾乎都會重復。

搞不懂的是，像公司文檔、產品資料這種不變的素材，為什么每次都去RAG？Agent為什么不去做緩存優化？也難怪調用token 是在燒錢。

以下為Avi Chawla的博文——

《大語言模型中的提示詞緩存詳解》

一則關于 Claude如何實現92%緩存命中率的案例分析

AI 智能體每執行一步操作，都會將完整對話歷史回傳給大語言模型。

這其中包含系統指令、工具定義，以及三輪對話之前已經處理過的項目上下文。每一輪交互，所有內容都會被重新讀取、重新計算、重新計費。

對于長期運行的智能體工作流而言，這類冗余計算，往往是整套 AI 架構里成本最高的部分。

一段包含 20000 token 的系統提示詞，重復運行 50 輪，就會產生100 萬 token 的全額計費冗余計算，且不會產生任何新價值。該成本還會隨著用戶數量、對話場次不斷疊加。

解決辦法就是提示詞緩存。但想要用好這項技術，需要先理解底層運行原理。

靜態上下文與動態上下文

想要優化提示詞，首先要區分內容中可變與不可變的部分。

每一次智能體請求都包含兩個本質不同的部分：

? 跨輪次完全不變的靜態前綴：系統指令、工具定義、項目上下文、行為規范。

? 隨輪次不斷新增的動態后綴：用戶消息、模型回復、工具返回結果、終端運行信息。

正是這種結構劃分，讓提示詞緩存得以實現。平臺底層會存儲靜態前綴對應的模型計算狀態，后續所有包含相同前綴的請求，都可以直接跳過重復計算，從內存中讀取已有結果。

理解這一點后，本文所有架構設計思路都會一目了然。

KV 緩存的工作原理

想要明白緩存效果為何顯著，需要先了解 Transformer 模型處理提示詞的完整過程。

大語言模型每一次推理請求都分為兩個階段：

?填充階段（Prefill）：處理全部輸入提示詞。

對上下文內所有 token 執行密集矩陣運算，生成模型內部特征表征。該階段計算量大、算力消耗高。

?生成階段（Decode）：逐一生成新 token。

每一個新 token 接入序列后，模型預測下一個 token。該階段主要讀取歷史計算結果，計算量小，受內存限制。

在填充階段，Transformer 會為每個 token 計算三組向量：查詢向量 Query、鍵向量 Key、值向量 Value。

注意力機制依靠這三組向量，計算各個 token 之間的關聯關系。任意 token 的 Key、Value 向量僅由其前方的 token 決定，一旦計算完成便固定不變。

無緩存機制時，每次請求結束后這些 Key、Value 張量都會被丟棄，下一次請求需要全部重新計算。以 20000 token 的前綴為例，大量本可復用的注意力計算被重復執行。

KV 緩存解決了該問題：將上述張量持久化存儲在推理服務器中，并以 token 序列的加密哈希值作為索引。當新請求攜帶相同前綴時，哈希值匹配成功，直接從內存加載對應張量，完全跳過該部分 token 的填充計算。

該優化將單個生成 token 的計算復雜度從 O(n2) 降至 O(n)。對于重復 50 輪的 20000 token 前綴，計算量優化效果極為顯著。

成本分析

計費規則決定了該架構優化的實際價值。

? 緩存讀取價格為基礎輸入單價的 0.1 倍，即每個緩存 token 享受 90% 折扣

? 緩存寫入價格為基礎單價的 1.25 倍，存儲 KV 張量需額外支付 25% 溢價

? 一小時延長緩存有效期，價格為基礎單價 2.0 倍

以下為 Anthropic 旗下各 Claude 模型的對應計費情況。

上述成本優勢成立的前提，是維持高緩存命中率。最典型的落地應用案例就是 Claude Code。

Claude Code 30 分鐘編程實戰案例

Claude Code 的設計核心目標僅有一個：保持緩存活躍。

以下從計費角度還原真實 30 分鐘編程對話全過程：

第 0 分鐘
Claude Code 加載系統提示詞、工具定義、項目 CLAUDE.md 文件。

整體內容超 20000 token，全部為全新內容，是本次對話全程成本最高的時刻，該費用僅需支付一次。

第 1~5 分鐘
用戶下達指令，Claude Code 調用探索子智能體遍歷代碼庫、打開文件、執行檢索指令。

所有新增內容全部追加至動態后綴。而 20000 token 的靜態前綴已走緩存讀取，單價從 3.00 美元/百萬 token 降至 0.30 美元/百萬 token。

第 6~15 分鐘
規劃子智能體接收精簡摘要信息，而非原始返回結果，避免動態后綴無意義膨脹。模型生成開發方案，用戶確認后，Claude Code 開始修改代碼。

每一輪交互均從緩存讀取靜態前綴，緩存命中率突破 90%，且每次讀取都會重置緩存有效期，維持緩存活躍狀態。

第 16~25 分鐘
用戶提出修改需求，觸發更多工具調用、終端輸出，動態后綴持續累積內容。

本次對話累計處理數十萬 token，但每一輪交互均復用緩存中 20000 token 的基礎前綴內容。

第 28 分鐘
用戶在終端查看費用。若無緩存，調用 Sonnet 4.5 模型處理 200 萬 token 需花費 6.00 美元。

本次緩存效率達 92%，其中 184 萬 token 為緩存讀取，最終總費用僅 1.15 美元，單任務成本降低 81%。

這就是活躍緩存的實際效果：僅需一次性支付靜態基礎內容費用，后續均可低價復用，僅動態新增部分正常計費。

基于哈希緩存的局限性

提示詞緩存最反常識的一點：
1 + 2 = 3 可命中緩存，2 + 1 則緩存未命中。

底層機制會對完整從頭開始的 token 序列做哈希計算。只要序列內任意內容改動，哪怕僅調換兩個元素順序，哈希值就會改變，整段前綴都需要全額重新計算。

這并非細微的實現細節，而是約束條件，Claude Code 所有工程設計均圍繞此約束展開。

以下為生產環境中真實導致緩存失效的案例：

? 系統提示詞中插入時間戳，導致每次請求哈希值均不同

? JSON 序列化工具在不同請求中調整工具結構鍵值排序，前綴全部失效

? 對話中途更新智能體工具參數，20000 token 緩存全部清空

由此總結三條使用原則：

1. 對話全程不修改工具。工具定義屬于緩存前綴內容，增刪工具會導致后續全部緩存失效。

2. 對話中途不切換模型。緩存與模型一一綁定，中途切換低價模型需要重建全部緩存。

3. 不修改前綴內容來更新狀態。Claude Code 不會改動系統提示詞，而是在用戶消息末尾追加標記，保證前綴內容固定。

應用到自研智能體開發

無論使用 Claude Code，還是從零搭建自研智能體，以上規則全部通用。

提示詞按如下順序排版：

1. 頂部放置系統指令與行為規則，對話全程不改動

2. 一次性加載全部工具定義，不中途增刪

3. 緊接著放置檢索上下文與參考文檔，單輪對話內保持固定

4. 底部放置對話歷史、工具返回結果，作為動態后綴

調用 Anthropic API 開啟自動緩存后，隨著對話推進，緩存分界點會自動向后延伸。

若未開啟自動緩存，則需要手動劃分 token 邊界，邊界劃分錯誤會直接無法命中緩存。

當上下文長度即將達到上限時，可使用緩存安全分支壓縮方案：保留原有系統提示詞、工具、對話歷史不變，僅新增一條上下文壓縮指令作為消息追加。前綴緩存完全復用，僅新增的壓縮指令 token 需要計費。

想要校驗緩存是否正常生效，可監控 API 返回的三個字段：

? cache_creation_input_tokens：寫入緩存的 token 數量

? cache_read_input_tokens：從緩存讀取的 token 數量

? input_tokens：未走緩存、正常計算的 token 數量

緩存效率計算公式：
緩存效率 = cache_read_input_tokens ÷ (cache_read_input_tokens + cache_creation_input_tokens)
需要像監控服務可用性一樣持續跟蹤該指標。

核心總結

提示詞緩存并非簡單開關功能，而是需要整體架構圍繞其設計的開發準則。

核心原理十分簡單：提示詞結構上，靜態內容居上，動態內容向下新增。平臺對前綴做哈希存儲、保存 KV 張量，后續每次讀取均可享受高額折扣。

真正的難點在于細節規范：不向系統提示詞插入時間戳、不隨意調整工具定義順序、對話中途不切換模型、不改動緩存分界點之前的任何內容。

Claude Code 實現了規?；涞?，達到 92% 緩存命中率、81% 成本降幅。若你正在開發智能體，卻沒有圍繞提示詞緩存做架構設計，將會錯失大量成本優化空間。