OpenClaw 省錢攻略：一天燒掉 2150 萬 tokens，我做對了什麼？

作者拆解一次 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 沒有穩定觸發，問題會迅速放大。 實戰優化策略 對於超大工具輸出： ·保留摘要 ...