Appearance
Q133 · 什么是 Plan-and-Execute 模式？它和 ReAct 有什么区别？
假设用户把一份出差报销交给 Agent：“帮我核对机票、酒店是否符合公司规定；如有问题告诉我，不要提交报销。”完成这件事至少要读票据、查政策、比金额和日期、整理结论。Agent 可以每做一步再决定下一步，也可以先写一份任务清单再逐项执行。ReAct 更接近前一种组织方式；Plan-and-Execute 把“规划”与“执行”明确拆成两个阶段。二者都可以调用工具、读取工具结果，并在发现新情况时调整行为。
图里送件员代表 Agent，路口代表下一步可选动作。左边每走一步都要看环境再选路；右边先画一条路线，走到路障时修改路线。“先有计划”并不等于“盲目把原计划执行到底”：高质量实现必须检查每步结果，并允许重规划或停止。
术语：先看清系统里谁做什么
| 词 | 初学者可以这样理解 | 报销例子 |
|---|---|---|
| Agent | 接收目标、读取信息、选择下一动作，并根据结果继续工作的程序系统；语言模型通常是它的决策部件之一。 | 接到“核对但不提交”的任务。 |
| LLM | 大语言模型。输入文字与上下文，输出文字或结构化工具调用；本身并不自动读到公司数据库。 | 判断需要先查什么，但数据库读取须由程序接好。 |
| 工具 | 程序给 Agent 开放的受控操作，如查询订单、读取政策。工具有输入格式与返回结果。 | 查询机票、读取酒店政策 两个只读接口。 |
| 观察 / Observation | 工具执行完返回给 Agent 的事实，不应由模型凭空编造。 | 机票价格 980 元、政策上限 1200 元。 |
| 动作 / Action | Agent 请求执行的一个操作。系统还要检查权限，才真正执行。 | 调用“查询机票”，传入报销单号。 |
| ReAct | Reasoning and Acting：把对当前情况的判断与动作交替进行，动作结果再进入下一轮判断。 | 看票据 → 查政策 → 看结果 → 再查酒店。 |
| Planner / 规划器 | 根据最终目标生成步骤清单的部分，常由 LLM 实现。 | 列出“取票据、查政策、逐项对照、汇总”。 |
| Executor / 执行器 | 逐项完成计划的部分；可以是工具调用程序，也可以是另一个能调用工具的 Agent。 | 按清单查询并记录每步证据。 |
| Replan / 重规划 | 执行中发现原计划的前提不成立时，改写剩余步骤。 | 酒店票据缺入住日期，先要求补充再继续核对。 |
| 状态 | 跨步骤保存的任务信息，如已完成步骤、工具结果、证据和剩余任务。 | “机票已核，酒店待补日期”。 |
这里出现的工具中文名是教学示例，不是某个框架要求的函数名。假设输入是报销单 R-17，含机票 980 元、酒店 2 晚共 900 元；假设政策规定机票不高于 1200 元、酒店每晚不高于 500 元。所有数字只为演示控制流程，不代表实际公司的报销规定。
ReAct：每得到一次新事实，再决定下一动作
ReAct 原论文把模型生成的判断与可对外部环境执行的动作交织起来。动作让模型得到新的事实，后续判断能据此更新。论文中的搜索、交互任务说明：模型不必一开始就知道完整答案，可以边获取信息边推进。ReAct 原论文
在报销例子里，可把一次运行读成下面的可观察轨迹：
- Agent 看到用户目标和单号
R-17，意识到金额不能靠猜，先请求“读取票据”。工具返回机票980 元，酒店2 晚共 900 元，以及酒店日期字段。 - Agent 根据票据内容决定查“机票上限”。工具返回
1200 元。它算出980 ≤ 1200，记录“机票金额符合这条政策”，同时保留政策版本或引用。 - Agent 再决定查“酒店每晚上限”。工具返回
500 元/晚。它算出900 ÷ 2 = 450 元/晚，记录450 ≤ 500。 - Agent 检查任务边界：用户只让核对，没有授权提交。最终输出核对结论与证据，不调用“提交报销”。
这是一种观察 → 选择动作 → 执行动作 → 再观察的循环；不是必须先写完四步才允许开始。优点是局部灵活：酒店政策接口如果返回“只适用于指定城市”，下一轮就能去查出差城市。代价是长任务可能多次让模型重新思考“接下来做什么”，若没有状态记录和终止条件，可能重复查询、漏掉核对项或在工具间打转。
“ReAct 没有计划”是错误说法。它可以在每一轮做短期或长期判断；区别在于是否把一个独立、可追踪的完整步骤清单当作核心控制结构。具体实现还可能在 ReAct 循环外加待办列表，因此两种模式不是互斥产品名。
Plan-and-Execute：先把目标拆成可执行任务，再逐项落实
LangChain 对 Plan-and-Execute 的介绍把高层规划与短期执行分开：规划器先给出步骤，执行器逐项操作；执行结果可用于更新计划。它是一种架构模式，不限定只能用某一套框架或某一种模型。LangChain：Plan-and-Execute Agents · LangChain：Planning Agents in LangGraph
同一报销任务中，规划器先得到用户目标，输出一份有依赖顺序的清单：
| 步骤 | 要做的事 | 产出与继续条件 |
|---|---|---|
| 1 | 读取 R-17 的机票、酒店票据。 | 得到金额、晚数、日期；关键字段缺失则暂停并询问。 |
| 2 | 按票据类型与出差日期查询适用政策。 | 得到政策条款、版本、生效日期；政策查不到则不能擅自认定合规。 |
| 3 | 用同一口径逐项比较并记录证据。 | 机票 980 ≤ 1200；酒店 900 ÷ 2 = 450 ≤ 500。 |
| 4 | 向用户报告结果和不确定项。 | 只读、只报告，不提交报销。 |
执行器完成第 1 步，把票据数据写入状态；完成第 2 步，把政策版本写入状态；完成第 3 步，用票据与政策做计算；第 4 步生成报告。注意：**计划中写了“查政策”，不等于政策已经查到。**只有工具返回的数据才是证据，规划器的预测不能当作查询结果。
如果执行第 1 步时发现酒店票据缺少入住日期，原计划的第 2 步无法判断哪版政策适用。正确做法是让执行器标记“缺日期”，规划器把剩余任务改为“先请用户补日期 → 再查生效政策 → 再核对酒店”；若用户不补，就输出“机票可核，酒店无法判断”的部分结果。不能沿着旧计划硬算，也不能从聊天记录推测日期。
有的系统每执行一步都重规划，有的只在遇阻时重规划，有的先规划一次、末尾汇总。它们都属于相关设计思路，但重规划频率决定额外调用成本和适应变化的能力。高风险动作仍应经过权限检查；规划器写出“提交”并不构成用户授权。
两种模式放到同一把尺子上比较
| 比较点 | ReAct 侧重 | Plan-and-Execute 侧重 |
|---|---|---|
| 决策节奏 | 依据当前观察决定下一动作，循环推进。 | 先显式列步骤，再由执行器逐步完成；必要时改计划。 |
| 全局任务覆盖 | 可以规划，但覆盖检查常要额外设计。 | 任务清单天然便于看到“哪些步骤已完成、哪些未做”。 |
| 新情况 | 下一轮可直接改下一动作。 | 需判断是否重规划，并更新剩余步骤与依赖。 |
| 模型调用 | 常在每轮工具结果后再调用模型。 | 多一个规划调用，执行阶段可由较便宜的机制处理部分步骤；也可能因频繁重规划而调用更多。 |
| 延迟与费用 | 短任务常更直接；长任务可能反复探索。 | 规划有起步成本；长任务若减少重复探索，可能更划算。具体要实测。 |
| 常见失败 | 局部看似合理，但漏步骤、重复调用或无法停机。 | 初始计划遗漏前提，后续机械执行；或重规划太频繁、计划始终不落地。 |
**不能断言 Plan-and-Execute 一定更便宜、更快或更准。**费用取决于规划模型、执行器、工具延迟、错误重试次数；规划一次就成功可以省探索，但频繁重规划也会增加调用。LangChain 早期介绍把分离高层规划与短期执行作为设计动机，并指出不同代理执行方式的权衡；具体系统必须量化每项任务的完成率、平均调用次数、延迟、错误类型。LangChain：Plan-and-Execute Agents
同样也不要把 Plan-and-Execute 与 Plan-and-Solve（PS）提示方法混在一起。PS 主要是让模型在一道推理题里先生成解题计划，再按计划作答；它可以只在一次文本推理里发生。此处的 Plan-and-Execute 讨论的是 Agent 如何把外部工具、状态、规划器和执行器组织成任务流程。两者都有“先规划”的想法，系统边界不同。Plan-and-Solve 原论文
真正上线时如何选，并防止越权
如果任务只有“查询报销单状态并回答”，一步只读查询即可，显式规划可能没有收益。若任务跨票据、政策、审批记录和多项核对，先列清单有助于控制覆盖与审计。一个实用的选择方法是取同一批真实任务，分别记录两种实现的完成率、漏查率、重复工具调用、费用、延迟和越权次数，而不是因为名称听起来高级就更换架构。
无论选哪种模式，权限边界都应由工具层落实。用户说“不要提交”，就不给这次运行开放提交权限；只读查询工具返回的事实要带来源或版本；重要金额计算可由确定性代码完成并校验。若工具超时，保留“未核实”状态并有限重试，不能让模型把超时当作“查到合规”。若执行器重复执行可能产生副作用，接口还需要幂等键或审批机制。规划结构改善组织能力，不能代替业务系统的验证与授权。
面试时怎么回答
ReAct 是推理判断和动作交替进行的 Agent 循环：根据当前观察选一个动作，拿到工具结果，再决定下一步。Plan-and-Execute 先让规划器把目标拆成显式步骤，再让执行器完成每一步，并根据执行反馈更新计划。两者都能调用工具和适应环境；主要区别是全局步骤是否被独立生成、保存和管理。ReAct 对短任务和变化快的局部决策比较直接；Plan-and-Execute 更适合需要跟踪多个子任务与依赖的长任务，但规划、重规划也有费用，错误计划会传递给执行阶段。真实项目里我会用同一批任务比较完成率、漏项、调用成本和延迟；同时把工具权限、验证、终止与失败处理写在系统层，不能让模型的计划代替授权。
追问“Plan-and-Execute 是不是先列计划后绝不改变？”回答：不是。观察到工具失败、数据缺失或条件变化时应重规划或停机；否则“先规划”反而会放大错误。追问“Executor 一定也是大模型吗？”回答：不一定。能被确定性程序完成的步骤可以直接用代码或受控工具；需要判断的子任务才可能让模型执行。
资料依据
- Yao 等：ReAct 原论文：判断与动作交替、工具观察更新后续行为。
- LangChain：Plan-and-Execute Agents：高层规划与短期执行分离的初始设计。
- LangChain：Planning Agents in LangGraph：规划、执行、重规划的示例模式。
- Wang 等：Plan-and-Solve 原论文：用于辨明提示式计划与 Agent 架构的边界。