从 ReAct 到 Planning：从走一步看一步到先拆解再推进

如果说 ReAct 解决的是“大模型如何边思考边行动”那么 Planning 解决的就是当任务变长、步骤变多、约束变复杂时很多 Agent 不再直接进入执行而是会先做任务拆解再决定如何推进。一、 这篇解决什么问题在学完 ReAct 之后很多人会自然产生一个新的疑问既然 ReAct 已经能“边想边做”为什么还需要 Planning什么情况下模型临场决策已经不够用了为什么有些 Agent 在真正执行前会先产出一个 planPlanning 和 Workflow 是一回事吗Planning、ReAct、Workflow 到底分别解决什么问题这篇文章要回答的核心问题就是当任务复杂到一定程度时为什么很多 Agent 不再满足于“走一步看一步”而会先做任务拆解再进入执行阶段。二、 先讲最小概念1. ReAct 在做什么ReAct 的核心是读当前上下文 - 判断下一步该做什么 - 调工具或继续思考 - 根据新结果进入下一轮。 它更像一种“边走边想”的推进方式。2. Planning 在做什么Planning 的核心是在真正执行前 - 先把目标拆成若干步骤或子任务 - 给后续执行提供一个相对稳定的路线图。 它更像一种“先想清楚大致路径再开始动手”的方式。最短区别ReAct更关注“当前这一步该做什么”。Planning更关注“整个任务大致应该怎么拆、怎么走”。三、 为什么单步推理有时候不够用ReAct 很强但它有一个天然特点它每一轮都更关注“眼前下一步”而不是“整个任务全局结构”。这在简单任务里完全没问题。但一旦任务开始变复杂就容易出现几个问题容易只顾眼前不顾全局模型可能会当场找到一个能做的动作就先做但根本没有先考虑整体路径是否合理。容易重复、绕路当缺乏整体计划时模型可能会重复搜索、重复调用相近工具或者在多个子问题之间来回无意义地切换。长任务里容易丢失结构感如果一个任务本来包含多个阶段纯靠局部循环推进模型很容易在中途失去对“当前到底做到第几步”的清晰把握就像在深层的代码调用栈里迷失了方向。很难提前暴露任务分解对于人类或系统来说有时候最想知道的不是“模型现在在干嘛”而是它准备怎么做它打算分成几步每一步想解决什么问题这时就需要 Planning。四、 什么样的任务开始需要 Planning多阶段任务例如写一份深度的技术调研报告、做一轮微服务架构的源码分析、排查一个复杂的线上服务器 OOM 异常。这些任务天然不是一步就能完成的。包含多个子问题的任务例如“帮我比较 5 个消息队列框架的优缺点并结合高并发场景给出选型建议”或者“先分析需求再查资料再输出方案”。这里不是单次工具调用的问题而是任务拆解问题。有明显前后依赖关系的任务例如先收集信息 - 再筛选信息 - 再总结 - 最后生成结论。如果前后顺序绝对重要Planning 的价值就会直线上升。需要更强可解释性的任务有些时候你希望系统先把计划列出来给人看。这样一来人可以提前校正方向系统执行过程更可审计后续如果中断也更容易恢复和接管。五、 Planning 通常长什么样最简单的 Planning模型在动作前会先输出类似这样的文本内容明确任务目标拆解子任务确定执行顺序按步骤逐步执行 也就是说Planning 的最小形态可能就是一个结构化的计划列表。更工程化的 Planning在真实 Agent 系统里Planning 往往会映射成具体的数据结构表现为一个plan字段一个subtasks列表一个current_step游标一个专门的“Planner Node”先生成任务分解后面再由 Executor 逐步执行。也正因为如此很多走向工程化的 LangGraph 项目里会开始频繁出现plan、steps、task_queue这类状态State字段。六、 Planning 和 ReAct 是什么关系最容易误解的是有了 Planning是不是就不用 ReAct 了 答案通常不是。Planning 和 ReAct 往往不是替代关系而是不同层级的能力。一种常见组合方式Planning 负责先把任务拆开。ReAct 负责在每个子任务内部边思考边行动。比如先规划出“查资料 - 提炼重点 - 写总结”。然后在“查资料”这一步内部模型仍然可以用 ReAct 的方式去高频地搜索和筛选信息。总结Planning 解决“先分几步做”ReAct 解决“当前这一步怎么做”。七、 Planning 和 Workflow 又是什么关系很多人会把这两者混为一谈。区分它们其实很简单Planning更像“先做任务拆解”动态生成的计划。Workflow更像“把流程结构显式写进图和路由”静态定义的骨架。也就是说Planning 不一定意味着流程已经硬编码在代码里了Workflow 也不一定要求模型先产出一个文本计划。两者可以完美结合但绝不是一回事。总结Planning 更关注任务拆解本身Workflow 更关注执行骨架和流程控制。八、 Planning 的优势更有全局感模型不再只盯着“眼前这一步”而是先建立整体路线图。更适合复杂任务任务越长、阶段越多Planning 防跑偏的价值越明显。更容易解释和审查先把计划列出来人类和系统都更容易判断大方向是否合理。更利于和其他机制结合有了计划清单就极其方便接入 Human-in-the-loop人类审批、Workflow 节点跳转或者进行多 Agent 协同分工。九、 Planning 的代价和局限不要把它当成所有场景的银弹它也有明显的代价先规划本身有成本多一次模型调用就多一层 Token 消耗、多一层状态和逻辑维护。计划不一定靠谱模型给出的计划也可能会漏步骤、顺序不合理或者拆得太粗/太细。过度规划会拖慢简单任务有些任务本来一句话就能答硬套 Planning 框架反而白白浪费时间。计划和执行可能脱节即使计划看起来天衣无缝在执行中仍可能因为外部结果的变化而必须推翻重来。就像你一开始规划好了游戏地图的渲染和寻路逻辑但在实际编写时突然发现水域底下的物理映射逻辑行不通比如水区其实不该有路径这时候你就必须中途打破原定计划动态修改路线。十、 什么时候该考虑引入 Planning如果你的任务满足以下特征优先考虑 Planning任务明显包含多个阶段。子任务之间存在强依赖关系。你希望在系统执行前先看到路线图以求心安。发现纯 ReAct 极其容易绕路、钻牛角尖或反复试错。你希望后续和 Workflow、HITL 或多 Agent 架构深度结合。如果你的任务满足以下特征则不一定需要任务很短问题简单直接。单轮或少量工具调用就能顺理成章地完成。额外引入规划节点只会徒增系统的延迟和维护开销。十一、 总结ReAct 让模型学会了边思考边行动但它更偏向“眼前下一步”的动态决策。当任务变长、步骤变多、结构变复杂时很多系统就会进一步引入 Planning让模型先把任务拆开再进入执行阶段。所以Planning 解决的不是“会不会调用工具”而是“在真正行动之前要不要先建立一张任务路线图”。也正因为如此Planning 往往不是为了替代 ReAct而是为了在更复杂的长线任务里给 ReAct 赋予一个更清晰、更稳固的上层结构。