Plan-and-Execute

3 秒看懂

一句話定義： Plan-and-Execute（規劃-執行）是一種將 LLM Agent 的任務完成流程拆分為**“先由規劃器制定多步計劃、再由執行器逐步落實”的架構模式，核心是規劃與執行解耦**，用結構化的全域性計劃替代 ReAct 式的逐步試探。

關鍵詞： Agent 架構 / 任務分解 / 規劃器-執行器分離 / 迭代重規劃

3 分鐘產業解釋

它解決什麼問題？

在 ReAct（Reasoning + Acting）範式中，LLM 在每一步交替思考和行動——這在簡單任務上流暢，但在多步驟、長鏈條、需要全域性協調的複雜任務中暴露出嚴重缺陷：

問題	具體表現
短視決策	逐步推論容易貪心，前幾步方向性錯誤後面無法自糾
上下文膨脹	逐步累積的中間結果迅速佔滿上下文視窗，後期推論質量下降
不可預測性	使用者無法預知 Agent 將採取什麼路徑，缺少”可審計”的中間計劃
資源浪費	每一步都呼叫大型模型做完整推論，成本高且延遲大

Plan-and-Execute 的核心思路直覺且樸素：人類面對複雜任務時也是先列計劃再逐項執行——將這一認知過程形式化為 Agent 架構。

產業定位

Agent 架構光譜（從簡單到複雜）：

Chain-of-Thought → ReAct → Plan-and-Execute → DAG/多Agent協作
 (純推論)         (逐步行動)   (全域性規劃+逐步執行)  (圖編排)
                            ↑
                         你在這裡

Plan-and-Execute 位於 Agent 複雜度的中間地帶——比 ReAct 多一層全域性規劃，比多 Agent 協作系統輕量得多。它是目前單 Agent 處理中等複雜度任務的主流架構範式之一。

15 分鐘專家深入

架構全景

Plan-and-Execute 的標準架構由三個核心元件構成：

┌─────────────────────────────────────────────────────┐
│                   使用者輸入 (Goal)                     │
└──────────────────────────┬──────────────────────────┘
                           ▼
              ┌────────────────────────┐
              │       Planner          │
              │  (規劃器: 大型模型/強模型) │
              │  輸入: Goal + 當前狀態   │
              │  輸出: Step 1..N 的計劃  │
              └────────────┬───────────┘
                           │ Plan = [Step1, Step2, ..., StepN]
                           ▼
              ┌────────────────────────┐
              │       Executor         │
              │  (執行器: 可是更小模型)  │
              │  逐條執行計劃中的每一步   │
              │  可呼叫工具/檢索/計算    │
              └────────────┬───────────┘
                           │ Step 執行結果
                           ▼
              ┌────────────────────────┐
              │      Re-Planner        │
              │  (重規劃器, 可選元件)    │
              │  根據執行反饋修正剩餘計劃 │
              │  新增/刪除/重排步驟      │
              └────────────────────────┘

關鍵設計決策：

Planner 與 Executor 分離：Planner 需要強推論能力（通常用大引數模型），Executor 可以用更小、更快的模型，因為每個子步驟已足夠明確。這是成本最佳化的核心槓桿。
Re-Planning 迴圈：並非一次規劃、不回頭執行。執行完每一步後，可以將結果反饋給 Planner（或獨立的 Re-Planner），動態修正後續計劃。這是應對真實世界不確定性的關鍵機制。
計劃的中間表示：計劃可以是自然語言列表、JSON 結構化步驟、甚至是類 PDDL 的形式化表示——中間表示的選擇直接影響系統的可靠性和可解析性。

與 ReAct 的核心差異

這是理解 Plan-and-Execute 最關鍵的對比：

ReAct 模式 (逐步交織):
  Thought → Action → Observation → Thought → Action → Observation → ...
  （每一步都做"想+做"，無全域性視野）

Plan-and-Execute 模式 (先全域性後區域性):
  Plan: [Step1, Step2, Step3, Step4]     ← 全域性規劃（一次或少數幾次）
  Execute Step1 → Result1                 ← 逐步執行
  Execute Step2 → Result2
  [Re-Plan if needed: updated Plan]       ← 按需修正
  Execute Step3 → Result3
  ...

