ReAct vs 传统规划怎么选?

这道题其实是在问：[[Agent]]做决策的时候，是应该每一步都看当前情况再决定，还是先把整条路画好再走。这本质上是个决策节奏的取舍问题。

先说[[ReAct]]。它的核心是交错式循环：想一下，动一步，看一眼结果，再想下一步。你可以把它理解成「走一步看一步」的实时反馈闭环。每一步都会生成推理轨迹，也就是它为什么这么做的思考过程，然后调用工具，比如查个数据库或者调个API，观察返回结果再更新状态。这种模式的好处是容错性很强，单步走错了没关系，下一步看到反馈马上就能修正。而且信息是按需获取的，不会提前拉一堆用不上的数据。还有一个隐形的优点是可解释性，推理轨迹天然就是透明的，你很容易追查它每一步的决策依据。

但ReAct也有明显短板。最头疼的是短视，它每一步都只盯着局部最优，复杂长程任务很容易跑偏。比如让它做一个多步的客服退款流程，它可能在第一步查订单时发现金额不对，就一直在那来回查，忘了最终目标是完成退款。这就是典型的循环风险，反复试错出不来。而且每多一步交互就多一次延迟，累积下来总耗时可能很大。

再说Planning架构。它的思路正好反过来，先做全局规划，再按计划执行。比如用 [[Tree-of-Thoughts]] 或者分层规划，一次性把任务拆成子步骤，然后按顺序或并行执行。这就像先画好施工图再动工，适合环境确定、约束明确的场景。比如数学证明题或者代码生成，前提条件不会中途变，全局规划能保证长程依赖和约束条件都处理好，执行起来效率也高。

但Planning的毛病也很要命。最核心的是僵化，一旦环境变了，比如你规划的是去数据库查A表，结果实际运行时A表结构改了，整个计划就废了。而且规划阶段可能做了很多无用功，比如把可能用到的数据都拉进来，结果实际只用了一小部分。失败时重规划的代价也高，相当于推倒重来。

所以说白了，ReAct适合开放域、动态环境，比如网页浏览、数据库查询这种走一步看一步的；Planning适合封闭域、确定性任务，比如代码生成、数学证明。但真正落地的时候，我很少只用其中一种。更常见的是混合架构：高层用Planning做全局分解，比如把「处理客户退款」拆成「查订单→验资格→算金额→执行退款」几个大阶段，然后每个阶段内部用ReAct细粒度执行。这样既保证了长程目标不跑偏，又保留了应对局部变化的灵活性。

这里有个有意思的延伸：如果任务环境是部分可观测的，比如智能客服，用户意图可能中途变，那Planning的全局规划很容易失效。这时候可以引入 [[Reflexion]] 机制，让Agent在每次执行完一个子任务后自我反思，把反思结果反馈回规划层动态调整。这其实就是把两种思路进一步融合了。

所以我的判断是：ReAct和Planning不是互斥的，而是互补的。我更倾向根据任务复杂度、环境确定性和实时性要求来动态选择。比如简单任务直接用ReAct，复杂但稳定的任务用Planning，复杂且动态的任务就用混合架构。上线前我会特别关注一个风险：混合架构里规划层和行动层的反馈回路如果设计不好，容易出现调度死锁或者状态不一致，这个在系统设计时就要提前做好监控和兜底。