想象你是一家餐厅的老板。过去，你雇了一位厨师，每做一道菜都要跑过来问你一次：“接下来做什么？”你回答一句，他做一步；做完再跑来问，你再回答。菜还没做完，你已经口干舌燥，厨师也累得够呛。现在，你换了一种方式：先花几分钟把整桌宴席的菜谱写好——先冷盘、再热菜、最后甜点——然后厨师照着菜谱一道一道做，只有遇到突发情况（比如食材不够）才回来找你。哪一种更省力、更高效？ 这就是 Agent 设计中“规划器与执行器分离”（Plan-and-Execute）的核心思想。传统方案（如 ReAct）让大模型每走一步都要“想一下再做一下”，就像第一种厨师，虽然灵活，但交互次数多、Token 消耗大。而 Plan-and-Execute 把“思考”和“做事”拆成两个角色：规划器像主厨一样一次性制定完整计划，执行器像厨师一样按步骤执行并反馈状态。AutoGPT 和 BabyAGI 正是这一思想的早期实践者，后来 LangChain 把它提炼为显式的 Plan-and-Execute 模式。本文将从演进背景、模式对比、角色分工、执行机制、适应性改进等角度，带你看懂这套“先写菜谱、再做菜”的 Agent 设计哲学。

岗位关联

对 AI 从业者而言，掌握规划与执行解耦是设计高性价比、可扩展 Agent 系统的基本功——它直接影响 Token 成本、任务连贯性和系统可维护性，是面试与工程实践中绕不开的核心考点。

目录
  1. 可视化演示
  2. 演进背景
  3. 模式对比
  4. 核心概念
  5. 执行机制
  6. 改进方向
  7. 核心价值
  8. 应用场景
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Agent规划器与执行器分离设计：规划器一次性生成完整步骤列表，执行器逐步实施并反馈状态。对比ReAct模式，动态重规划机制。切换模式查看不同工作流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Plan-and-Execute 工作流程 规划器一次性生成完整任务步骤列表 执行器逐步实施每个步骤并反馈状态 调用 = 1（规划） + N（执行） 规划与执行解耦，减少LLM交互轮次

演进背景

在厨房里分工成为常态之前，厨师们经历了一段“忙乱期”。初代 Agent 的做法（ReAct）很像新手厨师：每做一个动作就要停下来问主厨“下一步怎么办”。主厨被迫放下手头所有工作，一遍遍回答。AutoGPT 的出现改变了这个局面——它给 Agent 加了一块“便利贴”，上面写着待办清单，让 Agent 不再完全依赖实时询问。而 BabyAGI 进一步把任务列表变成动态管理的队列：可以加新任务、标记完成、调整优先级。到了 Plan-and-Execute 模式，LangChain 等框架把这些实践沉淀为清晰的架构模式：规划器一次性写下完整菜谱，执行器照着菜谱做，两者各司其职。

这套演进的内在逻辑是：交互成本是 Agent 系统的核心瓶颈之一。ReAct 的“边想边做”虽然灵活，但每一步都要付出完整的大模型推理成本。AutoGPT 的任务列表减少了一部分交互，但规划和执行仍然交织在同一个循环里。Plan-and-Execute 之所以成为重要里程碑，是因为它把“想”和“做”从结构上彻底分开，让系统既有全局视角，又有执行效率。这就像餐厅从“厨师随时问老板”进化为“主厨定菜单、厨师照单做”的专业分工。

  • ReAct 循环模式：思考与行动交替，每步都调用大模型
  • AutoGPT 任务列表：用待办清单减少实时询问，但仍边规划边执行
  • BabyAGI 任务管理：任务队列可动态增删，强调持续调度
  • 模式沉淀提炼：LangChain 等框架将上述实践抽象为显式架构

理解这段演进，你就能明白 Plan-and-Execute 不是凭空发明，而是对前人经验的系统化总结。它像餐厅管理从“人盯人”走向“制度管人”，每一个新方案都在解决前一个方案的成本或灵活性问题。

模式对比