本質差異是推論的”時間尺度”不同：ReAct 每一步做區域性推論；Plan-and-Execute 將推論分為全域性層（規劃）和區域性層（執行），實現了推論層次化。

理論基礎與學術淵源

Plan-and-Execute 並非全新概念，它是經典 AI 規劃（Classical AI Planning）思想在 LLM 時代的復興與泛化：

經典規劃	LLM Plan-and-Execute
STRIPS / PDDL 狀態空間搜尋	LLM 用自然語言生成計劃
需要完整的世界模型定義	LLM 內隱知識充當”軟世界模型”
規劃結果100%可執行（在定義域內）	計劃可能含錯誤，需 Re-Planning 修正
對新任務泛化能力弱	LLM 具有強泛化能力

直接學術源頭（基於公開論文，檢索失敗無法精確標註年份，以下為學界已廣泛引用的工作方向）：

Plan-and-Solve Prompting（Wang et al.，主要來自新加坡管理大學（SMU）等機構的研究團隊）：提出讓 LLM 先”制定計劃”再”按計劃求解”的提示策略，在數學推論等任務上顯著優於 Zero-Shot CoT
LLM+P（Liu et al.）：將 LLM 的自然語言理解能力與經典 PDDL 規劃器結合——LLM 負責將問題翻譯為 PDDL 格式，經典規劃器負責求解，再由 LLM 將結果翻譯回自然語言
BabyAGI（Yohei Nakajima，2023 年 3 月開源）：早期最具影響力的 Plan-and-Execute 類 Agent 實現，包含任務建立→優先順序排序→執行→結果儲存的完整迴圈
LangChain Plan-and-Execute 模組：Harrison Chase 團隊將其工程化封裝，提供了開箱即用的 Planner + Executor + Re-Planner 架構

技術原理

核心機制詳解

1. 規劃階段（Planning）

Planner 接收使用者目標（Goal）和可用工具列表，輸出一個有序的子任務序列。

Prompt 設計模式：

你是一個任務規劃器。給定以下目標和可用工具，將其分解為一系列
可獨立執行的子步驟。

目標: {user_goal}

可用工具: {tool_descriptions}

請輸出一個 JSON 格式的步驟列表。每個步驟包含:
- step_id: 步驟編號
- description: 該步驟需要做什麼（足夠具體，執行器可直接操作）
- depends_on: 依賴的前置步驟 ID 列表（可選）
- tool_hint: 建議使用的工具（可選）

計劃質量的關鍵影響因素：

粒度：太粗→執行器無法操作；太細→失去規劃的意義，退化為 ReAct
可執行性：計劃中的每一步必須是 Executor 能夠理解和執行的
完整性：計劃應覆蓋完成目標所需的所有步驟，無遺漏
順序合理性：依賴關係正確，不存在邏輯順序錯誤

2. 執行階段（Execution）

Executor 逐條取計劃中的步驟，結合當前上下文和前序步驟的結果，執行具體操作。

Executor Prompt（示意）：
你是一個任務執行器。請根據以下資訊執行指定步驟。

原始目標: {goal}
當前步驟: {current_step}
前序結果: {previous_results}
可用工具: {tools}

請選擇合適的工具並執行，返回執行結果。

執行器的關鍵能力要求：

工具選擇與引數構造
結果解析與錯誤處理
上下文視窗管理（只保留與當前步驟相關的資訊）

3. 重規劃階段（Re-Planning）

這是 Plan-and-Execute 區別於簡單任務分解的關鍵差異化機制。

Re-Planner 輸入：
  - 原始目標
  - 原始計劃
  - 已完成步驟及其結果
  - 未完成步驟

Re-Planner 輸出（三種可能）：
  ① 確認原計劃，繼續執行下一步
  ② 修改後續步驟（增刪改）
  ③ 判定目標已完成 / 不可完成，終止

觸發重規劃的典型場景：

