ReAct、Reflection、规划执行：Agent三种常见思路怎么选？
这三个词不是三套神秘的框架，而是三种很朴素的Agent做事方式：
- ReAct:边想边做，看一步走一步
- Reflection:做完回头看，发现问题再改
- 规划执行:先拆解任务，再按照计划推进
Agent本质是一个循环
一个Agent最基本的循环是：
看到目标->想下一步->调用工具->看结果->再想下一步
不是一次性给答案，而是每一步都根据上一步结果继续判断
所以这三者本质上都是在回答同一个问题：
Agent到底应该怎么推进任务，只是推进任务不同
ReAct：边思考、边行动、边观察
ReAct是Agent里面最经典的一种思路
它的名字来自两个词：
- Reasoning ：推理，先想清楚下一步为什么要这么做
- Acting：行动，调用工具或者执行动作
但是这两个词还不够，ReAct真正关键的是中间还有一个Observation
也就是工具执行后的观察结果
一个典型的ReAct循环长这样：
- Thought:我现在需要知道什么
- Action：我要调用哪个工具
- Observation：工具返回来什么
- Thought：根据结果，我下一步应该做啥
它不要求一开始就把完整计划想完，而是每拿到一个结果，再决定下一步
这就是为什么ReAct特别适合工具调用的场景
因为真实的环境里面，你一开始根本不知道问题在哪里
你只能查一步看一步，再决定下一步
ReAct的一些细节
三大细节
-
你是否理解工具调用不是一次性的
- 真正的agent可能要调用很多次工具，而且每次调用什么工具，要看上一步的结果
-
你是否理解Observation的重要性
- 没有Observation，模型就是在脑补，工具返回什么、返回是否为空、返回是否异常，都会影响下一步
-
你是否知道ReAct也会翻车
- ReAct不是万能的，它最大的问题是容易跑散
- 因为每一步都动态决策，如果没有约束，Agent很容易：
- 查着查着忘了原始目标
- 一直调用无关工具
- 在失败结果里反复重试
- 明明信息够了，还继续查
ReAct适合路径不确定的任务，但必须配合步数限制、工具权限、状态记录和停止条件
Reflection：不是让模型自嗨，而是让它检查结果
Reflection翻译过来叫反思
核心不是一句提示词，而是给Agent一个明确的检查环节
比如Agent写完一段SQL ，不要直接交付
让它回头检查：
- 字段有没有写错
- WHERE条件有没有漏
- 是否会全表扫描
- 返回结果是否符合用户目标
再比如Agent生成一份问题分析报告，也不要直接交付
让它检查：
- 结论有没有证据支撑
- 是否遗漏关键时间点
- 是否把相关性当成因果
- 建议是否能落地
这才是Reflection
他不是让模型"感觉自己更认真"，而是让模型按照标准检查输出
Reflection适合解决什么问题？
结果容易有格式错误
比如结构化输出、SQL、配置文件、接口参数
模型第一次生成很可能看起来对，但是细节错误
这时候加一个检查环节，能拦住很多低级问题
任务有明确验收标准
比如：
- 单测是否通过
- JSON是否符合Schema
- SQL是否能执行
- 报告是否包含指定字段
没有标准，只让模型"反思一下"，它很容易给你一段漂亮废话
Agent容易过早交付
很多Agent的问题不是不会做，而是做了一半就开始总结
Reflection可以在交付前加一道门：
当前结果是否已经满足用户目标？如果不满足，还缺什么证据？是否需要继续调用工具
如果模型本身不知道正确答案长什么样，他反思十遍也没用
规划执行：先拆解任务，再推进
先让模型根据用户目标生成一个计划
然后按照机会一步一步执行
规划执行的优点是：任务有方向，不容易一开始就跑偏
规划执行最大的问题：计划跟不上变化
规划执行不是万能的，最大的问题是：一开始的计划不一定对
而是先有大方向，执行中根据结果调整计划
我们不会让Agent生成一个计划后机械执行到底，而是把计划当做可以更新的任务清单。每完成一步，都记录状态和证据，如果发现假设不成立，就重新规划后续步骤