你讓 AI Agent 執行一個需要 50 個步驟的複雜 DeFi 策略。執行到第 30 步時，Agent 突然「忘了」它在第 5 步做過的決定，重新查詢了同一個數據，或者更糟糕地，開始和自己第 5 步的決定矛盾。
這不是 bug，也不是 LLM 變笨了。這是 Context Window 管理問題——當 Agent 的工作記憶裝滿了，它就必須開始「忘記」一些東西。如何設計「忘什麼、留什麼」的策略，是 Agentic 系統工程裡最核心的技術問題之一。
Context Window 是 LLM 在單次推理時能「看到」的所有文字的上限，以 Token 計算。Claude Opus 的 Context Window 是 200,000 Token，GPT-4o 是 128,000 Token，Claude Haiku 是 200,000 Token。聽起來很大，但對一個長時間運行的 Agent 來說，這個上限比你想象的要快到達。
為什麼 Agent 的 Context 會快速膨脹？因為一個運行中的 Agent 的 Context 通常包含：System Prompt（策略描述、工具定義、安全規則，通常 2,000-10,000 Token）；對話歷史（過去所有輪次的用戶輸入和 Agent 輸出）；工具調用記錄（每次工具調用的輸入參數 + 完整 API 回傳）；以及當前任務的工作狀態（Agent 在這個任務裡做了什麼、發現了什麼）。
一個 DeFi 策略 Agent 每小時執行一次推理，每次推理的 Context 增長約 2,000 Token（包含這次的工具回傳和決策記錄）。200 小時後（不到 9 天），累積的 Context 達到 400,000 Token，已經超過大多數模型的上限。實際上問題更早出現——當 Context 超過 60-70% 時，LLM 的「大海撈針」問題就開始顯現：它開始忽略 Context 中間的重要信息，只關注開頭和結尾。
Context Window 管理的核心挑戰是：你需要決定「當 Context 快滿時，丟掉什麼、保留什麼」——而這個決定直接影響 Agent 的決策品質和行為一致性。
了解 Context 的消耗模式，能幫助你預測問題並提前設計解決方案。Context 的主要消耗來源有四個：
工具回傳數據的累積（最大的 Context 殺手）：每次工具調用的完整回傳都進入 Context。DeFi 協議的 API 通常回傳大量原始數據——一次 Aave 的全市場利率查詢可能回傳 15,000 Token 的 JSON（包含幾十個資產的詳細數據）。如果你每次把完整的 API 回傳放入 Context，幾十次工具調用就能讓 Context 達到上限。正確做法：在工具函數的後端代碼裡，在回傳數據進入 Context 之前先做過濾，只保留當前決策真正需要的字段。同樣是 Aave 市場數據，如果 Agent 只需要 USDC 和 ETH 的供應 APY，就只傳這兩個數字（200 Token），而不是完整市場數據（15,000 Token）。
對話歷史的線性增長：Agent 的每一輪 Thought-Action-Observation 循環都在 Context 裡留下記錄。如果不做任何管理，Context 會線性增長，直到達到上限。一個每天執行 48 次推理循環的 Agent，一週後的對話歷史可能佔用 50,000-100,000 Token。
System Prompt 的隱性成本：System Prompt 在每次推理都完整地包含在 Context 裡。一個描述了 10 個工具、包含詳細安全規則和策略說明的 System Prompt 可能有 8,000 Token。這 8,000 Token 在每次推理都要重新計算，是一個固定的「基礎 Context 成本」。
錯誤和重試的記錄：當工具調用失敗並重試時，失敗的調用記錄也留在 Context 裡。如果一個工具連續失敗了 5 次，5 次失敗記錄 + 5 次重試記錄都進入 Context。對某些框架，這個問題在長時間運行的 Agent 裡會顯著放大 Context 大小。
沒有一種策略能完美解決所有場景，需要根據你的 Agent 任務類型選擇合適的組合：
策略一：滑動窗口（Sliding Window）——最簡單，適合短任務 Agent
設定一個固定的「保留最近 N 輪對話歷史」規則，超過 N 輪的舊記錄自動丟棄。例如：永遠保留最近 20 輪對話記錄 + System Prompt + 當前工具回傳，丟棄更早的歷史。實作簡單，在 LangChain 裡一行配置（`memory = ConversationBufferWindowMemory(k=20)`）。適合場景：每次任務都相對獨立的 Agent（例如每次利率優化都是全新的獨立決策，不需要參考 2 週前的決策）。限制：如果 Agent 在第 21 步需要參考第 1 步的決策，滑動窗口會導致它「忘記」那個關鍵信息。
策略二：摘要壓縮（Summarization）——最靈活，適合長任務 Agent
當 Context 達到閾值（例如 60% 容量）時，讓另一個 LLM（可以是較便宜的小模型）對歷史記錄做摘要壓縮，用幾百 Token 的摘要替代幾千 Token 的詳細記錄。例如：把過去 50 輪的詳細對話歷史壓縮成「Agent 在過去 48 小時執行了 47 次利率優化，其中 38 次移倉到 Morpho（APY 5.1%），9 次選擇保持 Aave（因 Gas 費過高）。累計Gas 支出：$42，淨利差收益：+$89」。這個摘要比原始歷史小 95%，但保留了關鍵決策模式。實作複雜度：中等。需要設計「什麼信息在壓縮後仍然必須保留」的壓縮規則。
策略三：外部記憶（External Memory / RAG）——最適合需要長期記憶的 Agent
把所有的歷史操作記錄存入向量資料庫（Chroma、Pinecone、pgvector），在每次推理前，先用語義搜索（Semantic Search）找出「和當前決策最相關的歷史記錄」，把這些相關記錄（而不是完整歷史）放入 Context。例如：Agent 正在決定是否移倉到 Compound，它會搜索「過去所有涉及 Compound 的操作記錄」，找到「3 週前曾因 Compound 智能合約升級暫停操作」的記錄，把這個關鍵背景放入 Context——即使這條記錄已經超出了滑動窗口的範圍。外部記憶讓 Agent 有了「選擇性長期記憶」：不是記住所有事情，而是在需要時能找到最相關的事情。
策略四：結構化狀態管理（Structured State）——最精確，適合複雜多步驟任務
不把 Agent 的工作狀態放在自由文本的對話歷史裡，而是用一個結構化的 JSON 對象維護 Agent 的當前狀態，每次推理時只把這個狀態對象（而不是完整歷史）放入 Context。例如：不是把「Agent 在 10:00 查了 Aave，在 10:01 查了 Morpho，在 10:02 決定移倉，在 10:03 廣播交易，在 10:05 確認成功」全部放進 Context，而是維護一個狀態對象：`{current_position: morpho, current_apy: 5.1, last_rebalance: 10:05, total_gas_spent: 42, operation_count: 38}`。這個狀態對象是定長的——無論 Agent 跑多久，狀態對象的大小基本不變。LangGraph 的設計哲學就是以結構化狀態管理為核心。
把以上策略轉成可執行的代碼實作：
工具回傳過濾（最高優先級，立竿見影）：在每個工具函數的返回值里，加一個「過濾層」，在數據進入 LLM Context 之前先做裁剪。舉例：`get_defi_rates()` 工具的原始 API 回傳可能是 50 個資產的完整數據，但傳給 LLM 的只有「USDC 和 ETH 在 Aave、Morpho、Compound 的當前 APY」——6 個數字，而不是 50 個資產的完整 JSON。這一步不需要改 Agent 框架，只需要改工具函數的代碼，是成本最低的 Context 優化手段。
Context 監控和觸發式壓縮：在每次推理前，先計算當前 Context 的 Token 數（大多數 LLM SDK 提供 `count_tokens()` 函數）。設定觸發閾值：當 Token 數超過模型上限的 60%，自動觸發壓縮（摘要 or 丟棄舊記錄）。Python 實作：
def check_and_compress_context(messages, model_limit=200000): current_tokens = count_tokens(messages); if current_tokens > model_limit * 0.6: messages = compress_history(messages); return messages
分層 Context 設計：把 Context 分成「永久層」（System Prompt，永遠不壓縮）、「工作層」（當前任務的工作狀態，用結構化 JSON 保持固定大小）、「歷史層」（過去的對話記錄，按策略定期壓縮或丟棄）。不同層的壓縮策略不同，讓你能精確控制「什麼必須保留、什麼可以壓縮、什麼可以丟棄」。
Context Window 管理問題在 Agent 開發早期幾乎不會出現——在你剛開始測試時，任務很短，Context 遠未達到上限。但在你把 Agent 部署到生產環境、讓它 24 小時持續運行幾天之後，Context 問題就會突然出現：Agent 開始做出和早期一致的決策矛盾、開始忽略你在 System Prompt 裡設定的規則、或者 LLM API 開始返回「Context 超限」的錯誤。
最實用的建議：在開發階段就加入 Context 監控（記錄每次推理的 Token 數），讓你在問題出現之前就能看到 Context 增長的趨勢，提前設計壓縮策略。同時，最高優先級的 Context 優化是工具回傳過濾——這個改動成本最低、效果最顯著，往往能把 Context 使用量降低 50-80%，是任何 Onchain Agent 開發者應該優先做的事。