執行某步失敗（工具呼叫返回錯誤）
執行結果與預期不符（需要調整後續策略）
發現新的資訊改變了任務的前提條件
前序步驟結果表明後續計劃不再合理

執行時狀態機

                    ┌──────────┐
         ┌─────────│  START   │
         │         └────┬─────┘
         │              ▼
         │    ┌──────────────────┐
         │    │  Generate Plan   │◄────────────┐
         │    └────────┬─────────┘             │
         │             ▼                       │
         │    ┌──────────────────┐             │
         │    │  Select Next Step│             │
         │    └────────┬─────────┘             │
         │             ▼                       │
         │    ┌──────────────────┐    Plan     │
         │    │  Execute Step    │────Update───┘
         │    └────────┬─────────┘   (Re-Plan)
         │             ▼                       ▲
         │    ┌──────────────────┐             │
         │    │  Evaluate Result │─────────────┘
         │    └────────┬─────────┘   Need Re-Plan?
         │             │
         │         All Steps Done?
         │          /        \
         │        No          Yes
         │         │           │
         │         ▼           ▼
         │   [Back to Select]  ┌──────────┐
         └────────────────────►│  OUTPUT  │
                               └──────────┘

並行執行最佳化

當計劃中的某些步驟無依賴關係時，可以並行執行：

Plan:
  Step1: 搜尋論文 A 的引用次數
  Step2: 搜尋論文 B 的引用次數    ← Step1, Step2 可並行
  Step3: 比較兩者引用次數         ← 依賴 Step1, Step2
  
執行時間線:
  序列: |---Step1---|---Step2---|---Step3---|  = 3T
  並行: |---Step1---|            |---Step3---|
        |---Step2---|                         = 2T

這種基於依賴關係的 DAG 並行執行在工程實現中能顯著降低延遲。

技術演進史

時間節點	里程碑	關鍵意義
經典 AI 時代	STRIPS, PDDL, HTN 規劃	規劃問題的形式化定義，但需要手工建模世界
~2022Q4	ChatGPT 釋出，CoT 推論被廣泛驗證	LLM 展現出初步的推論規劃能力
~2023Q1	BabyAGI 開源（Yohei Nakajima）	首個引爆關注的 LLM Plan-and-Execute 架構，任務建立-優先順序-執行迴圈
~2023Q2	LangChain Plan-and-Execute 模組釋出	工程化封裝，Planner/Executor/Re-Planner 架構標準化
~2023Q2	Plan-and-Solve Prompting 論文發表	學術界系統論證”先規劃再解題”優於 CoT
~2023Q2	LLM+P 論文發表	LLM 與經典規劃器的混合範式
~2023H2-2024	多 Agent 架構興起（AutoGen, CrewAI, MetaGPT）	Plan-and-Execute 思想融入多 Agent 編排
~2024-2025	各大平台將規劃能力作為 Agent 核心賣點	OpenAI Assistants、Anthropic Claude 等內建規劃行為

演進趨勢：從”簡單線性計劃”→“分層計劃”→“可執行可修正的動態計劃”→“多 Agent 共享計劃”。

技術路線對比

維度	ReAct	Plan-and-Execute	LLM+P（混合規劃）	多 Agent 協作
規劃時機	無顯式規劃，每步區域性推論	任務開始時全域性規劃	LLM 翻譯→經典規劃器求解	每個 Agent 區域性規劃，協調器全域性管理
模型呼叫次數	步數 × 1（每步推論）	規劃 1 次 + 執行 N 次 + 重規劃 M 次	翻譯 2 次 + 規劃器求解（無 LLM）	多 Agent 各自呼叫
適合任務複雜度	低-中	中-高	高（但需定義域可形式化）	高-極高
靈活性	高（每步可自由轉向）	中（受計劃約束，但可重規劃）	低（受限於形式化定義域）	高
可審計性	低（黑盒逐步推論）	高（計劃可審閱）	高（PDDL 計劃可驗證）	中
成本效率	每步用大型模型則成本高	可分層用模型，成本更優	經典規劃器求解過程無需 LLM，翻譯環節仍需 LLM	總呼叫量大
實現複雜度	低	中	高（需 PDDL 建模）	高
錯誤恢復	每步自帶糾錯	Re-Planning 機制	執行階段出錯機率低，但仍有外部失敗可能	Agent 間協商

