OpenClaw省錢攻略：月省兩萬，我做對了什麼？

原文標題：為什麼我的 OpenClaw 會在一天內燒掉 21.5M 代幣（Token）（以及實際修復方式）
原文作者：MOSHIII
編譯：Peggy，BlockBeats

編者備註：在 Agent 應用快速普及的當下，許多團隊發現一個看似反常的現象：系統運行一切正常，但代幣成本卻在不知不覺中持續攀升。本文通過對一次真實 OpenClaw 工作負載的拆解發現，成本爆炸的原因往往並不來自使用者輸入或模型輸出，而是被忽略的上下文快取重播（cached prefix replay）。模型在每一輪呼叫中反覆讀取龐大的歷史上下文，從而產生大量代幣消耗。

文章結合具體 session 數據，展示了工具輸出、瀏覽器快照、JSON 日誌等大型中間產物如何被不斷寫入歷史上下文，並在 agent 迴圈中被重複讀取。

通過這一案例，作者提出了一套清晰的優化思路：從上下文結構設計、工具輸出管理到 compaction 機制配置。對於正在構建 Agent 系統的開發者而言，這不僅是一份技術排查記錄，也是一份真金白銀的省錢攻略。

以下為原文：

我分析了一次真實的 OpenClaw 工作負載，發現了一個我認為許多 Agent 使用者都會認出來的模式：

代幣使用量看起來很「活躍」

回覆看起來也很正常

但代幣消耗卻突然爆炸式增長

下面是這次分析的結構拆解、根本原因，以及實際可行的修復路徑。

TL;DR

最大的成本驅動因素並不是使用者消息太長。而是巨量的快取前綴（cached prefix）被反覆重放。

從 session 數據來看：

總 tokens：21,543,714

cacheRead：17,105,970（79.40%）

輸入：4,345,264（20.17%）

輸出：92,480（0.43%）

換句話說：大多數調用的成本，其實並不是在處理新的使用者意圖，而是在反覆讀取龐大的歷史上下文。

「等等，怎麼會這樣？」的時刻

我原本以為高 token 使用量來自：非常長的使用者提示、大量輸出生成，或者昂貴的工具調用。

但真正主導的模式是：

輸入：幾百到幾千個 token

cacheRead：每次調用 17 萬到 18 萬個 token

也就是說，模型每一輪都在反覆讀取同一個龐大的穩定前綴。

數據範圍

我分析了兩個層面的數據：

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

Token 實際消耗在哪裡？

1）Session 集中

有一個 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

2）行為集中

token 主要來自：

toolUse：16,372,294

stop：5,171,420

說明問題主要出在 工具調用鏈循環，而不是普通聊天。

3）時間集中

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 前綴重新讀取它們。

具體範例（來自 session 檔案）

在以下位置反覆出現了 體量巨大的上下文塊：

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 萬字元）

「重複內容浪費」vs「緩存重放負擔」

我也測量了 單次呼叫內部的重複內容比例：

重複比例約：1.72%

確實存在，但並不是主要問題。

真正的問題是：緩存前綴的絕對體量太大

結構是：巨大的歷史上下文、每輪呼叫重新讀取、上面只疊加少量新的輸入

因此優化重點不是去重，而是上下文結構設計。

為什麼 Agent 迴圈特別容易出現這個問題？

三個機制互相疊加：

1、大量工具輸出被寫入歷史上下文

2、工具迴圈會產生大量短間隔呼叫

3、前綴變化很小 → cache 每次都會重新讀取

如果 context compaction 沒有穩定觸發，問題會迅速放大。

最重要的修復策略（按影響排序）

P0—不要把巨大的工具輸出塞進長期上下文

對於超大工具輸出：

·保留摘要 + 引用路徑 / ID

·原始 payload 寫入文件 artifact

·不要把完整原文保留在 chat history

優先限制這些類別：

·大型 JSON

·長目錄列表

·瀏覽器完整快照

·子 Agent 完整 transcript

P1—確保 compaction 機制真正生效

在這份數據中，配置兼容性問題多次出現：compaction key 無效

這會悄悄關閉優化機制。

正確做法：只使用版本兼容配置

然後驗證：

openclaw doctor --fix

並檢查啟動日誌確認 compaction 被接受。

P1—減少reasoning文本持久化

避免長推理文本被反覆 replay

生產環境中：保存簡短摘要，而不是完整reasoning

P2—改善 prompt caching 设計

目標 不是最大化 cacheRead。目標是，在緊湊、穩定、高價值的前綴上使用 cache。

建議：

·把穩定規則放進 system prompt

·不要把不穩定數據放進穩定前綴

·避免每輪注入大量 debug 數據

實操止損方案（如果是我明天要處理）

1、找出 cacheRead 佔比最高的 session
2、對 runaway session 執行 /compact
3、對工具輸出加入 截斷 + artifact 化
4、每次修改後重新跑 token 統計

重點追蹤四個 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 系統看起來一切正常，但成本卻在持續上升，可以先檢查一個問題：你付費的是新的推論，還是在大規模重放舊上下文？

在我的案例裡，絕大部分成本其實來自 上下文重放。

一旦你意識到這一點，解決方案也就很明確：嚴格控制進入長期上下文的數據。

[原文連結]