更大的 Context Window 能容納更多 token，卻不保證模型能同樣可靠地找到、區分並使用每段資訊。長任務真正的問題常是 Context Rot：舊假設、工具輸出與無關內容累積後，高訊號資訊變得更難被正確取用。
「放得下」和「用得好」是兩件事
2023 年的原始研究 Lost in the Middle 測試多文件問答與 key-value retrieval，發現相關資訊位於長 context 中間時，模型表現可能顯著下降，常在開頭或結尾較好；研究也包含明確支援長 context 的模型。Lost in the Middle 論文 這項實驗不能證明每個新模型都有同樣曲線，但足以否定「只要塞得下，就能等品質使用」的簡化假設。
Anthropic 在 2025 年的工程文章使用 Context Rot 一詞，描述 token 增加時資訊回憶能力可能下降，並把 context 視為有限的 attention budget。Effective context engineering for AI agents 因此採購模型時只比較 context window 上限，像只看倉庫坪數卻不看索引、標籤與揀貨流程。
長任務常見的三種腐化
1. 舊資訊污染
第 10 輪暫定「活躍用戶 = 30 天內登入」，第 40 輪已改成「90 天內付費」，但兩段都留在 history。若沒有明確 artifact 標示最新版，模型可能混用兩種定義。
2. 工具輸出淹沒決策
多次 show tables、schema、查詢預覽與錯誤堆疊會快速擴張 context。真正關鍵的 join key 或使用者核准條件，反而只佔短短一句。
3. 對話成為唯一狀態
當計畫、進度、來源與限制全靠聊天順序維持，任何截斷、fork 或跨日接手都容易失去脈絡。更長的 history 只是延後問題，不是解決問題。
四種比「一直加長」更有效的做法
Compaction：壓縮軌跡，保留可回查指標
將舊工具結果整理成步驟摘要，但保留 step_id、快取名、SQL 來源或錯誤代碼，必要時再讀完整內容。壓縮不是刪光細節，而是把細節移出每輪必帶 context。
Structured artifacts：把決策移出聊天
用 Plan 保存核准口徑，用 SQL 保存取數邏輯，用 Report 保存結論與 limitations。Artifacts 有名稱、狀態和版本，比「往上滑找到那句話」穩定。
On-demand retrieval：需要時再取
每輪只帶小型 summary；當任務碰到特定表、Reference 或舊步驟，再透過工具取完整內容。這能降低無關 token，但 retrieval 本身也可能漏抓，因此關鍵決策仍應結構化並可人工檢查。
Memory governance：只保留跨任務仍有效的知識
把「本公司財務季定義」放入經核准 Memory，把「這次嘗試過但失敗的 SQL」留在執行紀錄。兩者生命週期不同，不該一起永久注入。
Plan、Reference、Memory 怎麼分工
| 資訊 | 應放位置 | 原因 |
|---|---|---|
| 本次分析的分母、時間窗、checkpoint | Plan | 與任務綁定、需審閱 |
| 大型狀態碼表、欄位映射 | Reference | 按需全文讀取，不必每輪塞入 |
| 跨專案穩定規則 | 核准後的 Memory | 可重用，但需治理 |
| SQL 執行結果與錯誤 | Query steps／evidence | 可回查，不當永久知識 |
| 最終結論與限制 | Report | 形成可交付成果 |
這張分工表的目標，是讓 context window 裡留下「目前做對下一步所需的資訊」，而不是保存所有曾經發生的事。
Lantide Data 如何處理長分析 Context
Lantide Data 的 Context Engine 每輪提供精簡 Summary，完整 schema 與文件由工具按需取得；長對話採 history 截斷，單輪多工具則可做 mid-turn compaction。近期查詢步驟以精簡 ledger 摘要保留，完整 SQL 仍可回到快取來源或步驟紀錄查看。相關設計見Context 工程說明與AI Agent 架構的 token 壓縮策略。
分析內容則分流到 Plan、Reference、SQL 分頁、Report 和已核准 Agent Memory，而不是只依賴聊天。這讓長任務跨多輪時仍有外部狀態可核對，也讓重要 artifact 能被人審閱。
這些機制是風險控制，不是 Context Rot 的「永久解法」。模型、retrieval、摘要都可能遺漏細節；對高風險分析，仍應在 Execute 前審 Plan、在 Report 前核對 evidence，並在 context 接近上限或任務明顯轉向時開新對話或新 Plan。
結語
Context Window 大有價值，但它是容量規格，不是品質保證。長任務應把聊天視為互動介面，把 Plan、SQL、Reference、Memory 與 Report 當作真正狀態；再用 compaction 和按需檢索控制每輪訊號密度。先整理 context，再考慮換更大的 window。