面试题 · Agent
搜索「摘要」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请分析ReAct与Plan-and-Execute两种推理框架在处理长上下文任务时的优缺点，并从上下文管理、推理效率和错误恢复能力等方面进行对比。
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 执行模式 | 推理→行动→观察 循环交错 |
按学习路线查看教程、项目和面试题。
| 先全局规划，再逐步执行 |
| 上下文结构 | 线性累积，历史全保留 | 规划阶段集中，执行阶段聚焦 |
| 场景 | 推荐方案 |
|---|---|
| 步骤不确定、需频繁调整 | ReAct + 上下文摘要 |
| 步骤明确、可预估 | Plan-and-Execute |
| 超长任务（>20步） | 分层：Plan-and-Execute做里程碑，ReAct做子任务 |
实际工程中常见ReWOO或LLMCompiler等混合方案，静态规划+动态执行结合，兼顾效率与灵活性。
场景切入
假设你在做一个复杂的电商客服系统，用户要处理退款、修改地址、查询物流等一连串操作。你会怎么设计推理框架，让模型既能逐步执行，又不会因为上下文太长而跑偏？
层层追问
你平时处理长任务时，模型是怎么一步步推理的？……如果任务步骤特别多，上下文一直增长会有什么问题？……那有没有办法先规划再执行，避免上下文膨胀？
直球架构
对比一下ReAct和Plan-and-Execute这两种推理框架，从上下文管理、推理效率和错误恢复三个角度，分析它们在长上下文任务中的优缺点。
这道题其实问的是，如果任务流程不确定，该让模型边想边做还是先想好再做。两种框架的差异，说白了就是动态决策和静态规划的取舍。
先说[[ReAct]]，它的模式是推理-行动-观察循环，每一步的思考、动作和观察结果全都拼到上下文里。好处是灵活，比如客服退款场景，用户一开始说订单错了，查完发现是物流问题，马上就能调整追问物流单号，不用从头规划。但这里有个坑：上下文会线性增长。任务如果超过十步，前面的观察结果就把注意力稀释了，模型容易忘掉最开始的目标。我一般会配合[[滑动窗口]]或者摘要压缩来缓解，但代价是可能丢掉关键信息。
再来看Plan-and-Execute，它先做一次全局规划，把整个任务拆成步骤列表，然后一步步执行。好处是上下文紧凑，执行时只看当前步骤和计划，token效率高。但问题在于规划成本，如果任务步骤不确定，比如商家满减政策经常变，模型第一步规划错了，后面都得重算，重规划的开销很大。而且计划粒度很难调，太细浪费token，太粗执行时容易跑偏。
举个例子，处理企业SOP与合规文档的审核，步骤明确，比如先提取条款再对比库，这种用Plan-and-Execute就很稳。但如果是处理订单异常，原因可能有一百种，ReAct更适合，因为每一步都能根据观察结果调整方向。
所以实际落地时，我更倾向混合方案。比如用Plan-and-Execute先定几个里程碑，每个里程碑内部用ReAct灵活执行。像LLMCompiler或者ReWOO就是这种思路，静态规划搭骨架，动态执行填血肉。
这里有个前提：如果任务步骤特别长，超过二十步，纯ReAct的上下文会炸，纯Plan-and-Execute的规划会漏。我的策略是分层，高层用计划，底层用ReAct。另外，错误恢复上，ReAct局部纠错快，但错误会累积；Plan-and-Execute全局一致性好，但单步失败重算成本高。上线我会特别关注token消耗和重试次数，如果重试超过两次，就切回人工兜底。
不过话说回来，现在还有一种思路是让模型自己决定什么时候切换框架，比如用[[Function Calling]]触发计划的重新生成。这个方向我觉得挺有意思，但还没看到特别成熟的方案，可能是个值得探索的点。
所以我的判断是，ReAct和Plan-and-Execute不是二选一，而是根据任务可预估程度和步骤数来选。我更倾向以Plan-and-Execute为骨架，ReAct做局部微调，同时做好上下文管理和重试兜底。