Agent Execution Patterns

四种 Agent 范式 · 一眼看懂

这四种范式的差别，本质是「流程图的形状」不一样——一个反复转圈、一个一条直线走到底、一个在外面套了一圈、一个分叉出去再收回来。
下面用同一个任务把四种走法各跑一遍，形状差异就自己跳出来了。

同一个任务

线上订单接口的 P99 延迟从 200ms 涨到 3 秒，找出原因并给出处理方案。
可用工具：查监控指标、查日志、查数据库慢查询、看最近发布记录。

先搞清楚：这四个东西，和 Agent 是什么关系

很多人第一眼会觉得「ReAct 的图，和之前讲 Agent 时那张图一模一样」。
确实一样——因为它们根本不在同一个维度上。

Agent（一个整体） LLM 大脑 无状态 买来的 + Harness（你写的那部分） 工具集 记忆 护栏 停止条件 上下文管理 Loop ← 让它转起来的那个 while 循环 循环怎么走 ↓ 就是下面四种范式 ReAct Plan-and-Execute Reflection Multi-Agent
概念回答什么问题属于哪一层
Agent = LLM + Harness一个 agent 由什么构成组成
Agent Loop这些部件怎么转起来机制
ReAct / Plan-and-Execute / …循环的每一轮具体怎么走范式

打个比方：Agent 是「车」，ReAct 是「后驱」。
问「Agent 和 ReAct 有什么区别」，就像问「汽车和后驱有什么区别」——后驱是汽车的一种驱动方式，不是它的对立面。

下面四种范式全都是 agent，全都符合 LLM + Harness。它们的差别只在一处：Harness 里那段控制流怎么写。

1

ReAct

形状：一个小圈，反复转

思考 → 行动 → 观察结果 → 再思考。每一步都取决于上一步真实看到了什么。

任务 思考 下一步查什么 行动 调一个工具 观察 结果回灌上下文 还不够 → 再来一轮 够了 给出结论 轮数不固定 可能 3 轮 也可能 30 轮
这个任务它会怎么走
  1. 思考：延迟涨了，先看是全部接口还是单个接口 → 行动：查监控 → 观察：只有订单接口涨了
  2. 思考：单接口问题，可能是代码或数据库 → 行动：查发布记录 → 观察：两小时前发过版
  3. 思考：时间对得上，看那次改了什么 → 行动：查慢查询 → 观察：一条新 SQL 没走索引
  4. 够了 → 结论：某次发布引入的 SQL 缺索引，建议加索引或回滚 （走了 3 轮）
适合

执行路径事先不确定，需要边做边根据证据修正方向。
排障、调研、探索性任务。

代价

灵活，但每一轮都要把全部历史再发一遍 → Token 高。轮数不定，成本不可预估，出问题要看整段轨迹才知道哪步歪的，调试难。

一个容易被忽略的历史包袱

今天大多数号称「ReAct agent」的东西，并不是原论文的 ReAct。

ReAct 论文是 2022 年的，那时候还没有 function calling。模型不会结构化地调工具，只能靠提示词逼它把思考过程用文本写出来，再用正则把动作抠出来执行：

Thought: 我需要先查一下监控
Action: search_metrics[order_api_p99]
Observation: P99 从 200ms 涨到 3000ms
Thought: 确认是这个接口，接着查发布记录

现在模型直接返回结构化的 tool_calls，根本不需要它输出 “Thought:” 这种文本了。所以你今天写的那个循环，准确叫法是 function-calling loop——形状和 ReAct 一样，实现机制完全不同。

面试时能说出这个区分，是加分项。

2

Plan-and-Execute

形状：一条直线，前面挂个计划

先把整个计划列全，然后一步一步照着做完。中途不改计划。