上下游

上游依賴

層級	具體元件	說明
基礎模型	GPT-4 / Claude / Llama 等大引數模型	Planner 需要強推論能力
推論架構	LangChain / LlamaIndex / 自研	提供 Agent 編排、工具呼叫基礎設施
工具生態	搜尋引擎、程式碼執行器、資料庫、API	Executor 的”手和腳”
上下文管理	記憶/向量檢索系統	長期任務中的狀態管理
評估/監控	日誌系統、可觀測性平台	追蹤計劃執行過程，除錯失敗

下游應用

應用領域	典型場景	使用方式
研究助手	文獻綜述、多源資訊綜合	Planner 規劃檢索策略，Executor 逐步檢索和總結
資料分析	複雜查詢、跨表資料整合	Planner 規劃 SQL 步驟，Executor 執行查詢
軟體開發	功能實現、Bug 修復	Planner 規劃程式碼修改步驟，Executor 編碼
客戶服務	多步工單處理	Planner 規劃排查流程，Executor 逐步執行
自動化工作流	企業內部流程自動化	Planner 規劃跨系統操作步驟

關鍵指標

評估一個 Plan-and-Execute 系統的核心維度：

指標	定義	衡量方式
任務完成率	給定目標最終成功完成的比例	端到端測試
計劃質量	生成計劃的可執行性、完整性、合理性	人工評估或自動化 checklist
規劃延遲	從收到目標到生成計劃的耗時	牆鍾時間
執行總延遲	從收到目標到任務完成的總耗時	牆鍾時間
模型呼叫成本	總 Token 消耗量和 API 呼叫次數	按呼叫計費
重規劃頻率	平均每個任務觸發重規劃的次數	計數統計
單步成功率	計劃中每個步驟首次執行成功的比例	逐步統計
可審計性	人工審閱計劃後判斷其合理的機率	人工評估

供需與市場資料

⚠️ 以下為定性產業分析，具體數字基於行業公開資訊整理，標註來源口徑。

需求側

企業 AI Agent 需求持續增長：據各主要諮詢機構（McKinsey、Gartner 等）2024-2025 年報告，企業對 AI Agent 的需求從”對話式助手”向”能完成多步驟複雜任務的自主系統”演進，Plan-and-Execute 架構是支撐這一需求的核心技術範式之一。
複雜任務場景佔比上升：簡單問答可由基礎 ChatBot 處理；真正需要 Agent 介入的場景（資料分析、內容創作工作流、跨系統操作）天然需要多步規劃。

供給側

主流 Agent 架構均內建支援：LangChain（PlanAndExecute agent type）、AutoGPT、BabyAGI、CrewAI 等開源架構，以及 OpenAI Assistants API、Anthropic Claude 的 tool use 模式，都提供了規劃-執行的基礎設施。
大型模型廠商逐步將規劃能力”內化”：部分前沿模型（如 OpenAI o1/o3 系列、Claude with extended thinking）在推論階段內建了隱式規劃，模糊了顯式 Plan-and-Execute 與模型原生能力的邊界。

關鍵趨勢

Plan-and-Execute 的顯式規劃步驟可能逐步被模型內化的鏈式推論能力替代——但當任務涉及外部工具呼叫、多系統協調時，顯式的結構化計劃仍然有不可替代的可審計性和可控性優勢。

代表公司與資本對映

層級	代表公司/專案	角色	Plan-and-Execute 相關性
基礎模型	OpenAI (GPT-4o, o3)	Planner/Executor 底座	模型推論能力直接決定規劃質量
	Anthropic (Claude)	Planner/Executor 底座	tool use + extended thinking 內化規劃能力
	Google DeepMind (Gemini)	Planner/Executor 底座	Agent 能力持續迭代
