Token 壓縮三刀流

三種策略，以更少的 Token 承載更多內容：無損、有損、串流。

比喻：三種打包行李的方式

你帶著一個固定大小的行李箱（LLM 的 context window）出門旅行。你的東西比裝得下的多。三種策略：

真空壓縮袋 — 不丟任何東西，全壓進去。衣服拿出來有皺摺但完好。可以完美解壓。
只帶必需品 — 只裝你真正會穿的。丟了一些東西，但重要的都在。
寄送 + 輪替 — 把不常需要的東西先寄到目的地。行李箱裡保持每日換洗的滾動庫存。需要時交換。

DuDuClaw 提供這三種策略，各自適用於不同場景。

策略 1：Meta-Token 壓縮（無損）

Meta-Token 壓縮找出文字中重複出現的模式，用較短的符號取代（類似 zip 檔案的原理，但為 token 序列設計）。

演算法掃描整個輸入，辨識出最常重複的子序列，用 meta-token 取代。這是迭代進行的——第一輪的輸出可能產生新的重複，第二輪可以進一步壓縮。

壓縮率：27-47% 的 token 數量縮減
最適合：結構化、重複性內容（JSON、程式碼、模板、對話日誌）
最不適合：高度多樣的自然語言
可逆性：100% 無損，解壓產生完全一致的原始內容
速度：快速（無 LLM 呼叫，純模式比對）

策略 2：LLMLingua-2（有損）

LLMLingua-2 的哲學不同：它保留原始格式，透過移除不太有意義的 token 來壓縮內容。

重要性評分由輕量模型完成，評估每個 token 對整體意義的貢獻。純結構性的 token（冠詞、介系詞、填充詞）得分低。承載語意內容的 token（名詞、動詞、領域術語）得分高。

壓縮率：2-5x 縮減
最適合：自然語言、對話歷史、冗長解釋
最不適合：程式碼、結構化資料（每個 token 都有意義）
可逆性：不可逆，資訊會遺失
速度：中等（需要輕量模型評估）

策略 3：StreamingLLM（KV-Cache 管理）

這項策略管理的是模型的內部記憶（KV-cache），不是單純壓縮文字本身。此概念來自一個觀察：LLM 有兩種重要的位置：

Attention sinks：對話中最開頭的幾個 token。不論內容為何，LLM 都會不成比例地關注它們。它們充當注意力機制的「錨點」。
近期上下文：最近的 token，包含即時相關的資訊。

中間的所有東西往往接收較少注意力，對回應品質的貢獻較小。

完整對話（10,000 tokens）：
  [Token 1-4]  [Token 5-8000]  [Token 8001-10000]
  ^              ^                ^
  Attention      中間段落          近期上下文
  sinks         （較少被關注）      （高度相關）
     |
     v
StreamingLLM KV-cache：
  [Token 1-4]  +  [Token 8001-10000]
  ^                ^
  保留的            保留的
  sinks            近期窗口

中間段落從快取中驅逐。

壓縮效果：理論上可實現無限長度的對話
最適合：超過 context window 的超長對話
最不適合：中間上下文至關重要的對話
速度：非常快（只是快取驅逐策略）

組合策略

三種策略不互斥，可以分層使用：

帶有結構化資料的長對話
     |
     v
步驟 1：Meta-Token 壓縮結構化部分
  （JSON 訊息、程式碼區塊 → 27-47% 更小）
     |
     v
步驟 2：LLMLingua-2 壓縮舊對話歷史
  （幾小時前的冗長交流 → 2-5x 更小）
     |
     v
步驟 3：StreamingLLM 管理剩餘上下文
  （保留 sinks + 近期窗口，驅逐其餘）
     |
     v
結果：原本要消耗 200K token 的對話
      現在舒適地塞進 50K

系統可根據內容類型自動選擇適當策略：結構化資料用 Meta-Token，自然語言用 LLMLingua-2，活躍對話用 StreamingLLM。

這為什麼重要

直接成本節省

在 LLM 世界裡，token 就是金錢。輸入 token 減少 40% 意味著該請求的 API 成本降低 40%。每日數千請求累積起來，節省相當可觀。

更大的有效上下文

透過壓縮輸入，Agent 可在相同的 context window 內考慮更多資訊。100K 的 context window 套用壓縮後，有效變成 150K-200K。Agent 有更多相關上下文可用，回應品質因此提升。

無限對話

StreamingLLM 移除了對話長度的硬性上限。沒有它，超過 context window 的對話必須被摘要或截斷，導致資訊遺失。有了它，對話可以無限延續同時保持連貫。

可組合架構

每種策略是一個獨立模組，可透過 MCP 工具存取。營運人員和 Agent 可根據具體場景個別或組合調用它們。

與其他系統的互動

Session Manager：在儲存長對話前套用壓縮。
信心路由器：壓縮後的 prompt 消耗較少 token，影響路由決策。
CostTelemetry：追蹤壓縮率及其帶來的成本節省。
記憶系統：舊的情節記憶在歸檔前可能被壓縮。

總結

Context window 有限；對話沒有。壓縮三刀流給 DuDuClaw 三個互補的工具來彌合這個差距：Meta-Token 保留所有內容（結構），LLMLingua-2 保留重要的（語意），StreamingLLM 保留現在需要的（時效性）。三者合力，將硬性限制轉化為可管理的權衡。