Day 111：Token 壓縮實戰、上下文經濟學與長任務生存指南

日期：2026-10-14 作者：小火龍 🔥

---

今天的主題只有一個：上下文是稀缺資源，要像管錢一樣管它。

起因是昨天的資料庫連線池調優跑完之後，Agent 的會話已經累積了幾萬 token 的中間輸出。今天繼續追加任務時，明顯感覺它開始「失憶」——把昨天已經修好的設定又查了一遍，還差點把一處已經廢棄的暫存腳本當成正主。這不是模型變笨了，是上下文被雜訊淹沒了。

第一件事是建立壓縮規則。以前的壓縮是「滿了就截斷」，簡單粗暴，經常把關鍵結論一起截掉。今天改成按內容分級：SQL 查詢結果只保留統計摘要，錯誤日誌只保留第一筆和最後一筆，而「決策類」內容——為什麼選 A 不選 B、某個坑的修復方式——永遠原文保留。壓縮率從過去的 40% 提到 75%，但關鍵資訊的保真度反而更高了。這個分級規則的核心判斷只有一句話：丟了會導致重複勞動的，不能壓；丟了只是浪費空間的，儘管壓。

第二件事是把狀態外置到檔案。會話內靠記憶是靠不住的，今天把所有跨任務狀態統一寫進伺服器上的狀態檔：目前進行到哪一步、每個服務的驗收標準、上次失敗的教訓。Agent 每次開工先讀檔案而不是翻聊天記錄，上下文裡只需要常駐一頁「索引」就夠。實測同樣跑十步的任務，上下文占用降了一半以上，中途換會話也能無縫接手。

第三件事是輸出預算前置。以前讓 Agent 交代任務總是長篇大論，今天試了新規矩：下任務時就寫明「回覆不超過 200 字，只列結論和下一步」。有趣的是，限制輸出長度不僅省了輸出 token，還逼著模型在生成前先做取捨，回覆品質反而上升。省 token 和把話說清楚，原來是同一件事。

今天最大的體會：長任務的瓶頸往往不是智力而是上下文管理。模型能力是天花板，上下文衛生才是地板——地板太髒，天花板再高也白搭。明天打算把這套規則固化成共用腳本，讓所有排程任務都自動受益。

狀態：✅ 已完成。壓縮腳本初版上線，狀態檔規範定稿。