Agent 架构模式——ReAct、Plan-and-Execute、Reflection 三大范式实战对比
Agent 架构模式——ReAct、Plan-and-Execute、Reflection 三大范式实战对比
同样是 Agent,”边想边做”、”先想再做”、”做后再想”——三种架构差别巨大。选错了成本能差 3 倍。
三种架构的核心区别
ReAct(边想边做)
1 | 思考 1 → 行动 1 → 观察 1 → 思考 2 → 行动 2 → ... → 结束 |
特点:每一步都基于上一步的结果,强适应性。
Plan-and-Execute(先想再做)
1 | 计划 → 行动 1 → 行动 2 → ... → 行动 N → 总结 |
特点:先一次性规划好所有步骤,强一致性。
Reflection(做后再想)
1 | 行动 → 反思 → 改进行动 → 反思 → ... → 结束 |
特点:每次行动后都”复盘”,强改进能力。
ReAct 深度解析
工作流程
1 | class ReActAgent: |
优点
- 自适应强:每步根据结果调整
- 实现简单:循环 + Prompt 即可
- LangChain 原生支持:AgentExecutor 默认就是 ReAct
缺点
- 容易走偏:模型可能陷入”反复调同一工具”的死循环
- Token 消耗大:每步都要重新生成思考
- 缺乏全局规划:只看眼前,不看长远
Plan-and-Execute 深度解析
工作流程
1 | class PlanExecuteAgent: |
优点
- Token 效率高:计划一次生成,不每步重算
- 可解释性强:用户能看到完整计划
- 可以用小模型执行:只要 plan 准,执行可以便宜
缺点
- 计划可能错:如果第一步规划错了,后面全错
- 不适应变化:中途环境变了,计划不调整
- 实现复杂:需要单独的 planner + executor
Reflection 深度解析
工作流程
1 | class ReflectionAgent: |
优点
- 自我改进:失败会”反思原因”,下次做得更好
- 适合代码/SQL 生成:有明确对错,反思有效
缺点
- 成本极高:每次失败重做 + 反思,3 倍 Token
- 依赖评估能力:模型要能”判断对错”
- 不适用主观任务:写诗、写文章没法”反思”
三种架构的实测对比
我做了个测试——让三个 Agent 完成同一组任务:
任务集:
- 查询”上海到北京明天的高铁”
- 分析一份财报并写摘要
- 写一个 Python 排序函数
- 规划一次 3 天旅游行程
- 多步调试一个 bug
| 任务 | ReAct | Plan-Execute | Reflection |
|---|---|---|---|
| 1. 简单查询 | ⭐⭐⭐⭐⭐ 快准 | ⭐⭐⭐ 慢一点 | ⭐⭐ 太重 |
| 2. 财报分析 | ⭐⭐⭐ 走偏 | ⭐⭐⭐⭐⭐ 清晰 | ⭐⭐⭐⭐ 不断改 |
| 3. 排序函数 | ⭐⭐ 反复试 | ⭐⭐⭐ 一般 | ⭐⭐⭐⭐⭐ 改到对 |
| 4. 旅游行程 | ⭐⭐⭐⭐ 不错 | ⭐⭐⭐⭐⭐ 完整 | ⭐⭐ 反复改 |
| 5. 多步调试 | ⭐⭐⭐⭐ 自适应 | ⭐⭐ 卡住 | ⭐⭐⭐⭐⭐ 越改越好 |
结论
没有”最好”,只有”最适合”:
- 简单任务 → ReAct
- 需要规划感 → Plan-and-Execute
- 代码生成/调试 → Reflection
- 长流程多步 → Plan-and-Execute
混合架构:生产系统的选择
实际项目里,很少用纯一种架构。更常见的是混合:
模式 1:Plan-and-Execute + Reflection
1 | Planner 制定计划 |
模式 2:ReAct + Plan-and-Execute
1 | Planner 制定大框架 |
模式 3:Plan-Execute + 动态重规划
1 | Planner 制定初始计划 |
真实系统的 Agent 架构,通常是这样”嵌套+循环”的复杂结构。
我的项目实战经验
项目 1:客服 Agent
用 ReAct——简单多步对话,ReAct 最合适。
效果:80% 任务 3 步内解决,平均 1500 Token/对话。
项目 2:研究助手
用 Plan-and-Execute——需要”先列大纲,再填充”。
效果:用户能看到完整研究计划,可解释性强。
项目 3:代码生成 Agent
用 Reflection——代码有”对错”,反思有效。
效果:首轮成功率 65%,反思后达 88%。
写在最后
Agent 架构没有”银弹”——不同任务需要不同架构。
选架构的核心原则:
- 看任务类型:简单多步 vs 复杂规划 vs 反复改进
- 看成本预算:Reflection 是 3 倍 Token,生产要算账
- 看可解释性:用户能看到 Agent 的”思考过程”很重要
- 看维护成本:架构越复杂,后期维护越难
最好的 Agent 架构,是”用最简单的架构解决 80% 的问题,剩下 20% 才用复杂架构”。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 高晓庄 札记!
