「AI Agent」Agent 的三大范式：ReAct、Plan-and-Execute 与 Reflection

0 前言

本文内容整理自公众号「小林面试笔记」的文章 6. ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？，用于记录与总结 AI Agent 相关的核心面试知识点。

「ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？」，可以这样作答：

这三者是 Agent 开发里最主流的三种设计范式，核心区别在于「决策和执行的关系」：

• ReAct（边想边干）：思考 → 行动 → 观察 → 再思考，走一步看一步，单步迭代实时调整，灵活度最高；
• Plan-and-Execute（先想全再干）：先定完整计划再分步执行，规划与执行解耦，适合长流程复杂任务，不容易跑偏；
• Reflection（做完再检查）：它不是独立的完整流程，而是给前两者加的「检查修正 buff」，通过「生成 → 评估 → 改进」闭环提升输出质量。

实际选型就看三个维度：任务复杂度、流程确定性、输出质量要求。新手入门首选 ReAct；复杂任务用 Plan-and-Execute；高要求场景在两者之上叠加 Reflection；生产级系统常见的混合用法是「全局计划 + 单步 ReAct + 整体 Reflection」。

下面展开详细解析。先记住理解这三种范式最关键的一个视角：它们不是在同一个维度上竞争，而是解决不同层次的问题：

• ReAct 解决的是「单步行动灵活度」的问题——每一步该怎么做；
• Plan-and-Execute 解决的是「长任务容易跑偏」的问题——整体目标怎么守住；
• Reflection 解决的是「输出质量不够好」的问题——做出来的东西对不对。

---

1 先厘清两个概念：设计范式 vs 推理模式

• 设计范式（Paradigm）：搭 Agent 的「顶层做事流程框架」，定的是整个系统从头到尾按什么大逻辑跑。
• 推理模式（Reasoning Pattern）：Agent 在每一步干活的时候「脑子里具体是怎么思考的」。就像店里的员工接了活，是稳扎稳打一步步来，还是先想几个方案选最优。

两者是一一对应的：设计范式是公司的管理制度，推理模式是员工的干活方法。本文讲的设计范式是更上层的概念，它决定了 Agent 整体按什么逻辑运转。

---

2 ReAct：单步迭代范式

2.1 核心逻辑：思考 → 行动 → 观察 → 再思考

ReAct 是所有 Agent 范式的「老祖宗」，也是最简单的一种。它的本质就是：

思考（Reason）→ 行动（Act）→ 观察（Observe）→ 再思考 → ...

走一步看一步，每一步的行动都完全基于上一步的结果实时调整，没有提前定死的完整计划。 规划与执行是混在一起的。

可以想象一个外卖骑手小哥，接了「把餐送到用户手里」的目标：

1. 他想「我要先去商家取餐」，于是骑车到商家，顺利取到了餐；
2. 接着想「下一步要去用户的小区」，于是开导航骑过去，到了小区门口；
3. 然后想「用户在 3 号楼，走西门更近」，于是骑到西门，到了用户楼下；
4. 最后确认餐已送到，给用户发消息完成交付。

每一步的决策都基于上一步的实际情况。中途如果发现路封了，他会立刻改路线，不会死守原来的计划。

ReAct 其实就是省略了「一次性规划」这一步的版本——每一步由 LLM 现场决策「是调工具还是给最终答案」：

def react_run(user_goal: str):
    memory = []
    while True:
        action = llm.decide(goal=user_goal, history=memory)
        if action.type == "tool_call":
            result = tools.execute(action.tool_name, action.args)
            memory.append(result)          # 观察结果，进入下一轮
        elif action.type == "final_answer":
            return action.content

2.2 优点与缺点

优点：

• 实现简单，新手入门零门槛；
• 灵活度高，流程不固定也能应对突发情况；
• 逻辑透明，每一步「为什么这么干」都能追溯到上一步的结果，出了问题好排查。

缺点：

• 遇到长流程、多步骤的复杂任务，很容易走着走着就跑偏，忘了最初的目标；
• 容易在某一步陷入无效循环（比如反复用一个关键词搜索不到结果还一直搜）。

