ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目怎么选型？

#RAG#Agent#面试八股

ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目怎么选型？

三个名字回答的是同一个问题的不同侧面：ReAct 解决"每步怎么想"，Plan-and-Execute 解决"先想清楚再干"，Reflection 解决"干完发现不对怎么办"。 它们不是互斥的三选一，而是可以叠在一个循环里的三种机制。面试里先讲控制流差异，再讲叠加方式，最后给选型判据。

1. 结论：差别在"思考发生在什么时候"

范式思考时机核心循环一句话概括
ReAct每一步之前想 → 做 → 看 → 想边走边看，局部最优
Plan-and-Execute动手之前一次性规划规划 → 逐步执行 → 必要时重规划先出图纸再施工
Reflection产出之后产出 → 批判 → 修订自己给自己改作业

选型看三点：任务步骤能否事先枚举、单步反馈是否昂贵、错误是否容易自我识别。

2. 机制：三张流程图

ReAct
  目标 ──▶ [Thought] ──▶ [Action] ──▶ 环境 ──▶ [Observation]
             ▲                                    │
             └────────────────────────────────────┘
         每步都重新决策；上下文随步数线性增长

Plan-and-Execute
  目标 ──▶ [Planner] ──▶ 步骤 1 ─▶ 步骤 2 ─▶ 步骤 3 ──▶ 汇总
                            │         │
                            └─ 失败/偏差 ─▶ [Replan] ─┘
         规划一次，执行多次；执行器可以是简单函数，也可以是子 Agent

Reflection
  产出 ──▶ [Critic 找问题] ──▶ 有问题? ──是──▶ [Revise 修订] ──┐
             ▲                        │                      │
             └────────────────────────┴──────── 否 ──▶ 交付 ◀─┘

三者的开销结构完全不同：ReAct 贵在步数（每步一次推理），Plan-and-Execute 贵在规划（一次长输出）但执行便宜，Reflection 贵在重复生成（至少两倍 token）。

3. 详细对比

维度ReActPlan-and-ExecuteReflection
上下文增长快，每步都堆观察慢，计划一次成型中，需保留草稿与批评
长任务表现容易走偏、忘记早期目标好，计划可反复对照中，只改局部
并行能力弱，天然串行强，无依赖步骤可并行弱
可中断恢复难，状态散在上下文里易，计划即状态中
典型失败死循环、重复调用同一工具计划本身错了、执行偏离计划反复改、越改越差
成本量级中低（步数固定）高

4. 工程上正确的做法是叠加

生产系统很少只用一种。常见组合是"外层计划、内层 ReAct、关键节点反思"：

def run(goal: str, budget: int = 40) -> str:
    plan = planner(goal)                     # ① 先规划：输出 JSON 步骤数组
    state, notes = {}, []

    for step in plan["steps"]:
        if step.get("depends_on") and not satisfied(step, state):
            plan = replan(goal, plan, state, reason="前置步骤失败")   # ④ 重规划
            continue

        result = react_loop(step, tools=TOOLS, max_steps=8)          # ② 步骤内 ReAct
        if step.get("verify"):
            result = reflect(result, rubric=step["verify"], max_rounds=2)  # ③ 反思
        state[step["id"]] = result

    return merge(goal, plan, state)

# 关键：三层各自有独立预算，任何一层超限都向上抛，而不是静默重试

这段结构里，Planner 只负责"分几步"，ReAct 负责"这一步怎么落地"，Reflection 只在有明确验收标准（如能跑通编译、能过单测）时启用。

5. 选型判据

场景特征推荐理由
3~8 步、每步依赖上一步结果ReAct计划会因信息不足而失真
步骤多（10+）、可并行、要求可恢复Plan-and-Execute计划即状态，便于断点续跑
有硬性验收标准（测试、schema、规则）叠加 Reflection有客观信号，反思才有效
需要人工审核的产出（报告、代码）ReAct + 一次 Reflection交付前自查一轮性价比最高
延迟敏感（<3 秒）都不用，走 Workflow多轮推理无法满足 SLA

经验阈值：设一个总步数预算 N，ReAct 每步消耗 1，规划消耗 3，反思每轮消耗 2，超预算就降级到 Workflow 兜底，而不是让循环无限跑。

6. 常见追问

问：Plan-and-Execute 的计划错了怎么办？ 必须有重规划（Replan）入口，触发条件写清楚：某步连续失败两次、工具返回"前置条件不满足"、执行结果与计划的预期产出不符。没有重规划的纯计划执行，本质就是一次性的 Workflow。

问：Reflection 什么时候不该用？ 没有客观判定信号时（如"这段文案好不好"），模型自评容易自我肯定，反思收益很低甚至有害；另外延迟敏感场景也不适合，它至少让成本翻倍。

问：ReAct 的"想"必须显式输出吗？ 不一定。推理模型（Reasoning Model）把思考放在内部，外部只暴露动作，这时 ReAct 退化为"函数调用循环"。显式 Thought 的好处是可观测、可干预，缺点是占 token。

问：三者能用一个框架统一吗？ 能，把"规划、行动、反思"都建模成图上的节点即可（LangGraph 这类图编排就是这么做的）。统一的好处是状态可序列化、可断点恢复；代价是抽象层变厚，简单任务反而更绕。

小结

ReAct 是"每步都想"，Plan-and-Execute 是"先想再做"，Reflection 是"做完再想"。真实系统按"计划 → 逐步 ReAct → 关键处反思"叠加，并用独立预算约束每一层。选型的根本判据不是范式新旧，而是任务步骤能否预知、有没有客观验收信号、延迟预算是多少。

笔记加载中…