回顾一下那家餐厅的两种经营方式。模式 A（ReAct）：厨师每做一个动作都跑回来问主厨。做 3 道菜，假设每道菜需要“问一次、做一次”，那么 3 道菜一共需要进行 6 次问答，加上开场的任务说明，共 7 次交互。模式 B（Plan-and-Execute）：主厨一次性写 3 道菜的菜谱（1 次交互），厨师照着做 3 道菜（3 次执行交互），最后向主厨汇报一次结果（1 次交互），共 5 次交互。随着菜的数量增加，模式 A 的交互次数几乎翻倍增长，而模式 B 只线性增加。这就是“每步都问”与“先计划再执行”的效率差异根源。

用数学语言描述：设总任务可拆解为 $K$ 个步骤。ReAct 模式每个步骤都要“推理 + 执行”两次交互，总体交互次数约为 $2K + 1$（额外一次是任务说明或最终汇总）；Plan-and-Execute 模式只需一次规划交互，加上 $K$ 次执行和最终一次结果汇总，总交互次数约为 $K + 2$。两者的比例随 $K$ 增大而趋于 $2$ 倍。

值得强调的是，“次数减半”不等于“能力减半”。Plan-and-Execute 牺牲的是 ReAct 那种“每步都重新判断”的灵活性，换来的是成本的大幅下降。在任务步骤多、执行环境相对稳定的场景中，这种交换非常划算。而如果任务步骤少（比如就一两步），两者差异不大，ReAct 甚至是更简单直接的选择。

RReAct=2K+1,RP&E=K+2,RP&ERReAct≈12 (K→∞)R_{\text{ReAct}} = 2K + 1, \quad R_{\text{P\&E}} = K + 2, \quad \frac{R_{\text{P\&E}}}{R_{\text{ReAct}}} \approx \frac{1}{2} \ (K \to \infty)
公式说明：$R$ 代表大模型交互总次数，$K$ 为任务步骤数。ReAct 的交互次数几乎为 Plan-and-Execute 的两倍，这意味着在 Token 消耗上，P&E 大约只有 ReAct 的一半（执行部分 Token 不变，省下的是每步“思考”的 Token）。
  1. 定义任务步骤数$K$ 表示整个任务被拆成的可执行步骤数量，比如“查天气、写文案、发通知”就是 $K=3$。
    K=任务步骤总数K = \text{任务步骤总数}
  2. 计算 ReAct 次数每步经历“思考”和“行动”两次交互，加上任务总览，共 $2K + 1$ 次。
    RReAct=2K+1R_{\text{ReAct}} = 2K + 1
  3. 计算 P&E 次数仅一次整体规划，$K$ 次执行，一次最终汇总，共 $K + 2$ 次。
    RP&E=K+2R_{\text{P\&E}} = K + 2
  4. 对比两倍关系当 $K$ 足够大时，比值趋近于 $\frac{1}{2}$，即 P&E 的交互次数约为 ReAct 的一半。
    lim⁡K→∞K+22K+1=12\lim_{K \to \infty} \frac{K+2}{2K+1} = \frac{1}{2}

核心概念

Plan-and-Execute 的核心是把 Agent 拆成两个有明确分工的角色。用餐厅做类比：规划器就是主厨，负责设计整桌宴席的菜单。他会考虑客人偏好、食材库存、上菜顺序，最终产出一份完整计划——“冷盘先上，热菜随后，甜点收尾，每道菜用时 10 分钟”。执行器则是后厨团队，不负责创意，只负责把菜单变成现实。他拿到计划后按顺序执行，每完成一道菜就向主厨汇报“做好了”或“食材不够，这道菜失败了”。两个角色各司其职，主厨不必亲自颠勺，厨子也不必操心菜式设计。

这个设计在技术上抽象为两个组件：

