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

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

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

因?yàn)槊看胃鶤gent對話，前面那些系統(tǒng)指令、工具定義、上下文，幾乎都會重復(fù)。

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

以下為Avi Chawla的博文——

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

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

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

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

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

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

解決辦法就是提示詞緩存。但想要用好這項(xiàng)技術(shù)，需要先理解底層運(yùn)行原理。

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

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

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

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

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

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

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

KV 緩存的工作原理

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

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

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

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

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

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

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

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

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

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

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

成本分析

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

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

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

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

以下為 Anthropic 旗下各 Claude 模型的對應(yīng)計費(fèi)情況。

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

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

Claude Code 的設(shè)計核心目標(biāo)僅有一個：保持緩存活躍。

以下從計費(fèi)角度還原真實(shí) 30 分鐘編程對話全過程：

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

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

第 1~5 分鐘
用戶下達(dá)指令，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ā)方案，用戶確認(rèn)后，Claude Code 開始修改代碼。

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

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

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

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

本次緩存效率達(dá) 92%，其中 184 萬 token 為緩存讀取，最終總費(fèi)用僅 1.15 美元，單任務(wù)成本降低 81%。

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

基于哈希緩存的局限性

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

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

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

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

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

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

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

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

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

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

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

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

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

提示詞按如下順序排版：

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

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

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

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

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

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

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

想要校驗(yàn)緩存是否正常生效，可監(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)控服務(wù)可用性一樣持續(xù)跟蹤該指標(biāo)。

核心總結(jié)

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

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

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

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