同一个模型，同一套工具，只是把「循环」换一种写法，任务成功率能差出一大截。
ReAct、Plan-Execute、Reflexion 这三个词最近被并列讲得很多，但它们其实不在一个层面上：一个管「下一步做什么」，一个管「整条活怎么排」，一个管「做完发现不对怎么办」。混着看，选型一定选错。这篇把三者摆到同一张桌面上，按任务类型给一个能直接对照的判据。
先分清层次，再谈选哪个
很多人第一次看到这三个名字，会以为是三选一的竞品。不是。
- ReAct 是最里面的那一层循环：模型想一步（Thought）→ 决定调哪个工具（Action）→ 拿到结果（Observation）→ 再想下一步。它解决的是「每一步依赖上一步结果」的探索型任务。
- Plan-Execute 是外面那一层调度：先把整件事拆成一份计划，再逐条执行。它解决的是「步骤基本独立、但要控制成本和时间」的长任务。
- Reflexion 是质检层：它不改任务怎么走，而是让 agent 回头批判自己的输出、记下失败原因，再带着这个教训重试一次。它通常叠在 ReAct 之上，而不是取代 ReAct。
一句话：ReAct 是内循环，Plan-Execute 是外编排，Reflexion 是复盘。生产里常见的组合是「外编排 + 内循环 + 复盘」，不是三选一。
ReAct：默认起手式，但不是万能
ReAct 的循环是 Thought / Action / Observation 三步转圈，好处是每一步都用上一步的真实结果兜底，不容易凭空编。
我会建议先用它起手，还有个现实原因：主流框架的默认路径就是 ReAct 形状 。比如 OpenAI Agents SDK 的执行模型本身就是一个 run loop------调一次模型、执行一次工具、重复到出结果；LangGraph 里官方文档给出的标准起点，也是那个预置的 create_react_agent。也就是说，选 ReAct，你基本是在走「已经铺好的路」。
但它的短板也很明确：
- 长任务里容易绕圈。步数一多，模型会反复在两个相邻的工具之间横跳，token 很快烧掉，而且不一定收敛。
- 没有全局视角。它只看得见「当前这一步最该干什么」，看不见「整件事还剩多少」。
- 确定性差。同样的输入，两次跑的路径可能完全不同，做压测时很难复现。
所以 ReAct 更适合短、探索型、每步强依赖的任务，比如「查一个报错→读日志→定位到某个文件→再看下一处」。
Plan-Execute：长任务的成本可控，但代价是你得自己搭
Plan-Execute 的思路正好相反：先让模型产出一份「要做哪几件事」的计划，然后一条一条执行；执行中发现跑不通，再回来改计划（replan）。
它最值钱的地方是成本可预测：因为任务被拆成了有限条计划步骤，你能在「计划条数」这个维度上给长任务封顶，而不是听凭模型无限次调用工具。
但这里有个坑，很多教程不会提前说：在 LangGraph 里，plan-and-execute 不是预置件，它是官方给你的一份「照着自己搭」的教程图。也就是说，你选它，就得自己维护计划的数据结构、步骤之间的依赖关系、执行器的分发，以及什么时候触发重排。这些编排代码全是你的，出 bug 也得你自己查。
反过来看，这条路也不是冷门。Anthropic 那篇讲 agent 设计的文章里主推的 orchestrator-workers 模式，结构上就是 plan-and-execute：一个主管先分工，几个 worker 各干一段。LangGraph 那份 deep agents 参考实现，走的也是「plan-execute 主管 + 子图当 worker」的骨架。
一句话判据：步骤基本独立、能提前拆、且你在意花费和时长 → 上 Plan-Execute；否则先用 ReAct。
Reflexion：让它在交卷前自己批一遍
ReAct 有个反直觉的失败方式：它会很有底气地给你一个错答案。工具返回的数据含含糊糊时，纯 ReAct 往往第一次就给出结果，而且看着毫无异常。
Reflexion 就是在最后加一道自检：让 agent 评价自己的输出，指出「哪一步的证据不足」，把这条反思存下来，再带着它重试。很多团队的「生产级单 agent 栈」，其实就是 ReAct + Reflexion------内层照常用 ReAct 探索，外层加一层复盘的把关。
代价是延迟和成本都会上升，因为它至少要多跑一轮「自评 + 重试」。所以它更适合「错了代价很大」的场景，不适合追求单次响应速度的场合。
一张表：按任务类型对号入座
| 你的任务长什么样 | 建议架构 | 理由 |
|---|---|---|
| 短、探索型，每步依赖上一步的结果 | ReAct | 走框架默认路径，最快能跑通 |
| 步骤基本独立、能提前列出来、你在意成本 | Plan-Execute | 用「计划条数」给长任务封顶 |
| 工具返回的数据不可靠、答错代价高 | ReAct + Reflexion | 交卷前多一道自检 |
| 大任务可拆成多个小任务并行 | Plan-Execute + 子任务 worker | 主管分工、worker 各跑各的 |
| 只是想验证一个想法 | ReAct | 别一上来就搭编排，先跑通再说 |
三个最容易踩的坑
第一个：拿 ReAct 硬扛长任务。 表现是步数暴涨、成本失控、还经常绕回来。这不是模型不行，是循环形状选错了。
第二个：计划一旦错，后面全错。 Plan-Execute 的第一份计划如果方向偏了，后面每一步都在错误的地基上执行。所以计划出来后要有一步人工或规则校验，别让它直接开跑。
第三个：把自评当成万能保险。 Reflexion 靠的是模型自己的判断，它有可能「自我说服」------把本来错的结论解释成对的。自评能拦住一部分错误，但它不是测试，替代不了真实的验证用例。
选型前可以先问自己这 4 句
- 这个任务的每一步，是不是都依赖上一步的真实结果？是 → ReAct
- 我能不能在动手前，把整件事拆成一份有限的计划清单？能 → 考虑 Plan-Execute
- 这个任务答错的代价，值不值得多花一轮自评和重试？值 → 加 Reflexion
- 我是不是在用重编排，解决一个其实很短的探索任务？是 → 换回 ReAct
顺序上也建议别急：先用 ReAct 把链路跑通，确认工具可靠，再考虑要不要加层。 一上来就搭一套完整的编排框架，多数时候是把简单问题复杂化------先能跑，再谈稳。