适用场景： 流程不固定、复杂度适中的任务，比如日常信息搜索、简单问答助手、客服机器人。它也是新手入门的首选。

---

3 Plan-and-Execute：规划执行范式

3.1 核心逻辑：先把完整计划定好，再按计划一步步干

Plan-and-Execute 是针对 ReAct「长任务容易跑偏」的痛点做的针对性优化：

• ReAct 是「走一步看一步，边想边干」；
• Plan-and-Execute 是「先把完整计划定好，再按计划一步步干」。

它把 ReAct 里混在一起的 「规划推理」和「执行推理」完全解耦（拆开）：专门用一个 LLM（或模块）负责「做规划」，把大目标拆成一步一步的执行清单；再用另一个 LLM（或模块）负责「按清单执行」，执行完了再统一汇总。

它就像公司里的项目经理，接了「做一个新产品」的大目标：

1. 先做用户需求调研，明确要做什么；
2. 再出产品原型设计，定好功能细节；
3. 然后交给开发写代码实现功能；
4. 接着测试团队做全流程功能验收；
5. 最后上线发布，交付最终结果。

先把完整的执行步骤全定好，再把每个步骤分给对应的模块去执行，全程按计划推进，不会中途随便乱改方向。

用伪代码来看，规划与执行被明确分成两个阶段：

def plan_execute_run(user_goal: str):
    # 阶段一：规划模块一次性拆解目标
    plan = llm.plan(user_goal)          # 得到步骤列表 [step1, step2, ...]

    # 阶段二：执行模块按计划逐步执行
    results = []
    for step in plan:
        result = llm.execute(step, summary_of_previous=results)
        results.append(result)

    # 汇总阶段：统一综合所有结果
    return llm.aggregate(results)

3.2 一个隐藏优势：「强模型规划、弱模型执行」

既然规划和执行是两个独立的模块，那它们完全可以用不同的模型：

• 规划阶段对推理能力要求高，用 GPT-4 或 Claude 这样的强模型，确保拆分质量；
• 执行阶段每一步的任务已经非常具体，用一个便宜的小模型（比如 GPT-4o-mini 或开源的 7B 模型）就完全够用。

这种「强模型规划、弱模型执行」的混合策略，在实际项目中可以把总成本降低 70% 到 90%，而任务完成质量几乎不受影响。原因很好理解：规划只调一次，花费有限；执行要调很多次，每次都用便宜模型，总成本就大幅下来了。

这也是 Plan-and-Execute 相比 ReAct 的一个隐藏优势——ReAct 每一步都是同一个模型又推理又执行，没法做这种差异化的模型分配。

3.3 优点与缺点

优点：

• 整体结构清晰，执行链路可控，复杂度很高的长流程任务也不容易跑偏；
• 识别出无依赖的步骤后可以并行执行，大幅降低整体耗时；
• 工程实践上，复杂多步任务的完成准确率通常高于 ReAct，因为有全局计划兜底。

缺点：

• 灵活度不如 ReAct，遇到计划外的情况容易卡住；
• 实现更复杂，需要分别维护规划模块和执行模块；
• token 消耗会增加（主要集中在规划与汇总阶段）。

适用场景： 流程长、复杂度高的任务，比如写完整的竞品分析报告、全流程的项目开发、多维度的行业调研。

3.4 现实中的产品例证：Cursor 的 Plan 模式

其实你身边就有 Plan-and-Execute 的工程化落地：Cursor 的 Plan 模式。它先调研代码库、形成一份可人工审阅的实现计划（虚拟文件形式），等你点击确认后再进入执行阶段；执行阶段还能让相互独立的步骤并行构建。它比教科书里的 Plan-and-Execute 多了一道人工审批闸门——不批准就不动手。这也说明设计范式落到真实产品里，往往会结合具体场景做增强。

---

4 Reflection：反思迭代范式

4.1 关键定位：它不是独立流程，而是「检查 buff」

这里有一个最容易搞错、也最容易被面试官追问的点：Reflection 不是一套独立的完整流程，而是给 ReAct、Plan-and-Execute 加的「锦上添花的 buff」。

它不改变原本的做事流程，只是在原本的基础上，加了一层「自我检查、自我修正」的环节：

• ReAct 就像你一道题一道题挨着做，做一道过一道，不回头看；
• Plan-and-Execute 是你先把整张卷子的做题顺序、时间分配定好，再按计划做题；
• Reflection 则是你做完一道题（或整张卷子），回头再检查一遍，看看有没有算错数、有没有看错题，发现错了马上改，改完再交卷。

它的核心循环，是在原本范式的基础上加了一个「生成 → 评估 → 改进」的闭环：设置一个独立的检查环节，判断当前输出有没有问题、达不达标，不达标就重试或调整策略，直到符合要求为止。

用伪代码表示，就是在外层套一个检查循环：

def with_reflection(run, check):
    result = run()                      # 先按原范式执行一遍
    while not check(result):            # 评估：达标了吗？
        feedback = analyze(result)      # 分析问题出在哪
        result = run(feedback)          # 改进：带着反馈重做
    return result

4.2 优点与缺点

优点： 输出质量明显提升，幻觉、逻辑错误、细节遗漏都会减少，对严谨性要求高的场景效果尤其明显。

缺点：

• 至少多一次 LLM 调用，token 消耗和延迟都会线性增加；
• 如果没有轮次限制，很容易陷入「为了改而改」的死循环——所以工程上一般设置最多反思 2 到 3 轮就够了。

适用场景： 对输出质量要求极高、不能出错的场景，比如写生产环境的代码、正式的商业报告、法律文书——但凡有错误就会出大问题的，都值得加上 Reflection。

一句话总结三者定位：前两者的核心是「把事做完」，Reflection 的核心是「把事做好」。

---

5 进阶机制：动态 Replan 与 Reflexion

5.1 动态 Replan：给 Plan-and-Execute 加「弹性」

Plan-and-Execute 最大的痛点就是：计划定死了，中途遇到意外怎么办？

比如你规划了五步来写竞品分析报告，执行到第三步发现某个竞品已经被收购了，原来的分析框架需要调整。但计划已经定好了，后面的步骤还是按老计划跑，输出的报告就会有问题。

动态 Replan 的做法是：在每个步骤执行完之后，把当前结果和剩余计划一起交给规划模块，让它判断「原来的计划还合理吗，需不需要调整」。如果需要，就生成一份新的剩余步骤计划，替换掉原来的。

这样既保留了 Plan-and-Execute「先规划再执行」的结构优势，又不会因为计划太僵硬而在意外情况下翻车。代价是每步都多了一次「重新评估计划」的 LLM 调用，token 消耗会增加。

5.2 Reflexion：把反思从「一次检查」升级成「错题本」

Reflexion 把 Reflection 的「自我反思」推到了更深的层次：

• 普通的 Reflection 是「做完了检查一遍、发现问题就重做」，有点像考试做完检查一遍；
• Reflexion 在此基础上多做了一件关键的事：它不只检查输出对不对，还会把每次失败的原因总结成一段「经验教训」，存进记忆里，下次再遇到类似任务时，这段教训会作为上下文传给 LLM，让它避免重蹈覆辙。

这就像你做错了一道数学题，不只是改答案，还会在错题本上写「这类题容易漏掉符号变化，下次要特别注意」，下次遇到同类题时翻一下错题本再动笔。

Reflexion 的效果在代码生成场景尤为显著：在 HumanEval 代码生成基准测试上，Reflexion 机制把 GPT-4 的 pass@1 准确率从 80% 提升到了 91%，提升了超过 10 个百分点。同样的基座模型，仅仅加了「反思 + 记住教训」这个机制，代码一次写对的概率就大幅提高。

背后的原因也好理解：代码生成天然适合 Reflexion——代码可以运行、可以测试，执行结果就是最直接的反馈信号。Agent 写完代码跑一遍测试，没通过就分析问题出在哪，把「这个 API 的参数顺序搞反了」「边界条件没处理」这样的具体教训记下来，下次重试时带着教训去改，成功率自然就高了。

这种「verbal reinforcement learning」（语言强化学习）的思路，让 Agent 不需要梯度更新就能从错误中学习，非常适合在推理阶段提升质量。

---

6 Token 消耗对比

三种范式在 token 消耗上的差异是选型时必须考虑的现实因素。用一个具体的例子直观感受一下：假设有一个需要 5 步工具调用的任务，每步产生的推理和工具结果平均占 2000 token。

ReAct： 每次调 LLM 都要把完整历史带上，第一步输入 2000 token，第二步 4000，第三步 6000……依次递增：

$$2000 + 4000 + 6000 + 8000 + 10000 = 30000 \text{ token}$$

增长曲线是线性的，步骤越多越吃钱。

Plan-and-Execute： 消耗集中在「规划」和「汇总」两个大头：

• 规划阶段调一次 LLM，输入是任务描述加工具列表，约 3000 token；
• 执行阶段每步只需带当前步骤的指令和前面步骤的结果摘要（不是完整的推理历史），每步约 1500 token，5 步共 7500 token；
• 汇总阶段再调一次 LLM，综合所有结果，约 4000 token。

总消耗约 14500 token，比 ReAct 的 30000 token 低了一半多。如果再用「强模型规划、弱模型执行」策略，执行阶段用便宜模型跑，实际花费还能再降 70% 以上。

加了 Reflection 之后： 每个需要反思的节点至少多一次 LLM 调用（评估一次，不达标还要重做），token 消耗会在基础范式上再增加 30% 到 100%，取决于反思的轮次和严格程度。如果一个步骤反思了两轮才通过，那这一步的消耗就翻了三倍。

所以实际项目的建议是：先用 ReAct 快速验证效果，确认任务能跑通之后，再根据 token 消耗和延迟的实际数据，决定要不要切换到 Plan-and-Execute 或者叠加 Reflection。不要一上来就选最复杂的方案，先跑起来再优化。

---

7 选型指南

7.1 选型口诀

把前面所有的分析浓缩成一句话选型逻辑：

任务特征	推荐范式
任务简单、流程不固定、需要实时调整	ReAct，够用就好
任务很长、容易跑偏、需要整体结构清晰	Plan-and-Execute
执行中经常遇到意外需要调整计划	在 Plan-and-Execute 上加动态 Replan
输出要求高、不能出错	在前两者基础上叠加 Reflection
需要跨任务积累经验、避免重复犯错	用 Reflexion 沉淀失败教训

7.2 三种范式的对比总结

维度	ReAct	Plan-and-Execute	Reflection
核心逻辑	思考 → 行动 → 观察，边想边干	先完整规划，再分步执行	生成 → 评估 → 改进
定位	基础范式（单步迭代）	基础范式（规划执行）	增强机制（buff），不能独立使用
解决的核心问题	单步行动的灵活度	长任务容易跑偏	输出质量不达标
优点	简单、灵活、逻辑透明	结构清晰、可并行、不易跑偏	减少幻觉和逻辑错误
缺点	长任务跑偏、易陷入无效循环	灵活度差、计划外卡住、实现复杂	多一次调用、token 与延迟增加
适用场景	信息搜索、问答助手、客服	竞品分析、项目开发、行业调研	生产代码、商业报告、法律文书

7.3 生产级的混合用法

实际项目中还有一种非常常见的混合用法：

规划阶段用 Plan-and-Execute 的思路定好全局计划，每一步的执行用 ReAct 的循环来处理（因为单步执行可能也需要多轮工具调用），最后对整体输出做一次 Reflection 检查质量。

这种三层嵌套的架构听起来复杂，但在 LangGraph 这类框架里实现起来很自然，很多生产级的 Agent 系统都是这么搭的。

7.4 最后一个忠告：别过度工程化

最容易踩的坑是：学了这些范式就全堆在一起——又要规划、又要反思、又要 Replan、又要积累经验，结果系统又复杂又慢，还容易出奇怪的 bug。

工程开发永远是「够用就好」：先把最基础的 ReAct 玩明白，再根据实际需求往上加，别为了炫技搞过度工程化。

---

参考

• 6. ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？ | 小林面试笔记

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。