Agent 架構	LangChain（融資總額約 $30M+，[公開揭露]）	開源 Agent 編排架構	內建 PlanAndExecute Agent 型別
	CrewAI	多 Agent 編排架構	將規劃能力融入多 Agent 協作
	AutoGPT / BabyAGI	開源 Agent 實驗專案	BabyAGI 是 Plan-and-Execute 的早期標杆實現
應用層	各垂直領域 Agent 創業公司	垂直場景 Agent	規劃-執行架構是複雜任務 Agent 的通用模式
基礎設施	Replit、Cursor 等 AI 程式設計工具	程式碼 Agent	程式碼生成/修改天然需要先規劃再執行

資本對映邏輯：Plan-and-Execute 本身不是一個可投資的”賽道”，而是 AI Agent 的核心架構模式。投資應錨定在採用此架構建置複雜 Agent 產品的應用層公司，以及提供底層工具呼叫和編排基礎設施的平台層公司。

投資邏輯

看多邏輯

複雜任務是 Agent 真正的價值高地：簡單問答已趨同質化競爭；能完成多步複雜任務的 Agent 才具備高付費意願客戶所需的差異化價值。Plan-and-Execute 是實現複雜任務的主流架構。
規劃能力是模型能力的”乘數效應”：一個有優秀規劃能力的 Agent + 中等推論模型，可能超越無規劃的頂級推論模型。這意味著 Agent 架構層有獨立於模型層的價值捕獲機會。
可審計性符合企業合規需求：相比 ReAct 的黑盒推論，Plan-and-Execute 產生的中間計劃可被人工審閱，更符合金融、醫療、法律等受監管行業的合規要求。

看空 / 風險因素

模型原生規劃能力的替代威脅：o3、Claude extended thinking 等模型在推論階段隱式執行多步規劃，可能使顯式的 Plan-and-Execute 架構變得冗餘。如果模型足夠強，架構層的價值會被壓縮。
計劃幻覺風險：LLM 生成的計劃可能包含邏輯錯誤、遺漏步驟、甚至”不可能執行”的步驟。Re-Planning 機制能緩解但無法根治此問題。
執行鏈路越長，失敗率指數級增長：若單步成功率為 p，N 步全部成功率為 p^N。對長計劃來說，即使 p=0.9，20 步計劃的成功率僅約 12%。這對工程可靠性提出很高要求。

核心判斷架構

Plan-and-Execute 架構的價值 = f(任務複雜度, 模型規劃能力, 可審計性需求)

- 任務越複雜 → 顯式規劃越有價值
- 模型越強 → 顯式規劃可能被內化替代
- 可審計性需求越高 → 顯式規劃越不可替代

當前階段判斷：模型能力尚不足以完全替代顯式規劃（尤其是涉及多工具、多系統的場景），Plan-and-Execute 在中期內仍是複雜 Agent 的主力架構。但需持續追蹤模型推論能力的進展。

常見誤讀糾偏

❌ 誤讀 1：“Plan-and-Execute 就是把任務簡單拆成子任務”

糾偏： 單純的任務拆解（Task Decomposition）只是 Plan-and-Execute 的第一步。完整的 Plan-and-Execute 包含三個核心機制：① 全域性規劃（生成帶依賴關係的結構化計劃）、② 逐步執行（Executor 獨立處理每個子任務）、③ 迭代重規劃（根據執行反饋動態修正計劃）。缺少 Re-Planning 機制的”任務拆解”只是靜態的分而治之，不具備應對真實不確定性的能力。

❌ 誤讀 2：“Plan-and-Execute 比 ReAct 一定更好”

糾偏： 取決於任務特徵。簡單任務（如單次搜尋、單次計算）用 Plan-and-Execute 反而是過度設計——規劃步驟增加了延遲和成本，但任務本身不需要全域性規劃。ReAct 在簡單任務上更輕量、更直接。Plan-and-Execute 的優勢在多步驟、有依賴關係、需要全域性策略的複雜任務上才體現。沒有銀彈架構，只有任務匹配的架構。

❌ 誤讀 3：“Planner 必須用最貴的大型模型”

