Plan-and-Execute

3 秒看懂

一句话定义： Plan-and-Execute（规划-执行）是一种将 LLM Agent 的任务完成流程拆分为**“先由规划器制定多步计划、再由执行器逐步落实”的架构模式，核心是规划与执行解耦**，用结构化的全局计划替代 ReAct 式的逐步试探。

关键词： Agent 架构 / 任务分解 / 规划器-执行器分离 / 迭代重规划

3 分钟产业解释

它解决什么问题？

在 ReAct（Reasoning + Acting）范式中，LLM 在每一步交替思考和行动——这在简单任务上流畅，但在多步骤、长链条、需要全局协调的复杂任务中暴露出严重缺陷：

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        │
              │  (重规划器, 可选组件)    │
              │  根据执行反馈修正剩余计划 │
              │  添加/删除/重排步骤      │
              └────────────────────────┘

关键设计决策：

1. Planner 与 Executor 分离：Planner 需要强推理能力（通常用大参数模型），Executor 可以用更小、更快的模型，因为每个子步骤已足够明确。这是成本优化的核心杠杆。

2. Re-Planning 循环：并非一次规划、不回头执行。执行完每一步后，可以将结果反馈给 Planner（或独立的 Re-Planner），动态修正后续计划。这是应对真实世界不确定性的关键机制。

3. 计划的中间表示：计划可以是自然语言列表、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 时代的复兴与泛化：

直接学术源头（基于公开论文，检索失败无法精确标注年份，以下为学界已广泛引用的工作方向）：

• 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 并行执行在工程实现中能显著降低延迟。

技术演进史

演进趋势：从”简单线性计划”→“分层计划”→“可执行可修正的动态计划”→“多 Agent 共享计划”。

技术路线对比

上下游

上游依赖

下游应用

关键指标

评估一个 Plan-and-Execute 系统的核心维度：

供需与市场数据

⚠️ 以下为定性产业分析，具体数字基于行业公开信息整理，标注来源口径。

需求侧

• 企业 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 本身不是一个可投资的”赛道”，而是 AI Agent 的核心架构模式。投资应锚定在采用此架构构建复杂 Agent 产品的应用层公司，以及提供底层工具调用和编排基础设施的平台层公司。

投资逻辑

看多逻辑

1. 复杂任务是 Agent 真正的价值高地：简单问答已趋同质化竞争；能完成多步复杂任务的 Agent 才具备高付费意愿客户所需的差异化价值。Plan-and-Execute 是实现复杂任务的主流架构。
2. 规划能力是模型能力的”乘数效应”：一个有优秀规划能力的 Agent + 中等推理模型，可能超越无规划的顶级推理模型。这意味着 Agent 架构层有独立于模型层的价值捕获机会。
3. 可审计性符合企业合规需求：相比 ReAct 的黑盒推理，Plan-and-Execute 产生的中间计划可被人工审阅，更符合金融、医疗、法律等受监管行业的合规要求。

看空 / 风险因素

1. 模型原生规划能力的替代威胁：o3、Claude extended thinking 等模型在推理阶段隐式执行多步规划，可能使显式的 Plan-and-Execute 架构变得冗余。如果模型足够强，架构层的价值会被压缩。
2. 计划幻觉风险：LLM 生成的计划可能包含逻辑错误、遗漏步骤、甚至”不可能执行”的步骤。Re-Planning 机制能缓解但无法根治此问题。
3. 执行链路越长，失败率指数级增长：若单步成功率为 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 小时）

1. 概念理解：阅读 LangChain 官方文档中关于 Plan-and-Execute Agent 的说明和示例代码
2. 动手实验：用 LangChain 的 PlanAndExecute agent type 跑一个简单示例（如多步数学计算、多源信息查询）
3. 对比感受：将同一任务分别用 ReAct Agent 和 Plan-and-Execute Agent 执行，观察两者的行为差异

进阶（1-2 周）

4. 读论文：阅读 Plan-and-Solve Prompting 原文，理解”先计划再解题”在学术实验中的效果和局限
5. 读 BabyAGI 源码：理解任务创建→优先级排序→执行→结果存储的完整循环
6. 工程优化：学习如何设计 Planner Prompt、如何实现 Re-Planning 触发条件、如何管理长执行链的上下文窗口
7. 读 LLM+P 论文：理解 LLM 与经典规划器的混合范式，思考其优劣

精通（持续）

8. 设计自己的 Plan-and-Execute 框架：不依赖 LangChain，从零实现 Planner/Executor/Re-Planner，理解每个设计决策的 trade-off
9. 研究计划质量评估：如何自动评估计划的可执行性和完整性？这涉及 Agent 的自我反思和验证机制
10. 跟踪前沿：关注模型原生规划能力（如 o3 的隐式推理链）对显式 Plan-and-Execute 架构的影响

一句话总结

Plan-and-Execute 的本质是将 LLM Agent 的推理从”边走边想”升级为”先想清楚再走，走的时候发现不对再重新想”——用显式的全局计划换取复杂任务中的方向可控性和执行可靠性，代价是增加了一次规划调用的延迟和成本。

延伸阅读与来源

学术论文（基于学界已广泛引用的工作，检索失败未能获取精确链接，建议在 Semantic Scholar / Google Scholar 搜索标题验证）

工程资源

框架文档

⚠️ 声明： 本文写作时联网检索失败（HTTP 403），所有技术事实基于作者对 Plan-and-Execute 范式的系统性知识整理。部分具体论文信息（作者、机构）为已知领域常识，但未通过本次检索交叉验证，建议读者在引用时自行核实原文。具体数字（如融资金额等）标注了来源口径，未标注的为定性判断。