Agent 设计模式：ReAct、Plan-Execute、Reflection 该选哪个

你不是模型不行，是 scaffold 不行

2026 年了，一个反复被验证的事实是：同一个 LLM，套不同的 agent 架构，行为可以差到不像同一个模型。GPT-5.5、Claude Opus 4.7、Gemini 3.5 Pro 各有强弱，但比模型差异更大的，是你给它套的那层 scaffold。

这篇文章把 2026 年实战中被验证有效的几个 agent 模式拎出来对比：ReAct、Plan-and-Execute、Reflection、Tree-of-Thoughts、Supervisor-Workers。每一个我们讲清楚它解决什么问题、什么时候选它、什么时候千万别选它。

一、ReAct：最普及，也最容易翻车

核心思想：模型每一步交替"思考（Thought）“和"行动（Action）”，根据观察（Observation）决定下一步。

Thought: 用户问的是 RouterHub 上排名前 5 的 AI 中转站
Action: search_sites(rank_top=5)
Observation: [...返回 5 个站点...]
Thought: 我需要拿到每个站点的可用模型列表
Action: get_models(site="apiplus")
...

优点：

实现极简，几十行代码就能跑
链路可解释，每一步都看得见
对单一明确任务表现稳定

缺点：

长链路下"飘"得厉害，第 5 步开始忘记最初目标
错误传播严重：一个 tool 失败，后面整条链可能跑歪
token 消耗随步数线性增长，成本不可控

典型适用：

单步或 2-3 步的明确任务
工具集 < 10 个
错误代价低（信息检索类）

典型不适用：

需要规划的多步任务（“重构这个模块并补全测试”）
涉及破坏性操作（删除、转账）
深度多跳推理

实测数据：在公开多步任务基准上，直接 ReAct 的成功率约 62%，平均成本 $0.011/任务。这个数据后面会被 Plan-Execute 反复对比。

二、Plan-and-Execute：把规划和执行解耦

核心思想：先用一个 planner LLM 一次性产出完整的步骤计划，再用 executor 逐步执行（执行可以是另一个更小、更便宜的模型，甚至是确定性脚本）。

[Planner @ Claude Opus]
1. 从 RouterHub 拉取 top-5 站点
2. 对每个站点查询模型列表
3. 统计模型出现频次
4. 输出 markdown 表格

[Executor @ Haiku / 确定性脚本]
按顺序执行，遇到错误则上报给 planner 重新规划

优点：

规划阶段一次性完成，避免 ReAct 的逐步漂移
执行阶段可以用便宜模型，整体成本骤降
计划清晰可审、可重放，调试体验好得多

缺点：

实现复杂度高
计划不能动态调整（变种 Re-Plan 模式可以，但又复杂一层）
对 planner 的能力要求高，弱模型规划质量差

实测数据：同样的多步任务基准上，结构化的 plan-then-execute（也叫 Plan-Compiler 模式）能拿到 92.67% 成功率，单任务成本 $0.00128——比 ReAct 准 30 个百分点，便宜 8 倍。

典型适用：

任务步骤可预先列出（数据迁移、批量处理、报表生成）
同类任务高频执行（定时调度、批量审批）
错误代价高，需要审批环节

陷阱：开发者容易把所有任务都套 plan-execute，结果对动态环境（实时对话、需要看反馈才能继续的任务）反而不灵活。

三、Reflection：让模型自我审视

核心思想：在 ReAct 或 Plan-Execute 的输出后再加一层 LLM，让它检查上一步输出是否符合质量要求。如果不合格，回到前一步重做。

[Generator] 写一段代码
[Reflector] 这段代码有没有空指针风险？性能怎么样？
[Generator] 根据反馈改写

优点：

在不换模型的情况下显著提升输出质量
对代码生成、文案撰写这种需要"打磨"的任务效果显著

缺点：

至少 double 调用次数，成本和延迟翻倍
反思深度难定，太浅没用，太深陷入死循环

经验阈值：reflection 最多 2-3 轮，超过基本就是 LLM 在跟自己空转。

典型适用：

代码生成
长文档写作
数学推理
任何"质量比速度更重要"的场景

四、Tree-of-Thoughts：并行探索多条路径

核心思想：不是线性走一条思路，而是同时展开多个候选，用一个评估器打分，剪枝、回溯。

优点：

对组合优化、搜索类问题（数独、24 点、规划问题）表现突出
跳出局部最优

缺点：

成本爆炸：每多一层 branching factor 翻倍
实现复杂，调参困难
对 99% 业务任务都过度

直白建议：除非你做的是科研、规划、组合搜索，不然别碰。生产里能用 ToT 的场景比能用强化学习的还少。

五、Supervisor-Workers：多 agent 协作

核心思想：一个 supervisor agent 负责接收任务、分派子任务给若干 worker agent、收集结果、最终合成。

[Supervisor]
"分析这家公司的财报"
   │
   ├─→ [Researcher Agent] 拉取公开数据
   ├─→ [Analyst Agent] 计算财务指标
   └─→ [Writer Agent] 撰写报告
   │
