ReAct、Plan-and-Execute、Reflection 三种范式的区别与选型？
谁在问：一二面通用；面试官用它看你是背了三个名词，还是能按任务特征做选型
口语化问法
- Agent 的几种范式你都了解吗？分别适合什么场景？
- 你们用的是 ReAct 还是先规划再执行？为什么这么选？
- 让 Agent 自己检查一遍再输出，这招什么时候有用、什么时候纯烧钱？
考察意图
三个名词的定义在任何一篇综述里都有，所以面试官压根不在意你能不能复述。他在看：
- 能不能按任务特征反推范式——而不是反过来先定范式再削足适履。
- 知不知道各自的失败模式——ReAct 会绕路、Plan 会在信息最少时做最重的决策、Reflection 会自我肯定。说得出失败模式才说明跑过。
- 知不知道 2026 的变化——推理模型内化了一部分显式规划和自省，早期手写的那套 planner / self-critique 有相当一部分可以删了。还在照搬 2023 年架构图的人，会在这里露出来。
- 是不是二选一思维——生产里三者几乎总是混着用。
参考答案
60 分答案（及格线）
三者解决的问题不同：
- ReAct（边想边做）：每一步都看上一步的观察结果再决定下一步。适合下一步依赖上一步结果的探索型任务，比如排障、查资料。
- Plan-and-Execute（先规划再执行）：先让模型产出一份步骤清单，然后按清单执行。适合任务能提前拆解、步骤较多、希望成本和路径可控的场景，执行阶段还能并行、还能用便宜模型。
- Reflection（自省重做）：产出结果后再让模型批评一遍并修订。适合有明确质量标准的产出物，比如代码、报告。
选型主要看三件事：任务能不能提前拆解、有没有客观的验证信号、成本和延迟预算有多少。
90 分答案（有生产经验的回答）
补三层：失败模式、判据表、2026 现状。
1. 各自的失败模式（这是分水岭）
| 范式 | 解决什么 | 代价是什么 | 什么时候不该用 |
|---|---|---|---|
| ReAct | 路径依赖观察，能随环境调整 | 每步一次模型请求，成本时延随步数线性涨；只有局部视野，容易贪心绕路、反复试探 | 路径本来就固定（写 workflow）；步骤多且需要全局编排/并行 |
| Plan-and-Execute | 全局视野、可并行、执行阶段可降档省钱、计划可展示给用户审阅 | 在信息最少的时候做最重的决策；环境一变计划就失效，需要 replan 机制；实现复杂度高 | 高不确定性的探索任务；短任务（规划开销不划算） |
| Reflection | 有验证信号时能显著提质 | token 和延迟成倍；没有外部信号时容易自我肯定，甚至越改越差 | 主观任务且无客观标准；高 QPS 低单价场景 |
Reflection 那条我想特别说：它的效果几乎完全取决于批评的信号从哪来。让模型自评自改，本质上是同一个分布再采样一次，很容易"看了一遍觉得自己写得挺好"。真正有效的是把外部信号接进来——代码跑测试、SQL 拿去 explain、数值去对账、结构化输出过 schema 校验。有硬信号的 reflection 是提质，没有的多半是花两倍的钱买一份心理安慰。
2. 落地上的判据顺序。 我一般按这个顺序问自己：任务能不能在动手前拆清楚？拆不清就 ReAct。步骤是不是多且有可并行的部分？是就上 plan。产出有没有可自动验证的信号？有就加一轮 reflection，并且固定轮数上限（通常 1 轮，最多 2 轮，收益衰减很快）。
3. 生产里是混合的。 我上一版的形态是：外层做一次轻量规划（3–5 步，给用户看得见的进度条），每个步骤内部是受限的 ReAct 循环（max_steps=3），最后对最终产出做一次带外部校验的 reflection。这样三种范式各自只在它擅长的层级出现。
4. 2026 的变化要说到。 推理模型把一部分显式 CoT 和自我检查内化进去了，早期手写的 planner 提示词、self-critique 环节很多可以直接删掉，删了之后成功率不掉、成本反而降。这正好对应"模型变强则 harness 变薄但不消失"的判断（截至 2026-08）。没被内化的部分是：外部工具编排、预算与步数控制、权限与确认、把计划展示给人审阅——这些属于 harness，模型再强也接管不了。所以显式 plan 现在的主要价值往往不是"让模型想得更清楚"，而是"让人能提前看见并干预"。
追问链
Plan-and-Execute的计划执行到一半发现不对了，怎么办？期望把计划当假设不是契约。replan 触发条件要写死：某步失败且重试无效、观察与计划前提矛盾（假设有权限、实际没有）、冒出计划外的新信息。做法优先局部重规划，只改剩余步骤、保住已确认的约束；再限 replan 次数（最多 2 次），防「计划—失败—重规划—又失败」的高级死循环信号说出「局部重规划 + replan 次数上限」→ 真跑过；只答「重新规划一次」→ 没遇过 replan 抖动Reflection 什么时候真有用？怎么判断它不是在烧钱？
期望判据只有一条：批评的依据是不是外部的。有硬信号（单测、编译器、schema 校验、对账、证据比对）收益明确；纯「再检查一遍」是自评，带自我偏好。要拿配对对比算账：有/无 reflection 的质量增益 vs 成本延迟涨幅，只对高价值请求开；轮数设上限，二轮后常是来回改信号立刻分开「有外部验证信号 vs 纯自评」并提配对量化 → 做过评测；答「自查一遍总归更好」→ 没算过账推理模型出来之后，还需要手写 CoT 和 planner 吗？
期望分两半：被内化的：「一步步思考」、多数自我检查、简单任务分解，再手写是负优化（占 token、和内部推理打架）；没内化的：工具编排、预算与步数控制、权限与人工确认、可干预的计划、跨会话状态，都是 harness。planner 从「帮模型想」→「让人能看见和干预」信号把「帮模型思考」和「给系统提供可控性」拆开 → 跟上了 2026；答「都不用了」或「模型不可靠当然还得写」→ 都是一刀切怎么用数据决定该切哪种范式，而不是拍脑袋？
期望配对实验控住变量：同模型、同工具、同评测集，只换控制结构。四维：成功率、步数分布、成本时延P50/P95、可解释性；Agent 不可复现，每条重复多次看分布。经验：先按意图分档再选范式（简单查询单步、复杂排查 ReAct、批量生成 plan），上线后拿一次解决率、转人工率复核信号提出控制变量 + 重复取分布 + 按意图分档 → 做过选型实验；答「试试哪个效果好」说不出对比方法 → 没有量化能力ReAct 长任务老绕路，产品要「更聪明」，团队提议大改 Plan-and-Execute，值不值？
期望先归因再谈范式：trace看形态——描述模糊致试错（改描述）、返回空不给提示致换措辞（改返回值）、真缺全局视野才是范式问题，前两类占多数 → 一天的低成本验证：加一版「先列 3–5 步计划再执行」的提示词跑评测，没改善即瓶颈不在规划 → 定门槛（成功率涨几点、P95步数降多少、成本不涨），达不到回滚 → 折中：外层轻量规划做进度展示，内层留 ReAct信号先归因再谈范式、点出「多数绕路其实是工具问题」、识破「不够聪明」其实是透明度诉求 → 有产品感；直接开干重构 → 缺一层判断
评分要点
- 三种范式各自解决什么，能用一句话说清
- 说得出各自的失败模式（ReAct 局部贪心绕路 / Plan 在信息最少时决策、需 replan / Reflection 自我肯定）
- Reflection 的有效性取决于是否有外部验证信号
- 有可操作的选型判据（能否提前拆解、有无验证信号、成本预算、是否需要人可见）
- 知道生产中三者常混合分层使用
- 加分：replan 的触发条件、局部重规划、次数上限防抖
- 加分：知道推理模型内化了部分规划与自省，harness 变薄但不消失（截至 2026-08）
- 加分：能用配对实验数据决定范式，而非凭感觉