在 AI Agent 的面试和实际开发里，ReAct、Plan-and-Execute、Reflection 是出现频率最高的三个名词。但很多人的困惑在于：背得出定义，却说不清三者到底是什么关系，也讲不出实际项目该怎么选。

这篇博客的目标，就是把这三者"掰开揉碎"，从论文溯源、运行机制、成本差异到选型策略，一次讲清楚。

先厘清一个关键前提：设计范式 vs 推理模式

很多人在概念上卡壳，是因为把两个层次的东西混在了一起。

设计范式是搭建 Agent 的"顶层做事流程框架"——它决定整个系统从接收任务到完成目标，按什么大逻辑运行。打个比方，它就像你开店，是走一步看一步的灵活夫妻店模式，还是先定好全套标准的连锁模式。

推理模式则是 Agent 在每一个具体步骤里"脑子里怎么想"，比如是稳扎稳打一步步来，还是先想几个方案选最优。打个比方：设计范式是公司的管理制度，推理模式是员工干活的思路——制度定好大框架，员工在每个环节里决定怎么干，两层配合才能把事做成。

分清这个前提之后，再看三者的关系就通透了：ReAct 和 Plan-and-Execute 是"把事做完"的两种独立执行范式，而 Reflection 是"把事做好"的增强机制，它不是一个可以独立成立的新流程。

ReAct：边想边做的奠基款

ReAct 是 Agent 范式的"祖宗"。它诞生于 2022 年，由 Shunyu Yao 等人提出，论文《ReAct: Synergizing Reasoning and Acting in Language Models》后来成为 ICLR 2023 的口头报告。这篇论文没有训练新模型、也没改模型架构，只是设计了一个提示词格式——Thought → Action → Observation 的循环，就把推理和行动结合了起来。

在此之前，大模型像个"关在隔音房里的传声筒"：你问它今天的比特币价格，它会凭训练数据自信地编一个去年的数。ReAct 的价值在于让模型既能思考、又能调用外部工具去核实，把 Chain-of-Thought 的推理能力和强化学习 Agent 的环境交互能力结合在了一起。

用生活化的例子理解：ReAct 就像外卖骑手，接了"把餐送到用户手里"的目标，不会提前把每一步定死。他先想"去商家取餐"，取了餐再想"去用户小区"，到了小区门口再想"3 号楼走西门更近"。每一步决策都基于上一步的实际情况，路封了立刻改路线，绝不死守计划。

ReAct 最大的优势是实现简单、灵活度极高、逻辑透明，出了问题好排查，新手入门零门槛。但短板也很明显：遇到长流程、多步骤的复杂任务，很容易走着走着就忘了最初目标，甚至在某一步陷入无效循环。所以它最适合流程不固定、复杂度适中的任务，比如日常信息搜索、简单问答、客服机器人。

Plan-and-Execute：先规划后执行的结构款

Plan-and-Execute 是专门针对 ReAct"长任务容易跑偏"这个痛点做的优化。它和 ReAct 的核心区别一句话就能说清：ReAct 是"走一步看一步，边想边干"；Plan-and-Execute 是"先把完整计划定好，再按计划一步步干"。

从推理模式上看，它把 ReAct 里混在一起的"规划"和"执行"彻底解耦：一个模型专门负责把大目标拆成执行清单，另一个模型（或模块）负责按清单逐步执行，最后统一汇总。它的学术渊源可以追溯到 Plan-and-Solve prompting 这类工作，核心思想都是"先规划、后执行"。

它的形象比喻是公司里的项目经理：接到"做一个新产品"的目标，不会上来就写代码，而是先做需求调研、再出原型设计、然后交给开发实现、最后测试验收和上线发布。先把完整步骤定好，再分模块推进，中途不随便乱改方向。

Plan-and-Execute 有一个实际项目中非常实用的隐藏优势：规划模块和执行模块可以用不同的模型。规划阶段对推理能力要求高，可以用 GPT-4 或 Claude 这类强模型；执行阶段每步任务已经很具体，用便宜的小模型就够用。这种"强模型规划、弱模型执行"的策略，能把总成本降低 70% 到 90%，而完成质量几乎不受影响——原因很简单，规划只调一次、花费有限，执行要调很多次、用便宜模型就能大幅压成本。

它的优势是结构清晰、执行链路可控，复杂长流程任务不容易跑偏，还能识别无依赖步骤做并行优化。代价是灵活度不如 ReAct，遇到计划外情况容易卡住，实现也更复杂，需要分别维护规划模块和执行模块。

Reflection：给前两者加的质量增强 buff

这是最容易搞错的一点：Reflection 不是一套独立的完整流程，而是叠加在 ReAct 或 Plan-and-Execute 之上的"自我检查、自我修正"机制。它不改变原本的做事流程，只是加了一层"生成 → 评估 → 改进"的闭环。

