上下文管理
本地壓縮 vs LLM 壓縮
壓縮上下文有兩條路：本地處理（正則替換、截斷）零成本但粗糙，LLM 摘要有成本但精準。該點樣揀？答案係：兩條都用，但有先後順序。
兩種方式對比
| 維度 | 本地壓縮 | LLM 壓縮 |
|---|---|---|
| 原理 | 正則匹配、字符截斷、模板替換 | 讓另一個 LLM 讀一遍後寫摘要 |
| 成本 | 零（純本地計算） | 要花錢（調用一次 API） |
| 延遲 | <1ms | 1~5 秒 |
| 效果 | 粗糙，可能漏咗關鍵資訊 | 精準，能保留核心語義 |
| 適合場景 | 工具輸出、JSON 結果、重複內容 | 多輪對話摘要、複雜上下文濃縮 |
案例對比：同一段對話的兩種壓縮
本地壓縮
原始對話（10 輪 · 4200 tokens）：
用戶：幫我查吓北京去上海嘅高鐵
AI：好呀，而家幫你查…（200字詳細回覆）
[工具] 12306查詢結果：G1次07:00-11:28¥553、G3次08:00-12:35¥553、G7次09:00-13:28¥553…（共15條結果，800字）
AI：共找到15個車次，推薦G1次…（300字分析）
用戶：G1次唔錯，幫我睇吓有冇商務座
[工具] 座位查詢結果：{json數據500字}
AI：G1次商務座餘票3張，¥1748…（200字）
用戶：好，就商務座，再幫我查吓酒店
[工具] 酒店搜索結果…（600字）
AI：推薦浦東香格里拉…（400字）
用戶：訂呢間酒店，幫我做個出行清單
用戶：幫我查吓北京去上海嘅高鐵
AI：好呀，而家幫你查…（200字詳細回覆）
[工具] 12306查詢結果：G1次07:00-11:28¥553、G3次08:00-12:35¥553、G7次09:00-13:28¥553…（共15條結果，800字）
AI：共找到15個車次，推薦G1次…（300字分析）
用戶：G1次唔錯，幫我睇吓有冇商務座
[工具] 座位查詢結果：{json數據500字}
AI：G1次商務座餘票3張，¥1748…（200字）
用戶：好，就商務座，再幫我查吓酒店
[工具] 酒店搜索結果…（600字）
AI：推薦浦東香格里拉…（400字）
用戶：訂呢間酒店，幫我做個出行清單
壓縮結果
點擊上方按鈕查看
LLM 壓縮
原始對話（10 輪 · 4200 tokens）：
（同左邊完全一樣的原始對話）
（同左邊完全一樣的原始對話）
壓縮結果
點擊上方按鈕查看
正確順序：先免費後花錢
上下文壓縮的推薦流程
1
本地截斷
刪掉工具輸出
截斷超長JSON
截斷超長JSON
→
2
模板替換
把重複結構
替換為佔位符
替換為佔位符
→
3
檢查是否夠
還超窗口？
進入下一步
進入下一步
→
4
LLM 摘要
花錢讓 AI
精煉上下文
精煉上下文
先用免費的方法儘量壓，實在壓不下去了再花錢請 AI 幫忙，這個順序不能反。本地壓縮和 LLM 壓縮是流水綫上的先後環節，無需二選一。