先给结论
这三种 Agent 范式并非三选一的并列关系，而是主体二选一外加一个可选增强层。在实际场景中，选型标准主要取决于任务步数、环境反馈速度以及失败成本。
当任务步数少且环境反馈快，例如简单的查资料或单点工具调用，选择 ReAct 靠灵活纠偏完成。面对复杂查询或多文件改动等多步长任务，选择 Plan-and-Execute 以保持方向稳定。若任务对质量高度敏感且具备自动验证条件，例如代码生成后用测试验证再修改，则在主体上叠加 Reflection 机制。
逐项对比
| 维度 | ReAct | Plan-and-Execute | Reflection |
|---|---|---|---|
| 定位 | 逐步循环架构 | 规划执行架构 | 执行后的增强层 |
| 强项 | 灵活，每步基于新观察纠偏 | 方向稳定，计划可审计，子任务可并行 | 执行后自我批评再修正 |
| 弱项 | 上下文随步数膨胀，长任务易发散 | 对环境突变的响应慢，改计划要显式触发 | 增加延迟 |
| 典型场景 | 步数少、环境反馈快的任务（查资料、单点工具调用） | 多步长任务（复杂查询、多文件改动） | 对质量敏感且可自动验证的任务（代码生成后用测试自检再改） |
| 成本 | 随步数增加的上下文开销 | 显式重规划的开销 | token 翻倍与延迟 |
ReAct 的核心在于走一步看一步，将思考、行动和观察组合成逐步循环。这种设计的优势是灵活，允许模型根据每步的新观察结果进行纠偏。但劣势同样明显，上下文会随着执行步数快速膨胀，处理长任务易发生发散。因此，它适合环境反馈及时且步骤简短的任务。
Plan-and-Execute 采用先出完整计划再逐步执行的策略。预先生成的计划让任务方向保持稳定，过程具备可审计性，独立的子任务甚至能并行处理。其局限在于对环境突变的响应较慢，一旦需要修改计划，必须显式触发重规划。它天然适合方向明确的多步长任务。
Reflection 是执行后自我批评再修正的增强层，通常叠加在前两者之上。它的引入如同给任务增加检验工序，必然会造成 token 消耗翻倍与整体响应延迟。但在代码生成后用测试自检再修改这类场景里，这种代价换取了质量保障，是合理的权衡。
面试怎么答
面试遇到此问题，切忌直接抛出具体方案，应先向面试官确认业务场景，主动询问任务预期步数、环境反馈速度及对失败成本的容忍度。获取前置条件后，再输出技术结论。
常见的错误答法是将三者视为平行选项做三选一。正确的答题框架是先定主体——明确短任务选 ReAct，长任务选 Plan-and-Execute；最后补充增强项——若任务对质量敏感且具备自动验证条件，则叠加 Reflection 机制。这能展现对架构层级的准确理解。