OpenClaw省錢攻略：月省兩萬，我做對了什麼？
本文通過對一次真實OpenClaw工作負載的拆解發現，成本爆炸的原因往往並不來自用戶輸入或模型輸出，而是被忽視的上下文緩存重放（cached prefix replay）。模型在每一輪調用中反覆讀取龐大的歷史上下文，從而產生巨量token消耗。
根本原因分析
在一次真實的工作負載中，發現token使用量看似活躍，回覆也正常，但成本卻突然爆炸式增長。數據顯示：
- 總tokens：21,543,714
- cacheRead：17,105,970（79.40%）
- input：4,345,264（20.17%）
- output：92,480（0.43%）
說明大多數調用的成本並非在處理新的用戶意圖，而是在反覆讀取巨大的歷史上下文。
主要問題來源
token消耗主要來自：
- toolUse：16,372,294
- stop：5,171,420
問題出在工具調用鏈循環，而非普通聊天。
巨大緩存前綴內容
並非對話內容，而是大型中間產物：
- 巨大的toolResult數據塊
- 長的reasoning / thinking traces
- 大型JSON快照
- 文件列表
- 瀏覽器抓取數據
- 子Agent的對話記錄
在最大session中，字符量大約為：
- toolResult:text：366,469 字符
- assistant:thinking：331,494 字符
- assistant:toolCall：53,039 字符
一旦這些內容被保留在歷史上下文中，後續每次調用都可能通過cache前綴重新讀取。
優化策略
針對問題提出以下修復路徑：
- P0—不要把巨大的工具輸出塞進長期上下文：保留摘要 + 引用路徑/ID，原始payload寫入文件artifact，不要把完整原文保留在chat history。優先限制大型JSON、長目錄列表、瀏覽器完整快照、子Agent完整transcript。
- P1—確保compaction機制真正生效：使用版本兼容配置，執行
openclaw doctor --fix，並檢查啟動日誌確認compaction被接受。 - P1—減少reasoning文本持久化：避免長推理文本被反覆replay，生產環境中保存簡短摘要，而非完整reasoning。
- P2—改善prompt caching設計：目標是在緊湊、穩定、高價值的前綴上使用cache。建議將穩定規則放進system prompt，避免不穩定數據放進穩定前綴，避免每輪注入大量debug數據。
實操止損方案
如果是我明天要處理，應：
- 找出cacheRead佔比最高的session
- 對runaway session執行/compact
- 對工具輸出加入截斷 + artifact化
- 每次修改後重新跑token統計
重點追蹤四個KPI：
- cacheRead / totalTokens
- toolUse avgTotal/call
- >=100k token的調用次數
- 最大session佔比
若優化生效，應看到：
- 100k+ token調用明顯減少
- cacheRead佔比下降
- toolUse調用權重下降
- 單個session的主導程度降低
若這些指標無變化，說明上下文策略仍過於寬鬆。