為什麼你的 AI 代理正在燒光 Token（以及如何修復）

上週我們在生產環境的日誌中發現了一個令人警覺的現象：一個普通的 OpenClaw 對話在單次 LLM 請求中膨脹到了 424,000 個輸入 token。這大約相當於一本 300 頁書的長度 — 每發一條訊息就要傳送給 API 一次。

代理運作正常。沒有錯誤，沒有崩潰。它只是安靜地在 API 呼叫上花費了比實際需要多 10 到 20 倍的費用。

如果你正在運行 AI 代理 — 無論是自架還是透過平台 — 這種情況很可能也正在發生。以下是原因和解決方法。

是什麼在消耗你的 Token

像 OpenClaw 這樣的 AI 代理透過維護對話歷史來運作，每條新訊息都會將歷史記錄一起發送給 LLM。每一輪對話包含：

• 系統提示（指令、人格設定、工具定義）
• 所有先前的使用者訊息和助手回覆
• 代理執行過每個工具呼叫的結果

最後一項就是問題所在。

當代理執行命令、讀取檔案或查詢 API 時，該操作的完整輸出會被儲存在對話歷史中。單個 config.schema 命令可能返回 30,000 個字元的 JSON。一次完整的會話記錄轉儲可能超過 50,000 個字元。這些輸出悄悄地堆積起來，因為代理會繼續工作 — 它永遠不會告訴你上下文正在膨脹。

以下是我們 424K 案例中的 token 分佈：

來源	Token 數	佔比
工具呼叫結果（累積）	~350,000	82%
先前的助手回覆	~45,000	11%
系統提示 + 工具定義	~20,000	5%
使用者訊息	~9,000	2%

超過 80% 的 token 是代理已不再需要的舊工具輸出。它們只是停留在對話歷史中，每一輪都被重新傳送，每次都在花錢。

這要花多少錢

Token 定價因供應商而異，但費用累積很快。以下是使用主流模型時 424K 輸入 token 每條訊息的費用：

模型	輸入價格（每百萬 token）	424K token 請求的費用
Claude Sonnet 4.5	$3.00	$1.27
Claude Opus 4	$15.00	$6.36
GPT-4o	$2.50	$1.06
Gemini 2.5 Pro	$1.25	$0.53

如果代理在這種膨脹水平下每天處理 50 條訊息，你每月僅在輸入 token 上就會浪費 $50–300 的 API 費用 — 而且這只是單個使用者。

另一個成本不太明顯：品質下降。大多數 LLM 在上下文視窗被塞滿時表現會變差。重要的指令被埋在大量過時的工具輸出下面。模型的注意力被稀釋。回覆變得不太相關且不太連貫。

上下文裁剪如何解決這個問題

上下文裁剪是一種策略，在發送給 LLM 之前自動修剪對話歷史中舊的、低價值的內容。概念很簡單：保留代理維持連貫性所需的內容，丟棄不需要的。

OpenClaw 支援一種稱為 cache-ttl 的裁剪模式，分兩個階段運作：

軟修剪在上下文使用量達到閾值時啟動（預設為模型上下文視窗的 75%）。它會截斷較舊的工具輸出 — 保留前 2,000 和後 2,000 個字元，移除中間部分。這保留了足夠的上下文讓代理理解工具返回了什麼，而不用攜帶完整的負載。

硬清除在更高的閾值時啟動（預設為 90%）。它完全移除舊的工具輸出，只保留最近的助手回覆，這樣代理不會失去對話的脈絡。

兩個階段都是漸進式的 — 只在需要時才啟動，並優先移除最舊、最大的工具輸出。

我們做了什麼改變

在執行環境版本 0.6.11 中，我們為所有 OCLauncher 實例預設啟用了上下文裁剪。以下是具體設定：

{
  "contextPruning": {
    "mode": "cache-ttl",
    "ttl": "5",
    "keepLastAssistants": 5,
    "softTrimRatio": 0.75,
    "hardClearRatio": 0.9,
    "minPrunableToolChars": 2000,
    "softTrim": {
      "maxChars": 20000,
      "headChars": 2000,
      "tailChars": 2000
    },
    "hardClear": {
      "enabled": true
    }
  }
}

每個設定的作用：

• ttl: 5 — 超過 5 輪的工具輸出變為可裁剪狀態
• keepLastAssistants: 5 — 始終保留最近 5 次助手回覆
• softTrim — 將大型工具輸出截斷至最多 20K 字元，保留頭尾各 2K
• hardClear — 當上下文達到 90% 時，完全移除舊的工具輸出
• minPrunableToolChars: 2000 — 不裁剪小型輸出

我們還為代理本身新增了使用指引：避免呼叫會產生巨大輸出的命令（如完整的 schema 轉儲），查詢歷史記錄時使用 limit 參數，並偏好簡潔的工具使用方式。

預期結果：那個 424K 的請求降至大約 30,000–50,000 個 token — 減少了 88–93%。代理的工作方式不變，只是不再拖著一本小說份量的過時資料。

你可以做什麼

如果你使用 OCLauncher：不需要做任何事。0.6.11 及以後的版本自動包含這些預設值。你可以在儀表板上查看你的版本並在需要時更新。

如果你自架 OpenClaw：將上面的 contextPruning 區塊加到你的 openclaw.json 檔案中的 agents.defaults 下。OpenClaw 的檔案監聽器會自動偵測變更 — 不需要重新啟動。

如果你在建構自己的代理：無論使用什麼框架，這個原則都適用。定期檢查你的對話歷史。尋找跨輪次持續存在的大型工具輸出。實作某種形式的修剪 — 即使是簡單的「丟棄超過 N 輪的工具結果」策略也能為你節省大量費用。

總結：一個看似運行正常的 AI 代理，仍然可能將大部分 token 預算浪費在過時的上下文上。幾行配置就能在不改變行為的情況下將你的 API 費用削減 90%。

---

想要運行自己的 AI 代理而不需要管理基礎設施？註冊 OCLauncher — 上下文裁剪和自動更新已內建於服務中。