作者拆解一次 OpenClaw 工作負載後發現，79% 的 token 消耗來自快取字首重播（cached prefix replay），而非使用者輸入或模型輸出，並提出三大上下文最佳化策略，有效壓低 AI Agent 營運成本。本文源自 MOSHIII 所著文章《Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)》，由動區編輯、翻譯。
（前情提要：MEXC 躋身全球 Top 3 CEX，深化現貨與大宗商品市場布局）
（背景補充：熊市靠穩定幣生息：各平台利息比較 OSL 18%、MEXC 15%、Binance 8%……）
我分析了一次真實的 OpenClaw 工作負載，發現了一個我認為很多 Agent 使用者都會認出來的模式：
token 使用量看起來很「活躍」
回覆看起來也很正常
但 token 消耗卻突然爆炸式增長
下面是這次分析的 結構拆解、根本原因，以及實際可行的修復路徑。
最大成本驅動：快取前綴重播
最大的成本驅動因素 並不是使用者訊息太長。而是巨量的快取字首（cached prefix）被反覆重放。
從 session 資料來看：
總 tokens：21,543,714
cacheRead：17,105,970（79.40%）
input：4,345,264（20.17%）
output：92,480（0.43%）
換句話說：大多數呼叫的成本，其實並不是在處理新的使用者意圖，而是在反覆讀取巨大的歷史上下文。
我原本以為高 token 使用量來自：非常長的使用者 prompt、大量輸出生成、或者昂貴的工具呼叫。
但真正主導的模式是：
input：幾百到幾千 token
cacheRead：每次呼叫 17 萬到 18 萬 token
也就是說，模型 每一輪都在反覆讀取同一個巨大的穩定字首。
Session 數據拆解
我分析了兩個層面的資料：
1、執行時日誌（runtime logs）
2、會話記錄（session transcripts）
需要說明的是：
執行日誌主要用於觀察行為訊號（如重啟、報錯、配置問題）
精確的 token 統計來自 session JSONL 中的 usage 欄位
使用的指令碼：
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
生成的分析檔案：
tmp/session_token_stats_v2.txt
tmp/session_token_stats_v2.json
tmp/session_duplicate_waste.txt
tmp/session_duplicate_waste.json
tmp/session_duplicate_waste.png
有一個 session 的消耗遠高於其他：
570587c3-dc42-47e4-9dd4-985c2a50af86：19,204,645 tokens
然後是明顯斷崖式下降：
ef42abbb-d8a1-48d8-9924-2f869dea6d4a：1,505,038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5：649,584
token 主要來自：
toolUse：16,372,294
stop：5,171,420
說明問題主要出在 工具呼叫鏈迴圈，而不是普通聊天。
Token 峰值從何而來？
token 峰值並不是隨機的，而是集中在幾個小時段：
2026-03-08 16:00：4,105,105
2026-03-08 09:00：4,036,070
2026-03-08 07:00：2,793,648
並不是對話內容，而主要是 大型中間產物：
巨大的 toolResult 資料塊
很長的 reasoning / thinking traces
大型 JSON 快照
檔案列表
瀏覽器抓取資料
子 Agent 的對話記錄
在最大 session 中，字元量大約是：
toolResult:text：366,469 字元
assistant:thinking：331,494 字元
assistant:toolCall：53,039 字元
一旦這些內容被保留在歷史上下文中，後續每次呼叫都可能 透過 cache 字首重新讀取它們。
在以下位置反覆出現了 體量巨大的上下文塊：
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
大型閘道器 JSON 日誌（約 3.7 萬字元）
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
瀏覽器快照 + 安全封裝（約 2.9 萬字元）
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
巨大的檔案列表輸出（約 4.1 萬字元）
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status 狀態快照 + 大型 prompt 結構（約 3 萬字元）
我也測量了 單次呼叫內部的重複內容比例：
重複比例約：1.72%
確實存在，但並不是主要問題。
真正的問題是：快取字首的絕對體量太大
結構是：巨大的歷史上下文、每輪呼叫重新讀取、上面只疊加少量新的輸入
因此最佳化重點不是去重，而是上下文結構設計。
上下文膨脹的三重機制
三個機制互相疊加：
1、大量工具輸出被寫入歷史上下文
2、工具迴圈會產生大量短間隔呼叫
3、字首變化很小 → cache 每次都會重新讀取
如果 context compaction 沒有穩定觸發，問題會迅速放大。
實戰優化策略
對於超大工具輸出：
·保留摘要 + 引用路徑 / ID
·原始 payload 寫入 檔案 artifact
·不要把完整原文保留在 chat history
優先限制這些類別：
·大型 JSON
·長目錄列表
·瀏覽器完整快照
·子 Agent 完整 transcript
在這份資料中，配置相容性問題多次出現：compaction key 無效
這會悄悄關閉最佳化機制。
正確做法：只使用版本相容配置
然後驗證：
openclaw doctor –fix
並檢查啟動日誌確認 compaction 被接受。
避免長推理文字被反覆 replay
生產環境中：儲存簡短摘要，而不是完整 reasoning
目標 不是最大化 cacheRead。目標是，在緊湊、穩定、高價值的字首上使用 cache。
建議：
·把穩定規則放進 system prompt
·不要把不穩定資料放進穩定字首
·避免每輪注入大量 debug 資料
1、找出 cacheRead 佔比最高的 session
2、對 runaway session 執行 /compact
3、對工具輸出加入 截斷 + artifact 化
4、每次修改後重新跑 token 統計
追蹤四個關鍵 KPI
重點追蹤四個 KPI：
cacheRead / totalTokens
toolUse avgTotal/call
>=100k token 的呼叫次數
最大 session 佔比
如果最佳化生效，你應該看到：
100k+ token 呼叫明顯減少
cacheRead 佔比下降
toolUse 呼叫權重下降
單個 session 的主導程度降低
如果這些指標沒有變化，說明你的上下文策略仍然過於寬鬆。
python3 scripts/session_token_breakdown.py ‘sessions’ \
–include-deleted \
–top 20 \
–outlier-threshold 120000 \
–json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py ‘sessions’ \
–include-deleted \
–top 20 \
–png-out tmp/session_duplicate_waste.png \
–json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
如果你的 Agent 系統看起來一切正常，但成本卻在持續上升，可以先檢查一個問題：你付費的是新的推理，還是在大規模重放舊上下文？
在我的案例裡，絕大部分成本其實來自 上下文重放。
一旦你意識到這一點，解決方案也就很明確：嚴格控制進入長期上下文的資料。
📍相關報導📍
MEXC 躋身全球 Top 3 CEX，深化現貨與大宗商品市場布局
熊市靠穩定幣生息：各平台利息比較 OSL 18%、MEXC 15%、Binance 8%……
加密貨幣不再有趣？建設者集體出走 AI，智慧體公司或許是web3產業最終解答
