Agent vs Workflow：到底怎么选？

Agent 不是生产环境的默认答案。Workflow 控制强但死板，Agent 灵活但难控。真正落地的系统往往是"用 Workflow 框住主流程，在关键节点嵌入 Agent"。本文把 Agent 与 Workflow 的本质区别、三种主流设计范式（ReAct / Plan-and-Execute / Reflection）、选择决策阶梯与设计规范一次讲清楚。

ReAct Plan-and-Execute Reflection Agentic Workflow Anthropic 原则

1. Agent 与 Workflow：一句话分清楚

Workflow 是你写的流程：节点、分支、条件、顺序都预先定义好，LLM 只是流程中某些步骤的"执行者"。Agent 是模型自己决定流程：它根据目标自主决定下一步调用什么工具、是否继续、何时终止。

Workflow（工作流） 流程由开发者预设，确定性强 开始 LLM 执行 固定步骤 结束 开发者控制路径，LLM 只填内容 Agent（智能体） 流程由模型自主决定，灵活性强 思考 行动 观察 模型决定循环，直到目标达成
图 1 · Workflow = 预定脚本；Agent = 模型自驱动
维度WorkflowAgent
控制权开发者LLM / 智能体
流程预先写死，分支规则明确动态决策，可能走不同路径
确定性高，可预测低，概率性
调试定位快，节点可追踪路径多变，排查困难
测试覆盖容易覆盖所有分支很难穷尽路径
成本相对可控容易失控（循环/重复调用）
适用流程明确、质量要求稳定需求模糊、需要灵活决策

2. 从简单到复杂的四种形态

生产环境里不是"要不要 Agent"的二选一，而是一个连续谱。Anthropic 的建议是：能用前者绝不用后者。从简单到复杂依次为：单个 LLM 调用 → 固定 Workflow → Agentic Workflow → 纯 Agent。

① 单个 LLM 调用 一次提问直接出答案 · 无工具 · 无流程 ② 固定 Workflow 预定义节点+分支 · 规则驱动 · 稳定可控 ③ Agentic Workflow Workflow 框主流程 · 关键节点嵌入 Agent ④ 纯 Agent 全流程自驱动 · 灵活最高 · 可控最低 复杂度低 / 可控性高 复杂度高 / 可控性低 更复杂 →
图 2 · 决策阶梯：先选简单的，按需升级，避免过度设计
1

单个 LLM 调用

一次性提问，直接生成答案。无工具、无流程。

最简单可控性最高
2

固定 Workflow

按预设流程执行，分支由规则决定，稳定可控。

中等复杂度可控性较高
3

Agentic Workflow

整体流程可控，关键节点引入 Agent 处理复杂决策。

生产主流可控性中等
4

纯 Agent

LLM 自主决策、动态选工具、自规划并执行。

最复杂可控性低
Anthropic 原则：能用 Workflow 解决的问题，就不要用 Agent。先从最简单开始，只有写死的逻辑无法覆盖时，才把对应节点升级成 Agent。

3. Agent 的三种经典设计范式

真正的 Agent 不是"一个 LLM + 一堆工具"那么简单，它需要一套"想—做—看"的循环机制。目前主流有三种设计范式：

🔄

ReAct

思考（Thought）→ 行动（Action）→ 观察（Observation）循环，边想边做。

📋

Plan-and-Execute

先整体规划，再逐步执行，支持根据反馈动态重规划。

🪞

Reflection / Reflexion

执行后自我评估，失败则反思总结并带着经验重试。

4. ReAct：最常见的边想边做

ReAct 把推理（Reasoning）和行动（Acting）显式分开。每一轮循环由三步组成：

  • Thought：LLM 先分析当前局面，把推理过程写出来，例如"用户想查竞品信息，我应该先用搜索工具查竞品 A"。
  • Action：根据 Thought，调用具体工具并传参，如 web_search(query="竞品A 最新动态")。
  • Observation：工具返回结果，LLM 读取后进入下一轮 Thought。