为什么“职责分离”如此重要？心理学上，“切换任务”是有成本的——大脑从“思考”切到“行动”再切回“思考”，每次都要重新加载上下文。大模型同样如此：每切换一次“推理模式”，都要额外消耗 Token 来重新理解“我现在在干什么”。规划器与执行器分离后，规划器只做一次深度推理，执行器则以固定模式高效运作，避免了频繁的模式切换。这就是 Plan-and-Execute 在架构设计上最优雅的地方——用结构性的分工，替代了流程性的反复确认。

Agent=fplanner(user_goal)→Plan,Plan=[T1,T2,…,TK]\text{Agent} = f_{\text{planner}}(\text{user\_goal}) \rightarrow \text{Plan}, \quad \text{Plan} = [T_1, T_2, \ldots, T_K]
Executor(Ti)→Resulti,∀i∈[1,K]\text{Executor}(T_i) \rightarrow \text{Result}_i, \quad \forall i \in [1, K]
公式说明：第一个式子表示规划器把用户目标转化为一组有序任务；第二个式子表示执行器逐个完成任务，每个任务产生一个结果。
  1. 规划器产出计划$f_{\text{planner}}$ 是规划器的函数映射，输入用户目标，输出有序任务列表 $\text{Plan}$。
    Plan=[T1,T2,…,TK]\text{Plan} = [T_1, T_2, \ldots, T_K]
  2. 执行器执行单步$\text{Executor}(T_i)$ 表示执行器处理第 $i$ 个任务，得到该步骤的结果。
    Executor(Ti)→Resulti\text{Executor}(T_i) \rightarrow \text{Result}_i
  3. 循环直到完成$i$ 从 $1$ 遍历到 $K$，所有任务执行完毕后，把各步骤结果拼接成最终答案。
    ∀i∈[1,K],Resulti 被记录并汇总\forall i \in [1, K], \text{Result}_i \text{ 被记录并汇总}

执行机制

当主厨把菜谱交给后厨后，后厨的工作就进入了“流水线模式”。Plan-and-Execute 的执行机制由三个关键环节构成：按序执行、状态反馈、结果拼接。执行器拿到计划清单后，从第一个任务开始依次执行。每个任务完成后，执行器都会把该任务的结果（成功或失败）记录在案，就像厨师每做完一道菜就勾掉菜单上的一项。所有任务执行完毕（无论成功还是失败），系统把所有步骤的结果拼接成一份完整答卷交给用户或上层的规划器。

执行器的状态管理是这套机制的灵魂。以四状态模型为例：

这种“先记录、后处理”的策略非常务实。它避免了“一个任务失败，整个系统瘫痪”的极端情况——就像宴席上某道菜做砸了，后厨不会掀桌子，而是先记下“这道菜失败”，继续上后面的菜，最终一起向主厨汇报。主厨可以根据失败信息决定是调整菜谱、重新做这道菜，还是向客人解释换菜。执行器不擅自做决定，但它确保信息完整地传达回来，这正是“执行”与“决策”分离带来的系统健壮性。

S:IDLE→执行RUNNING→成功DONE→汇总IDLES: \text{IDLE} \xrightarrow{\text{执行}} \text{RUNNING} \xrightarrow{\text{成功}} \text{DONE} \xrightarrow{\text{汇总}} \text{IDLE}
失败路径: RUNNING→异常FAILED→原因记录\text{失败路径: } \text{RUNNING} \xrightarrow{\text{异常}} \text{FAILED} \rightarrow \text{原因记录}
公式说明：执行器在各个状态之间流转。正常运行是“空闲→执行中→完成→回到空闲”；失败时则进入“失败”状态，并记录失败原因，供后续重规划使用。
  1. 初始空闲态$S = \text{IDLE}$，执行器等待接收计划。
    IDLE→收到计划RUNNING\text{IDLE} \xrightarrow{\text{收到计划}} \text{RUNNING}
  2. 执行中状态$S = \text{RUNNING}$，执行器正在处理某个具体任务。
    RUNNING→成功DONE\text{RUNNING} \xrightarrow{\text{成功}} \text{DONE}
  3. 完成状态$S = \text{DONE}$，当前任务已成功，记录结果并进入下一个任务。
    DONE→IDLE (取下一个任务)\text{DONE} \rightarrow \text{IDLE (取下一个任务)}
  4. 异常处理若执行过程中出现错误，则记录失败原因，不中断整个流程。
    RUNNING→异常FAILED,原因存储\text{RUNNING} \xrightarrow{\text{异常}} \text{FAILED}, \text{原因存储}