任务 规划 一次列出 全部步骤 ① 查监控指标 ② 查发布记录 ③ 查慢查询 ④ 查依赖服务 计划定死了，照单执行 汇总结论 重新规划（可选，且很弱） 步数固定 成本可预估
这个任务它会怎么走
  1. 规划：一次性列出四步——查监控、查发布、查慢查询、查依赖服务
  2. 照单执行 ①②③④，中途不管查到什么，四步都要走完
  3. 把四份结果一起交给模型，汇总出结论
  4. 注意：第 ② 步就已经查出问题了，但 ③④ 照跑不误——这是它的固有浪费
适合

任务很长、步骤多，但依赖关系明确。有全局计划就不容易跑偏、不容易在中途迷路。

代价

动态调整能力弱——计划一旦定下，中途发现方向错了也拐不了弯。
本质上已经很接近静态工作流了，只是计划由模型生成而已。

3

Reflection

形状：在外面套了一圈

先出一版，再自己挑毛病，然后改。它不单独用，是叠在前面两种之上的。

Reflection 这一圈套在外面 任务 生成一版答案 内核可以是 ReAct 自我批评 哪里站不住？ 够好 了吗 否 → 带着批评重写 是 输出
这个任务它会怎么走
  1. 内核（比如用 ReAct）先跑一遍，得出结论：「是那条新 SQL 没走索引」
  2. 自我批评：证据够吗？只看了慢查询，没验证「加了索引延迟真的会降」，也没排除是流量突增
  3. 带着批评重写：补查流量曲线、补看索引预估收益
  4. 再批评一次 → 这次挑不出硬伤 → 输出 （多花了一倍 Token，但结论扎实多了）
适合

质量要求高、且允许多轮迭代的场景。代表工作：Reflexion、Self-Refine、CRITIC。

代价

它是叠加项，不单独用——外面这一圈里必须先塞一个能干活的范式。
每多一轮反思，成本翻一倍；而且必须设死迭代上限，否则会陷入无限打磨。

4

Multi-Agent

形状：分叉出去，再收回来

按职责拆成几个独立角色，各干各的，最后汇总。

任务 协调者 拆任务 · 派活 排查 Agent 找根因 方案 Agent 出处理方案 验收 Agent 挑毛病、把关 汇总交付 每个角色内部，自己还可以是 ReAct 或 Plan-and-Execute
这个任务它会怎么走
  1. 协调者把任务拆成三份：找根因、出方案、做验收
  2. 排查 Agent 查监控和日志，定位到那条 SQL
  3. 方案 Agent 拿到根因，给出「加联合索引 + 灰度验证」的方案
  4. 验收 Agent 挑毛病：「没说加索引期间会不会锁表」→ 打回补充
  5. 协调者汇总三方产出，交付 （职责清晰，但三个角色之间来回传消息的成本不低）
适合

任务能拆成规划、执行、验收这类彼此独立的职责。各角色上下文互不干扰，不会互相污染。

代价

通信和调试成本翻倍。出了问题要先定位是哪个角色错的，再看是不是消息传丢了。
角色之间的上下文交接是最容易出 bug 的地方。

放一起看

按「谁决定下一步」排序——从模型说了算，到人说了算。

范式形状谁决定下一步适合代价
ReAct 小圈反复转 模型，每轮现场定 路径不确定，要边做边改方向 Token 高、轮数不定、调试难
Plan-and-Execute 一条直线 模型定一次，之后不再改 任务长、步骤多但依赖明确 动态调整弱，接近静态工作流
Reflection 外面套一圈 叠加在前两者之上 质量要求高、允许多轮迭代 成本翻倍，必须设迭代上限
Multi-Agent 分叉再汇合 协调者派活，各角色内部自决 职责能拆开、上下文需要隔离 通信和调试成本翻倍

它们不是四选一。Reflection 本来就是叠加项；Multi-Agent 里每个角色内部，多半还是跑着 ReAct 或 Plan-and-Execute。

真实系统常见的组合是：外层用 Plan-and-Execute 定骨架保证不跑偏，叶子节点用 ReAct 保证能应变，关键产出上再套一层 Reflection 把关。

选型只问一句话：这个任务的下一步，该由代码写死，还是让模型现场决定？写死的越多越可控、越便宜；交给模型的越多越灵活、越贵。