Agent 的规划与执行范式Plan-Execute-Replan 与 ReAct一.什么是 Agent在大模型应用中Agent 通常指一个系统。它围绕目标能够选择行动、调用工具并根据环境反馈继续工作。它常用于需要多个步骤才能完成的任务例如客服查询、资料调研也包括故障排查。大模型可以解释“订单通常为什么延迟发货”。但要回答“我的这笔订单能不能在周五前收到”就需要查询具体订单、库存和配送信息再根据查到的结果作出判断。这个过程中模型负责理解目标和选择行动工具负责查询或操作外部系统运行程序负责执行调用、保存结果和控制流程。这里有一个容易混淆的地方模型提出工具调用运行程序实际执行调用。工具返回的结果进入上下文后模型才有条件据此决定下一步。有了这些能力还需要解决任务怎样组织的问题先做什么后做什么原来的安排走不通时接下来怎样调整下面按照Plan-Execute → 暴露局限 → 引入 Replan → ReAct → 对比 → 协作的顺序逐步看清这些问题。二.先规划再执行Plan-Execute1.Plan 和 Execute 分别做什么Plan-Execute 将任务处理分成两个逻辑阶段。Plan也就是规划。根据用户目标和约束形成一组步骤明确先后顺序和依赖关系。这部分职责通常称为 Planner。Execute也就是执行。选取计划中的步骤调用工具或其他处理逻辑得到对应结果。这部分职责通常称为 Executor。例如Planner 安排“核对原仓的预计到货时间”Executor 再决定需要查询哪些信息。一个计划步骤不一定对应一次工具调用。核对到货时间可能需要先查订单再查备货时间最后查询配送时效。2.先采用一个简化版本为了看清后面的演变过程我们先约定Planner 只生成一次总体计划。执行器可以根据反馈完成当前步骤但系统暂时不修改总体计划。这里限制的是总体计划的修订。执行器仍然可以补查信息、记录失败或者调整当前步骤里的工具调用方式。这是本文的教学简化。LangChain 官方的 Plan-and-Execute 介绍本身就包含执行后的重规划因此不能把“计划始终不变”当成所有 Plan-Execute 实现的共同定义。3.用订单到货查询串起整个流程**案例说明**下文的订单、仓库、费用、工具名称与返回结果均为教学模拟。工具调用使用示意写法不对应某个平台的实际 API到货时间表示当前信息下的预计结果。假设现在是周二上午用户提出下面的需求时间统一使用北京时间帮我看看订单O1001能不能在本周五 18:00 前收到。如果原来的安排赶不上查一下其他办法。商品、数量和收货地址保持不变可以考虑其他仓库或配送方式额外总费用不能超过 20 元。本次只查询并给建议。订单购买了 1 件SKU-01商品目前安排由 A 仓发货。库存和配送情况还需要进一步查询。先从原仓路线开始给出一份尚未展开替代方案的初始计划。下面观察执行反馈如何暴露计划中的缺项再通过重规划补齐剩余工作。步骤工作内容预期产物P1确认订单、商品、数量、收货地址和原发货仓订单基础信息P2核对 A 仓供货情况和预计到货时间原仓路线的时效判断及依据P3在原仓路线能满足期限的前提下整理到货安排原仓方案P4汇总到货判断、处理建议及相关条件给用户的查询结果注意P3 依赖“原仓路线能够按时到货”这个待验证前提。用户允许评估其他仓库并没有要求必须沿用 A 仓。如果 P2 确认原仓能够按时送达后面就可以直接整理安排和建议。接下来我们会看到这个前提也可能被查询结果推翻。4.再看控制流程现在有了具体任务再看流程图就容易对应了Planner 生成 P1P4执行器依次处理步骤每次结果都会被保存但图中没有返回 Planner 修改计划的路径。继续执行无剩余步骤前提失效用户目标与约束生成初始计划选取当前步骤执行步骤保存结果后续安排检查并汇总返回阶段结果下面用语言无关的伪代码表示重点看计划怎样被使用计划 ← Planner(目标, 约束) 历史 ← 空记录 按依赖顺序处理计划中的步骤 结果 ← Executor(当前步骤, 约束, 历史) 保存步骤状态、结果和依据 如果后续步骤的关键前提不成立 返回阶段结果、未完成项和原因 核对目标与交付内容返回汇总结果这里的历史需要由程序保存再提供给后续步骤。新的模型调用不会自动知道之前查到了什么。三.当新信息推翻了原来的假设1.工具成功返回原仓路线却赶不上了执行到 P2 时查询得到以下信息【教学模拟E1原仓供货与配送信息】 订单O1001尚未出库 原发货仓A 当前可用库存0 预计补货时间本周六 10:00 按该备货时间估算的到货时间下周一 18:00库存与配送工具正常返回了信息但这些信息说明按照当前供货安排A 仓路线无法满足本周五 18:00 前到货的要求。再看原来的 P3在原仓路线能满足期限的前提下整理到货安排。它的执行前提已经不成立了。接下来要调查的内容变成了其他仓库有没有同款现货能否送到原地址到货时间和额外费用是否符合要求这些工作还没有包含在原计划中。2.原计划还能交付什么基础版本可以停止这条路线并告诉用户原仓缺货按现有安排预计下周一到货赶不上要求的时间。这个回答有依据但只完成了需求的一部分。用户还要求了解其他办法而我们尚未调查其他发货方案。初始计划建立在不完整的信息上执行过程中得到的新信息可能改变剩余工作本身。如果初始计划已经安排了其他仓库评估这里可以按条件继续执行。固定工作流可以覆盖预先设计的分支Replan 则允许系统根据新结果补充或调整安排。四.通过 Replan 更新剩余计划Replan也就是重规划负责结合执行结果检查目标是否已经满足剩余计划是否仍然合适需要继续、修改还是结束。加入这项职责后就形成了Plan → Execute → 检查结果 → Replan的循环。本文将其称为 Plan-Execute-Replan。Planner、Executor 和 Replanner 是逻辑职责可以使用同一个模型配合不同输入和程序控制完成不必对应三个独立 Agent。1.重规划需要哪些信息如果只把“A 仓没货”交给 Replanner它还不知道用户是否着急、能否接受加价也不知道哪些事情已经查过。在当前案例中它需要一起看到这些信息。**原始目标**判断能否按时到货并给出处理建议。**用户约束**本周五 18:00 前收到商品、数量和地址不变额外总费用不超过 20 元。**已完成工作**P1 已确认订单信息P2 已完成原仓供货与时效核查。**新观察及依据**E1 表明原仓预计周六补货按当前安排预计下周一到货。**剩余计划**P3 原本准备整理原仓方案P4 再汇总建议。这些信息放在一起才能判断哪些步骤需要保留哪些步骤需要调整。原仓赶不上并不意味着可以自行放宽用户的到货期限或费用上限。2.计划究竟改了什么前面准备沿用原仓现在查询结果已经否定了这个前提。原来的 P3 需要调整先把其他方案的调查补上原计划更新后的安排修改原因P1确认订单基础信息保留完成状态和查询结果商品、数量和地址仍然是后续查询的依据P2核对原仓供货与时效保留完成状态和 E1已经查明原仓路线赶不上期限P3整理原仓方案P3评估其他仓库的配送方案寻找满足到货期限和费用上限的候选原仓赶不上需要评估其他仓库的现货和配送方案P4汇总建议汇总候选方案的费用、预计到货时间及办理条件最终建议要建立在新调查上这里将不同配送方式放在同一个计划步骤中评估具体查询顺序由执行器根据反馈决定实际工具如果能一次返回完整报价也可以直接比较。这次调整保留了已经完成的调查只修改受影响的剩余工作。它也没有提前断言“其他仓库一定有合适方案”P3 还是待验证的任务。3.什么时候需要检查计划本例由一条成功取得的新信息触发重规划过程中并没有必须发生的工具报错。其他需要检查的情况还包括取得的报价违反费用约束且当前步骤内没有可继续评估的方案必要接口持续不可用多次查询没有带来进展已有结果已经足够回答用户可以取消多余步骤。实现时可以每完成一个步骤就检查也可以在关键发现出现时提前交接。检查计划不等于每次都必须改写计划。如果新的情况已经被剩余步骤覆盖继续执行就可以了。4.怎样判断可以结束完成判断要对照用户需求原仓能否按时到货、有哪些符合约束的候选方案以及办理时需要满足哪些条件这些问题是否已经回答清楚。计划列表为空只表示没有剩余条目还需要检查有没有遗漏工作。如果查过的方案都不满足要求可以给出“本次已核查的方案均不符合约束”的结论。如果只是关键资料没有查到则应说明“目前还不能判断”。两种结果的依据不同。调用次数、运行时间和无进展限制也会影响何时停止后面结合双层循环的伪代码一起说明。五.让推理与行动交替进行ReAct1.ReAct 的核心思想ReAct 来自Reasoning 与 Acting核心是让推理与行动交替进行根据目标和已有观察决定下一步通过行动获得新信息再让新信息影响后续决策。ReAct 原论文中常见的表示是Thought决定下一步 ↓ Action执行行动 ↓ Observation获得观察 ↓ 结合目标与新观察继续决定下一步这是一种组织决策与行动的方式不要求实现必须公开模型的内部思考。下文使用人为编写的简短决策摘要来解释过程。2.用三个连续阶段看清执行过程先让 ReAct 直接负责完整的订单查询目标看看下一次行动怎样受到上一条结果的影响。到第七章再把它放进具体的计划步骤中。2.1确认订单发现原仓赶不上先确认订单对应的商品和仓库再核对当前到货安排。查询发现订单还没有明确的预计到货日期就继续补查供货信息。【教学模拟原仓查询过程】 查询订单(O1001) → 1 件 SKU-01原仓 A尚未出库取得原收货地址。 查询原订单预计到货(O1001) → 等待补货预计到货日期暂缺。 查询补货(A, SKU-01) → 当前可用库存为 0预计本周六 10:00 补货。 估算配送(A, 原收货地址, 本周六 10:00 备货, 普通) → 预计下周一 18:00 到货。这里在“到货日期暂缺”后继续查询根据缺货信息补查备货时间再取得配送估算形成前面的 E1。原仓路线赶不上期限下一步就需要调查其他仓库。2.2找到加急方案发现费用超出约束接下来查询同一商品的其他发货方案先核对加急配送是否可行。【教学模拟E2其他仓库与加急报价】 查询其他仓库方案(O1001) → B 仓同一 SKU 可用库存为 4 件。 → 该订单支持申请改由 B 仓发货原地址可配送。 → 可查询加急和普通两种配送报价。 查询配送报价(O1001, B, 加急) → 预计本周四 18:00 到货。 → 额外总费用35 元。 → 报价要求本周二 16:00 前确认改仓与配送安排。这个方案的预计到货时间符合要求但额外费用是 35 元超过用户给出的 20 元上限。加急方案因此不能作为符合本次要求的建议。工具已经返回 B 仓还支持普通配送接下来就可以继续查它的时效和费用。2.3核对普通配送形成候选建议我们已经取得 B 仓库存和该订单的改仓条件可以沿用这些信息继续核对普通配送报价。【教学模拟E3B 仓普通配送报价】 查询配送报价(O1001, B, 普通) → 预计本周五 16:00 到货。 → 额外总费用10 元。 → 报价要求本周二 16:00 前确认改仓与配送安排。按当前报价普通配送的预计时间早于周五 18:00额外费用也没有超过 20 元因此可以作为候选方案。回头看这三个阶段没有明确到货日期就补查供货原仓赶不上就查其他仓库加急超预算就继续核对普通配送。后一个动作都有前一个观察作为依据。3.ReAct 能不能规划ReAct 也能拆解目标、形成计划还能跟踪进展并根据反馈调整安排。原论文就将这些列为推理的用途。它与显式 Plan-Execute-Replan 的主要区别在于是否把总体计划及其修订设置为独立的控制层。典型 ReAct 循环可以直接围绕目标选择行动不要求先创建一份单独维护的完整计划对象。在较长任务中如果状态管理不足ReAct 可能重复查询已经查过的仓库或者忽略先前的费用限制。这时就需要加强结果记录、阶段目标和进展检查。六.Plan-Execute-Replan 与 ReAct 怎样比较下面比较两种典型组织方式。它们的能力范围存在重叠也可以组合使用。比较维度Plan-Execute-ReplanReAct主要关注显式管理总体步骤、依赖和剩余工作根据目标与观察选择下一步行动怎样使用反馈更新步骤记录检查目标与剩余计划直接影响接下来的行动选择调整时机步骤完成、关键发现或异常等检查点获得新观察后即可调整下一步长任务中的特点便于检查进度、遗漏和路线变化需要注意历史管理、重复行动和目标偏离成本与延迟增加规划和重规划调用也可能减少无效探索多轮决策会产生开销短任务也可能很快结束常见适用情况多阶段、有依赖、需要持续检查进度的任务需要根据工具结果不断决定下一步的任务成本需要结合具体分工判断。如果几次查询就能完成任务再加入规划和重规划可能增加等待如果任务包含多个相互依赖的调查阶段显式计划则有助于管理剩余工作。还有一种组织方式保留总体计划在执行某个步骤时使用 ReAct。下面重点看它们怎样配合。七.Plan-Execute-Replan 与 ReAct 如何协作1.先看两层怎样连接一种常见的组合是外层通过 Plan-Execute-Replan 管理总体任务内层 ReAct Executor 完成当前步骤。LangGraph 的官方归档教程展示了这种结构用 ReAct 执行器处理计划中的当前步骤再将结果交给重规划逻辑。这里参考其架构归档代码不作为当前 API 的使用指南。看图时关注两个循环以及内层向外层交接的位置外层Plan-Execute-Replan内层ReAct Executor下发步骤输入否是继续调整验收通过阻塞或停止用户目标与约束生成初始计划选择步骤决定下一步需要交接调用工具记录观察返回步骤结果更新执行历史检查目标与计划修改剩余计划交付最终结果交付阶段结果“需要交接”包括步骤完成、发现影响总体安排的问题、无法继续调查或局部预算到限。内层可以调用多次工具再向外层返回一次结果。全局预算由运行程序统一检查可以在任一调用前触发停止图中只保留主要交接路径具体控制放在后面的伪代码中。2.把订单案例连续执行一遍2.1外层选择 P2并下发步骤输入P1 已经完成外层选择 P2。此时发送给执行器的内容可以是【教学模拟P2 的步骤输入】 步骤目标核对 A 仓供货与配送安排判断原路线是否符合到货期限。 已有上下文 订单 O10011 件 SKU-01原发货仓为 A原收货地址已取得。 用户约束 本周五 18:00 前收到商品、数量和地址不变 额外总费用不超过 20 元本次只查询并给建议。 局部完成条件 取得原仓供货与预计到货依据给出明确判断。 关键资料缺失时返回尚未完成及缺失原因。 工作范围 本步骤核查原仓替代路线交给外层安排。这里的完成条件是“查明原路线是否符合期限”。得出“不符合”的结论也因此可以完成这个调查步骤。2.2内层补查信息并返回结果包执行器先查询原订单预计到货时间发现日期暂缺于是补查备货情况再估算配送时效【教学模拟P2 内部的行动与观察】 查询原订单预计到货 → 等待补货暂缺到货日期 查询 A 仓补货安排 → 预计本周六 10:00 补货 根据备货时间估算配送 → 预计下周一 18:00 到货这个过程中执行器调整了调查路径但始终围绕 P2 的目标工作。取得 E1 后它向外层返回【教学模拟P2 的返回结果】 步骤状态已完成 结论按当前供货与时效信息原仓路线不能满足到货期限。 依据 E1A 仓补货查询与配送估算。 预计本周六 10:00 补货按该备货时间预计下周一 18:00 到货。 对剩余计划的影响 P3 所依赖的“原仓能够按时到货”前提不成立。 还缺少的工作 其他仓库及配送方式的调查。实际系统还应保留查询时间、关键参数和来源便于复核库存、报价等会变化的信息。注意此时这三个状态同时存在。**工具调用成功**取得了供货和配送信息。**当前步骤完成**已经回答原仓能否满足期限。**原路线受阻**沿用原仓无法满足本次要求需要评估其他办法。如果只返回一个“失败”外层就难以分清是接口没有查通还是已经查明路线不合适。前一种情况可能需要补查后一种情况需要调整剩余工作。2.3Replanner 调整剩余计划Replanner 结合目标和约束参考 E1 与当前计划保留 P1、P2 的完成记录将原来的 P3 替换为第四章中的候选方案调查【教学模拟更新后的剩余计划】 P3评估其他仓库的配送方案寻找满足到货期限和费用上限的候选。 P4汇总候选方案、费用、预计到货时间及办理条件。这里增加了原计划没有覆盖的工作原始到货期限和费用限制继续生效。2.4ReAct 执行新步骤外层继续检查外层下发新的 P3。ReAct Executor 查询其他仓库和加急报价取得 E2B 仓有同款现货但加急需要额外支付 35 元超出上限。评估还没有结束。执行器根据 20 元的费用上限排除加急方案继续核对普通配送这些行动都在 P3 内部完成。查询得到 E3预计周五 16:00 到货额外费用 10 元报价要求周二 16:00 前确认安排。执行器将普通配送作为候选连同 E2、E3 的依据一起返回外层。Replanner 检查候选与剩余计划确认可以继续执行 P4整理给用户的建议。这一次需要检查但没有必要再生成一份全新计划。2.5完成整体交付检查P4 可以形成下面这样的结果【教学模拟最终建议】 原仓安排 A 仓预计本周六补货按当前安排预计下周一到货赶不上要求。 依据E1。 加急方案 B 仓加急预计周四到货但额外总费用为 35 元超过费用上限。 依据E2。 候选建议 申请改由 B 仓使用普通配送商品、数量和地址不变。 按当前报价预计周五 16:00 到货额外总费用为 10 元。 依据E2 中的改仓条件以及 E3 的普通配送报价。 办理条件 需在本周二 16:00 前确认改仓和配送安排办理时复核库存与报价。 到货时间为预计值。 当前进度 已形成查询建议尚未修改订单或锁定库存。外层检查的重点是原仓判断有没有依据候选方案是否符合商品、地址、时间和费用要求办理条件与不确定性有没有交代清楚。这些内容齐全才满足本次“查询并给建议”的目标。仅有 P4 的“已完成”标记还不够。3.局部调整与总体重规划的边界刚才的过程可以这样区分。到货日期暂缺转而查询补货时间仍在回答 P2 的问题由内层 ReAct 继续调查。查明原仓赶不上新增其他仓库与配送方式的评估改变了剩余工作由外层 Replanner 调整。加急超预算继续核对普通配送仍在完成 P3 的候选评估由内层 ReAct 处理。这个边界取决于当前步骤被赋予的目标和范围。本例把配送方案评估放在同一个 P3 中因此加急与普通配送的切换都由内层处理。第五章的 ReAct 直接负责完整查询目标可以自行推进整条调查本章将它放入明确的计划步骤交接范围就随之收窄。4.用伪代码看两层怎样衔接先看内层。与第二章相比这里把 Executor 展开成一个循环能够继续调查也能够向外层交接过程 ReAct执行(步骤, 上下文, 约束, 共享预算) 局部记录 ← 必要上下文 循环 如果满足局部完成条件 返回已完成的结果包 如果发现需要外层处理的问题 返回步骤进展、依据和对总体计划的影响 如果全局停止条件触发或局部调查无法继续 返回阶段结果、缺失信息和停止原因 行动 ← 根据步骤目标、约束与局部记录决定下一步 结果 ← 执行行动并记录结果 更新局部记录、证据、预算和进展状态行动可以是工具调用也可以是整理结论。模型提出结束时仍要按局部完成条件检查证据是否足够交接结果还要区分步骤是否完成。再看外层。结果先进入历史Replanner 才能据此安排下一步共享预算 ← 初始化一次任务的全局预算 计划 ← Planner(目标, 约束) 历史 ← 空记录 循环 如果全局停止条件触发 返回阶段成果、未完成项和原因 步骤 ← 从计划中选取当前可执行步骤 如果步骤存在 结果 ← ReAct执行(步骤, 必要上下文, 约束, 共享预算) 更新历史中的步骤状态、结果和依据 如果全局停止条件触发 返回阶段成果、未完成项和原因 决策 ← Replanner(目标, 约束, 计划, 历史) 如果决策为完成 如果整体交付检查通过 返回最终结果 否则 将缺项补入剩余计划继续循环 如果决策为阻塞 返回已有成果和缺失条件 根据决策保留或更新剩余计划这些伪代码用于说明控制结构省略了工具参数校验、异常处理等实现细节。每次实际模型或工具调用前都需要由运行程序检查预算和超时达到全局上限时直接走停止出口不能继续调用 Replanner。可以为教学实现设置一组限制单个步骤最多调用工具 6 次整个任务最多调用工具 20 次、模型 30 次总耗时不超过 5 分钟。连续两次外层检查都没有新增证据、排除候选或推进步骤时也停止并报告进展不足。这些数字只是配置示例。模型调用次数应覆盖 Planner、ReAct 内部决策、Replanner以及额外的模型检查进入新步骤时局部额度可以重新分配全局预算继续累计。5.什么时候值得使用这种组合这种组合适合有多个总体阶段的任务阶段内部又需要根据反馈继续探索例如复杂订单异常处理和跨系统故障调查也包括多来源资料分析。它也会增加模型调用、状态维护和交接成本。步骤划分过细外层会频繁介入步骤过大外层又难以掌握实际进展。对于规则固定的订单查询如果一次接口就能返回完整结果直接使用业务工作流会更简单。需要持续管理剩余任务同时又无法预先确定每一次工具行动时外层规划与内层 ReAct 的分工才更有价值。