用考试来理解三者的关系最直观：ReAct 是"一道题一道题挨着做，做完不回头看"；Plan-and-Execute 是"先把整张卷子的做题顺序和时间分配定好，再按计划做"；Reflection 则是"做完一道题回头检查一遍，发现算错了马上改，改完再交卷"。

学术界对应的典型工作是 Reflexion，由 Noah Shinn 等人提出（东北大学与 MIT），发表于 NeurIPS 2023。它提出的核心思想叫"verbal reinforcement learning"——语言强化学习，让 Agent 不通过梯度更新，而是通过文字反思从错误中学习。

Reflection 的优势很直接：输出质量明显提升，幻觉、逻辑错误、细节遗漏都会减少，对严谨性要求高的场景效果尤其明显。代价是至少多一次 LLM 调用，token 消耗和延迟线性增加，如果不设轮次上限，还容易陷入"为了改而改"的死循环。

进阶：动态 Replan 与 Reflexion

讲完三个基础范式，还有两个面试加分项值得了解。

动态 Replan 解决的是 Plan-and-Execute 的"计划僵化"问题。比如你规划了五步写竞品分析报告，执行到第三步发现某个竞品已经被收购了，原计划就要调整。动态 Replan 的做法是每步执行完后，把当前结果和剩余计划一起交给规划模块，判断"原计划还合理吗"，不合理就生成新的剩余计划替换掉。代价是每步多一次"重新评估计划"的 LLM 调用。

Reflexion 则是把 Reflection 的反思推到更深一层：它不只检查输出对不对，还会把每次失败的原因总结成"经验教训"存进记忆，下次遇到类似任务时作为上下文传回，让 Agent 避免重蹈覆辙。这就像做错数学题后，不只是改答案，还会在错题本上写"这类题容易漏掉符号变化，下次注意"。

Reflexion 的效果有多强？在 HumanEval 代码生成基准上，它把 GPT-4 的 pass@1 准确率从 80% 提升到了 91%。代码生成天然适合 Reflexion，因为代码可以运行、可以测试，执行结果就是最直接的反馈信号。

Token 成本：选型绕不开的现实因素

以一个需要 5 步工具调用、每步约 2000 token 的任务为例：

范式	消耗逻辑	大致消耗	成本特征
ReAct	每步都带完整历史，线性递增	约 30000 token	步骤越多越贵，随步数线性增长
Plan-and-Execute	集中在规划+汇总，执行只带摘要	约 14500 token	比 ReAct 省一半以上，可配合弱模型再降 70%
Reflection	在基础范式上叠加评估轮次	基础消耗 +30%~100%	反思轮次越多越贵，需设 2~3 轮上限

ReAct 因为每步都要把完整历史带上，token 是线性递增的（2000+4000+6000+8000+10000）。Plan-and-Execute 把大头集中在规划阶段和汇总阶段，执行每步只带当前指令和结果摘要，总消耗比 ReAct 低了一半多。而 Reflection 在每个反思节点至少多一次调用，如果一个步骤反思两轮才通过，总消耗就是原来的三倍左右。

选型口诀与工程实践

选型的逻辑其实很清晰，可以浓缩成一句话：任务简单用 ReAct，流程长且复杂用 Plan-and-Execute，输出要求高再加 Reflection。

具体到场景：

• 任务不复杂、流程不固定、需要实时调整——直接用 ReAct，够用就好，别搞复杂的。
• 任务很长、容易跑偏、需要整体结构清晰——上 Plan-and-Execute，先定计划再执行；如果执行中经常遇到意外，再加动态 Replan。
• 输出要求高、不能出错——在前两者基础上叠加 Reflection 做自我检查；需要跨任务积累经验的，用 Reflexion 沉淀失败教训。

实际项目中最常见的做法其实是混合架构：规划阶段用 Plan-and-Execute 的思路定好全局计划，每一步的执行用 ReAct 循环处理（因为单步也可能需要多轮工具调用），最后对整体输出做一次 Reflection 检查质量。这种三层嵌套结构在 LangGraph 这类框架里实现起来非常自然——LangGraph 用状态图的方式把节点、边和数据状态组织起来，天然支持循环、条件分支和持久化，是搭建这类 Agent 系统的主流框架之一。

最容易踩的坑，是把所有范式全堆在一起——又要规划、又要反思、又要 Replan、又要积累经验，结果系统又复杂又慢，还容易出奇怪的 bug。工程开发的黄金法则是"够用就好"：先用 ReAct 快速验证业务能跑通，再根据 token 消耗、延迟和输出质量的实际数据，决定要不要切换到 Plan-and-Execute 或叠加 Reflection。先跑起来，再优化，别为了炫技搞过度工程化。