ReAct 与 Plan-and-Execute 有什么区别？Agent 如何选择规划方式？
简化版
ReAct（Reason + Act）把推理、动作、观察交替进行——想一步、做一步、看结果、再想，适合信息逐步揭示、需要快速纠偏的任务；Plan-and-Execute 先形成较完整的计划，再逐步执行、必要时重规划，适合依赖关系清晰的长任务。生产系统通常混合使用（粗计划 + 短 ReAct 循环），并让应用保存结构化计划，而不是把模型的思考文本当可信执行依据。
详细版
ReAct 循环：判断下一步 → 调工具 → 读观察 → 再判断。优点是反馈及时；缺点是易局部短视、重复调用、陷入循环。
Plan-and-Execute：先规划再执行。优点是便于检查依赖、并行、进度；缺点是初始计划可能基于不完整信息，执行中仍需重规划。
选择依据：任务长度、步骤依赖、环境不确定性、工具成本、可审计要求。无论哪种，都要设最大步数、预算、截止时间、完成条件、失败出口。
完整版教学
一、ReAct：边做边看
ReAct 的精髓是「推理轨迹」和「任务动作」交错，让动作从环境取得观察、再更新决策：
Thought: 要查用户订单状态，先调 get_order
Action: get_order(order_123)
Observation: 状态=已发货，物流=顺丰 SF123
Thought: 用户问何时到，需查物流
Action: track_logistics(SF123)
Observation: 预计明天送达
Thought: 信息够了，可以回答它适合搜索、问答、交互操作等不能一次拿全信息的场景。工程要点：不必向用户展示完整思考过程，真正要持久化的是工具名、参数、结果摘要、状态变化、决策理由这些可审计字段。
二、Plan-and-Execute：先看全局
规划器先把目标拆成带依赖的子任务，执行器逐项完成：
Plan:
1. 查产品 A 的负责人 （无依赖）
2. 查该负责人所在部门 （依赖 1）
3. 查该部门今年的项目 （依赖 2）
Execute: 逐项做；若某步结果让后续前提失效 → 重规划剩余计划（而非机械执行旧列表）复杂任务可把计划表示为 DAG（有向无环图） 识别可并行步骤；但涉及共享资源或副作用时仍需顺序和事务控制。
数据分析场景里计划怎么结构化、每一步怎么复用单次分析链路，见「数据分析 Agent 怎么把一个分析目标拆成多步计划并执行？」。
三、两种方式的风险对照
| ReAct | Plan-and-Execute | |
|---|---|---|
| 优势 | 反馈及时、灵活纠偏 | 全局视野、可并行、可审计 |
| 典型风险 | 循环、频繁试错、上下文膨胀 | 过度规划、错误前提传播、计划与实际脱节 |
| 适合 | 信息逐步揭示的短任务 | 依赖清晰的长任务 |
共同红线：模型写出看似合理的计划，不代表计划可执行——每一步都要经参数校验、权限检查、前置条件检查。
四、混合策略（生产最常用）
先生成粗粒度里程碑（Plan）：里程碑1 → 里程碑2 → 里程碑3
每个里程碑内部用短 ReAct 循环处理细节
完成一步 → 更新结构化状态 → 只在关键事实变化时重规划
高成本工具：计划先过规则/人工审批；低风险查询：允许 Agent 自主探索这样兼得「全局规划的条理」和「ReAct 的灵活纠偏」。
五、终止条件（比选哪种规划更重要）
不管 ReAct 还是 Plan-and-Execute，硬性终止条件是可靠性的地基，至少要同时具备：
✓ 任务成功谓词（怎样算完成）
✓ 最大工具调用数
✓ 最大连续失败数
✓ 总时长 / 费用预算
✓ 需要人工接管的状态记忆钩子：只在 Prompt 里写”不要循环”不能代替运行时的硬限制——模型不会可靠地自我约束，必须由代码兜底。
六、如何用同一批任务选择规划方式
不要凭个别演示决定架构，应把 ReAct、Plan-and-Execute 与混合策略放到同一评测集上比较。假设 200 个任务的结果如下：
| 策略 | 成功数 | 平均工具调用 | P95 延迟 | 平均成本 |
|---|---|---|---|---|
| ReAct | 158 | 8.2 | 21 秒 | 0.18 元 |
| Plan-and-Execute | 166 | 6.9 | 25 秒 | 0.20 元 |
| 混合策略 | 174 | 7.1 | 22 秒 | 0.21 元 |
混合策略成功率为 174/200=87%，但不能据此断言它在所有场景最佳。还要按任务类型切片：信息高度不确定的任务可能由 ReAct 占优，长依赖任务可能由 Plan 占优；涉及副作用的任务则必须额外统计越权执行、重复写入和超预算次数，并把安全违规设为上线否决项。
七、常见误区与追问
- 误区：ReAct 一定比 Plan-and-Execute 好（或反之）。 各有适用场景，可靠实现通常是二者混合。
- 误区：模型写出的计划就能执行。 看似合理≠可执行，每步都要参数/权限/前置条件校验。
- 误区：靠 Prompt 说”不要重复”就能防循环。 无硬保证，必须靠运行时的最大步数/失败数/预算限制。
- 误区：要把完整思考过程存下来/给用户看。 只需持久化工具名/参数/结果/状态/理由等可审计字段。
- 追问：ReAct 的核心思想？ 推理与动作交错，动作从环境取观察再更新决策，适合信息逐步揭示。
- 追问：Plan-and-Execute 何时重规划？ 执行结果让后续前提失效时修订剩余计划，而非机械执行旧列表。
- 追问：ReAct 和 Plan 各自的典型风险？ ReAct 易循环/试错/上下文膨胀；Plan 易过度规划/错误前提传播/计划脱节。
- 追问：终止条件要包含什么？ 成功谓词 + 最大调用数 + 最大连续失败 + 时长/费用预算 + 人工接管状态。
八、加强记忆
ReAct vs Plan-and-Execute 记「边做边看 vs 先看全局」：ReAct 推理-动作-观察交错（反馈及时但易循环，适合信息逐步揭示）、Plan-and-Execute 先规划带依赖子任务再执行（全局可并行但初始计划可能基于不完整信息）。可靠实现是混合——粗计划 + 短 ReAct 循环 + 可验证结构化状态 + 硬性终止条件。两条红线钉死：模型写的计划≠可执行（每步校验参数/权限/前置）、Prompt 说”别循环”不顶用（靠运行时最大步数/失败数/预算硬兜底）。
项目实战落地
项目里怎么做的
《AI Agent数据分析平台》的 Agent 分析是 Plan-and-Execute，计划和执行被拆成两个页面、两个动作：
- 先出计划：用户输入一个较大的分析目标（如「订单下降原因分析」），模型一次生成计划标题和步骤数组，存进
agent_plan，页面先把步骤列出来； - 点了才执行：用户在执行追踪页点「执行计划」，后端把每一步插成一条「待执行」的
agent_execution_step就立刻返回，后台线程按顺序逐步执行，前端每 2 秒轮询状态； - 每一步复用已有链路：Agent 本身不直接查库，而是把步骤里的分析问题转成一次标准的数据分析请求，走 Text-to-SQL、校验执行、图表推荐、数据解读；
- 成败按业务状态判：SQL 校验或执行没成功就记「执行失败」和原因，不以「没抛异常」当成功；某一步失败后照常执行后面的步骤，执行过程中不改计划。
《AI Agent 智慧医院智能导诊就诊系统》的分诊是 ReAct：没有事先的计划，模型每一轮看着上一步查到的数据决定下一步调哪个工具，最多 12 轮。
为什么这样取舍
- 数据分析先出计划：大目标要先拆成多个可执行的分析步骤，每一步都有自己的问题、SQL 目的和建议图表，拆好之后逐步执行、逐步留痕，报告再按计划汇总各步骤。
- 执行放后台：一个请求等多次 AI 调用会让前端超时断开，接口只负责建步骤和启动后台任务。
- 分诊用 ReAct：要查什么、查几次取决于患者说了什么，患者一句话和五句话需要查的信息量完全不同，没法事先写成计划。
面试官还会追问
- 某一步生成的 SQL 执行失败了，这一步会自动纠错吗？最多纠几次？为什么不多试几次？
- 同一个计划连点两次「执行计划」，第一次留下的步骤、分析记录和报告怎么处理？
学完《AI Agent数据分析平台》，上面这些追问你都会迎刃而解。