今天我们来深入探讨ReAct、Plan-and-Execute，以及二者结合的混合模式。在正式介绍这些概念之前，先抛出一个问题：各位在日常工作中处理需求时，通常采用哪种方式？
是这种流程吗？
- 先将项目运行起来
- 定位到相关代码位置
- 先修改一处，改完后再次运行测试
- 发现遗漏的地方，补充修改后继续运行
- 发现UI尚未调整，对照设计稿逐一修改
- 再次运行测试，确认无误后提交测试
还是这样的做法？
- 先全面梳理需求需要改动的内容，撰写一份规划方案
- 列出执行顺序：先调整数据结构，再修改接口，接着编写视图逻辑，最后优化UI
- 完成修改后自行测试一遍，发现问题就修复，没有问题则提交测试
这两种工作状态，恰好对应AI Agent的两种核心模式：前者是ReAct（推理+行动循环），后者是Plan-and-Execute（先规划后执行）。
到底什么是ReAct
ReAct，简单来说就是Reasoning（推理）与Acting（行动）的持续循环。其核心理念是：边思考边行动，边行动边思考。
这个流程，类似于我们外出旅游时的即兴探索：
- 观察：“咦，这条小巷看起来挺有意思。”
- 思考：“反正没有固定目的地，不如拐进去看看。”
- 行动：拐进小巷。
- 观察：“哇，里面有一家排长队的店铺。”
- 思考：“这么多人排队肯定味道不错，去凑个热闹。”
- 行动：跟着排队买了一份小吃。
- 观察：“确实好吃！老板说前面还有一个古玩市场。”
- 思考：“那顺道去看看。”
- 行动：往古玩市场方向走去……
这就是ReAct——每一步都基于当前的实际情况做出决策，没有预设的完整行程。主打“随遇而安”，玩得尽兴，但也可能错过原计划中的景点。比如在小巷里逛得太久，天黑了才想起还没去博物馆。
代码中的ReAct实现
Plan-and-Execute 又是什么？
Plan-and-Execute，顾名思义：先制定计划，再按计划执行。其流程图如下：
用生活中的例子来理解，可以想象装修房屋的过程：
- 理解需求：明确最终目标，例如“我要装修一套三室一厅，现代简约风格”。
- 拆解任务：将整体工程拆分为若干子步骤，比如水电改造→铺贴瓷砖→安装吊顶→墙面刷漆→定制柜子→软装布置。
- 规划顺序：确定优先级，例如必须先完成水电才能铺瓷砖，顺序不可颠倒。
- 分配资源：明确分工与时间，水电工3天，瓦工5天，油漆工2天。
- 执行：按部就班，逐一完成。
- 中间可能调整：如果某个环节出现问题（如瓷砖缺货），则重新调整方案。
Plan-and-Execute的核心并非死板不变，而是将大部分精力投入规划阶段，执行时尽量减少返工。
代码中的Plan-and-Execute实现
核心对比
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 思考时机 | 每一步都进行推理 | 集中规划，执行中偶尔思考 |
| 灵活性 | 极高，随时可以转向 | 中等，按计划执行但可重新规划 |
| 效率 | 可能走弯路，Token消耗较大 | 通常路径更优，Token更节省 |
| 可解释性 | 完整的思考链条，每一步都可追溯 | 规划清晰，但执行过程可能不够透明 |
| 适合场景 | 探索性强、不确定性高的任务 | 确定性高、步骤明确的任务 |
| 容错能力 | 强，发现错误可立即掉头 | 中等，出错后需要重新规划 |
| 实现复杂度 | 简单，一个循环即可完成 | 复杂，需要规划器/任务分解器 |
| Token消耗 | 高（每一步都要调用LLM） | 中低（规划一次+执行调用） |
深度对比——用实例说话
场景一：查询天气 + 预订餐厅 + 发送通知
ReAct的玩法
Plan-and-Execute的玩法
场景二：调试一个莫名其妙的Bug
ReAct的玩法
Plan-and-Execute的玩法
场景三：撰写一篇万字深度文章
ReAct的玩法
Plan-and-Execute的玩法
各自的优缺点
| ReAct的优点 | ReAct的缺点 |
|---|---|
| 极致的灵活应变，发现路不通立刻掉头，宛如秋名山车神 | Token消耗巨大，每一步都需要LLM推理，成本如同烧纸 |
| 天然支持纠错，每一步都有重新审视的机会 | 容易跑偏，顺着有趣的方向越走越远，忘记了初衷 |
| 实现简单，一个while循环加LLM调用即可 | 缺乏全局视野，只顾眼前“最优”而忽视整体最优 |
| 可解释性强，Thought/Action/Observation链条完整透明 | 效率低下，可能绕大量弯路才到达终点 |
| 零预设，无需提前了解任务结构 | 工具调用频繁，简单任务也可能调用多次工具 |
| Plan-and-Execute的优点 | Plan-and-Execute的缺点 |
|---|---|
| 效率高，规划阶段一次性想清楚，执行阶段如同切黄油般顺畅 | 规划本身有成本，LLM生成的计划不一定可靠 |
| Token友好，规划仅花费一轮，执行时减少大量推理开销 | 面对不确定性脆弱，计划赶不上变化时需频繁重规划 |
| 倾向全局最优，规划时能够看到全景 | 重规划代价大，一旦偏差，整个计划可能推倒重来 |
| 结果一致性好，相同输入→相同计划→相同输出 | 过度规划，简单任务也可能生成复杂计划 |
| 可管理性强，子任务可分配、可追踪、可并行 | 灵活性不足，执行中发现的意外惊喜可能被忽略 |
混合模式（Hybrid Approach）
目前较先进的Agent系统，通常不会单独使用上述两种模式。像LangGraph、AutoGPT等工具，采用的就是Plan-and-Execute与ReAct相结合的混合模式。整体流程大致如下：
现实中的例子：AutoGen + LangGraph
微软的AutoGen和LangChain的LangGraph，便是典型的混合模式代表：
- 高层：一个Planner Agent负责分解任务、生成DAG（有向无环图）。
- 中层：一个Dispatcher负责任务调度、依赖管理。
- 底层：每个Worker Agent内部使用ReAct执行具体任务。
这套组合拳，就像先绘制好作战地图（Plan），再派出侦察兵灵活执行（ReAct）。遇到意料之外的敌人，就及时更新地图。既有战略规划，又有战术应变。
最后总结
为每种模式打个比喻：
- ReAct：像追求伴侣，走一步看一步，灵活应对，不行就换策略。
- Plan-and-Execute：像步入婚姻，先认真规划，然后按计划执行，中间可以调整，但大方向不变。
- 混合模式：像经营婚姻，既有长远规划，也懂得在情人节临时买束花。
