logo

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

By: blockbeats|2026/03/10 18:00:06
0
分享
copy
原文標題：為什麼我的 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 系統看起來一切正常，但成本卻在持續上升，可以先檢查一個問題：你付費的是新的推論，還是在大規模重放舊上下文？

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

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

[原文連結]

猜你喜歡

油價退燒，加密反彈

为什么石油和比特币的价格，总是背道而驰

a16z 發佈 Top 100 AI 應用榜單，模型正在走出瀏覽器和應用

隨著視訊創作、Agent 工具和 AI 瀏覽器興起，AI 正從聊天產品演變為新的平台與操作環境。

如果只看新聞，你可能已經誤判了這場伊朗衝突

帶著輿論引導目的，西方媒體捏造戰事報導

ERC-8183：為價值三百萬美元的鏈上代理生意，撰寫規則

三百萬美元之前跑在沒有規則的地方，今天，規則寫下來了

AI失誤「打賞」26萬美元後，24小時把錢賺了回來

AI 觺醒似乎真的在發生：它們已經開始學會自己賺錢，甚至賺錢能力比人類更強。

Arthur Hayes：為何HYPE是5倍潛力標的？

Arthur Hayes 對 HYPE 在 2026 年 8 月的目標價是 150 美元。

熱門幣種

最新加密貨幣要聞

19:01

貝萊德向Coinbase存入1,133.78枚比特幣與27,189枚以太坊

BlockBeats 消息，3 月 10 日，据 OnchainLens 監測，貝萊德已向 Coinbase 存入 1,133.78 枚比特幣，價值 8024 萬美元；以及 27,189 枚以太坊，價值 5610 萬美元。
19:01

鏈上白銀日內上漲5.2%，「白銀最大多頭」多倉解套浮盈47萬美元

BlockBeats 消息，3 月 10 日，据 Hyperinsight 监测显示，Hyperliquid 上 SILVER（白銀）價格近 24 小時上漲 5.2%，現報 88.17 美元。曾在 2 月 28 日高點追漲的白銀最大多頭巨鯨（0x63c），經過一周反覆做 T 摊平成本，今日終扭虧為盈，浮盈達 47 萬美元（13.5%），單日盈利約 50 萬美元。當前其持有 3 倍槓桿 SILVER 多單，持倉規模 830 萬美元，均價 83.16 美元，為鏈上白銀最大多頭。此外，該地址還持有 3 倍槓桿 GOLD（黃金）多單，規模 300 萬美元，均價 5093 美元。
19:01

美股盤前加密概念股普漲，Strategy漲2.79%

BlockBeats 消息，3 月 10 日，据 Bitget 行情数据，美股盘前加密概念股普涨，其中：Strategy（MSTR）涨 2.79%；Coinbase（COIN）涨 3.11%；Circle（CRCL）涨 1.66%；MARA Holdings（MARA）涨 1.85%；Riot Platforms（RIOT）涨 2.11%；BitMine Immersion（BMNR）涨 1.16%；SharpLink Gaming（SBET） 涨 1.97%。
19:01

「美、布兩油主力空軍」短時連續滾倉CL空單至1260萬規模，現為鏈上原油最大空頭

BlockBeats 消息，3 月 10 日，据 Hyperinsight监测显示，「美、布两油主力空军」地址（0x985f…）在约半小时内对其 CL（WTI 原油）空头仓位进行连续滚仓，累计增持约 26960 份 CL 空单，总价值约 342 萬美元。該地址經過此輪連續加倉，其 CL 空單持倉總價值已增至 1260 萬美元，均價進一步降至 88.03 美元。當前該倉位浮動盈利約 4.16 萬美元，收益率為 0.77%，清算價為 123.3 美元。該筆 CL 空單於過去 7 小時內建倉並一路滾倉。與此同時，該地址在過去數小時同步加倉 BRENTOIL（布倫特原油）空單，持倉規模擴大至 620 ...
18:46

數據：BTC 全網合約持倉量 24h 增長 5.08%

ChainCatcher 消息，据 Coinglass 資料顯示，BTC 全網合約持倉量在過去 24 小時增長 5.08%，當前總持倉量為 461.24 億美元。其中 Binance 持倉量為 81.45 億美元，OKX 持倉量為 29.75 億美元，Bybit 持倉量為 39.84 億美元，Gate 持倉量為 47.87 億美元。
閱讀更多
社區
iconiconiconiconiconiconiconicon

聯繫客服Bot：@WEEX_support_smart_Bot

VIP服務：support@weex.com