1. Thought · 思考 "我应该先搜索竞品 A" 2. Action · 行动 调用 web_search(竞品A) 3. Observation · 观察 接收搜索结果 循环
图 3 · ReAct 三步循环：思考 → 行动 → 观察，直到能给出最终答案
为什么把 Thought 显式写出来？ 如果让模型直接输出 Action，它容易"冲动决策"——还没搞清楚用户要什么就急着调工具。Thought 让模型先把问题理清楚，决策更稳定，而且内容可见，调试时能看到在哪一步想歪了。
ReAct 的短板：走一步看一步，每步都是局部最优。处理需要十几步的全局任务时，容易中途迷失方向，或在几个工具之间反复打转。

5. Plan-and-Execute：先规划，再执行

针对 ReAct 容易迷失全局的问题，Plan-and-Execute 把规划和执行解耦：先用一个 LLM 做规划器（Planner）生成完整步骤列表，再由另一个 LLM 或同一模型以不同角色去执行。

规划器 Planner 负责拆解任务、生成计划、评估反馈并重规划 step1 明确需求 step2 收集信息 step3 分析竞品 step3' 深挖 step4 生成方案 根据反馈动态重规划：插入/修改/替换后续步骤 执行器 Executor 负责执行当前步骤、调用工具、产出结果 step1 ✓ 已完成 需求文档 step2 ✓ 已完成 竞品清单 step3 ⟳ 执行中 竞品分析初版 step4 step5 反馈执行结果 → 触发重规划
图 4 · Plan-and-Execute：规划与执行解耦，支持根据执行反馈动态重规划
关键机制：动态重规划。 成熟的 Plan-and-Execute 不是"先定计划再死板执行"。每执行完一步，执行结果会反馈给规划器，规划器判断是否需要修改或插入新步骤。这样既有全局视野，又不会死板失效。
代价：多了规划和重规划的 LLM 调用，延迟和成本都增加；如果初始规划方向就错了，后续调整也很难挽回。

6. Reflection / Reflexion：做错题本，而不是简单重做

Reflection 在前两种范式上加了一层质量保障。Agent 完成一步或整个任务后，用一个评估器（Evaluator）判断做得好不好。如果不通过，就重试或换一种策略。

生成器 LLM 生成 结果/代码/文案 → def sum(arr): ... 评估器 运行测试 / 检查 规则 / 人工 / 模型 ✗ IndexError 反思总结 反馈：错误/不足 带着改进建议重试 Reflexion 变体 把失败原因写成 具体"错题本"， 作为额外上下文 传给下一次尝试。
图 5 · Reflection / Reflexion：生成 → 评估 → 反思 → 带着经验重试

Reflexion 是 Reflection 的升级版：不只是说"这个结果不好，重做一遍"，而是生成一段具体的反思总结，记录失败原因和改进建议，并把它作为额外上下文传给下一次尝试。类比人类学习，就是"写错题本"。

效果：在 HumanEval 代码生成基准上，GPT-4 直出约 80%，加上 Reflexion 可提升到约 91%。代价是 LLM 调用 ×2~3、token 翻倍。

7. 三种范式对比与组合使用

范式核心机制特点适合场景成本
ReActThought → Action → Observation 小循环边想边做，根据观察决定下一步步骤少、每步独立、不需要全局规划低
Plan-and-Execute先规划，再执行，动态重规划先整体规划，再逐步执行，根据反馈调整任务复杂、步骤有依赖、需要全局视角中
Reflection生成 → 评估 → 反思 → 重试先生成结果，再评估反思，总结经验优化质量要求极高、容错率低、需要持续自我优化高

实际项目里，这三种范式不是互斥的，而是常常叠加：

1. Plan-and-Execute 先做整体规划 动态调整计划 2. ReAct 每个步骤内部 按步决策执行 循环往复 3. Reflection 关键步骤/输出后 做质量把关 失败则反思重试 实际生产里的常见组合：Plan 定方向 → ReAct 填细节 → Reflection 保质量
图 6 · 三种范式常叠加使用：Plan 定全局 → ReAct 做执行 → Reflection 做质检

8. 如何选择：决策矩阵与 Anthropic 原则

核心看两个维度：任务复杂度和质量要求。步骤少、独立 → ReAct；复杂、有依赖 → Plan-and-Execute；质量要求极高 → 叠加 Reflection。