糾偏： Planner 確實需要較強的推論能力來生成高質量計劃，但不必然是最強的模型。實踐中可以：① 使用中等模型做初版規劃，用強模型做 Re-Planning 稽核；② 利用 few-shot 示例引導較小模型生成結構化計劃；③ 將計劃格式約束為模板化結構（如 JSON Schema），降低模型的推論負擔。Executor 反而更可以用小模型，因為子任務已被分解到足夠明確的程度。

❌ 誤讀 4：“計劃一旦生成就不能改”

糾偏： 這是對早期簡單實現的誤解。成熟的 Plan-and-Execute 系統必須支援 Re-Planning。實際上，計劃的”可修正性”是該架構區別於傳統 AI 規劃（STRIPS/PDDL，計劃一旦生成則確定性執行）的關鍵進化。Re-Planning 頻率和質量是衡量系統成熟度的核心指標。

學習路徑

入門（2-4 小時）

概念理解：閱讀 LangChain 官方文件中關於 Plan-and-Execute Agent 的說明和示例程式碼
動手實驗：用 LangChain 的 PlanAndExecute agent type 跑一個簡單示例（如多步數學計算、多源資訊查詢）
對比感受：將同一任務分別用 ReAct Agent 和 Plan-and-Execute Agent 執行，觀察兩者的行為差異

進階（1-2 周）

讀論文：閱讀 Plan-and-Solve Prompting 原文，理解”先計劃再解題”在學術實驗中的效果和侷限
讀 BabyAGI 原始碼：理解任務建立→優先順序排序→執行→結果儲存的完整迴圈
工程最佳化：學習如何設計 Planner Prompt、如何實現 Re-Planning 觸發條件、如何管理長執行鏈的上下文視窗
讀 LLM+P 論文：理解 LLM 與經典規劃器的混合範式，思考其優劣

精通（持續）

設計自己的 Plan-and-Execute 架構：不依賴 LangChain，從零實現 Planner/Executor/Re-Planner，理解每個設計決策的 trade-off
研究計劃質量評估：如何自動評估計劃的可執行性和完整性？這涉及 Agent 的自我反思和驗證機制
追蹤前沿：關注模型原生規劃能力（如 o3 的隱式推論鏈）對顯式 Plan-and-Execute 架構的影響

一句話總結

Plan-and-Execute 的本質是將 LLM Agent 的推論從”邊走邊想”升級為”先想清楚再走，走的時候發現不對再重新想”——用顯式的全域性計劃換取複雜任務中的方向可控性和執行可靠性，代價是增加了一次規劃呼叫的延遲和成本。

延伸閱讀與來源

學術論文（基於學界已廣泛引用的工作，檢索失敗未能獲取精確連結，建議在 Semantic Scholar / Google Scholar 搜尋標題驗證）

論文	關鍵貢獻
Plan-and-Solve Prompting (Wang et al.)	系統論證”先規劃再解題”優於 CoT
LLM+P (Liu et al.)	LLM + 經典 PDDL 規劃器的混合架構
Tree of Thoughts (Yao et al.)	將規劃空間從線性擴充套件為樹搜尋
Reflexion (Shinn et al.)	Agent 自我反思與計劃修正機制

工程資源

資源	說明
LangChain Plan-and-Execute 官方文件	工程實現參考，含程式碼示例
BabyAGI GitHub 倉庫	早期標杆實現，程式碼簡潔適合學習
AutoGPT 原始碼	更完整的 Agent 實現，含規劃模組

架構文件

架構	文件位置
LangChain	`langchain` 官方文件 → Agents → Plan-and-Execute
LlamaIndex	`llama-index` 官方文件 → Agent 模組
CrewAI	CrewAI 官方文件 → Planning 章節

⚠️ 宣告： 本文寫作時聯網檢索失敗（HTTP 403），所有技術事實基於作者對 Plan-and-Execute 範式的系統性知識整理。部分具體論文資訊（作者、機構）為已知領域常識，但未通過本次檢索交叉驗證，建議讀者在引用時自行核實原文。具體數字（如融資金額等）標註了來源口徑，未標註的為定性判斷。