改进方向

“先写菜谱再做菜”有一个前提：环境稳定。如果主厨上午写好菜单，下午发现海鲜市场的虾全部售罄，那这份菜谱就过时了。这暴露了 Plan-and-Execute 最初的短板：静态计划可能脱离实际。同样，Agent 在执行任务时可能遇到外部条件变化——API 接口变更、用户临时补充要求、某个步骤返回错误数据——这些都在规划时无法预料。若执行器还死板地按原计划走，就会像厨师坚持用没有的食材做菜一样尴尬。

因此，后续的 Plan-and-Execute 变体引入了 反馈循环 与 按需重新规划。执行器不只是一个“机械手”，它还承担了“侦察兵”的角色：当某个任务连续失败、或外部环境出现重大变化时，执行器会把异常信息打包反馈给规划器，规划器基于最新状态修订计划，再交给执行器继续执行。这个过程可以用条件逻辑表示：当失败率超过阈值、或外部输入变化超预期时，启动重新规划。

这像极了成熟的餐厅管理：主厨不会在营业期间完全消失，而是“半隐形”——平时不打扰后厨，但一旦接到“某道菜无法完成”的信号，立刻出来调整菜单。反馈循环让 Plan-and-Execute 从“一次规划定终身”进化为“规划—执行—反馈—再规划”的闭环，既保留了批量执行的效率，又恢复了 ReAct 式应对突发情况的灵活性。这种“默认不打断、异常必反馈”的设计哲学，是工程实践中非常值得借鉴的弹性思路。

If ∃Ti:FAILED 或 ΔEnv>θ,则触发 fplanner(goal,history)→Plan′\text{If } \exists T_i: \text{FAILED} \ \text{或} \ \Delta \text{Env} > \theta, \quad \text{则触发 } f_{\text{planner}}(\text{goal}, \text{history}) \rightarrow \text{Plan}'
公式说明：符号 $\exists T_i: \text{FAILED}$ 表示存在失败任务，$\Delta \text{Env} > \theta$ 表示环境变化超过阈值。满足任一条件，规划器就会用当前目标与执行历史重新生成一份新计划 Plan′。

核心价值

把规划和执行拆开，究竟带来了什么？回到餐厅的例子：最大的收益不是菜变好吃了，而是后厨效率大幅提升、主厨终于能腾出时间研究新菜。在 Agent 系统中，这个收益可以拆成四个层面。首先是减少交互轮次：规划一次、执行多次，避免每步都调用大模型，这是最直接的收益。其次是降低 Token 成本：省下的是“重复思考”的开销——大模型不需要反复理解“我现在在做哪一步、下一步该干嘛”。再次是保持任务连贯：因为步骤在计划阶段已被合理排序，执行阶段不会出现“走一步看一步”的碎片化。最后，解耦还带来一个隐藏红利：支持并行调度——多个执行器可以同时处理互不依赖的任务，就像餐厅同时开多个灶台。

从成本公式看，总成本由规划成本与执行成本构成：

这里有一个反直觉的洞察：Plan-and-Execute 不是“省掉了思考”，而是把思考集中化了。ReAct 的思考是“碎片化”的，每步都想一点，加起来可能比一次完整规划想得更全面——但代价是每次都付出“切换上下文”的成本。集中式规划像写文章前列提纲，碎片式思考像边写边想，前者写起来更连贯、更少涂改。对多步骤任务而言，集中规划的收益远大于碎片思考的灵活性。AutoGPT 的实践也证明了这一点：当任务列表足够清晰时，执行者几乎不需要中途打断，效率提升非常明显。

