跳到主要内容

Workflow vs Agent

学习 AI Agent 时，一个最容易混淆的问题就是：

多步工作流到底算不算 Agent？

很多系统表面上都在“分步骤执行”：

  • 先拿用户输入
  • 再检索资料
  • 再调用工具
  • 最后生成答案

看起来已经很像一个会做事的系统了。

但这里面其实有两个完全不同的设计方向：

  • Workflow：由工程师预先写死流程
  • Agent：由模型在运行时决定下一步

这篇文档的目标，就是把这两个概念拆清楚，并回答一个更重要的问题：

在真实项目里，什么时候应该用 Workflow，什么时候才真的需要 Agent？

1. 先看一句最简定义​

可以先用一句最简单的话记住：

  • Workflow 是“预先定义好的执行流程”
  • Agent 是“围绕目标动态决定下一步的执行系统”

可以直接记成：

  • Workflow 更接近“流程自动化”
  • Agent 更接近“目标驱动的动态编排”

2. Workflow 是什么​

Workflow 可以理解为：一组由人提前设计好的步骤。

它通常长这样：

  1. 接收输入
  2. 做资料检索
  3. 调用某个工具
  4. 把结果交给模型总结
  5. 输出答案

这些步骤谁先谁后、什么条件下走哪条分支，往往都已经由工程师提前写好。

所以 Workflow 的核心特点是：

  • 步骤是预定义的
  • 执行路径基本可预测
  • 系统自由度较低
  • 工程可控性较高

3. Agent 是什么​

Agent 则不只是照流程走，而是会在运行中围绕目标不断做判断。

它通常具备这些能力：

  • 理解目标
  • 判断当前缺什么
  • 决定下一步做什么
  • 选择是否调用工具
  • 根据结果调整后续动作
  • 必要时重试、换路、停止

所以 Agent 不是“有多步流程的系统”，而是“在多步过程中拥有动态决策能力的系统”。

4. 两者最本质的区别​

最本质的区别不在于“有没有多步”，而在于：

下一步是谁决定的。

4.1 Workflow：由工程师决定​

在 Workflow 里：

  • 第一步做什么
  • 第二步做什么
  • 什么条件下走分支
  • 最多执行几次

这些都主要由系统代码或配置决定。

模型可以参与某一环，但通常不负责“整体路径决策”。

4.2 Agent：由模型基于状态决定​

在 Agent 里：

  • 当前目标是什么
  • 现有证据够不够
  • 该不该调工具
  • 要不要继续循环
  • 是不是已经完成

这些更偏运行时决策，会交给模型结合上下文和状态来判断。

5. 一个直观对比​

5.1 Workflow 的例子​

比如做一个“文档问答助手”：

  1. 接收问题
  2. 检索 Top 5 文档片段
  3. 拼进 prompt
  4. 生成答案
  5. 返回结果

这就是一个非常典型的 Workflow。

它当然有多步，也会调用模型和检索，但并没有明显的自主决策循环。

5.2 Agent 的例子​

再比如做一个“调研并生成报告”的系统：

  1. 接收调研目标
  2. 判断需要先搜哪些方向
  3. 调用搜索工具
  4. 发现资料不够，继续追问新的问题
  5. 发现来源冲突，重新验证
  6. 判断资料基本完整，开始写报告
  7. 自查是否缺关键部分
  8. 再补一轮信息
  9. 最终输出

这时候系统就不是在走固定脚本，而是在围绕目标持续决策。

这已经更偏向 Agent。

6. 为什么很多人会把两者混在一起​

因为很多系统处在中间状态。

比如：

  • 固定流程里嵌了模型判断
  • 路由节点由模型来选
  • 出错后允许模型重试一次

这会让系统看起来带一点 Agent 味道，但本质上可能还是 Workflow。

所以现实里不是非黑即白，而是一个连续谱：

Fixed Workflow -> Conditional Workflow -> LLM-Routed Workflow -> Lightweight Agent -> Full Agent

可以把它理解成：

  • 越靠左，越可控
  • 越靠右，越灵活

7. 为什么很多场景其实先用 Workflow 更好​

学 Agent 时非常容易出现一个误区：

把所有复杂任务都默认做成 Agent。

