與 AI 協作分析 · 6/7
Context 還放得下，就應該一直往裡面放嗎？
假設一個 Agent 有 1M 的 context window，到了 800k 才觸發自動壓縮。這只是用來討論的假設，不代表某個產品的規格或壓縮門檻。我想問的是：眼前這個分析，真的需要一直帶著這 800k 的內容嗎？
我更想根據分析進展，決定哪些 context 應該繼續帶著走，以及哪些內容已經可以先保存備查。
Context 還放得下，就應該繼續往裡面放嗎？
與 Agent 分析一段時間後，對話裡通常已經有好幾版 SQL、不同分母算出來的結果、初步猜測，以及一輪輪的修正。
比如分析活動參與率，我們可能先用全體活躍用戶當分母，發現不合理，又試了符合活動資格的用戶，最後確認採用已解鎖活動入口的人。
這些討論都有價值。但口徑確認後，接下來做用戶分群，還需要每一輪都帶著前面所有的試算與討論嗎？
如果持續把這些內容放進模型輸入，除了 token 消耗，我更在意的是：目前採用的定義，會不會跟那些已經放棄的方案混在一起？（前面才說這個分母不用了，後面它又拿回來算，原來我們剛剛只是禮貌性地交換意見）。
接近容量門檻時，把對話整理成摘要，是一種常見的處理方式。但 context 還剩多少空間，跟這一階段的分析是不是已經可以收斂，是兩件事，並且有時會有衝突。
有些選擇在很早的時候就確認了，但當時沒有壓縮；對話快裝不下時剛好在進行大型連貫分析，壓縮完後好多數據要重拿。
我們其實一直在告訴 Agent，哪些內容可以收斂了
仔細想想，分析時我們常說的幾句話，其實已經提供了很明確的訊號：
| 協作中的訊號 | 應留下的內容 | 仍須分清的狀態 |
|---|---|---|
| 「這個分母確認了，接著往下做」 | 採用的口徑、選擇原因、適用範圍 | 採用口徑不等於所有結果都已驗證 |
| 「這條路先停，樣本量不夠」 | 嘗試的方法、停止原因、證據位置與重啟條件 | 停止不等於成功完成 |
| 「這個結果先留著，等等跟另一組比較」 | 結果與位置，以及尚未完成的比較 | 部分結果不能先當成最終結論 |
我們原本就在做這些判斷。如果能在當下把它們整理成後續可用的狀態，就不必每次都從整段對話裡重新辨認：哪些只是提過、哪些已經確認、哪些還欠一次驗證。
我暫時把這種方式叫做「自然壓縮」：隨著分析推進，根據人的選擇，讓 context 一段段收斂。
通用壓縮需要從已有記錄裡辨認重點；分析工作流則多了一個可以利用的條件——我們正在審閱、驗證、調整方法，而這些選擇本身就能成為整理的依據。
當然，這也包含「先不要收斂」。人說先保留、還沒確認的東西，就應該繼續維持待驗證的狀態，不能因為要寫一份漂亮的摘要，就順手把問題解決了。
這也讓我想到，當 Agent 產出越來越快，驗證這些產出的成本怎麼辦？至少在 context 收斂時，「我同意先這樣做」跟「這個結果已經驗證過」得分清楚。
採用的口徑、通過的檢查、還沒排除的疑問，要連同對應證據一起留下來，不然壓縮幾輪後，很容易只剩一句看起來什麼都確認過的結論。
當下可以少帶，但需要時要找得回來
不過，壓縮之後就真的不會再用到了嗎？
主管在會議上追問：「你當時怎麼判斷這群人的樣本不夠？」如果只剩一句「樣本不足，已停止」，我們還是得回頭找當時的 SQL、樣本分布，以及採用的判斷標準。
只靠摘要，通常沒辦法還原被省略的細節。所以我認為這套方法要成立，得同時處理「目前帶著什麼」與「細節存在哪裡」。
- 目前的 context：採用的計畫、口徑、必要理由、未解問題，以及對應證據的位置
- 工作區：保存計畫版本、查詢、結果與審閱紀錄，用 lineage 串連，需要時取回
像是已停止的分析方向，後續不必一直帶著整份舊 Plan 工作，但要知道它為什麼停、證據在哪裡。如果後來補到了數據，就能回頭判斷是否值得繼續。
這也是我在 Lantide Data 裡想做的事：把分析中原本就有的審閱、執行、驗證與迭代，變成整理 context 的自然節點。Agent 根據已確認的選擇保存分析狀態，後續再依任務取得需要的內容。
這不會讓摘要變成無損壓縮，整理與取回也都有成本。但至少我們有機會根據工作的進展，決定什麼需要持續參與分析、什麼可以先保存備查。
對我來說，context 管理值得關心的，除了能裝多少，還有能不能跟著分析進度收斂，以及在問題改變時，找回需要的細節。
延伸閱讀
在 Lantide Data 中試用這套分析工作方式：下載 Lantide Data。
上一篇：團隊做過的分析，怎麼成為人與 Agent 都能接手的經驗？ · 下一篇：文件版本之外：用 Change Context 留下分析判斷的轉折