ReAct vs 传统规划怎么选?

30 秒回答

1. ReAct的交错推理-行动循环机制
2. Planning的先验规划-后执行模式
3. 两者在容错性、实时性、可解释性上的对比
4. 适用场景差异（开放域vs封闭域）

回答与解析

答案要点

• ReAct的交错推理-行动循环机制
• Planning的先验规划-后执行模式
• 两者在容错性、实时性、可解释性上的对比
• 适用场景差异（开放域vs封闭域）

核心设计理念差异

流程对比

ReAct循环

Thought → Action → Observation → (repeat)

• 每步生成推理轨迹（Thought）说明"为什么做"
• 调用工具（Action）获取外部信息
• 观察结果（Observation）更新状态
• 动态决定下一步

Planning架构

Plan Generation → Plan Execution → (optional replanning)

• 一次性或分层生成任务计划（如ToT、CoT规划）
• 按序或并行执行子任务
• 失败时触发重规划

优缺点对比

ReAct优势

• 容错性强：单步错误可通过后续观察修正
• 信息高效：按需获取外部信息，避免冗余
• 可解释性好：推理轨迹天然透明

ReAct劣势

• 决策短视：局部最优可能偏离全局目标
• 循环风险：复杂任务易陷入反复试错
• 延迟累积：多轮交互增加总耗时

Planning优势

• 全局优化：长程依赖和约束条件处理更优
• 执行高效：规划完成后可快速执行
• 适合封闭域：环境确定时性能稳定

Planning劣势

• 僵化问题：环境变化时计划失效
• 信息浪费：预规划可能包含不必要步骤
• 重规划开销：失败时成本较高

选型建议

• 开放域/动态环境（如网页浏览、数据库查询）→ ReAct
• 封闭域/确定性任务（如代码生成、数学证明）→ Planning
• 复杂长程任务 → 混合架构：高层Planning + 低层ReAct

口语版讲法(约4分钟)

• 本质问的是决策节奏差异
• ReAct像实时反馈闭环
• Planning像先画图再施工
• 落地风险与选型边界
• 混合架构与延伸思考

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

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

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

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

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

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

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

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

关键一句:在部分可观测环境下，Planning容易失效，可以结合Reflexion让Agent自我反思后动态调整规划。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你要做一个智能客服Agent，用户说‘帮我查一下上个月的订单’，你打算怎么设计？是先规划好所有步骤再执行，还是边想边问系统拿数据？这两种思路你比较过吗？

2. 问法 2 · 层层追问

   Agent做决策时，你觉得是先计划再执行好，还是边推理边行动好？……如果环境会变化，比如查价格时库存突然变了，哪种更稳？……那长任务比如行程规划呢，会不会出现走偏的问题？

3. 问法 3 · 直球架构

   从设计理念到流程，对比ReAct和传统Planning在Agent行为决策中的差异，包括优缺点和适用场景。你先讲核心区别，再分析各自在什么情况下更优。