Skip to main content

除了 ReAct还有哪些 Agent 工作模式？各自的优缺点是什么？

· 7 min read

ReAct 是默认范式但不是唯一解——选错工作模式比选错模型更致命。

  1. Function Calling：无推理链的直接工具调用，延迟最低，仅适合单步任务。
  2. Plan-and-Execute：先规划全局再逐步执行，长任务完成率高 2-3 倍，但无法动态调整。
  3. Reflection：生成 → 批评 → 修正循环，能自纠低级错误，代价是每轮多烧一倍 token。
  4. Multi-Agent：多 Agent 分工或辩论，适合复杂任务，协调开销和成本是硬伤。
  5. Routing：先分类再分发到专精模型，成本可控但分类错误会连锁翻车。

最佳实践：确定性任务→Plan-Execute，开放探索→ReAct，质量敏感→加 Reflection，规模大→Multi-Agent。

为什么 ReAct 不够​

ReAct 的 Think → Act → Observe 循环解决了 LLM 最核心的问题：把推理接地到真实数据上。但这个循环有两个硬伤——一次只想一步，以及没有质量检查。

想一步做一步的代价是，任务超过五六步就容易丢掉初始目标。每步都是一次 LLM 调用，10 步就是 10 次，token 账单直接起飞。更麻烦的是，ReAct 对工具返回结果照单全收——某一步返回了错误数据，后面所有推理都建立在沙滩上。

说白了，ReAct 好用是因为它"够简单"，不是因为它"最优"。工程上真正要解决的问题是：在不同场景下，用可控性或效率换灵活性，值不值得。

Function Calling：能少就不要多​

Function Calling 是最基础的模式——连 Thought 都不需要，LLM 直接决定调不调工具、调哪个、传什么参数。

# 最简单的 Function Calling Agent —— 没有 Thought 循环
response = llm.chat(
    messages=[{"role": "user", "content": "北京今天天气？"}],
    tools=[get_weather]
)
if response.tool_calls:
    result = execute(response.tool_calls[0])

Anthropic 在 2025 年的实践指南里反复强调一句话："Keep it radically simple first." 如果你能把整个任务的决策树画出来，就别让 Agent 自己探索——直接写死分支逻辑，便宜、可控、延迟低。

Function Calling 的适用范围比很多人想的要广。翻译、摘要、分类、单次搜索，这些场景上 ReAct 纯属浪费。问题是，一旦任务需要多步推理（查 A → 根据 A 的结果查 B → 综合分析），Function Calling 就抓瞎了——它没有"下一步该干什么"的能力。

Plan-and-Execute：全局思考换效率​

Plan-and-Solve 的论文（Wang et al., 2023）给了一个很直观的数字：在需要 10 步以上的任务里，ReAct 完成率约 32%，Plan-and-Execute 能做到 78%。

差距的原因很简单：ReAct 每步都在重新决策，Plan-and-Execute 只在最开始决策一次。

ReAct:
Step 1: Think → Act → Observe
Step 2: Think → Act → Observe  # 重新思考"接下来干什么"
...

Plan-and-Execute:
Plan: 步骤1→步骤2→步骤3→步骤4  # 一次性规划
Step 1: Execute → Validate
Step 2: Execute → Validate       # 每步只执行+验证，不重新决策
...

Plan-and-Execute 的额外好处是可以降级执行模型——规划用强模型（GPT-4/Claude Opus），执行子任务时可以换成更便宜、更快的模型。对生产环境的成本控制来说，这一点比完成率提升更有吸引力。

但它有一个致命缺陷：规划是静态的。如果第三步执行时发现第二步的产出和预期不一样，原始计划就废了。需要额外加 re-plan 触发逻辑，否则 Agent 会硬着头皮按错误路线走下去——比 ReAct 的"想一步走一步"更危险，因为 ReAct 至少每步都在看反馈。

Reflection：让 Agent 自己检查作业​

Reflection 的核心逻辑是加一个内环：生成 → 评估 → 修正 → 再生成。 相当于在 ReAct 的每一步后面，多问一句"刚才这一步做得对吗？"

Reflexion（Shinn et al., 2023）的实验数据很说明问题：HumanEval 代码生成 pass@1 从 GPT-4 原生的 80% 拉到 91%，ALFWorld 决策任务 +20%。提升来自一个简单的机制——把失败经验存下来，下次做同类任务时注入上下文。 本质上是 verbal reinforcement learning，只是"梯度"不是数字，是一段自然语言的反思总结。

但这个模式的代价也很直接：每一步迭代都是一次额外的 LLM 调用。如果 Reflection 跑 3 轮，token 消耗就是原来的 3 倍。而且评估器的 prompt 质量直接决定效果——评估标准太宽，Agent 得过且过；太严，Agent 永远觉得自己做错了，陷入修正死循环。

实际落地时一个容易被忽略的坑：假阳性评估会提前终止 reflection。 比如代码生成的单元测试本身有 bug，Agent 生成的代码是对的但测试跑不过，reflection 就会往错误方向修正。这在 MBPP 数据集上被反复观察到。

Multi-Agent：分而治之​

Multi-Agent 的思路是把一个 Agent 解决不了的问题拆给多个 Agent。常见两种形态：

  • Orchestrator-Workers：一个中央调度 Agent 拆解任务、分发给执行 Agent、汇总结果。AutoGen、CrewAI 都是这个路子。
  • Debate/Consensus：多个 Agent 独立产出答案，交叉辩论或投票，选出最优解。

Multi-Agent 的强项是上下文隔离——每个 Worker 只看自己那部分任务，不会被全局上下文撑爆窗口。在代码生成场景里，把"写代码""写测试""做 review"拆给三个 Agent 分别处理，效果明显好于一个 Agent 全包。

但协调成本是硬伤。Agent 之间的信息传递靠自然语言，没有 schema 约束，传递过程中信息丢失和误解几乎是必然的。Google DeepMind 的 2025 实践指南也指出：production 系统中给终端用户用的，几乎都是确定性 workflow，不是高自主性 Multi-Agent。 后者更多用在内部工具和研究场景。

我也踩过坑：两个 Agent 辩论时，一个特别能说（生成文本更长），另一个相对简洁——结果系统倾向采纳能说的那个，和答案质量无关。这就是"辩论"作为共识机制的隐性偏见。

怎么选​

一句话总结选择逻辑：

任务特征推荐模式
单步、已知决策树Function Calling
多步、路径确定、容错低Plan-and-Execute
多步、路径不确定、需要探索ReAct
质量要求高、容错率极低ReAct + Reflection
规模大、可拆分、独立子任务多Multi-Agent

这些不是互斥的。实际生产系统里，Plan-and-Execute 的每个执行步骤跑 ReAct 循环，关键步骤加 Reflection 校验——混合才是常态。关键是理解每种模式的代价是什么，而不是把某一种当万能药。

References​