上下文管理
本地壓縮 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 壓縮是流水線上的先後環節，無需二選一。