从 ReAct 到 Planning：从走一步看一步到先拆解再推进
如果说 ReAct 解决的是“大模型如何边思考边行动”，那么 Planning 解决的就是：当任务变长、步骤变多、约束变复杂时，很多 Agent 不再直接进入执行，而是会先做任务拆解，再决定如何推进。
一、 这篇解决什么问题
在学完 ReAct 之后，很多人会自然产生一个新的疑问：
- 既然 ReAct 已经能“边想边做”，为什么还需要 Planning？
- 什么情况下，模型临场决策已经不够用了？
- 为什么有些 Agent 在真正执行前，会先产出一个 plan？
- Planning 和 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 赋予一个更清晰、更稳固的上层结构。