[Supervisor] 合成最终交付

优点：

每个 worker 可以用专门的 prompt、工具集、模型
并行执行，缩短端到端延迟
隔离失败：一个 worker 挂掉不会污染整体

缺点：

工程复杂度最高
跨 agent 上下文同步是难点
总 token 用量比单 agent 高 30-100%

典型适用：

大型分析任务
多领域协作（research + writing + verification）
需要专业化的工具/权限隔离

六、模式对比表

模式	实现复杂度	多步任务成功率	单任务成本	适用规模
ReAct	低	~62%	$0.011	1-3 步
Plan-Execute	中	~93%	$0.0013	3-20 步
Reflection	中	提升 5-15pp	2x 基线	任意
ToT	高	任务相关	5-20x 基线	搜索类
Supervisor-Workers	极高	任务相关	1.3-2x 基线	跨领域大任务

数据来源于 2026 年公开技术报告的实测综合，具体数值会因任务、模型、prompt 工程水平不同而浮动。

七、实战决策树

任务复杂度？
├─ 1-2 步、单一目标
│   └─ ReAct 直接干
├─ 3-10 步、可预先规划
│   ├─ 一次性任务 → Plan-Execute
│   └─ 高频同类 → Plan-Execute + 缓存计划模板
├─ 需要质量精修
│   └─ 上层模式 + Reflection（最多 2 轮）
├─ 需要跨领域协作
│   └─ Supervisor-Workers
└─ 搜索/组合优化
    └─ ToT（确定不是别的方案能搞定的）

绝大多数业务场景的最优解是Plan-Execute + 必要时加一轮 Reflection。ReAct 是 demo 友好但生产脆弱，Supervisor-Workers 是 demo 炫但工程门槛高。

八、Plan-Execute 的工程化要点

既然 Plan-Execute 是大多数场景的最优解，多花点篇幅讲讲怎么落地。

8.1 Planner 的输出 schema

不要让 planner 写自由文本，强制结构化：

{
  "goal": "...",
  "steps": [
    {
      "id": 1,
      "tool": "search_sites",
      "args": {"rank_top": 5},
      "depends_on": [],
      "retryable": true
    },
    {
      "id": 2,
      "tool": "get_models",
      "args": {"site": "${step_1.results[i].slug}"},
      "depends_on": [1],
      "retryable": true
    }
  ]
}

依赖关系显式，让执行器能并行处理无依赖步骤。

8.2 Executor 的失败策略

每一步都要明确 3 个问题：

重试几次？（建议 2-3 次，指数退避）
失败时降级还是回 planner？
部分成功怎么处理？（继续后续？回滚？告警？）

8.3 Re-Plan 触发条件

什么时候需要 planner 重新规划：

某步失败超过重试上限
中间结果与计划假设严重不符（用一个小模型做事实校验）
用户中途插入新需求

Re-Plan 不能无限触发，建议总次数 ≤ 2，超过就把控制权交还给人类。

8.4 计划模板化

同类任务（“每天爬一次某站点的模型列表”）不要每次都让 planner 重新生成计划。把第一次的计划缓存为模板，下次直接套用，不再调用昂贵的 planner LLM。这一招让 plan-execute 的成本降到 ReAct 的 1/8。

九、总结

如果你正在写 agent 业务，最容易踩的两个坑：

沉迷 ReAct：跑通 demo 觉得真香，上生产被多步任务打回原形
过度框架化：上来就搭多 agent supervisor，工程量爆炸，结果一个 plan-execute 就够用

我的建议是按"ReAct（验证可行）→ Plan-Execute（工程化）→ 必要时局部 Reflection / 多 agent"的顺序演进，每一步都对应业务真实增长，而不是技术想象。

最后一个反直觉提示：最可靠的 agent 模式是"半自治"——cron 任务触发确定性脚本，脚本里在需要判断的节点 call 一次 LLM，LLM 只负责"决策"而不负责"执行"。这种架构看着不性感，但生产稳定性远高于全自动 agent。

参考资料

“Agentic AI Design Patterns in 2026” by innovatrixinfotech
“Separating Plan Generation from Execution” tianpan.co
“What Are Agentic Design Patterns?” by augmentcode
“LLM Agent Architectures 2026” by futureagi
“Reliable execution loops” by breyta.ai
“Make Your AI Agent Reliable Without a Token Budget Burn” by roborhythms
arxiv 2509.08646 “A Guide to Secure Plan-then-Execute Implementations”

Agent 设计模式：ReAct、Plan-Execute、Reflection 该选哪个

正文

你不是模型不行，是 scaffold 不行

一、ReAct：最普及，也最容易翻车

二、Plan-and-Execute：把规划和执行解耦

三、Reflection：让模型自我审视

四、Tree-of-Thoughts：并行探索多条路径

五、Supervisor-Workers：多 agent 协作

六、模式对比表

七、实战决策树

八、Plan-Execute 的工程化要点

8.1 Planner 的输出 schema

8.2 Executor 的失败策略

8.3 Re-Plan 触发条件

8.4 计划模板化

九、总结

参考资料

相关阅读