大多數人對 AI Agent「規劃」的認識停留在一個模糊的概念：Agent 能「自主計劃」複雜任務。但這個描述掩蓋了一個實際問題：LLM 做規劃的方式是什麼、它在哪些情況下有效、在哪些情況下失敗？
理解 LLM 做規劃的機制，對 Onchain Agent 的設計尤其重要——DeFi 策略 Agent 的規劃失敗不只是「任務沒完成」，而可能是執行了錯誤的鏈上操作。這篇文章系統性地分析 Agent 規劃的四種策略、每種策略的適用場景與失敗模式，以及如何在系統設計層面讓規劃更可靠。
規劃（Planning）在 AI Agent 裡的定義是：給定一個目標（Goal）和當前狀態（Current State），Agent 生成一個「達到目標的行動序列」的過程。在 Onchain Agent 的具體場景，規劃的問題是：用戶說「幫我找到當前最佳的 USDC 收益策略並執行」，Agent 需要規劃出「查詢各協議 APY → 比較利差 → 判斷是否值得移倉 → 計算 Gas 費回收期 → 決定執行或等待」的行動序列。
規劃問題的難點在於：在規劃生成時，Agent 並不知道每個步驟的執行結果（在查詢 APY 之前，不知道利差是多少）；且環境是動態的（APY 在規劃執行過程中可能發生變化）。LLM 做規劃的核心挑戰是：如何在不確定性下生成合理的行動序列，且能在執行過程中根據新信息調整計劃。
規劃問題的複雜度決定了需要的規劃策略。對簡單的線性任務（A 完成後做 B，B 完成後做 C），基本的 ReAct 循環已經足夠；對複雜的非線性任務（多個子目標、條件分支、可能需要回溯），需要更結構化的規劃機制。
策略一：反應式規劃（Reactive Planning / ReAct）
這是最基本的 Agent 規劃方式——不預先生成完整計劃，而是在每個步驟裡讓 LLM 根據當前狀態決定下一個行動。每個循環：Thought（推理：現在的狀態是什麼、下一步應該做什麼）→ Action（執行一個工具調用）→ Observation（觀察工具回傳）→ 再次 Thought。這種方式的優勢是對環境變化的適應性強——每次行動都基於最新的觀察結果，不受一個固定計劃的約束。適合場景：任務步驟數量不確定、中間步驟的結果難以預先預測的場景（例如「分析這個協議的合約，找出可能的安全風險」）。限制：缺少全局視角，容易陷入「近視性決策」——每一步看起來合理，但整個序列可能走偏。對需要全局優化的策略（例如「在 Gas 費最低的時間點執行多步驟移倉」），純反應式規劃效率低。
策略二：預先規劃（Plan-then-Execute）
讓 LLM 在執行任何工具調用之前，先生成完整的計劃（任務分解 + 步驟序列），再逐步執行計劃中的每個步驟。System Prompt 設計：讓 LLM 在 Thought 的第一步輸出「計劃清單」，明確列出後續的所有步驟，然後再開始執行。優勢：全局視角更好，能在計劃層面做優化（例如把需要在 Gas 費低谷執行的步驟安排在計劃末尾）；能提前發現計劃裡的矛盾（某個步驟的前提條件不滿足）。限制：LLM 生成的計劃基於推理開始時的狀態，如果執行過程中環境發生變化（APY 在執行中途大幅波動），固定的計劃可能不再適用，需要觸發重規劃。適合場景：步驟數量和順序相對固定、環境變化不頻繁的任務（例如一次性的多步驟協議遷移）。
策略三：分層規劃（Hierarchical Planning）
把複雜任務分解成「高層計劃」和「低層計劃」兩個層次。高層 Planner（通常是能力更強的 LLM，例如 Claude Opus）負責任務分解——把「優化 DeFi 投資組合」分解成幾個相對獨立的子目標（查詢各類協議利率、評估風險、計算最優配置）；低層 Executor（可以是較便宜的 LLM 或確定性代碼）負責執行每個子目標的具體步驟。分層規劃的核心優勢：子目標之間的並行執行（可以同時查詢多個協議的 APY，不需要等一個完成再查下一個）；高層 Planner 不需要知道低層執行的細節，只接收子目標的「完成 / 失敗 / 結果」反饋，降低了高層 LLM 的 Context 複雜度。這是多 Agent 系統（Orchestrator + Sub-agent）的架構基礎。
策略四：Tree-of-Thought 規劃（探索式規劃）
讓 LLM 同時探索多個可能的計劃分支，評估每個分支的可行性，選擇最優的計劃路徑執行。類比：下棋時同時考慮幾個可能的走法，預測每個走法的後果，選擇最好的一個。對 DeFi Agent 的應用：給定「調整 DeFi 投資組合」的目標，Tree-of-Thought 讓 LLM 先生成 3-5 個不同的策略方案（全部移入 Morpho / 分散配置到 Morpho+Aave / 暫時保持現狀等待更好時機），評估每個方案在當前市場條件下的預期收益和風險，選擇最優方案執行。限制：計算成本高（多次 LLM 推理），且對 LLM 的推理能力要求更高。適合場景：高價值決策（資金量大、決策不頻繁）；普通的小額 DeFi 操作用 ReAct 或 Plan-then-Execute 已足夠。
理解規劃失敗的方式，讓你能在設計層面預防：
失敗一：計劃漂移（Plan Drift）：隨著執行循環增加，LLM 的推理逐漸偏離了最初的計劃目標。表現：Agent 在第 3 步執行的操作和第 1 步的計劃不一致，但每一步單獨看都「合理」。原因：在長 Context 的 Thought 歷史裡，早期的計劃細節被後來的對話內容稀釋，LLM 的注意力從計劃本身轉移到了最近的幾輪 Observation。防禦：在每輪推理前，把「當前計劃和已完成步驟」作為結構化 Prompt 注入 Context，確保 LLM 始終有對計劃全局的清晰認識。
失敗二：計劃僵化（Plan Rigidity）：LLM 嚴格按照初始計劃執行，即使中間步驟的 Observation 顯示計劃需要調整。表現：工具回傳顯示目標協議的 APY 已經降到不划算的水平，但 Agent 仍然按照初始計劃執行移倉。原因：Plan-then-Execute 策略在沒有觸發重規劃機制的情況下，執行層沒有回饋更新計劃層的通路。防禦：設計明確的「重規劃觸發條件」——當 Observation 和計劃假設的前提條件偏差超過閾值時，強制觸發重規劃而不是繼續原計劃。
失敗三：子目標衝突（Subgoal Conflict）：分層規劃裡，高層 Planner 分解的子目標之間存在隱含的衝突，低層執行時才被發現。表現：Planner 同時指派了「移倉到 Morpho」和「保持 Aave 的 ETH 抵押」兩個子目標，但可用資金量不足以同時完成兩者。防禦：在 Planner 生成計劃後、分派子目標之前，加入一個「子目標可行性驗證」步驟，提前檢查資源約束。
失敗四：規劃幻覺（Planning Hallucination）：LLM 在生成計劃時，引用了不存在的工具能力或假設了不成立的前提條件。表現：計劃裡包含「調用 get_compound_v3_vault_apy 工具」，但這個工具在實際的工具列表裡不存在。防禦：在計劃生成後，讓代碼層驗證計劃裡所有的工具名稱是否在白名單工具列表裡；把工具列表明確包含在 System Prompt 裡，讓 LLM 知道它能調用哪些工具。
動態重規劃（Dynamic Replanning）是讓 Agent 在執行過程中，根據新的 Observation 更新計劃的能力。這是讓 Agent 在動態環境（DeFi 市場）裡保持有效性的關鍵機制。
動態重規劃需要在三個層面設計：觸發條件（什麼情況下需要重規劃）、重規劃範圍（是局部調整還是完全重規劃）、重規劃的成本控制（避免頻繁重規劃導致 LLM 調用成本爆炸）。
觸發條件的設計：設定「計劃假設的前提條件」——在預先規劃時，讓 LLM 同時輸出「這個計劃成立的前提條件清單」（例如「前提：Morpho 的 APY > 5%，且 Gas 費 < $10」）；在執行過程中，每次 Observation 後自動檢查這些前提條件是否仍然成立；一旦任何前提條件不再成立，觸發局部重規劃（只重規劃受影響的後續步驟，不需要重新規劃已完成的部分）。重規劃範圍的設計：保留已完成步驟的結果（不重新執行），只對「從當前步驟到終點」的剩余部分重新規劃；用「已完成進度 + 當前狀態 + 更新後的約束條件」作為重規劃的輸入。成本控制：設定最大重規劃次數（超過閾值後告警並暫停，等待人工確認），防止因為市場過於波動導致 Agent 陷入無限重規劃循環。
規劃策略的選擇應該和你的 Agent 任務類型匹配，而不是默認用最複雜的策略：對執行固定利率掃描策略的 Agent，ReAct 已經夠用；對需要跨協議多步驟配置優化的 Agent，Plan-then-Execute 加上重規劃觸發條件更合適；只有在「高價值、決策複雜、值得花更多 LLM 成本的」場景，才考慮 Tree-of-Thought 或分層規劃。
最容易被忽視的規劃設計細節：計劃的前提條件記錄和驗證。在預先規劃時，讓 LLM 同時輸出「這個計劃依賴的假設」，並在執行過程中持續驗證這些假設——這個設計讓「計劃僵化」問題的影響從「靜默地執行錯誤計劃」變成「發現假設失效後正確觸發重規劃」。