Agent 架构的四种模式：ReAct、Plan-Execute、反思与多 Agent

先看结论：选型只看两个维度

模式	适合	典型失败
单次调用 + 工具	1~2 步，结果可验证	几乎不会失败
ReAct（边想边做）	3~8 步，路径不确定	循环、走偏
Plan-Execute（先规划后执行）	步骤多且可预知	计划过时、一步错步步错
多 Agent	任务可分解给不同专长	成本爆炸、互相甩锅

判断依据：任务需要几步？每一步的结果能不能预知？

步数少 + 能预知 → 单次调用
步数中 + 不能预知 → ReAct
步数多 + 能预知 → Plan-Execute
任务本身有多个独立子领域 → 多 Agent（最后才考虑）

一、单次调用 + 工具（别跳过这层）

很多人直接上 Agent 框架，其实大部分需求用「一次请求 + 几个工具」就够了。

用户问题 → 模型判断调哪个工具 → 执行 → 模型组织答案

适用：查订单、算税费、格式转换、单表查询。

它失败的时候才是 Agent 的起点——如果你发现需要「根据上一次结果决定下一步」，才进入 ReAct。

二、ReAct：Thought → Action → Observation

核心是一个循环，每轮模型输出三部分：

Thought: 我需要先查用户的订单列表
Action: query_orders(user_id="U1")
Observation: [{"order_id":"A1","status":"shipped"}, ...]
Thought: 用户问的是 A1 的物流，现在查物流
Action: query_logistics(order_id="A1")
Observation: {"carrier":"SF","eta":"2026-10-29"}
Thought: 信息齐了，可以回答
Final: 你的包裹由顺丰承运，预计 10 月 29 日送达。

优点：灵活，能处理预设不了的分支。
缺点（三个都得防）：

循环：反复调同一工具 → 必须设最大步数 + 检测「相同 action 重复 N 次」
走偏：越走越远 → 每步加一个「是否仍在解决原问题」的自检
幻觉观测：把没拿到的东西当成拿到了 → 严格用工具返回值，禁止推断

关键实现点：把 Observation 原样塞回上下文，不要让模型"复述"结果（复述会失真）。

三、Plan-Execute：先出计划，再逐步执行

两阶段：

阶段一：Planner 输出步骤列表（含每步的输入输出与验证条件）
阶段二：Executor 逐步执行，每步完成后校验；不符则触发重规划

优点：可控、可审计、可人工干预（计划给人看一眼再执行）。
缺点：计划基于假设，现实一变就失效。

所以 Plan-Execute 必须配一个重规划触发器：

如果满足任一条件 → 回到 Planner 重新规划
- 某步验证失败 2 次
- 工具返回的数据与计划假设冲突
- 已完成步数 > 计划的 1.5 倍

什么时候明显优于 ReAct：报告生成、数据迁移、批量处理——步骤数固定，跑偏的代价高。

四、反思（Reflection）：让模型自己挑错

在输出前加一轮自检：

第一轮：生成答案
第二轮：给定「答案 + 验证标准」，让模型找自己的问题
第三轮：根据问题修订

有效场景：代码生成（跑测试）、数学计算（代回验算）、结构化输出（schema 校验）。

注意：反思对有客观验证标准的任务有效；对主观任务（文案、创意）经常越改越差。而且每一轮都是一次完整调用，成本翻倍——只在关键路径用。

五、多 Agent：最后才考虑

三种常见形态：

形态	结构	适用
编排者-工人	主 Agent 拆任务分给子 Agent	子任务可并行、互不依赖
流水线	A 的产出是 B 的输入	阶段清晰（调研→写作→审校）
辩论	多 Agent 给不同意见再裁决	需要降低单点偏差

代价要提前算清：

token 成本通常是单 Agent 的 3~10 倍（重复读上下文）
上下文传递会丢信息（子 Agent 不知道全局约束）
出了错难定位是哪个 Agent 的问题
延迟显著上升

经验法则：单 Agent + 好工具能解决 80% 的问题。多 Agent 只在「子任务确实需要不同工具集/不同提示词/长时间独立运行」时才值得。

六、一张选型决策图

任务需要几步？
├─ 1~2 步 → 单次调用 + 工具
└─ 3+ 步
   ├─ 步骤能预先确定？
   │   ├─ 能 → Plan-Execute（+ 重规划触发器）
   │   └─ 不能 → ReAct（+ 最大步数 + 重复检测）
   └─ 子任务之间有本质差异？（不同工具/不同角色/可并行）
       └─ 是 → 多 Agent（先算成本）

七、四个通用工程约束（不管用哪种模式）

最大步数上限：任何循环都必须有硬上限，默认 8 步
工具调用全量日志：输入、输出、耗时、错误都要留，否则无法排查
不可逆操作前置确认：删除、支付、外发消息必须有人工确认或二次校验
降级路径：模型不可用时给用户什么？「转人工」比报错好得多