ReAct、Plan-and-Execute、Plan-Execute-RePlan 三种 Agent 范式分别适合什么场景？
这三种范式，本质上是在权衡三件事：决策粒度、执行稳定性、以及中途纠偏能力。选型时不要先看名字，要先看你的任务到底是“边想边做”型，还是“先规划再流水线执行”型，还是“目标不确定、执行中经常要改计划”型。
这三种范式，本质上是在权衡三件事：决策粒度、执行稳定性、以及中途纠偏能力。选型时不要先看名字，要先看你的任务到底是“边想边做”型，还是“先规划再流水线执行”型，还是“目标不确定、执行中经常要改计划”型。
先给一个直观结论：
ReAct 适合短链路、强交互、环境变化快、每一步都需要根据最新观察来决定下一步动作的场景。
Plan-and-Execute 适合目标清晰、流程相对稳定、可以先拆任务再按步骤执行的场景。
Plan-Execute-RePlan 适合复杂任务、长链路任务、外部不确定性高、执行过程中经常发现原计划不成立的场景。
1. ReAct 适合什么场景
ReAct 的核心是：Thought → Action → Observation → Thought，也就是“边推理边调用工具，拿到反馈后再决定下一步”。
它最适合这类任务：
第一类，是信息不完整、需要探索的任务。比如网页搜索、文档检索、多轮数据库查询、排查线上问题。因为你一开始并不知道完整答案，必须做一步看一步。
第二类，是环境反馈强依赖的任务。比如让 Agent 去调用 API、读页面、看工具返回结果，再决定下一步。因为下一步动作高度依赖上一轮 observation，预先规划的价值不大。
第三类，是任务链路不长，但每一步决策质量要求高的任务。比如客服问答里的工具调用、面向内部系统的查数 Agent、简单 coding assistant、检索增强问答中的动态工具路由。
ReAct 的优势是灵活，尤其适合“侦查式执行”。但它也有明显问题：
一是局部贪心，容易只盯着当前一步，缺少全局最优；
二是上下文膨胀，因为每一步 thought/action/observation 都会堆进上下文；
三是长任务容易漂移，做着做着偏题，或者陷入低效循环。
所以，如果你的任务平均只需要 3 到 8 步，而且每一步都依赖即时反馈，ReAct 往往是最自然的选择。
2. Plan-and-Execute 适合什么场景
Plan-and-Execute 的思路是先把任务拆成计划，再让执行器按计划跑。
它适合的是目标明确、子任务相对独立、流程可预拆分的场景。
典型例子有：
比如生成一份行业调研报告。你可以先规划成：收集资料、提炼框架、写市场现状、写竞品分析、写风险与结论，然后逐步执行。
再比如多步骤办公自动化：读取邮件、提取待办、整理日程、生成周报。
或者代码类任务中那种结构清晰的需求：先读 repo，再定位模块，再修改接口，再写测试。
这类范式的优势是：
第一，全局性更好。因为一开始就有一个任务分解，不容易在局部来回乱跳。
第二，成本更可控。规划一次后，执行阶段可以用更小的模型、更便宜的策略。
第三，工程可观测性更强。你可以看到 plan、step status、失败位置，比较容易做监控和重试。
但它的问题也很典型：
如果初始 plan 错了，后面执行可能一路错到底。
它对任务前提有要求：你得能在一开始就把事情拆得差不多。
所以它不太适合那种“做着做着才发现问题定义本身有问题”的任务。
因此，Plan-and-Execute 更适合半结构化但总体稳定的业务流程，而不太适合高不确定性的开放探索。
3. Plan-Execute-RePlan 适合什么场景
Plan-Execute-RePlan 可以理解成在 Plan-and-Execute 上加入了阶段性复盘和动态重规划。
它不是单纯“先计划后执行”，而是“先计划，执行一段，检查现实和计划是否一致，不一致就重做计划”。
它适合的任务往往具备三个特征：
第一，任务长。执行链路可能十几步甚至几十步，单次 plan 很难一开始就全对。
第二，外部依赖多。比如要访问多个系统、检索多个来源、调不同工具，而这些返回结果会不断改变后续路径。
第三，目标会被澄清。也就是执行过程中你会逐步理解真正的问题，而不是一开始就完全明确。
典型场景包括：
复杂 research agent。比如“帮我调研某个赛道并给出投资判断”，Agent 在搜集资料后很可能发现原先的问题拆法不合理，需要调整研究维度。
复杂工程任务。比如对一个陌生代码库做较大范围修改，执行后可能发现依赖关系和预估不同，需要回到 plan 层重拆。
长流程业务代理。比如旅行规划、供应链流程、复杂运营分析、跨系统 case resolution。
它最大的价值是：把战略层和战术层解耦，并允许战略层持续修正。
这比纯 ReAct 更有全局观，比纯 Plan-and-Execute 更抗不确定性。
代价则是系统更复杂：
你要定义什么时候触发 replanning，如何判断当前计划失效，如何避免频繁重规划导致成本暴涨，如何管理历史计划版本。
所以，这种范式通常更适合真正的“生产级复杂 Agent”，而不是简单 demo。
4. 三者怎么选：看四个维度
实际选型时，我建议看四个维度，而不是背概念。
第一，看任务长度
如果任务很短，通常优先 ReAct。
因为先单独做 planner 往往是额外开销，收益不大。
如果任务中等长度，而且步骤能提前想清楚，Plan-and-Execute 更稳。
如果任务很长，且中途容易发现前面拆错了，就上 Plan-Execute-RePlan。
第二，看环境不确定性
如果每一步都强依赖即时 observation，ReAct 很合适。
如果环境基本稳定，Plan-and-Execute 就够了。
如果环境是“整体不稳定，但又不能完全走一步看一步”，那就是 Plan-Execute-RePlan。
第三，看失败成本
如果试错成本低，ReAct 可以大胆一些。
如果一步错会带来较大代价，比如调用付费 API、修改生产数据、发邮件给客户，那就更需要 plan，甚至需要 replan 和审批节点。
第四，看可解释性和可运维性
生产系统通常不只看是否“能做出来”，还看是否“出了问题能不能查”。
ReAct 的轨迹很细，但容易冗长。
Plan-and-Execute 的结构最清晰。
Plan-Execute-RePlan 虽然更复杂，但也最接近真实项目管理流程，适合需要状态管理、审计、恢复和人工接管的系统。
5. 一个实用的选型规则
可以直接用这个经验法则：
如果你的任务是3到8步、强依赖即时反馈，选 ReAct。
如果你的任务是8到20步、目标明确、可提前拆解，选 Plan-and-Execute。
如果你的任务是长链路、高不确定、多阶段修正，选 Plan-Execute-RePlan。
再说得更工程一点：
- 做工具型助手、检索问答、简单自动化：优先 ReAct
- 做工作流编排、报表生成、标准化多步骤任务：优先 Plan-and-Execute
- 做复杂研究、多工具协同、长期任务代理：优先 Plan-Execute-RePlan
6. 不同场景下的推荐
场景一：企业知识库问答 + 搜索工具
更适合 ReAct。
因为用户问题千差万别，Agent 需要动态决定查哪个库、读哪篇文档、是否继续搜索。计划通常不需要太重。
场景二：自动写周报 / 自动生成运营分析
更适合 Plan-and-Execute。
因为流程固定：拉数据、清洗、归纳、成文。提前规划步骤可以让执行更稳定，还能做失败重试。
场景三：代码仓库级改造
如果改动小，ReAct 就够。
如果需求清晰且涉及多个模块，Plan-and-Execute 更合适。
如果是陌生仓库、大范围重构、执行中很可能发现架构约束，则更适合 Plan-Execute-RePlan。
场景四：Deep Research / 行业调研 Agent
更适合 Plan-Execute-RePlan。
因为研究任务不是简单检索，而是不断修正研究问题本身。这个过程天然需要 replan。
场景五：具身智能、网页操作、GUI Agent
通常先看环境反馈密度。
如果是高频观测-动作闭环，ReAct 很自然。
但如果任务很长，比如“完成一次完整报销流程”，更强的系统往往会在 ReAct 外层加一个 planner，实际落地更像分层版 Plan-Execute-RePlan。
7. 真正落地时，不要纯用某一种
工业界里，纯血单范式反而少。更常见的是分层组合：
顶层用 Planner，底层单步执行用 ReAct。
也就是：
- 高层先出阶段目标
- 每个阶段内部，再由一个 ReAct executor 去灵活调用工具
- 当阶段失败或环境变化时，再触发 replanning
这种架构通常比“纯 ReAct 一把梭”稳定，也比“死板 Plan-and-Execute”灵活。
很多成熟 Agent 系统，本质上都是这个思路。
你可以把三者理解成不是互斥关系，而是不同层级的控制策略：
- ReAct：战术层
- Plan-and-Execute：静态战略层 + 执行层
- Plan-Execute-RePlan：动态战略层 + 执行层
8. 最后给一个简洁决策表
选 ReAct：
任务短、反馈密、探索性强、允许边做边想。
选 Plan-and-Execute：
任务目标清楚、流程稳定、希望降低 token 成本、提升可控性。
选 Plan-Execute-RePlan：
任务复杂、链路长、外部变化多、执行中经常需要修正方向。
如果你是在做生产级 Agent 系统，默认建议是：
从“Planner + ReAct Executor + RePlan Trigger”这套混合架构开始。
因为它兼顾了灵活性、全局性和可运维性，后续也更容易加上 memory、human-in-the-loop、budget control、失败恢复这些能力。
你要的话，我可以下一条直接给你画一个三种范式的架构对比图 + 选型决策树，你拿去面试回答会很顺。