ReAct vs Plan-and-Execute 错误恢复谁强?
长上下文场景下两种 Agent 架构的优劣对比,3 个维度细谈
原题：比较ReAct框架与Plan-and-Execute架构在处理长上下文任务时的表现，从上下文管理、推理效率、错误恢复等方面分析各自的优缺点。
评估与监控 · 美团真题
30 秒回答
- ReAct的交错推理-行动机制及其对上下文的动态利用
- Plan-and-Execute的全局规划与阶段解耦特点
- 两者在长上下文下的token效率对比
- 错误恢复机制的差异（ReAct的局部回溯 vs Plan-and-Execute的重规划）
回答与解析
答案要点
- ReAct的交错推理-行动机制及其对上下文的动态利用
- Plan-and-Execute的全局规划与阶段解耦特点
- 两者在长上下文下的token效率对比
- 错误恢复机制的差异（ReAct的局部回溯 vs Plan-and-Execute的重规划）
- 适用场景的选择依据
核心差异
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 执行模式 | 推理→行动→观察 循环交错 | 先完整规划，再逐步执行 |
| 上下文结构 | 线性累积，历史全保留 | 阶段隔离，可选择性加载 |
长上下文下的表现对比
上下文管理
- ReAct：每一步的Thought/Action/Observation全部拼接，上下文线性增长。长任务后期可能触发窗口限制，早期关键推理被挤出。
- Plan-and-Execute：规划阶段一次性消耗token，执行阶段可只加载当前子任务+原始计划，上下文可控。支持"计划摘要+当前步骤"的压缩策略。
推理效率
- ReAct：单步决策轻量，但多步累积后每次推理都需处理冗长历史，后期延迟显著增加。
- Plan-and-Execute：前期规划较重，但执行阶段推理上下文短且稳定，整体token消耗更可预测。
错误恢复
- ReAct：天然支持局部回溯，上一步观察异常可直接在下一步Thought中修正，灵活性高。但错误可能连锁传播，且历史错误记录污染上下文。
- Plan-and-Execute：执行失败需触发重规划，成本较高；但全局视角便于结构性调整，避免局部最优陷阱。
选型建议
| 场景 | 推荐方案 |
|---|---|
| 步骤不确定、需频繁试错 | ReAct |
| 步骤明确、追求执行稳定性 | Plan-and-Execute |
| 超长任务（>20步） | Plan-and-Execute + 子计划递归 |
| 工具调用成本高 | Plan-and-Execute（减少无效调用） |
实际可混合：用Plan-and-Execute做粗粒度阶段规划，阶段内用ReAct灵活执行。
口语版讲法(约4分钟)
- 本质是动态决策与静态规划的矛盾
- ReAct的局部回溯 vs Plan-and-Execute的阶段隔离
- 业务场景示例：客服多轮退款
- 落地风险：上下文膨胀与重规划成本
- 我的取舍：混合使用，按步骤复杂度分层
这道题其实是在问一个本质矛盾：Agent 面对长任务时，是每一步都动态决策更灵活，还是先想清楚再执行更可控。ReAct 和 Plan-and-Execute 刚好是两种极端。我先说结论：没有绝对好坏，真正落地往往是混着用，关键看任务步骤的确定性和上下文长度。
先说 ReAct。它的核心是推理、行动、观察循环交替，每一步都依赖完整历史。好处是天然支持局部回溯，比如上一步工具调用返回了异常数据，下一步的 Thought 里马上就能修正，试错成本很低。但坏处也很明显：上下文线性增长，到了第 20 步，模型每次推理都要处理前面十几步的 Thought、Action、Observation，早期关键信息可能被挤出窗口，而且推理延迟会越来越慢。
Plan-and-Execute 相反，先一次性消耗 token 生成完整计划，然后按子任务隔离执行，每个步骤只加载当前子计划和原始计划摘要。上下文可控，token 消耗可预测。但错误恢复就很重了，一旦某步执行失败，往往要触发重规划，代价高。而且如果计划本身有逻辑漏洞，后面全白费。
举个例子你就清楚了。比如客服退款场景，用户说订单异常要求退款。如果用 ReAct，Agent 先查订单状态，发现已发货，就调用物流接口查轨迹，发现签收了，于是问用户是否收到货，用户说没收到，Agent 再查物流详情发现是代签，然后申请退款。每一步都基于上一步的观察灵活调整，非常自然。但如果是 30 步的复杂流程，比如企业合规审查，需要依次检查多个条款、交叉引用不同文档，用 ReAct 就会很痛苦，因为上下文越来越长，模型容易迷失。这时 Plan-and-Execute 就合适，先规划好要检查哪些条款、按什么顺序，然后每个子任务独立执行，上下文短且稳定。
这里有个坑：Plan-and-Execute 的前提是任务步骤能预先穷举。如果任务本身高度不确定，比如开放式问答，规划阶段可能漏掉关键分支，执行时发现不对再重规划，反而比 ReAct 更慢。所以上线我会特别关注任务的可枚举性，如果步骤数超过 20 且工具调用成本高，我会优先考虑 Plan-and-Execute 加子计划递归。
另外，我最近在思考一个问题：当任务步骤数超过 50 甚至 100 时，Plan-and-Execute 的规划阶段本身就会消耗大量 token，而且计划长度可能超过上下文限制。这时候是不是应该引入分层规划？比如先粗粒度规划，每个子计划再递归细化，但这样又引入了层级间的协调成本。我还没完全想清楚最佳实践。
所以我的取舍是：把 ReAct 看成局部执行器，把 Plan-and-Execute 看成全局控制器。对于步骤数少于 10 且需要频繁试错的任务，直接用 ReAct；对于步骤明确且超过 10 步的任务，先用 Plan-and-Execute 做粗粒度阶段划分，每个阶段内部再用 ReAct 灵活执行。这样既避免了上下文膨胀，又保留了局部回溯的灵活性。
关键一句:当任务步骤超过50步时，Plan-and-Execute的规划阶段本身可能超出上下文限制，需要考虑分层规划。
面试官还可能这样问
- 问法 1 · 场景切入
我看你做过订单处理Agent，假设有个任务要查10个订单的物流、更新状态、再发邮件，用ReAct一步步做的话上下文会越来越长，你有没有想过换一种先规划再执行的方案？
- 问法 2 · 层层追问
你一般怎么让Agent处理多步骤任务？……那如果任务步骤很多比如20步，上下文管理上会不会出问题？……你觉得ReAct和先规划再执行哪种更容易恢复错误？
- 问法 3 · 直球架构
比较ReAct和Plan-and-Execute在长上下文任务上的优缺点，从上下文管理、推理效率和错误恢复三个角度分析，你更推荐哪种？