Ctotal=Cplan+∑i=1KCexec(i),Cplan≪∑i=1KCexec(i)C_{\text{total}} = C_{\text{plan}} + \sum_{i=1}^{K} C_{\text{exec}}(i), \quad C_{\text{plan}} \ll \sum_{i=1}^{K} C_{\text{exec}}(i)
公式说明：总成本等于一次规划成本加上 K 次执行成本之和。规划成本只付出一次，而执行成本是必需的。ReAct 的额外开销在于它把“规划”隐藏在了每一步的执行中，导致每步都产生“隐性规划成本”。

应用场景

理解了核心原理，让我们看看它在真实世界的用武之地。最典型的场景是数据管道处理：假设需求是“获取 100 个网页的标题、清洗为结构化数据、存入数据库、生成分析报告”。传统做法是每处理一个网页都与大模型交互一次，100 个网页就是 100 多次 API 调用。Plan-and-Execute 的做法是：规划器一次性生成“抓取→清洗→入库→报告”四个阶段计划，执行器对 100 个网页循环执行“抓取 + 清洗”（不需要大模型参与，只要工具调用），最后统一生成报告。Token 消耗可能差一个数量级。

第二个经典场景是代码库迁移与重构。要求 Agent“把项目从 Python 2 迁移到 Python 3”，涉及数百个文件的语法调整、依赖更新、测试修复。规划器先分析整个代码库结构，生成文件清单和迁移顺序；执行器逐文件完成机械性转换；遇到不兼容的依赖报错时，反馈给规划器决定是切换替代库还是改写代码片段。相比 ReAct 每改一个文件都要问一次，这种分层方案的执行速度快得多，也更可控。

第三个场景是多工具串联的复杂任务。例如“从邮箱提取附件→识别发票→录入财务系统→发送确认邮件”。这是天然的多步骤、工具密集、稳定性要求高的任务。Plan-and-Execute 让规划器负责决定“用哪些工具、按什么顺序”，执行器负责实际调用各工具的 API，相互独立、便于调试。当某一环节的工具升级（比如换了发票识别服务），只需调整规划器的描述，执行器逻辑无需改动——这种“接口式”的架构分离，正是工程上解耦的价值所在。

AI 应用场景

智能审批与报表生成流程

阶段：执行器基于规划批量执行工具调用

解决的问题：传统 RPA 每条流程都要人写死分支逻辑，且每次需求变化都要重写脚本；AI 规划器让流程定义只需自然语言一句话，执行器按规划批量跑完，失败时自动上报而非宕机。这解决了流程自动化中“高定制成本”与“低容错性”两大痛点。

具体案例：某财务团队每天需要处理 200 张报销单。过去用 RPA 脚本逐条处理，其中 20% 因单据格式异常而中断人工介入。改用 Plan-and-Execute 架构后，规划器每天早晨生成“下载单据→OCR 识别→规则校验→入账→发送通知”的计划，执行器批量处理，识别失败的单据单独标记并反馈重规划。人工介入率从 20% 降到 3%，每天节省约 3 小时。

自动化代码审查与修复

阶段：规划器做全局分析，执行器逐文件修复

解决的问题：传统静态检查工具只能发现规则问题，不能理解“业务逻辑”层面的缺陷；人工 review 虽有深度但成本高。AI 规划器先生成整个仓库的审查计划与修复优先级，执行器按文件逐个应用小模型修复或规则修复，重要文件最后人工确认，兼顾了深度、速度与安全性。

具体案例：一个中型团队的 Go 微服务仓库在版本升级后发现 40 多个文件存在并发安全问题。架构师用 Plan-and-Execute 智能体：规划器分析各模块依赖关系，制定“先底层库、后业务层”的修复顺序；执行器使用本地化的 lint 工具与小模型批量生成修复补丁，并由 CI 自动跑测试验证。最终 37 个文件自动修复成功，人工只处理了 3 个高风险模块。

多源数据采集与结构化整理

阶段：动态规划 + 反馈驱动的批量抓取

