三种 Agent 范式的取舍——ReAct、Plan-and-Execute、Reflection

这张表是回答 Q3-07 的主干。 面试里能把"可人工审批"和"可并行"两列讲出来的人不多——它们恰恰是 Plan-and-Execute 在企业场景里真正的价值，而不是那句空洞的"更有条理"。

Plan-and-Execute 不是不能用，是不能开环用。把它改成 Plan → Execute → 触发式 Replan 的闭环：

plan = planner(task)
i = 0
while i < len(plan) and steps_used < MAX_STEPS:
    result = execute_step(plan[i])          # 每步内部可以是一个小 ReAct 循环
    if should_replan(plan, i, result):      # ← 关键：显式的重规划触发条件
        plan = planner(task, history, reason=diagnose(result))
        i = 0 if plan_restarted else i      # 重规划后从哪继续，要显式决定
        continue
    i += 1

should_replan 至少要覆盖五类信号：

1. 前置假设被证伪：计划假定存在的表/接口/文件不存在（开篇的情况）。
2. 结果为空或异常：空结果不等于"结论是零"，要区分"查到了 0 条"和"查错了地方"。
3. 步骤连续失败：同一步重试 N 次仍失败。
4. 新信息与计划矛盾：中途发现的事实推翻了计划前提。
5. 预算/步数已用过半但进度明显落后。

面试里被问"Plan-and-Execute 怎么用"，直接答 replan 触发条件，比复述范式定义高一个层级。

这是 2026 年最值得强调的一条判断：

Reflection 的增益，几乎完全取决于评审信号是不是外部的、可验证的。

• 有外部信号：单元测试通过/失败、编译器报错、schema 校验、检索到的事实比对、规则引擎判定——这类"验证比生成便宜"的场景，反思循环收益明确且可观。
• 纯自我反思：让同一个模型评价自己刚写的东西，增益有限，有时甚至是负的。模型倾向于认可自己的输出（自我偏好），或者在没有新信息的情况下把对的改错。

所以工程上的正确形态不是"加一个反思 prompt"，而是先想办法造出一个可执行的验证器，再让反思去消费它的输出。没有验证器的 Reflection，多半是花两倍的钱买一个心理安慰。

推理模型（thinking 类）把"多步推理"内化到了模型自身的生成过程里。这带来两个实际变化：

1. 显式 planner 节点的必要性下降。过去要专门跑一次"请先列出计划"的调用，现在很多任务里模型在单次响应内就完成了等价的规划。但这只消掉了"生成计划"这一步，没有消掉"计划需要被人看到、被审批、被并行调度"这些需求——如果你需要把计划展示给用户确认，显式 planner 依然有价值。
2. 单纯的自我反思收益进一步缩小，因为模型已经在内部做过一轮自我检查。反思的价值更集中在"引入外部验证信号"这一侧。

面试里主动区分"因为推理模型所以不需要 planner"和"因为需要人工审批所以仍然需要 planner"，是一个明确的加分动作。

参数经验值（起步值，务必自测）：

• 反思轮数：1～2 轮。边际收益衰减很快，第 3 轮往往只是改动措辞，却付了完整成本。
• 反思要有硬上限，否则会出现"修订 → 评审不过 → 再修订"的无限循环，这是 Reflection 版本的死循环。
• 计划步数：≤ 10 步。计划越长，开环风险越大，前提被证伪的概率越高。长任务应该分阶段规划，而不是一次规划到底。
• 每步内 ReAct 子循环：3～5 步上限，超了就上报给上层触发 replan。

• 解决什么：把"生成一次就交付"变成"生成-验证-修订"，在有客观验证信号的任务上显著提升正确率（代码、结构化抽取、需要满足硬约束的产出）。
• 代价是什么：① 成本和延迟接近翻倍甚至更多；② 无外部信号时增益微弱甚至为负（自我偏好、把对的改错）；③ 可能陷入修订循环；④ 让轨迹变长，加重上下文压力（T3-6）。
• 什么时候不该用：没有可执行验证器的主观任务（"这段文案好不好"）——那是 LLM-as-Judge 的评测范畴（T5-2），不该塞进在线链路；延迟敏感的同步接口；以及模型本身已经是推理模型、且任务简单时——你只是在为它已经做过的事情再付一次钱。

• 别让计划"看起来很专业"就信它。计划的自信程度和正确性无关，模型对不存在的表也能规划得头头是道。
• 空结果必须显式判定语义（"查到 0 条"还是"查错了地方"），这是 replan 的最高频触发点。
• replan 后要决定从哪继续：重头来、从当前步继续、还是回退 N 步。不显式决定就会出现重复执行副作用。
• 别在每一步都反思，那是成本黑洞。只在最终产出或关键节点反思。
• 反思的 prompt 要给具体检查项，不要只说"请检查你的回答是否正确"——那句话几乎必然得到"我检查过了，是正确的"。

Q3-07 是一二面常规题，问法通常是「ReAct、Plan-and-Execute、Reflection 有什么区别，你怎么选」。大部分候选人会把它答成名词解释，这正是拉开差距的机会。

高频追问：你的项目用了哪种、为什么？（→ 必须有理由，不能是"框架默认"）计划执行到一半发现错了怎么办？（→ replan 触发条件）反思真的有用吗？（→ 外部验证信号，这是最能体现深度的一问）推理模型出来之后还需要 planner 吗？（→ 时效认知）

1. 用"什么时候思考"统一三者：ReAct 边做边想、Plan 事前想、Reflection 事后想。一句话建立框架。
2. 给工程属性对比，重点讲可并行和可人工审批——这两点是 Plan-and-Execute 的真实价值。
3. 主动交代失败模式：Plan 的开环崩溃、ReAct 的绕圈、Reflection 的自我肯定。讲失败模式比讲优点更能证明你用过。
4. 给 Reflection 加限定："我们只在有测试信号的地方用反思，纯自我反思我们实测收益不明显。"
5. 收在混合架构上，并给出你的参数（反思轮数、计划步数上限）。

只读过资料的回答：

• 三个范式的名词解释背得很流利，说不出各自会怎么坏。
• 认为 Plan-and-Execute 比 ReAct"更高级"或"更先进"。
• 说 Reflection 能提升效果，但说不出前提条件。
• 没有 replan 概念，认为计划出来就照做。
• 完全没意识到推理模型对显式 planner 的影响。

真做过的回答：

• 说得出 replan 的具体触发条件，尤其是"前置假设被证伪"和"空结果的语义判定"。
• 明确指出 Reflection 需要外部可验证信号，纯自我反思增益有限。
• 提到 Plan-and-Execute 真正的收益是可并行 + 可审批，而不是"更有条理"。
• 报得出反思轮数上限和边际收益衰减的观察。
• 提到 replan 之后"从哪继续"以及副作用重复执行的风险。
• 能说清推理模型之后"planner 什么时候还需要保留"。