任务复杂度 → 质量要求 → ReAct 低复杂度 · 中低质量要求 Plan-and-Execute 高复杂度 需要全局规划 + Reflection 质量要求极高时叠加 再简单 → 直接用 Workflow / 单次 LLM 再高要求 → 加入评估器/人工审核
图 7 · 选择决策矩阵：按复杂度和质量要求匹配范式
工程实践原则：
1. 先选简单的：单个 LLM 调用 → 固定 Workflow → Agentic Workflow → 纯 Agent。
2. 能用 Workflow 解决的问题，不要用 Agent。
3. 只有当某个节点确实需要灵活决策、写死逻辑无法覆盖时，才把那个节点升级成 Agent。
4. 永远保留关键节点的可观测性与人工兜底。

9. Agent 设计规范

把 Agent 投入生产，不只是套一个 ReAct 框架。下面是经过实践验证的设计规范：

9.1 可控性优先：Agentic Workflow

纯 Agent 模式在生产里用得不多，因为行为不确定、难以调试、成本容易失控。主流做法是用 Workflow 框住主流程，在需要灵活判断的节点嵌入 Agent，既保留整体可控性，又有局部灵活性。

固定 Workflow 主链路 意图识别 [规则/小模型] Agent 局部嵌入 动态决定检索几轮 用哪些工具 / API 回答生成 [固定模板] 输出 生产主流：整体可控 + 局部灵活
图 8 · Agentic Workflow：主流程固定，只在关键节点嵌入 Agent

9.2 工具与提示设计

🛠️

工具要小而专

每个工具只做一件事，参数清晰、返回值结构统一。避免让 LLM 面对"万能工具"做复杂参数拼装。

📝

提示要约束边界

明确告诉 Agent 能调什么、不能调什么、何时停止、输出格式。用 few-shot 示例说明 Thought/Action/Observation 格式。

🛑

必须设终止条件

最大轮次、最大 token、超时时间、重复调用检测。防止死循环或无限重试导致成本失控。

🔍

全链路可观测

记录每一次 Thought/Action/Observation 和耗时、token。出问题才能定位是哪一步想歪了。

9.3 安全与兜底

🛡️

关键操作人工确认

涉及写库、发邮件、转账等高风险动作，必须留人工确认节点，不要完全交给 Agent 自动执行。

⚖️

权限最小化

Agent 只能访问它必须的工具和数据。避免给它过大的权限范围，降低误操作风险。

9.4 评估与迭代

没有评估就没有优化。 建立针对 Agent 的评估集，覆盖成功路径、失败路径、边界情况。对 Reflection 类系统，要单独评估"反思是否真的能指出错误"而不是生成套话。

10. 面试 / 设计 Checklist

  • ☐ 能否用单次 LLM 调用或固定 Workflow解决？能就不用 Agent。
  • ☐ 任务是否步骤多、依赖强、需要全局规划？是 → 优先考虑 Plan-and-Execute。
  • ☐ 任务是否步骤少、每步独立、可边做边看？是 → 优先考虑 ReAct。
  • ☐ 输出质量要求是否极高、容错率极低？是 → 叠加 Reflection / Reflexion。
  • ☐ 生产环境是否采用 Agentic Workflow，用 Workflow 框住主流程、关键节点嵌 Agent？
  • ☐ 是否设置了最大轮次、token 上限、超时、重复调用检测？
  • ☐ 工具设计是否小而专、参数清晰、返回结构统一？
  • ☐ 关键操作是否有人工确认或权限最小化机制？
  • ☐ 是否具备全链路日志，能追踪 Thought/Action/Observation？
  • ☐ 是否建立了评估集，能持续衡量成功率和成本？
一句话总结：Agent 不是目的，而是"当确定性流程无法覆盖需求时"的局部升级方案。生产系统的正确姿势是：Workflow 保可控，Agent 补灵活，Reflection 保质量，观测和兜底贯穿全程。

本文结合 ReAct、Plan-and-Execute、Reflection / Reflexion 三种主流 Agent 设计范式，以及 Anthropic "能用 Workflow 就不用 Agent" 的工程原则整理。具体实现可基于 LangChain、LlamaIndex、AutoGen、Mastra 等框架，但核心设计思想框架无关。