但真实项目里，很多需求其实更适合从 Workflow 开始。

原因主要有几个。

7.1 Workflow 更稳定​

因为路径是预定义的，所以：

  • 输出更可预测
  • 行为更容易复现
  • 出错更容易排查

7.2 Workflow 更便于评估​

流程固定之后，你更容易知道：

  • 哪一步出问题了
  • 哪个模块退化了
  • 哪个改动影响了最终结果

7.3 Workflow 更适合高频、结构化任务​

比如：

  • 表单解析
  • 文档摘要
  • FAQ 问答
  • 标准审批流
  • 固定格式报告生成

这些任务的变化范围其实不大，没必要过度引入动态决策。

8. 什么情况下才更适合 Agent​

当任务开始具备下面这些特征时，Agent 的价值会更明显：

  • 任务目标明确，但路径不固定
  • 中间步骤依赖运行时信息
  • 工具调用顺序无法提前完全写死
  • 经常需要补资料、换策略、重试
  • 最终结果依赖多轮判断和整合

典型场景包括：

  • 多源调研
  • 复杂排错
  • 开放式分析
  • 自动化执行复杂任务
  • 跨多个工具和知识源的协作任务

9. 一个非常实用的判断标准​

可以用下面 3 个问题快速判断是否需要 Agent：

9.1 路径能不能提前大致写出来​

如果能提前明确写出 80% 以上的步骤，通常先考虑 Workflow。

9.2 中间决策是否真的复杂​

如果只是：

  • 检索一下
  • 调一个工具
  • 再总结一下

这不一定需要 Agent。

9.3 动态决策带来的收益是否大于复杂度​

Agent 能带来灵活性，但也会带来：

  • 更高的不确定性
  • 更难的调试
  • 更复杂的评估
  • 更高的成本和延迟

如果收益不明显，就没必要上强 Agent。

10. Workflow 和 Agent 的关系​

这两者不是互斥关系。

更准确地说：

  • Workflow 是很多系统的基础骨架
  • Agent 是在部分节点上引入动态决策能力

所以真实项目里更常见的是：

  • 外层是 Workflow
  • 某几个复杂节点是 Agent

比如：

  1. 外层流程固定：接任务 -> 校验权限 -> 启动处理 -> 输出结果
  2. 中间一个“复杂分析节点”交给 Agent 决策

这比“一上来全系统 Agent 化”通常更稳。

11. 一个推荐的演进路径​

如果是边学边做，最稳的演进路径通常是：

11.1 第一步：先做固定 Workflow​

先把核心链路跑通：

  • 输入
  • 检索
  • 工具
  • 输出

11.2 第二步：识别最难写死的节点​

看看哪些地方最依赖运行时判断，比如：

  • 资料是否足够
  • 是否继续检索
  • 是否需要换工具

11.3 第三步：局部 Agent 化​

不要整套系统一起改，而是先让某个子任务拥有动态决策能力。

11.4 第四步：再补 Evals 和 Harness​

一旦引入 Agent，就最好同步考虑：

  • 轨迹记录
  • 回归测试
  • 任务完成率
  • 成本和步数控制

否则系统很快会变得难以维护。

12. 常见误区​

12.1 只要多步执行就是 Agent​

不是。

多步执行只能说明系统有流程，不说明它具备动态目标驱动决策。

12.2 Agent 一定比 Workflow 高级​

不一定。

Agent 更灵活，但不代表在所有场景都更优。

很多高质量生产系统反而是：

  • 以 Workflow 为主
  • 在少数高不确定节点用 Agent

12.3 先上 Agent，再考虑可控性​

这往往会导致：

  • 行为不可预测
  • 问题难复现
  • 评估成本上升

更稳的做法是先从可控的 Workflow 起步，再逐步增加 Agent 能力。

13. 一句话总结​

如果说：

  • Workflow 解决的是“把已知流程自动化”
  • Agent 解决的是“让系统围绕目标动态决策”

那么两者的关键区别就是：

系统的下一步，是由工程师预先写好，还是由模型在运行时基于状态来决定。

对大多数团队来说，最实用的策略通常不是“二选一”，而是：

先用 Workflow 搭稳骨架，再把真正需要动态判断的节点逐步 Agent 化。