解决的问题：传统爬虫面对网站改版就崩溃，需要大量人工维护；纯 LLM 逐页抓取则 Token 消耗巨大。Plan-and-Execute 的分离结构让“策略”（规划器）与“执行”（抓取器）解耦：抓取器是稳定的工具代码，规划器只在网站结构变化时介入更新策略，成本极低且维护方便。

具体案例：某市场调研公司需要每周从 20 个竞品网站采集价格与库存数据。执行器每天定时代码抓取，正常时不调用大模型；一旦某个网站改版导致连续抓取失败，执行器将失败样本反馈，规划器重新分析新页面结构并产出新的抓取规则。整个系统运行三个月，仅触发过 4 次自动重规划，完成率保持在 99.2%。

Python 演示

python82 行
"""Simplified Plan-and-Execute agent demo."""import json  class MockLLM:    """A fake LLM: returns JSON string (planner) or dict (reflection)."""     def generate(self, prompt: str) -> str:        """Planner: return serialized task list in JSON string."""        if "plan" in prompt:            return json.dumps({                "goal": "爬取数据并统计均值",                "tasks": [                    {"id": 1, "desc": "获取原始数据", "tool": "fetch"},                    {"id": 2, "desc": "清洗空值", "tool": "clean"},                    {"id": 3, "desc": "计算均值", "tool": "aggregate"},                ],            })        # Never used in this simple demo; keep interface complete.        return json.dumps({"kind": "unknown"})     def reflect(self, task_result: dict) -> str:        """Executor never asks LLM per step (no reflection tokens)."""        return "not_used"  class MockTool:    """Real executor side: do a step without LLM."""     def fetch(self) -> list:        return [3, 5, None, 8, 2]     def clean(self, data: list) -> list:        return [x for x in data if x is not None]     def aggregate(self, data: list) -> float:        if not data:            raise ValueError("empty data, plan should be replanned")        return sum(data) / len(data)  class PlanAndExecuteAgent:    def __init__(self):        self.llm = MockLLM()        self.tool = MockTool()        self.total_tokens = 0     def plan(self, goal: str):        self.total_tokens += 1  # planning costs one interaction        raw = self.llm.generate("plan for: " + goal)        plan = json.loads(raw)        return plan["tasks"]     def execute(self, tasks: list) -> list:        results = []        for task in tasks:            tool_name = task["tool"]            self.total_tokens += 0  # tool calls are token-free            if tool_name == "fetch":                data = self.tool.fetch()            elif tool_name == "clean":                data = self.tool.clean(self._last_data)            elif tool_name == "aggregate":                data = self.tool.aggregate(self._last_data)            else:                raise RuntimeError("unknown tool in plan")            self._last_data = data            results.append((task["desc"], data))        return results     def run(self, goal: str):        tasks = self.plan(goal)        self._last_data = []        results = self.execute(tasks)        for desc, out in results:            print("task:", desc, "->", out)        print("total tokens(approx):", self.total_tokens)  if __name__ == "__main__":    agent = PlanAndExecuteAgent()    agent.run("爬取数据并统计均值")
目的：模拟 Plan-and-Execute 的完整闭环——规划器产出一份计划，执行器按序调用工具完成所有步骤，不进行任何每步 LLM 推理。
  1. raw = self.llm.generate("plan for: " + goal)模拟规划器一次性生成包含任务列表的 JSON 计划，只消耗一次 Token。
  2. plan = json.loads(raw)将规划结果解析为任务数组，对应“主厨写下菜谱”。
  3. self.total_tokens += 0 # tool calls are token-free工具调用不消耗大模型 Token，这是 P&E 省成本的核心来源。
  4. if tool_name == "fetch":执行器按计划中的工具名分派任务，不需要“思考”。
  5. self._last_data = data每一轮的输出成为下一轮的输入，模拟任务间数据传递。
  6. agent.run("爬取数据并统计均值")入口函数，规划 + 执行一气呵成，无中途打断。

常见误区

误区我一直以为 Plan-and-Execute 就是把整个任务的计划一次生成，然后执行过程完全脱离大模型，相当于一个提前写死的脚本。

