Agent 工程化系列 · 第 02 篇

Agent 和 Workflow 有什么区别？不是所有自动化都叫 Agent

从工程视角讲清：什么时候用固定流程，什么时候才需要动态决策

---

开篇定位

这不是一篇“名词解释”。

因为在真实项目里，很多团队说自己在做 Agent，但最后做出来的其实只是一个 Workflow 自动化流程。

这并不是坏事。恰恰相反，很多能稳定上线的 AI 应用，第一步就应该从 Workflow 开始。

真正的问题是：

什么时候应该用 Workflow？什么时候才值得上 Agent？

这一篇就把这条边界讲清楚。

目录

1. 开篇定位：这篇先纠正一个常见误区
2. 01 一句话讲清：Workflow 和 Agent 的核心区别
3. 02 Workflow 是什么：把流程写清楚，把结果做稳定
4. 03 Agent 是什么：围绕目标动态推进任务
5. 04 真正的分界线：谁在决定下一步
6. 05 为什么工程里不能一上来就用 Agent
7. 06 什么时候必须引入 Agent
8. 07 最常见落地形态：Workflow + Agent 混合
9. 08 用一个真实场景看懂差异
10. 09 最后总结

---

01 一句话讲清：Workflow 和 Agent 的核心区别

如果只记一句话，可以这样理解：

Workflow 是“开发者提前写好的流程”；Agent 是“模型围绕目标在运行时动态决定下一步”。

更通俗一点：

• Workflow 像一条生产线。先做什么、后做什么、失败了怎么办，基本都提前设计好。
• Agent 像一个带工具的执行者。你给它目标，它会根据当前情况判断下一步该查资料、调工具、继续追问，还是停止输出。

所以，二者不是“谁更高级”的关系，而是解决不同问题。

对比项	Workflow	Agent
控制权	代码 / 流程编排器	LLM 在运行时动态决策
路径	预设路径、分支有限	路径不固定，可多轮探索
优点	稳定、可测、成本可控	灵活、能处理开放问题
风险	灵活性不足	成本、延迟、误操作风险更高
典型场景	审批、报表、工单、内容流水线	研究、排障、规划、复杂任务执行

---

02 Workflow 是什么：把流程写清楚，把结果做稳定

Workflow 本质上是一个 流程编排系统。

它可以包含 LLM，也可以不包含 LLM。关键不是有没有大模型，而是：

流程路径是开发者提前设计好的。

比如一个“合同审核摘要”的 Workflow 可以这样设计：

上传合同
  ↓
OCR / 文档解析
  ↓
提取关键条款
  ↓
调用 LLM 生成风险摘要
  ↓
人工确认
  ↓
导出 Word / PDF

这里面有 LLM，但它仍然是 Workflow。

因为 LLM 只是某个步骤里的一个能力节点，它没有决定整个流程怎么走。流程的顺序、分支、重试、超时、人工确认，都是外部系统控制的。

Workflow 更像“带 AI 节点的自动化流水线”

在工程里，Workflow 通常会以这些形态出现：

• DAG 有向图：节点和边提前定义好。
• 状态机：每个状态能跳到哪里提前定义好。
• 编排器：负责调度、重试、超时、日志和异常处理。
• Router 路由：根据条件选择一个预设分支。

注意，Router 并不一定等于 Agent。

即使你让 LLM 来判断“这个工单属于售后、财务还是技术支持”，只要可选分支是提前写好的，这仍然更接近 Workflow。

---

03 Agent 是什么：围绕目标动态推进任务

Agent 不是“流程更复杂的 Workflow”。

它真正多出来的是：

运行时决策权。

用户给 Agent 的通常不是一个固定流程，而是一个目标。

比如：

“帮我分析一下这个开源项目是否适合二次开发，并整理一份技术判断。”

这个任务很难提前写死完整步骤。

Agent 可能需要自己判断：

• 先读 README，还是先看目录结构？
• 是否需要查看 issue、release、license？
• 发现依赖复杂后，要不要继续查构建脚本？
• 结果不确定时，要不要换一个角度再验证？
• 最后输出报告前，要不要做一次自检？

这类任务的路径不是固定的，而是随着中间结果不断变化。

这就是 Agent 的典型价值。

Agent 更像“目标驱动的执行循环”

一个最小 Agent 通常会包含这样的循环：

观察当前状态
  ↓
判断下一步
  ↓
调用工具 / 查询资料 / 执行动作
  ↓
读取结果
  ↓
判断是否继续
  ↓
输出最终结果

这里的关键不在于“调用了多少工具”，而在于模型是否能根据状态动态改变后续动作。

---

04 真正的分界线：谁在决定下一步

区分 Workflow 和 Agent，不要只看它有没有 LLM，也不要只看它有没有工具调用。

真正的判断标准是：

下一步动作是代码预先规定的，还是模型根据当前状态动态决定的？

举几个例子就很清楚。

场景	更像 Workflow	更像 Agent
客服工单分类	按预设类别路由到不同队列	根据用户上下文持续追问、查订单、判断处理方案
文章生成	按固定模板生成标题、摘要、正文	自己查资料、发现信息不足、补充检索、调整结构
数据报表	固定 SQL 查询 + 固定图表	根据异常数据继续追查原因并提出假设
代码修复	固定 lint + 格式化 + 测试	读错误日志、定位文件、修改代码、运行测试、继续修复

