管理 LLM 上下文窗口：'Smart Zone' 與 'Dumb Zone'
大型語言模型 (LLM) 的上下文窗口通常被宣傳為擁有巨大的容量——達到 200k、1M 甚至 2M tokens——但這些數字往往無法代表一個可用的工作集。在實務中，隨著窗口填滿，性能通常會下降，從而產生一個高性能的 "smart zone" 與一個性能下降的 "dumb zone" 之間的差距，在 "dumb zone" 中，模型的注意力會下降且失去連貫性。
上下文腐爛 (Context Rot) 的現實
有效的上下文通常僅為廣告宣傳的限制值的極小部分。諸如 RULER benchmark 與 Chroma 關於 "context rot" 的報告指出，隨著上下文窗口被填滿，模型性能會逐漸下降。這對於編碼代理 (coding agents) 而言特別棘手，因為它們透過讀取文件、除錯階段和測試運行來快速消耗 tokens，通常在任務完成之前就將模型推入 "dumb zone"（有些人估計大約在 100k tokens 左右）。
雖然有些用戶報告在大窗口下取得了成功——特別提到 Claude Opus 的 1M token 窗口在達到 800k tokens 時仍能保持穩定——但其他人則認為注意力機制 (attention mechanism) 的 "mass" 分散得太薄，導致全局平均值呈現 "slop" 而非精確檢索。
維持高信號上下文的策略
為了避免與大型上下文窗口相關的性能衰減，開發者正在採用幾種技術策略，以將模型保持在其 "smart zone" 內。
1. 透過 Artifacts 外部化狀態
與其依賴模型的內部會話 (session) 記憶，不如透過將資訊移至書面 artifacts 實現高信號的交接。這包括：
- 手動規格說明交接 (Manual Spec Handoffs): 開啟一個新會話並提供一份自寫的規格說明，以確保在沒有長對話噪音的干擾下，保留最關鍵的資訊。
- 結構化工作流 (Structured Workflows): 使用如
obra/superpowers或mattpocock/skills等框架，圍繞著命名的 artifacts（如 PRDs、計劃和子代理交接）來組織代理工作流。 - 文件作為記憶 (Documentation as Memory): 將提交到 repository 的簡潔 Markdown 文件（檢查清單、索引頁和計劃）視為模型的首要 "memory"，這同時也作為人類可讀的審計追蹤。
2. 遞歸調用與根線程隔離 (Recursive Invocation and Root Thread Isolation)
控制 token 使用的一種進階方法是在頂層對話線程中防止工具調用。透過使用遞歸調用 (recursive invokes)——即代理下降到子程序中執行工具調用，並僅將結果返回給調用者——根對話線程可以保持精簡。這允許用戶在處理龐大的 codebase 時，能維持高層次的對話，而不會在主線程中觸及 100k token 限制，即使在遞歸調用中消耗了數百萬個 tokens。
3. 手動與自動壓縮 (Manual and Auto-Compaction)
許多現代代理，例如 Claude Code，實作了自動壓縮 (auto-compaction)，即對會話進行摘要並重置。然而，批評者認為，如果摘要是由一個已經處於 "dumb zone" 的模型產生的，那麼摘要本身的品質可能會下降。手動壓縮——例如使用 /last 命令來清除會話，但僅保留最後的輸出——允許用戶更精確地引導壓縮過程。
反對觀點與變動的性能
並非所有用戶都會經歷普遍的 "dumb zone"。上下文大小的影響通常取決於任務：
- 任務複雜度 (Task Complexity): 簡單的基礎工作可能在較長的上下文中保持穩定，而複雜的推理任務則下降得更快。
- 信號與噪音比 (Signal-to-Noise Ratio): 有些人認為性能衰減是由於 tokens 的數量，而非 tokens 本身，而是由 "debris" 或混亂的信號（例如：重複的失敗嘗試）淹沒了重要的指令。
- 模型架構 (Model Architecture): 不同的模型具有不同的注意力機制架構；因此，一個模型的行為不能推導至所有前沿模型。
"上下文窗口中事物的頻率會賦予權重，即使它們是錯誤的東西。我有很多技巧，例如不給 llm 很多工具，而是給它一個可以用來搜尋工具的工具等等。"
結論：將上下文視為預算
將上下文窗口視為預算而非容量，是確保 LLM 可靠性的最可靠方法。透過刻意地將資訊從即時會話中移出並放入結構化 artifacts，開發者可以最小化注意力機制必須應對的噪音，確保模型保持敏銳且專注。