正解实际架构中，规划器通常会参与“按需重新规划”。执行器在执行中若遇到失败或环境变化，会把反馈提交给规划器，规划器基于最新信息修订原有计划。成熟系统往往设定重规划的触发条件（失败次数、外部变化阈值），让大模型的关键推理能力保留在“异常分支”上，而不是彻底移除。

为何常见：人们容易把“减少交互”误读为“消除交互”。P&E 的目标是“减少不必要的交互”，而非“拒绝交互”——就像主厨平时不出现，但接到求救信号必须出现。

误区既然 P&E 省 Token 又连贯，那我的所有 Agent 任务都应该改成 Plan-and-Execute，ReAct 是过时的方法。

正解任务步骤少（K≤2）时，两者差异几乎可以忽略，而 ReAct 实现更简单、对动态反馈响应更快。在需要“边探索边决定”的场景（如用户意图不明确、每一步的结果都影响下一步方向），ReAct 的灵活性是真实价值。P&E 的优势主要体现在“步骤多、环境稳定、工具调用为主”的场景。

为何常见：见到一个架构有量化优势后，容易陷入“非此即彼”的思维。实际上，很多生产系统都采用混合模式——默认 P&E，关键节点切回类 ReAct 的每步推理。

误区规划器生成的任务列表就是完备的，不需要检查每个步骤是否可行，执行器照做就行。

正解规划器生成计划时，只看到开始时的世界状态。当执行器执行到第 3 步时，第 1 步可能已经改变了环境（比如创建了文件和目录）。这就是为什么执行器需要“持续检查”步骤的前提条件，并在前提不成立时暂停并向规划器求援。BabyAGI 中的任务队列专门设计了“重新评估剩余任务优先级”的机制。

为何常见：静态计划给新手一种“稳了”的错觉，但真实世界是动态的。没人会在宴席前承诺“所有食材一定不会缺货”。

误区执行器就是普通的函数调用器，把 LLM 替换成脚本也能完成同样的活。

正解执行器确实希望减少 LLM 调用，但它仍然需要一定的智能：如何解析工具输出、如何做数据转换、如何判断任务是否真正完成、如何格式化中间结果。在 LangChain 的实现中，执行器通常也是一个 Agent，只是它的推理范围被约束在“当前任务”而非“全局计划”。完全无脑的执行器会在异常输入面前崩溃。

为何常见：“分离”两个字容易让人联想到“彻底隔开”。实际上 P&E 是“重心分离”——规划器管全局推理，执行器管局部微决策，两者都是智能体，只是颗粒度不同。

面试题

Q1. Plan-and-Execute 模式的核心思想是什么？

单选题 · easy

  • A.每一步都让大模型先思考再执行
  • B.先一次性制定完整计划，再逐步执行← 正确答案
  • C.完全取消大模型，改用规则脚本
  • D.让执行器自行决定所有任务步骤

答案：B。P&E 的核心是“规划与执行解耦”——规划器统一制定计划，执行器照单实施。A 是 ReAct 的特征；C 和 D 分别走向了“无智能”和“无规划”两个极端，都不符合 P&E 的结构。

Q2. 在 Plan-and-Execute 架构中，规划器的核心职责是什么？

单选题 · easy

  • A.调用所有外部工具完成具体操作
  • B.把用户目标拆解为有序任务列表← 正确答案
  • C.记录每一步的执行日志
  • D.评估最终结果并给出分数

答案：B。规划器像主厨定菜单，负责把目标转化为有序任务列表。工具调用是执行器的职责；日志记录不是规划器核心职责；评估结果是可选的后续动作。B 最符合“规划”角色定义。

Q3. 假设一个任务可拆为 K 个步骤，ReAct 与 Plan-and-Execute 的交互次数约分别为多少？

单选题 · mid

  • A.K+1 与 2K
  • B.2K+1 与 K+2← 正确答案
  • C.2K 与 K+1
  • D.K+2 与 2K+1

答案：B。ReAct 每步含“思考+行动”2 次交互，总约 2K+1；P&E 只有一次规划+执行+汇总，总约 K+2。这是量化 P&E 成本优势的关键公式，也是面试中的常见考点。

