面试题 · 评估
搜索「延迟」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
比较ReAct框架与Plan-and-Execute架构在处理长上下文任务时的表现，从上下文管理、推理效率、错误恢复等方面分析各自的优缺点。
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 执行模式 | 推理→行动→观察 循环交错 | 先完整规划，再逐步执行 |
按学习路线查看教程、项目和面试题。
| 线性累积，历史全保留 |
| 阶段隔离，可选择性加载 |
上下文管理
推理效率
错误恢复
| 场景 | 推荐方案 |
|---|---|
| 步骤不确定、需频繁试错 | ReAct |
| 步骤明确、追求执行稳定性 | Plan-and-Execute |
| 超长任务（>20步） | Plan-and-Execute + 子计划递归 |
| 工具调用成本高 | Plan-and-Execute（减少无效调用） |
实际可混合：用Plan-and-Execute做粗粒度阶段规划，阶段内用ReAct灵活执行。
场景切入
我看你做过订单处理Agent，假设有个任务要查10个订单的物流、更新状态、再发邮件，用ReAct一步步做的话上下文会越来越长，你有没有想过换一种先规划再执行的方案？
层层追问
你一般怎么让Agent处理多步骤任务？……那如果任务步骤很多比如20步，上下文管理上会不会出问题？……你觉得ReAct和先规划再执行哪种更容易恢复错误？
直球架构
比较ReAct和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 灵活执行。这样既避免了上下文膨胀，又保留了局部回溯的灵活性。