老周和小王一起去云南旅行,但出发之前,两个人的准备完全不同。老周花了一晚上查攻略、看地图,把七天行程写成一本小册子:第一天到昆明,第二天去大理,第三天上丽江看雪山……小王则把行李一甩:“走到哪算哪。”七天后,老周按计划看完了雪山和古城;小王却发现自己待在一个连名字都念不顺的小镇,离玉龙雪山还有三百公里。小王并不笨,他每一个决定——今天下雨改室内、听说米线好吃多留半天——单独看都合理,可这些小偏差一个叠一个,把他带得越来越远。 AI 智能体做长链任务时也会犯同样的“病”:在多步推理的过程中,每一步的小误差都会混进后续的上下文里,让模型渐渐忘记最初的目标,这就是“决策漂移”。本文要讲的 Plan-and-Execute 策略,就是老周那本攻略——先规划好子任务序列,再一步步执行,让智能体在复杂任务的长途旅行中始终不迷路。
掌握 Plan-and-Execute,意味着你能设计出更可控、可审计的智能体架构,在长链任务中显著抑制决策漂移——这是 Agent 工程落地与 AI 安全治理的关键能力。
可视化演示
展示Plan-and-Execute策略三维度:规划执行流程(子任务分解-逐步执行)、漂移对比(直接执行漂移vs规划执行稳定)、对齐机制(偏差检测-重规划),理解Agent多步推理的漂移缓解范式。
本节配有交互动效(进入视口后自动加载,约 3KB)。
规划执行两阶段流程 规划阶段:任务分解为子任务序列 执行阶段:逐步执行子任务 plan -> execute 先规划子任务序列再逐步执行,显式分解降低长链决策漂移风险。
决策漂移
小王的旅行日志像一串散落的珠子:第一天因为下雨改去室内博物馆,第二天听说某家米线好吃又多留半天,第三天客栈老板推荐了一个“小众秘境”……每一个决定单独看都合情合理,可六天后他翻开地图,发现自己距离原计划里的雪山足足偏出去三百公里。问题从来不出在某一个决定上,而在于每个小偏差都悄悄溜进了第二天的“上下文”,影响了接下来的判断。
AI 智能体干长活时,剧本几乎一模一样。处理一个需要多步推理的任务时,模型每走一步都要把前面所有步骤的痕迹再读一遍:中间结果、工具输出、失败信息、上一轮的猜测……这些信息里杂质远比精华多。于是“我最初到底想干什么”这个信号,在一堆噪声里被越冲越淡,模型就在不知不觉中偏向了别的方向。
这种现象被称为决策漂移,也叫目标偏离。它的本质是两层效应的叠加:一是误差累积,每一步的微小失误会传给下一步;二是上下文污染,前面步骤产生的干扰性内容持续占据模型的注意力。把第 i 步的微小偏差记作 δi,n 步之后的总偏差就是这些偏差的叠加;当各步偏差彼此独立时,总偏差的方差会随步数线性增长——这正是“走得越远,偏得越狠”的数学根源。
小王的救星不是“下次做决定再谨慎一点”,而是出发前摊开的那张地图——把“每天去哪儿”这种原本需要现场拍板的问题,提前变成白纸黑字的清单。这正是 Plan-and-Execute 的起点。
- 单步偏差 δi第 i 步决策产生的微小失误,例如错误理解了一个工具输出的含义
- 累积偏差 εn前 n 步偏差之和,代表整条路径相对原始目标的偏离幅度
- 方差线性增长当各步偏差相互独立时,总方差等于各步方差之和,步数越多偏离越严重
核心思想
老周的行李里有一本手写攻略:D1 昆明、D2 大理、D3 丽江、D4 香格里拉。在路上,他几乎不再纠结“明天去哪”,每天早上翻到对应那一页,按计划走完,打个勾。他把“想”和“走”分开了:想,在出发前集中完成;走,在旅途中按图索骥。这个朴素的常识,就是 Plan-and-Execute 的全部灵魂。
把这个常识搬进智能体:先由 Planner(规划器)面对总体目标 G,产出显式的子任务序列 P;再由 Executor(执行器)逐项执行。执行器不需要反复自问“我到底要干嘛”,因为答案已经写在清单上。目标被“外化”成了一张纸,不再完全依赖模型的工作记忆——纸不会像记忆那样被噪声冲淡。
形式上,一次完整的任务可以看作对初始状态 s0 依次施加每个子任务的变换函数:先执行第一个子任务,得到中间状态;再执行第二个,依次传递,直到所有子任务完成。整条链路的顺序在规划阶段就被锁定,执行阶段只是“复读”这个顺序,因此每一步的输入输出都是清晰可控的。
把“在路上反复做决定”改成“出发前集中做决定”,这不仅是效率优化,更是风险控制:一份可以被人类检查、修改、执行的行程单,让智能体的每一步都有了锚点。这就是 Plan-and-Execute 的核心思想。
- 初始状态 s0任务开始前的输入,例如原始数据与可用工具集合
- 子任务函数 fi第 i 个子任务的执行逻辑,把当前状态转换为下一状态
- 复合运算 ∘表示先执行 f1 再执行 f2 的有序组合,顺序不可随意交换
- 最终结果 R经过全部分解后的输出,顺序被计划锁定,行为因此可预期
规划阶段
行程单不是随便写的。老周出发前要查车次、看天气、算里程,还得把“爬雪山需要先订索道票”这种依赖关系理清楚。行程单的质量直接决定旅行质量——哪怕写得再工整,如果顺序反了,人也得折返重来。
规划阶段由 Planner 承担。它把总体目标分解为若干子任务 p1 到 pn,每个子任务尽量“自包含”:需要什么输入、执行什么动作、产出什么结果。计划可以是结构化文本,也可以是 JSON 列表,核心要求是显式、可解析、可检查——机器能读,人也能读。
一个合格的计划不仅是子任务的集合,还隐含了顺序与依赖关系:某些任务必须排在另一些任务前面,因为前者的输出是后者的输入。这种“谁先谁后”的结构,正是规划阶段为执行阶段铺好的铁轨。
规划做得好,等于把“目标”复印了好几份,贴在途中的每个站点,执行器随时可以对照;做得不好,执行器再勤快也是南辕北辙。这就是“规划质量决定执行上限”的含义。
- 子任务集合 P把总体目标切分出的 n 个显式任务,构成计划的主体
- 先序关系 ≺符号 pi ≺ pj 表示 pi 必须在 pj 之前执行
- 依赖判断标准判断依赖的关键是数据流向——谁的输出喂给谁,谁就该排在后面
执行阶段
到了旅途执行期,老周每天只做一件事:翻开攻略今天那一页,把上面列的事做完,在页脚打个勾。他绝不会在早上八点重新思考“我这次旅行到底是为了什么”——那是出发前已经解决的问题。执行阶段的美德是“按部就班”,而不是“临场发挥”。
Executor 同样“目光短浅”:每一轮只取一个子任务,带上它所需的局部输入,调用相应的工具或小模型把它完成,把输出交给下一个步骤。它不需要也不应该翻遍全部历史——这种“局部上下文”设计,正是切断上下文污染的关键一刀。
状态更新的规则因此变得非常简单:从当前状态出发,应用当前子任务的执行函数,得到下一个状态。每步之间只传递必要的信息,过去的噪声被隔离在步骤之外。
执行阶段越“机械”,系统的行为就越可预测;而可预测正是可控的前提。这也是为什么安全审计偏爱 P&E——每一步都能对上清单,就像导游每到一站点一次名,谁掉队了一眼就能看出来。
- 当前状态 si执行到第 i 步时已经累积的中间成果
- 执行器调用 Exec把第 i 个子任务与当前状态交给执行器的一次独立运行
- 局部函数 fi该子任务对应的变换,只接触它需要的片段,不读取全量历史
方案对比
小王和老周代表两种旅行哲学。小王是“边走边想派”:每到一个路口,结合当下的天气、心情、路况即兴决定。老周是“先定后走派”:行程早写好,路上只执行。前者灵活,应对意外能力强;后者稳当,不容易跑偏。两种派别没有绝对优劣,只有适配场景的差异。
AI 世界里“边走边想派”的代表是 ReAct 模式:思考(Reason)、行动(Act)、观察(Observation)在每个时间步交错进行。它的优势是适应性强,适合开放式任务;劣势是每一步都背负着全部历史,长链中极易漂移。“先定后走派”就是本文的 Plan-and-Execute,代价是计划可能过时——天气突变、道路封闭时,老周的攻略也会失效。
为了兼顾两者,P&E 通常加入重规划(Replanning)机制:执行到关键节点或遇到异常时,让 Planner 重新审视原始目标 G 与已产生的执行历史 Hk,生成剩余任务的修订版计划。相当于旅途中掏出地图重新校对:既保留了大方向的稳定性,又恢复了应对变化的灵活性。
选型口诀:任务越结构化、链条越长,越该“先定后走”;任务越开放、交互越密,越该“边走边想”。生产系统中两者常常混合使用——P&E 当骨架,ReAct 当局部关节,各取所长。
- 执行历史 Hk到第 k 次重规划时已经产生的步骤记录与中间结果
- 重规划函数 Plan结合原始目标与最新历史,重新生成剩余子任务的计划
- 重规划次数 mm 是超参数,决定“多久校对一次地图”,越大越灵活、成本越高
工程实践
把老周的攻略变成一套可运行的系统,需要三样东西:写攻略的人(Planner)、照攻略走的人(Executor)、遇事改攻略的人(Replanner)。在 LangChain 中,这三者被封装为 PlanAndExecuteAgentExecutor,开箱即用,是业界最常见的 P&E 落地形态。
实际流水线并不复杂:Planner 把用户目标转成计划列表;主循环每次取出一个子任务;Executor 调用工具或子 Agent 执行并缓存结果;全部完成后汇总输出。若某步失败、或用户中途改需求,Replanner 拿着剩余计划与当前进度重新规划。计划本身是 JSON 对象,人类可以在执行间隙直接增删改——这就是“可控性”的落地形式。
从资源成本看,P&E 的性价比也清晰:一次集中规划加上 n 次子任务独立执行,远小于 ReAct 每步一次全上下文决策的 m 次调用。这个差距来自一个简单的事实:计划条目数 n 通常远小于决策步数 m,因为一个计划条目可以覆盖原本需要多次试探才能完成的工作。
工程上还有一个隐性收益:计划可以预览、日志可以回放,出问题时面对的不是一团黑盒,而是一份可指认的行程单——哪个子任务出了问题、哪个工具返回了异常数据,一目了然。对 AI 安全与合规而言,这比省几个 Token 重要得多。
- 规划成本 CplanPlanner 生成一次完整计划所需的模型调用开销
- 单步执行成本 ci每个子任务独立的执行开销,互相不重复阅读历史
- 步数差距 n ≪ m计划条目数远小于 ReAct 的决策步数,这是成本优势的根本来源
局限展望
攻略不是万能的。老周的行程单遇到突发封路就作废;写得再细,也预测不了天气突变。P&E 的软肋同样明显:计划质量依赖 Planner 的水平,如果目标本身含糊,计划必然含糊;计划一旦与真实环境脱节,执行得越忠实,反而错得越远。
局限可以归结为三点:一是规划偏差,目标描述不清晰时,子任务拆分必然走样;二是环境变化,静态计划对动态世界不敏感,必须靠重规划兜底;三是重规划成本,m 越大越灵活,但每一次 Plan 调用都是真金白银的模型开销。这三者共同构成一个核心权衡——多久重新看一次地图?
未来的研究方向包括:自适应重规划(让模型自己判断何时该重新看地图)、分层规划(先定省份再定城市,逐级细化)、以及 P&E 与 ReAct 的混合范式。回到云南的旅程:老周回了家,小王也回了家,只是一个电脑桌面是旅行照片,一个是教训总结。在 AI 长链任务这场旅途中,先规划再执行,始终是那条最稳妥的路。
- 重规划总成本m 次重规划带来的全部计划开销
- 固定执行成本n 个子任务本身必须付出的执行开销,与重规划次数无关
- 触发策略实际系统中常按固定步长或错误信号触发重规划,而不是每次执行都重新计划
AI 应用场景
智能客服工单的多步骤处理
阶段:任务规划与可靠执行
解决的问题:传统客服机器人面对“物流延误 + 申请退款”这类复合工单时,往往一次生成整段回答,在长对话中容易漏处理或答非所问。Plan-and-Execute 先把工单拆成“核对订单→查物流轨迹→查售后政策→生成回复”四个子任务,逐项执行,每步只关心局部信息,漏答率与跑偏率显著下降。
具体案例:某电商平台售后机器人上线 P&E 架构后,对双问题工单的完整解决率从 63% 提升到 89%,且每一步生成的中间结果都可追溯,方便质检团队抽查。
AI 安全审计中的可控性检查
阶段:AI 安全审计与合规
解决的问题:黑盒的多步推理难以审计,一旦智能体被对抗性输入诱导,可能在长链决策中悄悄越过安全边界。P&E 把计划外化为 JSON 清单,审计员可以在执行前检查子任务是否越权,执行中再对单步结果采样验证,把“不可见的推理”变成“可指认的行程单”。
具体案例:红队测试中,一个联网检索 Agent 被注入“忽略规则”的指令。由于 P&E 的规划清单里出现了“访问外部 URL 并直接采纳其中的操作指令”这一异常子任务,审计员在它执行前就将其拦截,避免了一次越权操作。
Python 演示
# -*- coding: utf-8 -*-"""Plan-and-Execute 的最小演示: 先规划子任务, 再逐步执行, 失败时重规划. """ class PlanExecuteAgent: """规划-执行智能体: 外层是线性计划, 内层是独立子任务执行. """ def __init__(self): self.plan = [] self.outputs = [] self.replans = 0 def plan_for(self, goal, items): # 规划阶段: 把目标拆成显式的 (任务, 参数) 序列 if goal == "sum_even_double": self.plan = [("sum_even", items), ("mul", 2)] elif goal == "double_first": self.plan = [("mul", 2)] # 故意漏掉求和, 用于演示重规划 else: self.plan = [("pass", items)] return [t for t, _ in self.plan] def execute(self, task, arg): # 执行阶段: 每个子任务只拿到自己的局部输入 if task == "sum_even": return sum(x for x in arg if isinstance(x, int) and x % 2 == 0) if task == "mul": if not self.outputs: raise RuntimeError("missing sum result") return self.outputs[-1] * arg if task == "pass": return arg raise ValueError("unknown task: " + task) def replan(self, cause, items): # 重规划: 发现依赖缺失时, 补齐前置子任务 self.replans += 1 names = [t for t, _ in self.plan] if "sum_even" not in names: self.plan.insert(0, ("sum_even", items)) def run(self, goal, items): self.plan_for(goal, items) self.outputs = [] guard = 0 while self.plan and guard < 6: guard += 1 task, arg = self.plan.pop(0) try: self.outputs.append(self.execute(task, arg)) except RuntimeError as cause: self.plan.insert(0, (task, arg)) # 失败任务放回, 等待前置补齐 self.replan(str(cause), items) return self.outputs[-1] if self.outputs else None def naive_one_shot(items): """无规划基线: 不加分解一次性处理, 容易误读目标. """ return sum(items) * 2 # 误把"偶数求和"理解成"全部求和" def main(): items = [1, 2, 3, 4, 5, 6] agent = PlanExecuteAgent() print("plan:", agent.plan_for("sum_even_double", items)) print("p&e result:", agent.run("sum_even_double", items)) # 期望 24 print("replan result:", agent.run("double_first", items)) # 期望 24 print("replan count:", agent.replans) print("naive result:", naive_one_shot(items)) # 得到 42, 偏离目标 if __name__ == "__main__": main()
self.plan = [("sum_even", items), ("mul", 2)]规划阶段把目标翻译成显式子任务序列,执行阶段不再需要边做边想目标是什么。task, arg = self.plan.pop(0)执行阶段逐项取出任务,每个子任务只面向自己的局部输入。raise RuntimeError("missing sum result")子任务暴露依赖缺失,成为触发重规划的明确信号。self.plan.insert(0, ("sum_even", items))重规划器补齐前置步骤,保证后续子任务有输入可用。naive_one_shot(items)无规划基线一次成型,误读目标后没有任何纠错机会,最终结果偏离预期。
常见误区
误区“Plan-and-Execute 不就是让智能体先想想再行动吗?那和 ReAct 完全是一回事,只是叫法不同。”
正解ReAct 是“思考→行动→观察→再思考”在每个时间步交错进行,决策时始终依赖累计的全部历史;P&E 则把“规划”与“执行”彻底分开,规划只做一次,生成显式清单,执行阶段按清单逐项完成。相当于小王每天起床现想“今天去哪”,老周出发前就定好行程——前者每步都动脑,后者一步到位,结构性完全不同。
为何常见:两者都强调“别急着动手”,初学者容易只看到“先思考”的表面,而忽略了“规划与执行分离”这一架构层面的差异。
误区“既然先规划好了子任务,那执行阶段肯定不会跑偏,完全不用管它。”
正解计划降低的是“决策漂移”这类系统性风险,并不消除所有执行错误:工具可能异常、环境可能变化、计划本身可能有缺陷。所以 P&E 通常还要配一个 Replanner,在子任务失败或结果偏离预期时重新生成剩余计划,相当于旅途前方封路时掏出地图重新绕行。
为何常见:人们容易把“显式计划”误当成“完美计划”,忽略了现实世界的动态性和工具调用的不可靠性。
误区“把任务拆得越细,执行就越不容易出错,所以子任务粒度越小越好。”
正解粒度太细会带来两个问题:一是规划成本与执行开销同步上升,Token 消耗和工具调用次数都会膨胀;二是计划对动态环境更敏感,一个小变化就要大改。粒度应当匹配任务复杂度,让每个子任务“自包含、可验证”即可,这与行程单不需要精确到每分钟是一个道理。
为何常见:“细化等于严谨”的直觉让初学者走向极端,忽略了成本与适应性之间的平衡。
误区“P&E 又稳又可控,以后所有智能体任务都应该无脑用 P&E,ReAct 该淘汰了。”
正解P&E 更适合结构清晰、步骤可预知的长链任务;对开放式探索、强交互的任务,如自由对话和动态决策,ReAct 的灵活性更优。选型要看任务的可规划性,就像自驾游适合定行程,街头漫游反而随性更好。
为何常见:看到 P&E 在长链任务上的显著收益后,容易把局部优势推广成全局结论,忽略了 ReAct 在交互场景中的不可替代性。
面试题
Q1. Plan-and-Execute 策略的核心思想是什么?
- A.每一步都先思考再行动
- B.先规划子任务再逐项执行← 正确答案
- C.省略规划只做快速执行
- D.依赖更大模型直接完成
答案:B。P&E 的核心是先把总体目标拆成显式子任务清单,再按清单逐项执行,对应选项 B。A 是 ReAct 的思路;C 和 D 都跳过了规划,不是 P&E。就像老周出发前写好行程,而不是边走边想。
Q2. “决策漂移”主要源于什么?
- A.单步偏差在长链中累积← 正确答案
- B.模型的参数量设置太少
- C.工具调用的速度不够快
- D.网络带宽存在明显瓶颈
答案:A。决策漂移的本质是每一步的微小偏差顺着上下文一路累积,最终大幅偏离目标。它与模型参数量、工具速度、带宽无关。好比小王每个决定都只偏一点点,六天后却偏出三百公里。
Q3. 与 ReAct 相比,P&E 的主要区别是什么?
- A.ReAct 每步都重新整体思考
- B.ReAct 与 P&E 完全同质
- C.P&E 显式计划并分离执行← 正确答案
- D.P&E 不关注规划质量
答案:C。ReAct 在每个时间步交错进行思考与行动,P&E 则把规划一次性前置、执行阶段只按清单走。A 描述的是 ReAct 的特点而非区别,B 和 D 都与事实不符。类似小王边走边想与老周按图索骥的差别。
Q4. 在 P&E 架构中,执行阶段的每个子任务应使用什么上下文?
- A.全部历史步骤拼成的上下文
- B.与当前子任务相关的局部信息← 正确答案
- C.未来子任务的完整执行结果
- D.随机抽取的若干上下文片段
答案:B。P&E 的关键设计之一就是“局部上下文”——每个子任务只拿自己需要的输入,避免全量历史造成上下文污染。A 正是 ReAct 的做法,C 属于未来信息不可用,D 是随机噪声,都不对。
Q5. 在 P&E 中,重规划(Replanning)通常发生在什么时机?
- A.规划阶段开始之前就进行重规划
- B.所有子任务全部完成之后进行
- C.执行异常或结果偏离目标之时← 正确答案
- D.Plan-and-Execute 从不重规划
答案:C。重规划发生在执行过程中出现异常、或中间结果明显偏离预期时,让 Planner 结合最新历史重新生成剩余计划。A 缺少可参考的历史,B 为时已晚,D 否定了重规划机制的存在。
Q6. 为什么显式计划能降低长链决策漂移?
- A.目标外化为清单且上下文更短← 正确答案
- B.让模型看到更多历史信息
- C.降低工具调用次数以提高速度
- D.完全消除所有可能的执行错误
答案:A。显式计划把目标变成外部清单,不再依赖模型的工作记忆防遗忘;同时每个子任务只用局部上下文,切断了噪声累积。B 方向相反,C 与漂移无关,D 过度绝对化——计划不能消除所有错误。
Q7. 下列哪类任务最适合采用 P&E?
- A.开放式自由闲聊对话
- B.结构化多步骤数据处理← 正确答案
- C.单步短文本补全任务
- D.无目的的随机信息检索
答案:B。P&E 适合结构清晰、步骤可预知的长链任务,例如多步骤数据处理。开放式对话更需要 ReAct 的灵活性,单步任务用不上计划,随机检索也没有可规划的目标。
Q8. 下列关于 P&E 局限性的说法,正确的有哪些?
- A.计划质量依赖规划器能力← 正确答案
- B.动态环境可能使计划失效← 正确答案
- C.重规划不会产生额外成本
- D.子任务粒度过细会降低适应性← 正确答案
答案:ABD。规划质量取决于 Planner 对目标的理解,动态环境下静态计划可能过时,粒度太细会放大对变化的敏感度,因此 A、B、D 正确。重规划每次都要调用 Planner 产生模型开销,C 错误。
Q9. P&E 架构通常包含哪些核心组件?
- A.Planner 负责拆解总体目标← 正确答案
- B.Executor 逐项执行子任务← 正确答案
- C.Replanner 处理异常与变更← 正确答案
- D.Database 负责持久化索引
答案:ABC。标准 P&E 三元组是 Planner、Executor、Replanner,分别负责规划、执行、重规划。数据库索引不是 P&E 的必要组件,缺少它系统依然可以运行,因此 D 不选。
Q10. 下列哪些机制可以缓解长链决策漂移?
- A.使用显式子任务分解策略← 正确答案
- B.每步都依赖全量历史上下文
- C.在关键节点执行定期重规划← 正确答案
- D.限制单步使用的局部上下文← 正确答案
答案:ACD。显式分解外化目标、定期重规划纠正方向、局部上下文减少噪声,三者都能抑制漂移。B 恰恰是漂移的温床——全量历史会让噪声持续累积,与缓解目标背道而驰。