做 Agent 开发绕不开一个选型问题：任务来了，是让模型边想边做（ReAct），还是先出一份完整计划再照着执行（Plan & Execute）？这两个模式各有死穴，选错轻则效率低，重则任务整个跑偏。先把两者的脾气摸清楚。
两个失败的开场，引出正确姿势
理解 ReAct 的价值，最快的办法是看两个反例。
纯推理不调工具：模型凭参数里的旧知识回答"北京今天晴，15度"，实际上外面沙尘暴——幻觉就是这么来的，模型在用统计记忆冒充实时事实。
纯行动不动脑：模型确实查了天气，也查到了"沙尘暴、不适合户外"，下一步却照旧推荐公园——工具返回的事实摆在眼前，推理链断了照样犯蠢。
把"想"和"做"交替进行，就是 ReAct：思考、行动、观察，循环往复直到给出答案。
它的优势有三个——根据观察实时调整、执行轨迹可追溯、工具返回的真实数据能压住幻觉。代价是每一步都要过一次模型，串行执行慢，而且步数不可控，任务复杂了容易在原地打转。
Plan & Execute：先画图，后施工
规划器先产出一份多步骤计划，执行器按序落地，中途触发重规划。
它的长处正好补 ReAct 的短：全局计划像图纸一样防跑偏，无依赖的步骤可以并行（查三个标的行情同时发出去，比串行快三倍），规划阶段集中推理、执行阶段多为固定的工具调用，整体成本更低。
短板同样明显：异常分支弱。计划里没写的意外，执行器不知道怎么处理；计划本身错了，后面全错。所以成熟的做法是混合架构——Plan & Execute 定主干，执行器局部自治用 ReAct 处理突发，不惊动全局规划。
Reflection：自己给自己当审稿人
第三个模式思路不同，它不解决"做什么"，解决"做得好不好"。生成初稿后，让模型按既定原则批判自己的输出，再据此修订，循环一到三轮。
要小心一个反直觉现象：模型批改自己的输出，有时会把错误也一起强化——它对同一份答案的判断并不独立，第二轮很可能只是把第一轮换个说法。所以 Reflection 想真起作用，必须引入外部锚点：代码就跑一遍测试，事实陈述就做核查，格式要求就用程序校验。反思循环的质量取决于锚点的客观程度，而不是反思的轮数。轮数也别贪多，超过三轮基本只剩成本没有收益。
三种模式的选择题
| 维度 | ReAct | Plan & Execute | Reflection |
|---|---|---|---|
| 核心 | 想-做-看循环 | 先规划后执行 | 生成-批判-修订 |
| 擅长 | 动态、结果不可预知的任务 | 步骤清晰的高确定任务 | 对输出质量要求高的场景 |
| 依赖 | 工具反馈的质量 | 计划质量 | 外部校验锚点 |
| 主要风险 | 循环打转 | 计划错全盘错 | 自我强化、成本翻倍 |
选型口诀：看确定性。步骤清晰、工具固定，用 Plan & Execute 省钱省时；环境动态、需要边做边看，用 ReAct；质量敏感的任务在前两者外面再套一层 Reflection。三者不互斥，生产系统里常见组合是"Plan 定框架 + ReAct 干活 + Reflection 收尾"。
上线后用什么指标验证模式选对了
模式不是选完就完，要用数据验证：
- ReAct：盯轨迹步数和工具命中率。同一任务的历史平均步数突然上涨，通常是提示词或工具描述被改坏了；
- Plan & Execute：盯重规划触发率。触发率持续偏高说明规划器产出的计划质量不行，该升级规划模型而不是调执行器；
- Reflection：盯迭代收益曲线。第二轮修订后的质量提升应该显著，第三轮之后曲线走平甚至下降，说明该砍轮数了。
另外给几个时效性提醒：OpenAI 早期的 Swarm 实验库已并入官方 Agents SDK，新项目别再基于 Swarm 起步；OpenAI 的 Assistants API 也已进入退役通道，官方主推 Responses API 加 Agents SDK 的组合，老项目迁移要排上日程。框架榜单月月在变，模式本身却很稳定——把三种模式的适用边界刻进脑子里，比追逐任何一个具体框架都保值。
评论0