读 Agent 相关资料时，你一定反复见过这三个词：ReAct、Plan-and-Execute、Reflection。它们经常被并列罗列，好像是三个竞争方案，但实际上它们回答的是三个不同的问题：下一步做什么（ReAct）、整件事怎么安排（Plan-Execute）、做完了对不对（Reflection）。理解了这一点，选型就不再纠结——成熟的 Agent 往往三者叠着用。
这篇文章用同一个任务「调研三款向量数据库并输出对比报告」贯穿演示三种模式，讲清各自的机制、代价和适用场景。
三种模式不是三选一：ReAct 管单步决策，Plan-Execute 管全局安排，Reflection 管质量兜底。
ReAct：边想边做的单步循环
ReAct（Reasoning + Acting，出自 2022 年 Yao 等人的论文）是最基础也是使用最广的模式：模型在每一步先输出推理（Thought），再决定动作（Action），拿到工具返回的观察（Observation）后进入下一轮，直到判断任务完成。
Thought: 需要先了解有哪些主流向量数据库
Action: search("主流向量数据库对比 2026")
Observation: [Milvus, Qdrant, Weaviate, pgvector ...]
Thought: 先查 Milvus 的部署方式和性能数据
Action: read_url("https://milvus.io/docs/...")
Observation: ...
...
Thought: 信息足够了，开始撰写对比报告
Final Answer: ...优点：实现简单，灵活性最高——每一步都基于最新观察决策，遇到意外（页面打不开、结果为空）能立刻改道。今天几乎所有支持工具调用的模型 API，原生的多轮 tool use 循环就是 ReAct 的工程化形态。
缺点：目光短浅。它只看眼前一步，没有全局观，长任务里容易走弯路、来回横跳、在某个死胡同里反复尝试；每步都携带全部历史，上下文和成本随步数线性膨胀。适合 10 步以内、路径不确定的探索型任务。
Plan-and-Execute：先谋后动
Plan-Execute 把「规划」和「执行」拆开：先让模型（通常用最强的模型）把任务分解成有依赖关系的子任务清单，再逐项执行（执行器可以是 ReAct 循环，甚至是更便宜的小模型），执行中可以按需重新规划（Replan）。
Plan:
1. 确定评测维度（性能、部署、生态、成本）
2. 分别调研 Milvus / Qdrant / pgvector ← 三项可并行
3. 汇总数据，生成对比表
4. 撰写结论与选型建议
Execute: 按清单逐项跑，每项内部是小型 ReAct 循环
Replan: 若某项失败或发现新信息 → 更新剩余计划优点：全局性好，长任务不迷路；计划本身就是进度条，用户能看到「做到第几步」；无依赖的子任务可以并行，快且省；计划还是天然的审批点——先给人看计划、确认后再执行，这正是上一篇讲任务边界推荐的安全设计。
缺点：计划赶不上变化——初始计划建立在对任务的想象上，执行中发现前提不成立就要 Replan，Replan 逻辑写不好会退化成「反复重排计划却不干活」；简单任务套计划纯属浪费。适合 10 步以上、结构可预判的复合任务。Claude Code 的 Plan Mode、各类 Deep Research 产品都是这个模式的落地。
Reflection：做完自查再改
Reflection 关注的不是「怎么做」，而是「做得对不对」：产出初稿后，由模型审视结果（可以是同一个模型换一个「批评者」提示词，也可以是另一个模型），指出问题，然后带着批评意见修改，循环一到两轮。
Draft: 生成对比报告 v1
Critique: “性能数据没有标注来源；pgvector 部分缺少规模上限讨论；
结论与表格数据有一处矛盾”
Revise: 针对三条意见修改 → 报告 v2
Check: 批评者确认问题已解决 → 输出优点：对产出质量的提升立竿见影，尤其是代码（跑测试、看报错、自我修复就是 Reflection 的自然形态）、长文写作、数据核对这类「有明确质量标准」的任务。批评者拿着 checklist 审查，比生成时「一次做对」容易得多。
缺点：成本翻倍起步（每轮多一次审查一次修改）；对没有明确标准的任务，模型会陷入「自我表扬」或者反复改而不收敛，所以必须设最大轮数（通常 1–2 轮），并尽量给批评者外部信号——测试结果、编译报错、检索证据，而不是纯靠感觉互评。
Reflection 最有效的场景是有外部信号可依据的任务：测试通过与否、报错信息、数据是否对得上。
三种模式怎么组合
把三者放进同一张表：
| 模式 | 回答的问题 | 成本 | 典型场景 |
|---|---|---|---|
| ReAct | 下一步做什么 | 低 | 短探索任务、工具问答 |
| Plan-Execute | 全局怎么安排 | 中 | 长任务、多子任务、需审批 |
| Reflection | 结果对不对 | 高（翻倍） | 代码、报告、高准确性要求 |
实践中的组合套路：
- 简单问答 + 一两次工具调用：裸 ReAct 就够，别过度设计；
- 中长任务：Plan-Execute 做骨架，每个子任务内部用 ReAct 执行；
- 质量敏感的产出（代码、对外报告）：在最后一步加 Reflection，优先用测试、编译、校验脚本这类硬信号驱动；
- 预算敏感：规划用强模型，执行用便宜模型，审查看任务价值决定要不要加——配合模型路由能省下可观成本。
LangGraph、LlamaIndex Workflows 等框架里，这三种模式都有现成模板；自己手写的话，Plan-Execute 只是「先让模型输出 JSON 计划再循环执行」，没有想象中复杂。
成熟 Agent 的常见形态：计划做骨架、ReAct 做执行、Reflection 做质检。
适用人群与常见坑
适合正在设计 Agent 架构、或想看懂各框架文档里这些术语的开发者。三个高频坑提醒：
- 给短任务上 Plan-Execute：五步能完成的事，规划环节比执行还贵，延迟还高。先用 ReAct 跑，发现迷路了再升级。
- Reflection 不设轮数上限：模型互相「再改改」能改到天荒地老。1–2 轮封顶，改不好就交给人。
- 把模式当银弹：模式解决的是控制流问题，工具质量、提示词、上下文管理不行，什么模式都救不了。Agent 失败的更多原因见《AI Agent 为什么容易失控》。
常见问题
Q：Multi-Agent（多智能体）和这三种模式什么关系？ A：正交关系。Multi-Agent 是把子任务分给多个角色执行，每个角色内部照样跑 ReAct/Reflection。多数场景下，一个规划得当的单 Agent 比一群互相开会的 Agent 更可控也更便宜——先把单 Agent 做好。
Q：推理模型（o 系列、DeepSeek-R1 这类）还需要这些模式吗？ A：推理模型把一部分「Thought」内化到了模型内部，简单任务确实可以少一层显式规划。但工具调用的循环结构、执行边界、结果校验仍然需要在工程层实现，模式并没有过时。
Q：从哪个开始学？ A：ReAct。亲手写一个「模型 + 两个工具」的循环（百行代码以内），把日志打全，你对另外两种模式的理解会自然长出来。可以参考《从 0 搭一个 AI Agent》。
小结
ReAct、Plan-Execute、Reflection 不是三个流派，而是 Agent 的三块积木：单步决策、全局规划、质量自查。选型口诀：短任务 ReAct，长任务加计划，重要产出加自查，并且永远给循环设上限。理解积木之后，各种框架的花名（Plan-and-Solve、LATS、Self-Refine……）都只是这三块的变体和组合。