Agent 推理范式详解：ReAct、Plan and Execute、Reflexion 怎么选
给大模型接上搜索、数据库、代码执行器之后，它就不再是一个「问答机器」，而是一个需要自主决策的 Agent。但决策本身也有架构——Thought 和 Action 要不要交错？Plan 是一次性生成还是边做边改？失败了是重试还是反思？ReAct、Plan and Execute、Reflexion 是三种最常被引用的范式，选错了轻则 token 爆炸，重则任务链断裂。这篇博客把它们拆开讲透。
一、为什么 Agent 需要「推理范式」
裸 LLM 做 Agent 有一个根本矛盾：模型只能生成文本，但任务需要与外部世界交互。
你要它查天气，它要么瞎编一个温度，要么调用 API 拿到真实数据。中间这段「决定调用什么工具、拿到结果后怎么继续推理」的逻辑，就是 Agent 推理范式要解决的问题。
三种范式回答的是三个不同层次的问题：
| 范式 | 核心问题 |
|---|---|
| ReAct | 推理和行动怎么交错？ |
| Plan and Execute | 复杂任务要不要先拆步骤？ |
| Reflexion | 执行失败了怎么从错误中学习？ |
它们不是互斥的——生产系统里经常组合使用。但在选型之前，需要理解每种范式独立解决什么、代价是什么。
二、ReAct：推理与行动交错
2.1 起源与核心思想
ReAct（Reasoning + Acting）由 Yao 等人于 2022 年提出。核心洞察是：让模型在每一步行动前先显式输出推理过程，能显著提升工具调用的准确性。
传统 Chain-of-Thought 只推理不行动；传统 Action-only Agent 只行动不推理。ReAct 把两者逐步交错：
1 | Thought → Action → Observation → Thought → Action → ... |
2.2 执行流程
一次典型的 ReAct 循环在上下文里长这样：
1 | Question: 北京今天天气怎么样？适合户外跑步吗？ |
2.3 上下文结构
ReAct 的 prompt 通常包含四段固定格式：
| 字段 | 作用 |
|---|---|
| Question | 用户原始问题 |
| Thought | 模型当前推理，解释为什么要做下一步 |
| Action | 工具名 + 参数，或 Finish[答案] |
| Observation | 工具返回结果，由系统注入（不是模型生成的） |
关键设计点：Observation 必须由系统写入，不能信任模型自己「编造」工具返回值。这是 ReAct 与纯 CoT 的本质区别——模型负责决策，环境负责反馈。
2.4 优势与局限
优势：
- 可解释性强：每一步 Thought 都可见，调试时能精确定位「哪一步推理错了」
- 适应动态环境：每拿到一个 Observation 就重新推理，不需要预先知道全部步骤
- 实现简单：一个循环 + 工具注册表即可，LangChain、LlamaIndex 都有开箱即用的 ReAct Agent
- 工具调用准确率高：显式 Thought 步骤显著减少「调错工具、传错参数」
局限：
- Token 消耗高：每个 Thought/Action/Observation 三元组都占上下文，长任务容易撑爆窗口
- 缺乏全局规划：逐步决策，容易陷入局部最优——前面某步走错，后面全部跟着偏
- 无自我纠错机制：Observation 返回错误结果时，模型可能继续基于错误数据推理，没有内置的「停下来反思」逻辑
- 串行执行：一步接一步，无法并行调用多个独立工具
2.5 适用场景
- 步骤数 ≤ 5 的短链任务（查资料、算数、单轮 API 调用）
- 需要逐步探索、信息逐步披露的任务（「帮我调研 X 公司」）
- 调试和 Demo 阶段——Thought 日志直接可读
- 工具种类少、调用逻辑清晰的场景
三、Plan and Execute：先规划，再执行
3.1 起源与核心思想
Plan and Execute 的灵感来自人类处理复杂任务的方式：先列 todo，再逐项完成。
与 ReAct 的「边想边做」不同，Plan and Execute 明确拆成两个阶段：
1 | 阶段一（Planner）： 输入目标 → 输出完整步骤列表 |
LangChain 在 2023 年将其标准化为 PlanAndExecute Agent，Planner 和 Executor 可以使用不同的模型——Planner 用强推理模型，Executor 用快速便宜模型。
3.2 执行流程
一个典型的计划长这样：
1 | Goal: 写一份关于 2024 年中国新能源汽车市场的调研报告 |
Executor 逐步执行，每步完成后把结果写入上下文，Planner 可以在中途 Re-plan。
3.3 上下文结构
Plan and Execute 的上下文分两层：
Planner 上下文：
| 字段 | 作用 |
|---|---|
| Goal | 最终目标 |
| Current Plan | 当前步骤列表及每步状态（pending / done / failed） |
| Past Steps | 已完成步骤的结果摘要 |
| Re-plan Trigger | 某步失败或结果与预期不符时触发 |
Executor 上下文（每步独立）：
| 字段 | 作用 |
|---|---|
| Current Step | 当前要执行的单步描述 |
| Available Tools | 该步可用的工具子集 |
| Step Result | 执行结果，回传给 Planner |
关键设计点：Planner 和 Executor 的上下文是隔离的。 Executor 不需要知道完整计划，只关注当前步骤——这降低了每步推理的复杂度，也允许 Executor 使用更轻量的模型。
3.4 Re-plan 机制
Plan and Execute 不是「计划一次、执行到底」。当以下情况发生时，Planner 会重新生成计划：
- 某步执行失败（工具报错、超时）
- 某步结果与预期不符（搜到的数据年份不对）
- 执行过程中发现原计划遗漏了关键步骤
- 上下文窗口接近上限，需要压缩已完成步骤的摘要
Re-plan 的开销是一次额外的 Planner 调用，但避免了 ReAct 那种「一步错、步步错」的连锁反应。
3.5 优势与局限
优势：
- 全局视角：Planner 先看全貌再动手，步骤之间的依赖关系更清晰
- Token 效率更高：Executor 每步只看当前任务，不被完整历史拖累
- 可并行：Plan 中无依赖的步骤可以并行执行（ReAct 做不到）
- 模型分层：Planner 用 GPT-4，Executor 用 GPT-4o-mini，成本可控
- 进度可追踪：Plan 列表天然就是进度条，适合 UI 展示
局限：
- 计划可能脱离实际：Planner 在没有真实数据的情况下「空想」步骤，执行时才发现不可行
- Re-plan 延迟：中途调整计划需要额外的 LLM 调用，增加延迟
- 简单任务过度设计：查个天气也要先列 3 步计划，反而更慢
- Planner 质量是瓶颈：计划拆得不好，Executor 再强也救不了
3.6 适用场景
- 步骤数 > 5 的多阶段任务（写报告、数据分析、代码生成）
- 步骤之间有明确依赖关系，需要全局排序
- 需要向用户展示进度（「正在执行第 3/6 步」）
- 对成本敏感、希望 Executor 用便宜模型的生产环境
- 部分步骤可以并行执行的任务
四、Reflexion：从失败中反思迭代
4.1 起源与核心思想
Reflexion 由 Shinn 等人于 2023 年提出。它解决的是 ReAct 和 Plan and Execute 共同的盲区：执行失败了怎么办？
ReAct 遇到错误 Observation 可能继续错下去；Plan and Execute 的 Re-plan 只是调整步骤，不会分析「为什么失败」。Reflexion 引入了显式的自我反思循环：
1 | Actor（执行） → Evaluator（评估） → Reflector（反思） → 带反思记忆重新执行 |
关键创新：反思结果以自然语言形式存入 episodic memory，下次尝试时作为上下文注入，模型从「经验」中学习——不需要微调权重。
4.2 执行流程
4.3 三个角色的职责
| 角色 | 输入 | 输出 | 可用模型 |
|---|---|---|---|
| Actor | 任务 + 历史反思 | 具体执行结果 | 与 ReAct/Executor 相同 |
| Evaluator | 任务 + Actor 输出 | 成功/失败 + 评分 + 具体反馈 | 可以用规则引擎，也可以用 LLM |
| Reflector | 任务 + Actor 输出 + Evaluator 反馈 | 自然语言反思（「我失败是因为…，下次应该…」） | 通常用强推理模型 |
Reflector 输出的反思示例：
1 | Reflection 1: |
这段反思会在 Attempt 2 中作为上下文注入 Actor，Actor 不会重复同样的错误。
4.4 Episodic Memory 结构
Reflexion 的记忆不是向量数据库里的 RAG，而是结构化的尝试记录：
1 | Trial 1: |
每次新尝试只携带反思摘要，不携带完整的历史 Trajectory——否则 token 会指数增长。
4.5 与 ReAct / Plan and Execute 的关系
Reflexion 不是第四种独立范式，而是覆盖在 ReAct 或 Plan and Execute 之上的纠错层：
1 | Reflexion + ReAct: Actor 使用 ReAct 循环执行，失败后 Reflector 分析 ReAct 轨迹 |
实际上，LangGraph、AutoGPT 等框架的「retry with reflection」模式都是 Reflexion 的工程化实现。
4.6 优势与局限
优势：
- 自我改进：不需要人工标注或模型微调，纯 prompt 层面从失败中学习
- 错误隔离：每次尝试是独立的 episode，不会因为累积错误污染上下文
- Evaluator 灵活：可以用规则（单元测试通过率、API 状态码）或 LLM 做评估
- 适合高失败率任务：代码生成、复杂推理、多跳 QA 等「一次做不对」的场景
局限：
- 成本翻倍起步：每次失败 = 完整重跑 + Evaluator + Reflector，3 次尝试 ≈ 3x 成本
- Evaluator 设计是难点：评估标准模糊时，Reflector 的反思质量也会下降
- 可能陷入重复错误：如果 Reflector 分析不到位，多次尝试犯同样的错
- 延迟高：不适合实时交互场景
4.7 适用场景
- 有明确评估标准的任务（代码能否跑通、答案是否有据可查）
- 一次成功率低但「接近正确」的任务（代码生成、数学证明）
- 允许 2-3 次 retry 的非实时场景（后台任务、批处理）
- 与 ReAct 或 Plan and Execute 组合，作为可靠性兜底
五、三种范式对比
5.1 核心维度对比
| 维度 | ReAct | Plan and Execute | Reflexion |
|---|---|---|---|
| 决策方式 | 逐步交错 | 先全局后局部 | 执行-评估-反思循环 |
| 规划范围 | 无全局规划 | 完整步骤列表 | 取决于底层 Actor |
| 上下文增长 | 线性（每步 +3 段） | 亚线性（Executor 隔离） | 按尝试次数倍增 |
| 错误处理 | 无内置机制 | Re-plan 调整步骤 | 显式反思 + 重试 |
| 并行能力 | 不支持 | 支持（无依赖步骤） | 不支持 |
| 模型分层 | 单模型 | Planner + Executor 可不同 | Actor + Evaluator + Reflector 可不同 |
| 实现复杂度 | 低 | 中 | 高 |
| Token 成本 | 中 | 中低 | 高 |
| 可解释性 | 高（Thought 日志） | 高（Plan 列表） | 高（Reflection 日志） |
| 典型延迟 | 低 | 中 | 高 |
5.2 执行路径对比
1 | ReAct: |
5.3 失败模式对比
| 失败类型 | ReAct 的表现 | Plan and Execute 的表现 | Reflexion 的表现 |
|---|---|---|---|
| 工具调用参数错误 | 下一步可能纠正 | Re-plan 换方案 | 反思后重试，参数修正 |
| 工具返回空/错误 | 可能基于空结果继续 | 触发 Re-plan | Evaluator 捕获，Reflect 分析 |
| 推理方向错误 | 连锁偏航，难自救 | Planner 可能 Re-plan | 反思指出方向问题 |
| 步骤遗漏 | 无法发现 | Planner 在 Re-plan 时补 | Reflector 指出遗漏 |
| 上下文溢出 | 截断后丢失早期信息 | Executor 隔离缓解 | 只保留反思摘要 |
六、选型决策
6.1 决策流程
6.2 按场景推荐
| 场景 | 推荐范式 | 理由 |
|---|---|---|
| 智能客服（查订单、改地址） | ReAct | 步骤少、工具固定、要求低延迟 |
| 调研报告生成 | Plan and Execute | 多阶段、有依赖、需展示进度 |
| 代码生成 / 修复 | Reflexion + ReAct | 有测试作为 Evaluator，retry 价值高 |
| 数据分析 pipeline | Plan and Execute + Reflexion | 先规划分析步骤，执行失败则反思 |
| 多工具并行查询 | Plan and Execute | 无依赖步骤可并行 |
| 实时对话 Agent | ReAct | 延迟敏感，不宜 retry |
| 复杂问答（多跳推理） | ReAct 或 Reflexion + ReAct | 信息逐步披露用 ReAct；准确率低则加 Reflexion |
| 后台自动化任务 | Plan and Execute + Reflexion | 不要求实时，可靠性优先 |
6.3 组合模式
生产环境中最常见的不是「三选一」，而是分层组合：
1 | ┌─────────────────────────────────────────────┐ |
推荐的分层策略：
- 默认 ReAct：80% 的日常任务够用，实现最简单
- 步骤 > 5 或需要进度展示时切换 Plan and Execute
- 有客观评估标准（测试、API 校验）且失败代价高时，叠加 Reflexion
- Planner / Reflector 用强模型，Executor / Actor 用快模型——这是成本和质量的最佳平衡点
6.4 常见踩坑
1. 简单任务上了 Plan and Execute
查个天气先列 4 步计划，Planner 调用一次，Executor 再调用一次——比 ReAct 多一次 LLM 调用，延迟和成本都更高，体验反而更差。
2. Reflexion 没有 Evaluator 标准
Evaluator 输出「不太好」这种模糊反馈，Reflector 无法生成有效反思，retry 变成碰运气。Evaluator 必须能给出具体的、可操作的失败原因。
3. ReAct 上下文不做截断
20 步 ReAct 循环后，上下文里堆了 60 段 Thought/Action/Observation，早期步骤被截断，模型「忘记」了关键信息。应对：超过 N 步后压缩历史为摘要。
4. Plan and Execute 的 Plan 不可变
计划生成后执行到底，某步失败后直接报错而不是 Re-plan。正确做法是：任何步骤失败都应触发 Re-plan，而不是让整个任务失败。
5. 三种范式混用但不隔离上下文
Reflexion 的反思记忆和 ReAct 的执行轨迹混在同一个上下文里，token 膨胀且互相干扰。反思摘要和当前执行轨迹应分通道管理。
七、总结
| 如果你需要… | 选这个 |
|---|---|
| 快速实现、步骤少、低延迟 | ReAct |
| 多阶段任务、全局规划、进度可见 | Plan and Execute |
| 高可靠性、允许 retry、有评估标准 | Reflexion（叠加在前两者之上） |
三种范式的本质区别不在于「谁更先进」，而在于决策粒度：
- ReAct 是逐步决策——适合探索性任务
- Plan and Execute 是分层决策——适合结构化任务
- Reflexion 是迭代决策——适合高失败率任务
从 ReAct 开始，按需叠加 Plan and Execute 的全局规划能力和 Reflexion 的纠错能力，是大多数 Agent 项目的务实路径。