看到 LangChain 的 Lance Martin 寫的這篇 Agent Design Patterns，覺得整理得很好。他從 Claude Code、Manus、Cursor Agent 等當紅 agent 產品中，歸納出幾個共通的設計模式，核心觀點就是: 有效的 agent 設計，本質上就是 context management。

同團隊最近又發了一篇 Context Management for Deep Agents，把這些 pattern 落地到他們的 Deep Agents SDK，實作了具體的 context 壓縮機制，值得一起看。

Lance Martin 也錄了一場 YouTube 講座，把這些原則濃縮成三個關鍵字: Offload、Reduce、Isolate，並對照 Claude Code、Manus、Deep Agents CLI 的實作來解說，非常清楚。

以下摘我偏愛的重點:

0. 為什麼 Context Management 是核心問題?

Agent 可以簡單理解成 LLM 在迴圈中呼叫 tool: LLM 做 tool call → 執行 tool → 觀察結果回傳 LLM → 重複直到完成。問題是，AI agent 能處理的任務越來越長，Lance Martin 引用數據指出任務長度大約每七個月翻一倍。Manus 提到平均一個任務超過 50 次 tool call，Anthropic 也說 production agent 動輒上百 turn。

這帶來的麻煩是: 每一輪你都得把之前所有的 tool result 塞回 context window，成本和延遲會爆炸。更糟的是效能會劣化——Anthropic 有份關於 context rot 的報告，顯示 context 越長，模型表現越差。

Karpathy 把應對這個問題的技術統稱為 context engineering: “the delicate art and science of filling the context with just the right information for the next step”。Lance 進一步歸納出三個原則:

  • Offload（卸載）: 把 context 從 LLM context window 移到外部（如檔案系統），需要時再選擇性取回
  • Reduce（縮減）: 減少每一輪傳給 LLM 的 context 大小
  • Isolate（隔離）: 用獨立的 sub-agent 和 context window 處理個別任務

1. 給 Agent 一台電腦

Agent 不只是 LLM + tool calling，真正強的 agent 是有一台電腦可以操作的。有檔案系統做持久化 context，有 shell 跑指令、裝套件、寫程式。Claude Code 就是這個路線的代表，Karpathy 說它 “lives on your computer”，Manus 則用虛擬電腦。Rauchg 講得更直白: coding agent 的核心抽象不是 chat，是 CLI，是作業系統層的存取。

2. 多層 Action Space: 用最少的 Tool 做最多的事

一個有趣的發現: 主流 agent 用的 tool 數量其實很少。Claude Code 大約十幾個，Manus 不到 20 個，LangChain 的 Deep Agents package 只有 8 個原生 tool，CLI 版也只有 11 個。怎麼做到功能豐富但 tool 很少? 靠的是把 action 從 tool calling 層推到電腦層。Agent 只需要幾個原子工具 (像 bash、檔案操作)，然後透過寫程式、跑 CLI 來完成各種動作。

Lance 在講座中特別強調這個設計的好處: tool 太多會造成兩個問題——一是 LLM 選錯 tool 的機率上升，二是所有 tool description 會佔掉大量 system prompt token。以 Manus 為例，它只給 agent bash tool 和檔案操作工具，agent 就能搜尋 script 目錄、找到需要的 script 並用 bash 執行，等於用三四個簡單工具就能展開巨大的 action space。CodeAct 論文也驗證了這點: 讓 agent 寫 code 串接動作，還能省下中間 tool result 的 token 消耗。

3. Progressive Disclosure

所有資訊不要一次塞進 context。Manus 的做法是在 system prompt 列出可用的 CLI 工具清單，agent 需要時再用 --help 去查細節。Cursor Agent 把 MCP tool 的描述同步到檔案夾，只給 agent 看簡短清單，需要才讀完整定義。

Anthropic 的 Claude Skills 就是這個思路的具體實作: 每個 skill 是一個資料夾，裡面有 skill.md 檔案。系統一開始只把每個 skill 的 header（簡短描述）載入 context，當 Claude 判斷需要某個 skill 時，才讀完整的 skill.md，而 skill.md 又可以引用同目錄下的其他檔案和 script。這樣 Claude 只用內建的 Bash tool 就能讀取 skill 內容、執行 script，不需要額外綁定新的 tool，既省 token 又擴展了能力。

4. 把 Context 卸載到檔案系統 (Offload)

與其硬塞所有東西進 context window，不如寫到檔案。Manus 把舊的 tool result 寫進檔案，只在卸載到極限時才做摘要。Cursor Agent 也把 tool result 和 agent 軌跡卸載到檔案系統。這比直接做 context 摘要好，因為摘要會丟資訊，但檔案隨時可以讀回來。

另一個用途是用檔案引導長時間 agent: 把計畫寫到檔案，定期讀回來強化目標。Anthropic 的 multi-agent researcher 就是讓 researcher 先把計畫寫到檔案，派 sub-agent 去做事，最後再把計畫讀回 context 確認每個步驟都完成了。

檔案系統還有一個好處是跨 session 持久化。Claude Code 的 CLAUDE.md 可以放在專案層級或全域層級，存放你想跨不同互動保留的資訊。Deep Agents CLI 用 memories 目錄和 agent.md 做類似的事。Manus 也支援跨 session 的 user memory。

