OpenClaw一天燒掉2150萬token？三招優化策略讓成本驟降

原文標題：Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)

原文作者：MOSHIII

原文編譯：Peggy，BlockBeats

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

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

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

以下為原文：

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

token 使用量看起來很「活躍」

回覆看起來也很正常

但 token 消耗卻突然爆炸式增長

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

TL;DR

最大的成本驅動因素 並不是用戶訊息太長。而是巨量的快取前綴（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

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

數據範圍

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

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

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

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

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

原文連結