很多所谓 Agent Demo，实际只是：

用户输入 → Prompt → LLM 输出 → 展示结果

这种系统可以是一个很好的 LLM 应用，但不能轻易称为 Agent。

如果它没有状态管理，没有工具执行，没有反馈闭环，也没有动态决策，那它就还没有进入真正的 Agent 范畴。

---

05 为什么工程里不能一上来就用 Agent

Agent 听起来更智能，但工程落地时，越智能的系统往往越难控制。

因为 Agent 会带来几个非常现实的问题。

第一，路径不可完全预测

Workflow 的执行路径通常能画成流程图。

Agent 的执行路径更像一条运行时轨迹。它每一步调用什么工具、查什么资料、是否继续执行，都可能因为中间结果不同而变化。

这意味着测试难度会明显上升。

第二，成本和延迟更难估计

Workflow 通常知道会调用几次模型、几个接口。

Agent 可能为了完成一个任务，多轮调用模型、多次检索、多次工具执行。任务复杂时，成本和耗时可能被放大。

第三，错误影响范围更大

普通 LLM 回答错，最多是文本错。

Agent 如果调用了工具，错误可能变成：

• 查错数据
• 写错文件
• 发错消息
• 修改错配置
• 执行了不该执行的动作

所以，Agent 系统必须有权限控制、参数校验、日志审计和人工确认。

第四，可观测性要求更高

做 Workflow，你主要看每个节点是否成功。

做 Agent，你还要看：

• 它为什么选择这个工具？
• 中间状态有没有被污染？
• 它有没有陷入重复循环？
• 失败时能不能恢复？
• 用户能不能追溯它做过什么？

这也是为什么很多 Agent Demo 看起来很强，但真正上线后会遇到稳定性问题。

---

06 什么时候必须引入 Agent

不是所有任务都需要 Agent。

只有当任务具备明显“不确定性”时，Agent 才开始有价值。

可以用下面这组标准判断。

适合 Workflow 的任务

• 步骤清楚
• 输入输出固定
• 分支可以提前枚举
• 对稳定性要求高
• 需要低成本、高吞吐

比如：发票识别、合同摘要、日报生成、审批流、数据同步、固定格式报告。

适合 Agent 的任务

• 目标清楚，但路径不清楚
• 中间结果会影响下一步
• 需要查资料、比较、推理、验证
• 工具选择无法提前完全写死
• 需要多轮执行和自我修正

比如：复杂问题排障、开源项目调研、竞品分析、代码修复、数据异常分析、长任务规划。

一个非常实用的判断口诀

能写死流程，就先用 Workflow。
写不死路径，但能定义目标和边界，再用 Agent。

这句话非常重要。

因为工程系统最怕的不是“不够智能”，而是“不可控”。

---

07 最常见落地形态：Workflow + Agent 混合

真实项目里，最常见的不是纯 Workflow，也不是完全自治 Agent。

更常见的是：

Workflow 做主干，Agent 做局部智能决策。

也就是说，主流程仍然由工程系统控制，但在某些难以提前写死的节点里，引入 Agent 进行判断。

比如一个“企业知识报告生成系统”：

用户输入主题
  ↓
Workflow：校验权限、确认范围
  ↓
Agent：判断需要查哪些资料
  ↓
Tools：检索文档、查询数据库、读取网页
  ↓
Workflow：结构化生成报告
  ↓
人工确认
  ↓
导出文件

这样设计的好处是：

• 流程边界清楚
• Agent 的自由度受控
• 安全动作可审批
• 日志更容易追踪
• 成本和失败范围更容易管理

---

08 用一个真实场景看懂差异

假设我们要做一个“老板每天早上收到公司经营简报”的系统。

如果用 Workflow

流程可以这样写死：

每天 8:00 触发
  ↓
查询销售数据
  ↓
查询项目进度
  ↓
查询财务数据
  ↓
按固定模板生成简报
  ↓
发送到企业微信

这种方式非常适合第一版 MVP。

因为数据源固定、输出格式固定、发送时间固定，Workflow 更稳定。

如果引入 Agent

Agent 可以处理更开放的问题。

比如老板追问：

“为什么华东区昨天收入下降？帮我查一下是不是项目延期导致的。”

这时，固定流程就不够用了。

Agent 需要自己决定：

• 先查销售区域数据
• 再查项目交付进度
• 对比历史趋势
• 找异常客户或异常订单
• 如果证据不足，再继续查 CRM 或会议纪要
• 最后给出判断和置信度

这个过程不是简单流水线，而是目标驱动的探索。

最合理的方案

第一版不要直接做全自动 Agent。

更合理的是：

固定日报用 Workflow，异常追查用 Agent。

这样既能保证系统每天稳定运行，又能在真正需要智能判断的地方发挥 Agent 的价值。

---

09 最后总结

Agent 和 Workflow 的区别，不是“有没有大模型”，也不是“有没有工具调用”。

真正的区别是：

Workflow 的流程由代码提前规定；Agent 的过程由模型在运行时动态推进。

工程上最稳妥的路线，不是直接追求“全自动 Agent”，而是先把确定性流程做稳定，再把不确定、需要探索、需要判断的部分交给 Agent。

可以把这篇的核心结论浓缩成三句话：

Workflow 解决确定性。
Agent 解决不确定性。
真正可落地的系统，往往是二者的组合。

下一篇，我们继续往下讲：

Agent 有哪些工作模式？