ReAct vs Plan-and-Execute 怎么选?
长上下文场景下两种Agent架构的优劣对比,4个维度细谈
原题：比较ReAct框架与Plan-and-Execute架构在处理长上下文任务时的表现：各自的信息管理机制、上下文利用率、错误恢复能力及推理效率方面的优劣。
Agent · 美团真题
回答与解析
核心差异
ReAct 把决策与工具执行交错进行：根据当前状态选择动作，读取观察，再更新下一步。它适合环境变化快、工具结果不可预知的任务。历史若全部保留会增长，但可用结构化状态、摘要和检索控制上下文，因此不能断言必然以完整 O(N) 轨迹累积。
Plan-and-Execute 先生成高层计划，再由执行器处理子任务，并在检查点重规划。它有利于显式依赖、并行子任务和阶段验收；但计划可能过时，也有协调成本，不保证 LLM 调用次数或 token 一定更少。
信息管理上，ReAct 与工具观察紧耦合，Plan 架构分离计划、状态与产物；恢复上，前者可局部调整，后者可在检查点重试、回滚或重规划；效率取决于交互步数、规划成本和并行机会。
长任务常采用混合模式：可修改的任务图管理全局约束，子任务内部使用观察—动作循环。系统保存目标、已验证事实、工具输入输出、依赖和错误码，而不是公开原始隐藏推理。还应设置幂等键、超时、重试上限、补偿操作和人工升级，并以成功率、尾延迟、调用成本与恢复率比较。
口语版讲法(约90秒)
- ReAct在观察与动作之间动态调整
- Plan架构显式管理计划和子任务
- 上下文增长取决于状态压缩策略
- 两类架构都需要检查点和副作用控制
- 用任务质量、延迟、成本和恢复率选型
ReAct 根据当前状态选择动作，读取工具观察后再决定下一步，适合工具返回不可预测的任务。若把完整轨迹都塞回提示词，上下文会增长；但生产系统可以只保留结构化状态、验证事实和必要工具结果，因此增长方式由记忆策略决定。
Plan-and-Execute 先建立高层计划，再按子任务执行并在检查点重规划。它适合依赖清晰、可阶段验收或并行的任务，但计划可能过时，维护计划也有成本，所以不能保证调用数和 token 一定更少。
错误恢复取决于系统机制。两类架构都需要幂等键、超时、重试上限、补偿操作和人工升级。系统记录可审计状态和工具结果，而不是公开模型的原始隐藏推理。长任务可用可修改任务图管理全局约束，子任务内部采用观察与动作循环，并用成功率、尾延迟、成本和恢复率对比。
关键一句:可修改计划与局部观察动作循环可组合，结构化状态应替代原始隐藏推理轨迹。
核验来源
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服机器人，用户问一个复杂订单问题，比如退款进度、物流异常和商品瑕疵一起问。你会怎么设计agent的推理流程？是让模型边想边调用工具，还是先整体规划再一步步执行？
- 问法 2 · 层层追问
Agent处理长任务时，你觉得是边推理边行动好，还是先做计划再执行好？……那当上下文越来越长、接近token上限时，这两种方式各自会出什么问题？……比如早期的一个错误观察，哪种架构更容易恢复？
- 问法 3 · 直球架构
直接比较ReAct和Plan-and-Execute两种框架在长上下文任务中的表现，从信息管理、上下文利用率、错误恢复和推理效率四个维度，讲清楚各自的优劣和适用场景。