Q4. 执行器在执行任务时发现某一步失败，最合理的做法是？

单选题 · mid

  • A.立即中止全部任务并报错
  • B.忽略失败，继续执行后续任务
  • C.记录失败原因并反馈给规划器← 正确答案
  • D.自行改计划后继续执行

答案：C。P&E 的职责分离要求执行器不擅自改决策，但应完整记录失败信息并触发重新规划。A 太激进、B 太消极、D 越权。正确的模式是“记录+反馈”，由规划器决定调整。

Q5. 相比 ReAct，Plan-and-Execute 的哪些优势是真实存在的？

多选题 · mid

  • A.减少与大模型的交互轮次← 正确答案
  • B.降低整体 Token 消耗← 正确答案
  • C.完全消除任务失败的可能
  • D.保持多步骤任务的连贯性← 正确答案

答案：ABD。P&E 确实减少了交互轮次（A）、降低了 Token 成本（B）、通过全局计划保持连贯（D）。但它不能消除失败（C）——环境变化仍可能导致任务失败，只是失败处理更有序。

Q6. 关于“反馈循环 + 按需重新规划”的设计，下列说法正确的是？

单选题 · hard

  • A.每次执行完一个任务都必须重新规划
  • B.只有任务失败或环境变化超阈值时才重规划← 正确答案
  • C.重新规划会完全放弃执行器的工作
  • D.反馈循环只用于日志记录，不影响计划

答案：B。按需重规划的核心是“默认不打断、异常必反馈”。A 把重规划变成常态，反而失去 P&E 的效率优势；C 丢弃已有执行成果不划算；D 忽视反馈的价值。B 准确描述了触发条件和设计意图。

Q7. 以下哪个项目最早实践了“任务列表驱动执行”的思想？

单选题 · easy

  • A.ReAct
  • B.AutoGPT← 正确答案
  • C.Chain-of-Thought
  • D.LangChain

答案：B。AutoGPT 引入了显式的任务列表，让 Agent 不再每步都询问 LLM。ReAct 是“边想边做”的前身；CoT 是提示词技巧；LangChain 是框架而非原始实践者。AutoGPT 的任务列表是 P&E 思想的重要来源。

Q8. 在 Plan-and-Execute 的执行器设计中，哪些职责属于执行器的合理范围？

多选题 · hard

  • A.按计划调用对应工具 API← 正确答案
  • B.将工具返回值转为标准格式← 正确答案
  • C.判断当前步骤前提条件是否满足← 正确答案
  • D.重新设计全局任务步骤

答案：ABC。执行器负责调用工具（A）、数据转换（B）、局部前提检查（C）。D 属于规划器职责——若执行器重新设计全局步骤，规划与执行的边界就被破坏了，系统会退化为无结构状态。

Q9. 数据管道任务中，Token 消耗大幅下降的根本原因是？

单选题 · hard

  • A.工具调用次数减少了
  • B.每步的“思考”Token 被省掉了← 正确答案
  • C.规划模型变小了
  • D.执行结果不再返回给用户

答案：B。工具调用是必要成本，没有减少（A 错）；规划模型可大可小，但关键不是模型尺寸而是调用模式（C 错）；结果仍需返回（D 错）。真正的节省是“不再为每步执行都付出推理 Token”，即省掉了碎片化思考。

Q10. 以下哪些场景更适合采用 Plan-and-Execute 架构？

多选题 · easy

  • A.步骤多且需要批量处理的流水线← 正确答案
  • B.意图开放、每步需探索的任务
  • C.多工具串联的稳定流程← 正确答案
  • D.对延迟和成本敏感的线上服务← 正确答案

答案：ACD。多步骤流水线（A）、多工具稳定串联（C）、对成本敏感（D）都是 P&E 的舒适区。B 是“开放探索”型任务，更适合 ReAct 的每步灵活判断——方向未定，无法提前规划，强用 P&E 反而产生大量无效重规划。