LangChain 的 Deep Agents SDK 把這套做法系統化了，實作了三層漸進式的 context 壓縮:

  1. 卸載大型 tool result: tool 回傳超過 20,000 tokens 時，自動寫入檔案系統，只保留檔案路徑和前 10 行預覽
  2. 卸載大型 tool input: 當 context 用量超過 85% 時，把舊的 file write/edit 的完整內容從歷史中移除，因為這些內容已經存在檔案系統裡了
  3. 摘要: 前兩招都不夠用時才啟動。用 LLM 生成結構化摘要（包含 session intent、產出的 artifacts、下一步），同時把完整對話寫入檔案系統保底

關鍵設計是摘要不是最後手段而已——它會保留 session intent 和 next steps 等結構化欄位，避免 agent 在壓縮後迷失方向。完整對話也還在檔案系統裡，agent 隨時可以用 search 撈回特定細節。

4.5 Reduce: Compaction vs. Summarization

Lance 在講座中特別區分了兩種不同的 context 縮減策略:

  • Compaction（壓縮）: 把舊的 tool result 完整內容存到檔案，message history 中只保留檔案參照。這個操作是可逆的，因為原始資料還在檔案裡，隨時可以讀回來。Manus 就是這樣做的——agent 跑到接近 context window 上限時觸發 compaction，把歷史 tool result 全部卸載，context 使用量大幅下降。
  • Summarization（摘要）: 把整段 message history 濃縮成精簡摘要。這是不可逆的，會丟失資訊，所以需要謹慎設計。Claude Code 在 context 用量達到約 95% 時會觸發 summarization，Deep Agents CLI 則在 170,000 tokens 時啟動。

另外 Deep Agents 的 file system middleware 還會過濾過大的 tool result，避免單一 tool 回傳直接灌爆 context，這也是一種 reduce 策略。

5. Prompt Caching 是命脈

Manus 團隊說「cache hit rate」是 production agent 最重要的指標。用高階模型搭配 caching 甚至可能比用便宜模型不 cache 還省錢。沒有 prompt caching 的話，coding agent 的成本根本不可行。

6. Sub-Agent 做 Context 隔離 (Isolate)

把任務委派給有獨立 context window 的 sub-agent。一種是可平行化的任務 (像 code review 分別檢查不同面向)，另一種是長時間任務。有個模式叫「Ralph Wiggum」: 一個迴圈反覆跑 agent 直到計畫完成，context 透過 git history 在不同 agent 間傳遞，每輪都是乾淨的 context window。

Lance 在講座中指出最常見的溝通模式是: parent agent 派指令給 sub-agent，sub-agent 在自己乾淨的 context window 中執行任務，完成後只把結果傳回 parent。但有時候 sub-agent 也需要更多 context——Manus 允許把 parent 的完整 message history 共享給 sub-agent，Deep Agents CLI 則讓 sub-agent 存取同一個檔案系統，透過檔案來共享 context。

7. 讓 Context 進化

Agent 要能從經驗學習。做法是回顧過去的 session 軌跡，用反思來更新 context。可以應用在:

  • 任務 prompt 的最佳化 (GEPA 做法: 收集軌跡、評分、反思失敗、產生 prompt 變體)
  • 開放式記憶學習 (把 session 蒸餾成日記，再更新 CLAUDE.md)
  • Skill 學習 (從軌跡中萃取可重用的程序，存成新 skill)

怎麼驗證 Context 壓縮有效?

Deep Agents 那篇還提了一個實務上很有用的觀點: 怎麼 eval context compression。在真實 benchmark 上壓縮事件太少不好觀察，所以他們的做法是故意把觸發門檻調低（例如從 85% 降到 10-20%），大量觸發壓縮事件來放大訊號，方便比較不同策略。

他們特別設計了幾種 targeted eval:

  • 目標保持測試: 在任務中途觸發摘要，驗證 agent 是否還能繼續原本的任務，而不是迷路或宣告完成
  • 資訊恢復測試: 在對話早期埋一個關鍵事實（needle-in-the-haystack），觸發摘要把它壓掉，再要求 agent 回憶。Agent 必須從檔案系統中搜尋回來才能通過

最危險的失敗模式是 goal drift: agent 在摘要後忘了使用者的意圖，可能開始問澄清問題，或誤判任務已完成。這種失敗很隱蔽，不容易在一般測試中發現。

未來方向

作者提了幾個他覺得值得追蹤的方向:

  • Learned Context Management: 現在的 context 管理靠手工 prompt 和 scaffolding，但 Bitter Lesson 告訴我們，這些最終可能被模型本身吸收。RLM (Recursive Language Model) 的研究方向就是讓 LLM 學會自己管理 context
  • 多 Agent 協作: 平行 agent 之間怎麼共享 context、避免衝突決策，目前還沒好的解法。Gas Town 專案用 git-backed 追蹤 + Mayor agent 做協調，是個有趣的嘗試
  • 長時間 Agent 的基礎設施: 需要 observability、human-in-the-loop 監控、graceful degradation，目前還很原始

總覽: 各 Agent 的 Context 管理策略

Lance 在講座最後做了一張對照表，很清楚:

  原則 Claude Code Manus Deep Agents CLI
卸載 Context 使用檔案系統 Yes Yes (E2B) Yes
  啟用 User Memory Yes (CLAUDE.md) Yes Yes (memories dir, agent.md)
  最小化 Tool 數量 Yes (~12) Yes (<20) Yes (11)
  給 Agent 電腦 (bash tool) Yes Yes Yes
  Progressive Disclosure Yes (skills) Yes WIP
縮減 Context Compaction Yes Yes No
  Summarization Yes Yes Yes
隔離 Context Sub-agents Yes Yes Yes

以上，這篇把過去一年 agent 設計的智慧做了很好的總結。如果你在做 agent 相關的東西，這些 pattern 蠻值得對照自己的設計看看有沒有遺漏的。

原文: