ReAct、Plan-and-Execute 与 Reflection

一句话理解：ReAct 是“想一步、做一步、看结果”，Plan-and-Execute 是“先列完整计划再逐项执行”，Reflection 是“做完回头检查、总结教训再改”。现代 Agent 通常把三者组合使用。

上一课讲了 Agent Loop 的骨架。骨架相同，每一轮“怎么思考”却可以很不一样：有的 Agent 每看到一个结果就重新决定下一步；有的先花时间把整件事规划清楚，再按部就班执行；有的做完之后会停下来检查、反思，再修正。

这三种思路都来自有代表性的研究工作。了解它们，你就能看懂不同 Agent 产品的行为差异，也能在设计时有意识地选择：这个场景要的是灵活应变、全局规划，还是反复打磨？

ReAct：推理与行动交替进行

ReAct 出自 2022 年发表的论文《ReAct: Synergizing Reasoning and Acting in Language Models》（Yao 等，发表于 ICLR 2023）。它的核心想法是：让模型交替输出推理和行动，而不是先想完再做，或者只做不想。

在这之前，有两条相对独立的路线：一条让模型先写出一长串推理再给答案（思维链），但推理过程中接触不到外部信息，容易一本正经地编造；另一条让模型直接输出行动，但没有推理过程，难以处理多步任务。ReAct 把两者交织在一起：

问题：上周华东区销售额为什么下降？

Thought 1：先确认下降幅度，以及是否集中在某个品类。
Action 1：query_sales(region="华东", week="W37", group_by="category")
Observation 1：总体 -18%；饮料 -52%，其余品类基本持平。

Thought 2：问题集中在饮料。看看是销量下降还是价格下降，以及是不是缺货。
Action 2：query_inventory(region="华东", category="饮料", week="W37")
Observation 2：主力 SKU 在 W37 有 4 天库存为 0。

Thought 3：缺货能解释大部分下降。确认缺货原因。
Action 3：query_purchase_orders(sku="主力 SKU", weeks=["W36", "W37"])
Observation 3：供应商交付延期 6 天。

Thought 4：证据链完整，可以下结论。
Final：华东销售额下降 18%，主要原因是饮料主力 SKU 因供应商延期缺货 4 天……

论文在知识问答（HotpotQA）和事实核查（Fever）任务中让模型调用维基百科接口，减少了纯推理时的幻觉和错误传递；在两个交互式决策基准上，ReAct 只用一两个示例，成功率就比当时的模仿学习和强化学习方法分别高出 34 和 10 个百分点。

优点：每一步都基于最新观察，遇到意外情况能立即调整；推理过程可读，方便排查。缺点：每一步都要调用一次模型，长任务的成本和延迟较高；缺少全局视角，容易在局部绕圈子，或者忘记最初的目标。

今天大多数基于工具调用的 Agent，其循环形态都与 ReAct 一脉相承：模型根据上一步的结果决定下一次调用什么工具。只是“Thought”不一定以文本形式显式输出，可能在模型的内部推理中完成。

三条路线的差别可以这样对照：

图 1 · ReAct 让推理与行动交替：每次思考都建立在最新的观察之上

Plan-and-Execute：先规划，再执行

这一思路的代表之一是 2023 年的 Plan-and-Solve 提示方法（Wang 等，发表于 ACL 2023）：先让模型制定计划，把整个任务拆成若干子任务，再逐个完成。LangChain 在 2024 年的一篇文章中把它发展成 Agent 架构，并介绍了几种变体：

图 2 · Plan-and-Execute：大模型只在规划与重规划时出场，执行可以交给更便宜的执行器

基本版：规划器生成多步计划，执行器逐步完成，结束后可以重新规划。
ReWOO：计划中的步骤可以引用前面步骤的结果（比如用变量表示“第 2 步查到的 SKU”），执行时不必每步都回到规划器。
LLMCompiler：计划以任务依赖图的形式输出，没有依赖关系的任务并行执行。

优点：大模型只在规划和重新规划时出场，执行可以交给更小的模型甚至普通代码，速度更快、成本更低；先整体思考一遍，不容易遗漏；计划本身可以展示给用户确认。缺点：计划基于开始时的信息，执行中发现新情况时，计划可能已经过时，需要重新规划的机制；对探索性强、一开始就不知道要查什么的任务，事先规划的价值有限。

适合 Plan-and-Execute 的例子：对一个站点的 200 个页面做 SEO 诊断。步骤清楚（抓取、检查、汇总、排序），而且大部分可以并行。

Reflection：回头检查，从反馈中改进

Reflection 类方法关注的是：做完之后，怎么变得更好？ 两个有代表性的工作：

Self-Refine（Madaan 等，2023）：同一个模型先生成初稿，再给自己的初稿写反馈，然后根据反馈修改，如此循环。不需要额外训练。论文在七类任务上报告了平均约 20 个百分点的绝对提升。

Reflexion（Shinn 等，2023）：Agent 在一次尝试失败后，用文字总结“哪里做错了、下次该怎么做”，把这段反思存进记忆，下一次尝试时带上。相当于用语言而不是模型参数更新来“强化学习”。论文报告在 HumanEval 代码基准上达到 91% 的 pass@1。

图 3 · Reflexion：用文字总结教训并带入下一次尝试

这里有一个对产品设计非常关键的细节：反思的质量高度依赖反馈信号的质量。 Reflexion 在代码任务上效果突出，一个重要原因是有测试结果这种客观反馈。如果没有外部信号，只让模型“再检查一遍自己的答案”，它很可能发现不了自己的错误，甚至把对的改成错的。模型自评与外部验证的可靠性差异，见「自我检查与外部验证」。

三者对比与组合

维度	ReAct	Plan-and-Execute	Reflection
核心问题	下一步做什么？	整件事分几步做？	做得怎么样，怎么改进？
决策时机	每一步	开始时，必要时重新规划	一次尝试或一个阶段结束后
擅长	探索性、需要随机应变的任务	步骤可预见、可并行的任务	有清晰评价标准或客观反馈的任务
主要风险	局部绕圈、成本高	计划过时、对意外反应慢	没有外部信号时自我确认偏差
典型例子	客服工单排查	200 个页面的 SEO 诊断	Coding Agent 根据测试结果修复

真实产品很少只用一种。以一个典型的 Coding Agent 处理复杂需求为例：

图 4 · 真实产品通常组合使用：Plan 定方向，ReAct 走每一步，Reflect 把关结果

常见误区

“ReAct 已经过时了。” 具体的提示格式在演变，但“根据观察决定下一步行动”的循环结构，仍然是绝大多数工具型 Agent 的基础。
“先规划一定比边做边想好。” 规划的价值取决于任务在开始时有多少是可知的。排查未知故障时，第一步查到什么决定了第二步查什么，事先的详细计划可能毫无用处。
“加一步反思，质量就会提升。” 没有外部反馈的反思，效果有限，还会增加成本。先确认有什么客观信号可以用来反思。

设计要点

判断任务是“开始时就基本可知”还是“边查边知”，据此选择规划的深度。
使用 Plan-and-Execute 时，必须设计重新规划的触发条件。
使用 Reflection 时，优先接入外部反馈（测试、校验脚本、数据核对），并限制反思轮数。
把推理或计划以适当的形式展示给用户，这既方便排查问题，也能建立信任，参见「计划与进度」。

练习

用同一个任务体验三种范式（约 50 分钟）：

任务：让 Agent 分析一份销售 CSV（可以自己构造 3 个区域、5 个品类、8 周的数据，并埋入一个缺货导致的下滑）。
分别用三种指令运行：
- ReAct 风格：“每一步先说明你的判断，再执行一个分析动作，根据结果决定下一步。”
- Plan-and-Execute 风格：“先列出完整的分析计划，等我确认后再按计划执行。”
- 加入 Reflection：“给出结论后，用原始数据逐条核对每个结论，发现问题就修正。”
对比三次运行的步数、是否找到埋入的原因、结论是否有数据支持，写下你的观察。

下一步

下一课「规划与任务拆解」深入 Plan 这一侧：Todo 列表、计划模式、任务拆解的好坏标准，以及什么时候应该重新规划。

ReAct、Plan-and-Execute 与 Reflection