很多讲 Agent 的文章，都会把 ReAct、Plan-and-Execute、Reflexion、Self-Consistency、Critic-Refine、Router、Fixed Workflow 一股脑摆在一起。
这很容易让人产生错觉：这些模式彼此互斥、处在同一层级，只需要从中选一个。
但真正做系统时，很快就会发现并不是这样。
- ReAct 和 Reflexion 可以叠加
- Router 和 Fixed Workflow 可以组合
- Self-Consistency 甚至可以包在不同执行器外面
这篇文章想解决的，正是这个混乱：把这些常见模式放进同一张认知地图里，看清它们各自所处的位置。
🎯 核心观点：这些模式并不是同层替代关系，而是分布在不同层级。先看清层级，再谈选型和组合。
一、为什么需要一张「推理模式谱系图」
不少 Agent 入门文章喜欢把各种模式并排介绍，然后告诉你：这是几种主流方案，可以任选其一。
这种写法最大的问题，是会带来三个常见误解：
- 误解一：把 ReAct 和 Plan-and-Execute 理解成「简单版 vs 高级版」
- 误解二：把 Reflexion 当成 ReAct 的替代品
- 误解三：觉得用了 ReAct，就不再需要 Fixed Workflow
但现实并非如此。这些模式往往不在同一个维度里。
硬把它们放在一起比较，就像问「分诊台和手术室哪个更高级」一样------它们压根不是一类东西。
所以，我们需要的不是一张普通的对比表，而是一张 谱系图（Genealogy Map）：
- 每个模式属于哪一层
- 它解决的是什么问题
- 它和谁是同类
- 它又能和谁组合
只有先建立这张图，后面的设计判断才会清晰。
二、三层谱系总览：Agent 推理的认知骨架
Agent 在做动态决策时，本质上在回答三个不同的问题：
| 层级 | 回答的问题 | 典型模式 | 类比 |
|---|---|---|---|
| 🧭 路由层 Routing | 这个任务该走哪条路？ | Router / Classifier | 医院分诊台 |
| ⚙️ 执行层 Execution | 进入路径后，具体怎么推进？ | Fixed Workflow / ReAct / Plan-and-Execute | 科室内的诊疗流程 |
| 🔍 优化层 Optimization | 结果够不够好，要不要修？ | Reflexion / Critic-Refine / Self-Consistency | 复核医生 |
这三层是 递进关系，不是并列关系：
- 先路由，再执行，最后优化
- 某一层可以不存在：只有一条链路时，不需要 Router；流程足够稳定时，也未必需要优化层
- 最容易混淆的，是把 执行层的 ReAct 和 优化层的 Reflexion 当成同级方案
💡 记住这句话：ReAct、Reflexion、Router 不是三选一，它们甚至不在同一层。
三、第一层：路由层 Routing ------ 先决定走哪条路
它回答什么问题
当系统里同时存在多种任务类型或多条专门化链路时，怎样把任务分发到最合适的那一条？
路由层本质上是一个 轻量分类决策层：
- 输入是任务描述
- 输出是标签或目标链路
- 下游再根据这个结果进入对应流程
它的职责很单纯：只负责选路，不负责执行。
三个直观类比
- 交换机 vs 水管：交换机只决定流量走哪个端口，不处理具体内容
- 分诊台 vs 科室：分诊决定你去哪里，真正治疗发生在科室内
- 导航选路线 vs 开车上路：选路和执行，是两件事
为什么这层经常被低估
📌 很多人学完 ReAct 后，会不自觉地觉得：既然模型能动态决策，那所有任务都该交给它自由发挥。
但在真实系统里，大量任务只需要先被正确分类，然后进入一条稳定流程即可。
真正有效的动态，不是每一步都动态，而是只在需要动态的地方动态。
什么时候不需要 Router
- 系统里本来就只有一条执行链
- 任务类型高度一致
- 分类本身已经需要复杂多步推理
最后一种情况尤其值得注意：如果"分类"本身已经很复杂，那它就不再只是路由问题，而进入了执行层。
四、第二层：执行层 Execution ------ ReAct 与 Plan-and-Execute 的本质区别
进入某条路径后，任务要怎样一步步推进，就是执行层要解决的问题。
执行层的三种典型策略
scss
┌──────────────────────────────────────┐
│ 执行层策略谱系 │
├──────────────────────────────────────┤
│ 1. Fixed Workflow ------ 写死的流水线 │
│ 2. ReAct ------ 走一步看一步 │
│ 3. Plan-and-Execute ------ 先规划再执行 │
└──────────────────────────────────────┘4.1 Fixed Workflow：并不是「没有推理」
有一些文章会把 Fixed Workflow 讲成一种"老旧方案"，仿佛它意味着系统不够智能。这个理解并不准确。
Fixed Workflow 写死的是 编排路径，不是节点内部的推理能力：
- 每个节点仍然可以调用模型进行局部判断
- 固定的是节点之间的连接方式
- 它适合流程稳定、输入结构清晰、异常边界相对可控的场景
在生产环境里，大量环节其实就应该是 Fixed Workflow。只有当路径本身确实需要临场判断时，才有必要引入更高的动态性。
4.2 ReAct：边想边做
ReAct（Reasoning + Acting）把"决定下一步要做什么"的过程显式展开：
erlang
Thought → Action → Observation → Thought → Action → ...🧩 你平时在通用 AI 产品里看到的「正在搜索...」「正在读取网页...」「正在分析...」，背后往往就是类似 ReAct 的循环。
模型先决定下一步动作，拿到结果后，再根据新信息继续往下推进。
ReAct 的核心特征有四点：
- 决策粒度细：每一步只决定下一步动作
- 灵活性高：能根据中间结果即时调整方向
- 可观测性强：执行过程便于追踪和调试
- 适合探索型任务：尤其适合中间结果会显著影响后续路径的场景
4.3 Plan-and-Execute：先规划，再落地
如果说 ReAct 是"走一步看一步"，那 Plan-and-Execute 更像"先画路线图，再按图执行"。
它通常分成两个阶段：
- Planner：先产出整体计划
- Executor：再按照计划逐步执行
这种拆分的工程价值很明显：
- 规划阶段可以用更强的模型
- 执行阶段可以降级到更轻量的模型
- 因而更容易控制成本
当然，计划不可能永远完美，所以它通常还需要一个 Replan 机制：
当执行中发现原计划失效时，把当前状态和剩余目标重新交给 Planner，再生成新的方案。
4.4 两者的本质分歧：局部决策 vs 全局规划
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 决策时机 | 每一步都重新决策 | 开始时先做整体规划 |
| 决策视野 | 聚焦下一步 | 关注整体结构 |
| 模型成本 | 大模型持续参与 | 规划重，执行可降级 |
| 类比 | 每到路口再看地图 | 出发前先规划整条路线 |
4.5 一个实用判断标准
当你犹豫该用 ReAct 还是 Plan-and-Execute 时，可以先问自己：
下一步的决策，是否必须依赖上一步的具体结果？
- 如果必须依赖：更适合 ReAct
- 如果大体可以提前安排：更适合 Plan-and-Execute
- 如果流程本身已经足够稳定：那你可能根本不需要两者，Fixed Workflow 就够了
⚠️ ReAct 和 Plan-and-Execute 都只解决执行层的问题。
它们不负责"该走哪条链"，也不负责"结果要不要返工"。
把路由、执行、优化混为一谈，是很多设计混乱的根源。
五、第三层：优化层 Optimization ------ 做完以后，要不要回头检查
执行层有一个共同特点：默认任务一旦完成，就直接返回结果。
但现实中的问题是：
- 前后可能不一致
- 关键点可能遗漏
- 结论可能偏题
- 表达也可能不够好
优化层的作用，就是在执行完成后补上一轮 复核、修订或增强稳定性 的机制。
5.1 Reflexion：整体评估，再带着反思重跑
Reflexion 通常包裹在执行链外层，形成一个"做完---评估---必要时重跑"的闭环。
它通常包含三个角色：
- Actor：真正执行任务的 Agent
- Evaluator：评估输出是否达标
- Reflector：提炼失败原因，形成可操作的反思
流程大致是：
评估不过关 → 生成反思 → Actor 带着反思再次执行。
🧠 Reflexion 不是另一种执行方式，而是一层执行后的优化机制。
所以它不会替代 ReAct 或 Plan-and-Execute，而是可以叠加在这些执行器之上。
你日常和模型交互时，其实也经常在手动做这件事：
第一轮先让模型输出结果；看完后指出"你漏了行动项""结构还不清楚"；第二轮结果往往就更好。把这个人工反馈过程自动化，基本就是 Reflexion 的思路。
5.2 Critic-Refine：局部修订，而不是整链重跑
Reflexion 很强，但也更贵，因为它常常意味着整条链重跑。
如果执行过程本身基本可信，只是最终结果还有局部问题，那更经济的办法是 Critic-Refine：
- Critic：指出问题点
- Refine：只修改有问题的部分
它适合：
- 结论没错，但表达不够清晰
- 结构基本完整，但个别段落需要润色
- 输出已接近可用，只差最后一轮修订
5.3 Self-Consistency：多次独立推理，再做投票
第三种优化思路并不是"修"，而是"比"：
让模型独立推理多次，再根据多数结果做聚合或投票。
它利用的是一个常见现象：
对于有相对明确答案的任务，多次独立推理后的多数结果，通常比单次输出更稳。
常见适用场景：
- 分类判断
- 风险评级
- 冲突检测
- 相对明确的打分任务
不太适合的场景：
- 长篇开放式写作
- 创意内容生成
- 高度主观的表达任务
因为在这些场景里，投票往往会削弱表达的完整性和风格。
5.4 三种优化策略对比
| 策略 | 修订粒度 | 成本 | 适用任务 |
|---|---|---|---|
| Reflexion | 整链重跑 | 高 | 执行过程本身可能出错 |
| Critic-Refine | 局部修订 | 中 | 过程可信，但结果需要打磨 |
| Self-Consistency | 并行投票 | 中 | 有较明确答案的判断任务 |
六、把三层合起来看：Agent 系统的常见组合
把三层叠起来，一个完整的 Agent 系统通常长这样：
css
用户输入
↓
[ 路由层 ] ← 选择是否分流
↓
[ 执行层 ] ← 选择执行策略
↓
[ 优化层 ] ← 选择是否复核或修订
↓
最终输出
不同任务，对应的组合方式也不同：
| 组合类型 | 路由层 | 执行层 | 优化层 | 适合场景 |
|---|---|---|---|---|
| 稳健型 | Router | Fixed Workflow | Critic-Refine | 多类型稳定任务 + 成品打磨 |
| 探索型 | --- | ReAct | Reflexion | 任务模糊、需要试错 |
| 批量型 | Router | Plan-and-Execute | Critic-Refine | 多任务编排与统一汇总 |
| 判定型 | --- | Fixed / ReAct | Self-Consistency | 分类、评分、风险判断 |
三条组合原则
- 不是三选一，而是分层选策略
- 某一层可以留空：不是每个系统都需要 Router 或优化层
- 层级职责要清晰：选路、执行、复核，最好不要混在一起
⚠️ 要特别警惕一种常见问题：过度动态化。
如果你把每一层都交给高自由度的动态决策，系统往往会变得不可预测、难以调试，成本也会迅速上升。
动态是一种能力，也是一种代价。 只在真正有必要的地方使用，通常才是更好的设计。
七、从谱系图回到设计实践
这张谱系图最重要的价值，不是帮你记住几个名词，而是帮你在设计 Agent 时问对问题。
启示一：先分层，再选模式
面对一个任务，先问三个问题：
- 我需不需要先分流？
- 执行过程应该固定，还是允许临场调整？
- 输出结果要不要复核、修订或增强稳定性？
这三个问题想清楚之后，选型通常不会太难。
启示二：默认从稳定方案开始，再逐步引入动态能力
一个很实用的原则是：
- 能用 Fixed Workflow，就先别上 ReAct
- 能用 Critic-Refine，就先别上 Reflexion
- 能用单链路，就先别上 Router
动态能力不是"越多越先进"，而是"越精准越有效"。
启示三：模式更像叠加关系，而不是替代关系
这是整张图最关键的洞察。
当你再看到"用 ReAct 替代 Fixed Workflow""用 Reflexion 替代 Plan-and-Execute"这类说法时，先别急着接受，先问一句：
它们真的在同一层吗？
部分概念的争议，一旦放回层级框架里，往往会立刻变得清楚。
启示四：让每一层都能独立替换
更好的系统设计，通常具备这样的可替换性：
- 换一个 Router，不影响下游执行器
- 换一个执行器，不影响优化层
- 增加一种优化机制，不需要重写主链路
这意味着系统的演进可以沿着层级逐步展开，而不是牵一发而动全身。
启示五：真正的智能，往往发生在路径级
很多人理解 Agent 智能时，容易把重点放在"某一步推理多聪明"。
但在实际系统里，更关键的往往是：
- 有没有走对链路
- 有没有在合适的时机切换策略
- 有没有在输出前做必要的复核
单步很聪明，不一定代表系统整体可靠；路径判断正确，往往更重要。
八、结论：推理模式不是互相替代，而是可以分层叠加
回到文章开头的问题：为什么这些模式总让人觉得杂乱？
答案是：因为它们原本就分布在不同层。
- 路由层决定任务进入哪条路径
- 执行层决定任务如何推进
- 优化层决定结果是否需要再检查和修订
当你把 ReAct、Plan-and-Execute、Reflexion、Critic-Refine、Self-Consistency、Router、Fixed Workflow 放回这三层框架里，就会发现：
它们不是互相排斥，而是各有位置，也各有组合空间。
这张谱系图真正的意义，不是让你背下几个术语，而是提供一张可复用的认知地图。
以后再遇到新的模式时，你可以更快判断：
- 它属于哪一层
- 它解决什么问题
- 它适合替换谁
- 它又可以和谁叠加
✨ 一句话总结：
好的 Agent 设计，不是堆最多的模式，而是在合适的层级，用合适的模式。
写在最后 🧪
这里是言萧凡的 AI 编程实验室 。 我会在这里持续记录和分享 AI 工具、编程实践 ，以及那些值得沉淀下来的高效工作方法。 不只聊概念，也尽量分享能直接上手、能够复用的经验。 希望这间小小的实验室，能陪你一起探索、实践和成长。2026 年，一起进步。
有兴趣的话可以添加我的微信号一起交流，不仅是编程也可以是畅谈人生
延伸阅读
如果你想更系统地理解 AI Agent 如何从概念走向可落地的产品实践，可以看看我在掘金小册新上架的《AI Agents 开发实践》。
你会在书里看到一个产品怎样从第一行代码逐步长成完整系统：架构怎么决策，抽象在哪里引入，性能瓶颈在哪里出现，安全边界在哪里划定，以及多个 Agent 怎么分工又怎么协调。