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

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

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

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

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

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

以下為Avi Chawla的博文——

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

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

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

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

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

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

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

靜態(tài)上下文與動態(tài)上下文

想要優(yōu)化提示詞，首先要區(qū)分內(nèi)容中可變與不可變的部分。

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

? 跨輪次完全不變的靜態(tài)前綴：系統(tǒng)指令、工具定義、項目上下文、行為規(guī)范。

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

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

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

KV 緩存的工作原理

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

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

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

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

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

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

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

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

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

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

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

成本分析

計費規(guī)則決定了該架構(gòu)優(yōu)化的實際價值。

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

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

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

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

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

Claude Code 30 分鐘編程實戰(zhàn)案例

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

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

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

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

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

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

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

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

第 16~25 分鐘
用戶提出修改需求，觸發(fā)更多工具調(diào)用、終端輸出，動態(tài)后綴持續(xù)累積內(nèi)容。

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

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

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

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

基于哈希緩存的局限性

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

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

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

以下為生產(chǎn)環(huán)境中真實導致緩存失效的案例：

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

? JSON 序列化工具在不同請求中調(diào)整工具結(jié)構(gòu)鍵值排序，前綴全部失效

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

由此總結(jié)三條使用原則：

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

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

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

應用到自研智能體開發(fā)

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

提示詞按如下順序排版：

1. 頂部放置系統(tǒng)指令與行為規(guī)則，對話全程不改動

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

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

4. 底部放置對話歷史、工具返回結(jié)果，作為動態(tài)后綴

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

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

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

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

? cache_creation_input_tokens：寫入緩存的 token 數(shù)量

? cache_read_input_tokens：從緩存讀取的 token 數(shù)量

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

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

核心總結(jié)

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

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

真正的難點在于細節(jié)規(guī)范：不向系統(tǒng)提示詞插入時間戳、不隨意調(diào)整工具定義順序、對話中途不切換模型、不改動緩存分界點之前的任何內(nèi)容。

Claude Code 實現(xiàn)了規(guī)模化落地，達到 92% 緩存命中率、81% 成本降幅。若你正在開發(fā)智能體，卻沒有圍繞提示詞緩存做架構(gòu)設計，將會錯失大量成本優(yōu)化空間。