Agent 設計模式

上下文的三招

當任務跨越多個上下文視窗，每個新視窗都會失憶。生產環境中已驗證三種策略來應對這個根本挑戰，讓 Agent 能在長任務中保持連貫和高效。

根本挑戰
長任務的失憶問題
一個複雜的程式設計任務可能需要 Agent 執行數十步操作，產生數萬 Token 的對話歷史。當上下文視窗快滿時，系統面臨兩難選擇：

Option A：開啟新視窗，但新視窗什麼都不記得，Agent 會重複已做過的工作。
Option B：繼續在舊視窗工作，但隨著 Token 增多，模型的注意力被稀釋，表現下降。

這不是理論問題。Claude Code、Cursor、Devin 這些產品每天都在解決這個問題。
策略一
1
Compaction
上下文壓縮
當對話快要觸達上下文視窗上限時，用一次 LLM 呼叫對已有對話做摘要：保留關鍵資訊，丟棄冗餘細節，然後在壓縮後的上下文上繼續工作。
實踐 Tip
壓縮時讓 LLM 生成的摘要應該是結構化的，自由文字很難快速定位資訊。例如：「已完成：[列表] | 未完成：[列表] | 關鍵決策：[列表] | 已知問題：[列表]」，這樣後續推理可以快速找到需要的資訊。
策略二
2
Structured Note-taking
結構化筆記
Agent 在執行過程中主動將關鍵資訊寫到外部檔案，而不僅僅依賴對話歷史。當上下文重置（新視窗）後，從筆記檔案讀回這些資訊來恢復記憶。
對比 Compaction
Compaction 是壓縮舊資訊繼續用，Note-taking 是把資訊存到外面以後取用。前者適合連續工作場景，後者適合可能被中斷或需要跨 session 延續的場景。兩者可以組合使用。
策略三
3
Sub-agent Architecture
子 Agent 架構
主 Agent 把需要深入探索的子任務委派給子 Agent。子 Agent 在自己獨立的上下文視窗中工作（可能消耗數萬 Token），最終只返回一個精煉的摘要（1000-2000 Token）給主 Agent。
類比
想像一個 CEO（主 Agent）讓 3 個部門經理（子 Agent）分別調研競品、分析市場、評估技術。每個經理可能花了一週（大量 Token），但彙報給 CEO 的只是一頁 PPT（精煉摘要）。CEO 的認知頻寬始終保持在戰略層面。
JIT Context vs 預載入
預載入（Preloading）
在對話開始時就把資訊塞進上下文
  • CLAUDE.md / Rules 檔案直接載入
  • 使用者偏好、專案配置
  • 高頻使用的上下文資訊
  • 優點：即時可用，無需額外呼叫
  • 缺點：每次都佔 Token，不管用不用得到
JIT（Just-In-Time 按需取得）
只在需要時才檢索資訊到上下文
  • 用 glob/grep 按需搜尋檔案
  • 用 RAG 檢索相關文件
  • 呼叫 API 取得即時資料
  • 優點：上下文保持精簡，只含當前需要的
  • 缺點：多一次工具呼叫的延遲
最佳實踐：混合策略
高頻資訊預載入（專案約定、核心規則、使用者偏好）+ 長尾資訊按需取得（具體檔案內容、API 文件、歷史記錄）。

類比瀏覽器快取策略：熱資料放記憶體快取（預載入），冷資料放磁碟或網路取得（JIT）。目標是讓上下文的命中率最大化：大多數推理所需的資訊已經在視窗裡，偶爾需要的才動態取得。
三種策略對比
策略 核心思想 適用場景 代表產品
Compaction 壓縮舊上下文，保留關鍵資訊繼續 連續長對話，不會被中斷 Claude Code auto-compact
Note-taking 主動寫筆記到外部，跨視窗讀回 可能中斷、需跨 session 延續 Claude Code TODO、Cursor Rules
Sub-agent 子 Agent 深入探索，只回傳摘要 需要深度探索但不想汙染主上下文 Cursor Task、Claude Code spawn
長任務的本質挑戰是有限的注意力視窗 vs 無限增長的資訊量。壓縮、筆記、子 Agent 三招，分別解決三個問題：在視窗內保持精簡、跨視窗傳遞記憶、隔離深度探索的噪聲。三者組合使用，才能讓 Agent 在複雜長任務中保持高效。