工作流和智能体的区别: 什么时候用流程, 什么时候放权

第05课我们拆完了 AI 工作流, 再往前的第04课讲了智能体。两个概念单独看都不难, 难的是放在一起做选择: 手上这个需求, 到底该做成工作流, 还是做成智能体? 这是 AI 产品经理在方案评审会上最容易被问住的问题, 也是这一课要解决的问题。

先把结论放在最前面: 工作流和智能体的区别, 不是”老技术和新技术”的区别, 而是确定性和自主性之间的取舍。工作流是你提前把路修好, 模型只在每个路口干活; 智能体是你给模型一张地图和一个目的地, 路让它自己走。选哪个, 取决于你的场景更需要稳定可控, 还是更需要随机应变。

学完这一课, 你能带走三样东西: 一条用来定位任何 AI 需求的光谱模型、一份 6 个问题的决策清单、一套向老板解释架构选型的汇报话术。评审会上再被问”为什么不做成 Agent”, 你可以直接把清单拍在桌上。

先修正一个误区: 这不是二选一, 是一条光谱

很多讨论把工作流和智能体说成两个对立阵营, 好像做产品必须先站队。实际工程里, 它们是同一条光谱的两端:

• 光谱左端是确定性: 每一步做什么、按什么顺序、失败了怎么办, 全部由人提前写死, 模型只是流水线上的一个工位。
• 光谱右端是自主性: 人只定义目标和边界, 走哪条路、调用什么工具、什么时候算完成, 由模型自己在循环里决定。

先给两个术语各补一句白话解释。工作流(workflow), 就是把一个大任务拆成固定步骤、像流水线一样串起来的自动化管道, 每一步的输入输出都提前定义好。智能体(agent), 就是给大模型一个目标, 让它在”思考、行动、观察”的循环里自己决定下一步做什么, 直到目标达成。

用招人做类比最直观: 工作流像按 SOP(标准作业程序)培训一个新员工——每一步都写在手册里, 他不需要理解为什么, 照做就行, 换谁来做结果都一样。智能体像请一位资深顾问——你说清楚要什么结果、预算多少、什么红线不能碰, 过程交给他, 他可能给你惊喜, 也可能给你惊吓。

站内那篇从 Prompt 到 Agent Loop 的范式转移把分界线说得很准: 工作流和智能体的本质区别, 是控制权在谁手里。控制流写在你的代码里, 就是工作流; 控制流由模型的输出决定, 就是智能体。两者之间还有大量灰色地带——比如固定流程里留一个分支交给模型判断, 这就是光谱中段的形态, 后面混合架构一节会展开。

所以正确的问题不是”用工作流还是用智能体”, 而是”我的场景应该落在光谱的哪个点位”。下面两节分别看两端各自的主场。

什么时候用工作流: 把确定性攥在手里

四个信号, 命中越多, 越应该用工作流。

信号一: 步骤是已知的

如果你能在白板上把任务从头到尾画成一张流程图——先做什么、后做什么、每一步的输入输出长什么样——那就没有理由让模型自己去”探索”这条你已经知道的路。探索是有成本的: 每一次让模型自主决策, 都引入一次出错的机会。

典型场景: 客服工单自动分类、发票信息提取、内容审核初筛、周报汇总。这些任务的共同点是路径唯一且已知, 模型只需要在单个环节内发挥语言理解和信息抽取的能力, 不需要决定流程往哪走。

信号二: 要合规、要审计

金融、医疗、政企这类行业, 结果对还不够, 过程还要可解释。监管来查的时候, 你要能回答: 这条数据为什么被这样处理? 在哪一步、依据什么规则? 工作流天然满足这个要求——每个节点的输入输出都能落日志, 整条链路可以回放。智能体的决策过程藏在模型推理里, 事后很难还原。社区已经在给智能体补这块短板, 比如给 AI 智能体引入不可篡改审计日志的开源项目 Halo, 但那是在给自主性打补丁, 不如工作流从结构上就可审计。

信号三: 失败成本高

一笔错误的退款、一封发错的客户邮件、一次误删的数据, 损失可能远超自动化省下的钱。失败成本高的场景, 要的是错误可预期、可拦截——工作流可以在关键节点插入人工审核, 把风险卡在出口之前。

信号四: 量大, 要稳定要便宜

同一个任务每天跑一万次, 工作流的优势是压倒性的: 每次执行的 token 消耗基本恒定, 延迟可预估, 成本可以精确算进单位经济模型。智能体每次执行的步数不定, 可能三步完成, 也可能绕二十步, 成本和延迟都是一个分布而不是一个数。量产场景里, 方差本身就是成本。

工具层面不用纠结, 第05课给过一句话定位: n8n、Dify、Coze 这类平台就是为工作流形态服务的, 选型可以看站内的 LangChain/LangGraph/n8n/Dify 框架选型指南。至于”AI 都能直接写代码了, 为什么还需要低代码平台”, 站内也有一场针对 Dify、Coze 存在价值的讨论——答案恰恰呼应本课主题: 因为生产环境买的就是确定性。

什么时候用智能体: 把路径交给模型

三个信号, 命中任何一个, 硬写工作流都会很痛苦。

信号一: 路径未知

有些任务你根本画不出流程图。”帮我查清楚这个报错的根因”——是先查日志、还是先读代码、还是先搜历史工单? 都有可能, 顺序取决于每一步看到的结果。路径依赖中间结果的任务, 流程图会膨胀成一棵无法穷举的树, 这时候就该放权给智能体, 让它在”思考、行动、观察”的循环里自己找路。

目前最成熟的例子是 AI 编程智能体: Claude Code、Codex 这类工具接到”修掉这个 bug”的目标后, 自己决定读哪个文件、跑什么命令、改哪几行、怎么验证。没人能提前写出这个流程, 因为流程本身取决于代码库长什么样。对这类工具能力边界的讨论, 可以看智能体编码的基准测试观察。

信号二: 探索型任务

竞品调研、开放式数据分析、”帮我看看这份合同有什么坑”——这类任务的特点是连”做完”的标准都是模糊的, 需要在过程中不断重新定义下一步。工作流处理不了”我看到 A 之后才知道要去查 B”的动态性, 而这正是智能体循环的主场。

信号三: 长尾场景写不完规则

客服机器人处理头部二十个高频问题, 用工作流又稳又省; 但第二十一到第两千个长尾问题呢? 每个都配一条流程分支, 管道会变成没人敢动的意大利面条。长尾的本质是规则的边际收益递减——写到后面, 每条规则覆盖的案例越来越少, 维护成本却不降。这时候用一个带知识库的智能体兜底, 比无限堆分支划算得多。

注意一个前提: 放权的信心来自验证能力。编程智能体之所以最先落地, 是因为代码天然可验证——测试跑不跑得过、编译报不报错, 反馈又快又客观。如果你的场景没有这种客观验证手段(比如生成营销文案), 放权之前要先想清楚谁来兜底质量。

混合架构: 生产系统的常态

光谱两端看完了, 现实中大多数生产系统落在中间。两种主流的混合方式, 方向正好相反。

方式一: 工作流里嵌智能体节点

主干仍然是确定性管道, 但某几个节点内部跑着一个小智能体。比如内容生产流水线: 选题、写作、审核、发布是固定四步, 但”写作”这一步内部, 智能体可以自己决定要不要检索资料、要不要推翻重写。对外, 这个节点仍然有确定的输入输出契约; 对内, 它有探索自由。

这是把智能体引入业务最稳妥的路径: 自主性被关在笼子里, 出了问题影响面清晰。节点内部的复杂度控制, 可以参考站内用渐进式披露解决工作流路由臃肿的讨论——不要让一个节点一次看到所有工具和分支, 按需暴露, 复杂度就不会失控。

方式二: 智能体把工作流当工具调用

反过来, 顶层是一个智能体, 它的工具箱里除了单个工具, 还有打包好的整条工作流。比如运营智能体接到”给这批流失用户发召回邮件”的目标, 策略由它自己定, 但”发邮件”这个动作调用的是一条带审核、带频控的固定管道。放权给了大脑, 手脚仍然戴着手套。

工程上还有第三种值得知道的形态: 用状态机给智能体上骨架——把智能体的每一步显式建模成状态和转移, 失败可以从断点恢复, Apache Burr 对比 LangGraph 构建可恢复 Agent 那篇实战讲的就是这个思路。你可以把它理解为”给自主性套一层确定性的骨架”, 是光谱中段的典型工程样本。

对产品经理来说, 混合架构的关键设计决策只有一个: 自主性的边界画在哪里。边界内模型自由发挥, 边界外一切确定。边界画得越清楚, 系统越好测、越好排障、越好向老板解释。

两种失败模式: 都是团队踩过的坑

全 agent 化: 演示惊艳, 上线翻车

把整条业务链交给一个大智能体, 演示环节永远收获掌声——因为演示只跑一条精心挑选的顺利路径。上线之后问题全来了: 同样的输入, 今天走五步明天走十二步; 出了错没人说得清它为什么这么决策; 想做测试都无从下手, 因为行为空间根本无法穷举。更隐蔽的坑是长时任务的状态管理——任务跑到一半挂了, 状态没了, 只能从头再来, Dify 能否胜任长时异步任务与状态监控的讨论就是这个痛点的真实写照。

一句判词: 没有验证手段的自主性, 不是能力, 是风险敞口。

全 workflow 化: 需求一改, 管道重排

反面同样常见: 团队被”可控”的安全感吸引, 把所有东西都做成工作流。前三个月很美好, 直到需求开始变——每次改动都要重排管道, 分支越堆越多, 最后没人敢碰。判断的标志很具体: 当流程图里的条件分支超过两位数、每个新需求都在往里加特例, 说明这个场景的复杂度已经超出规则能承载的范围, 该把其中一段升级成智能体节点了。

文档驱动工作流的 task-planner 实践能缓解一部分维护痛苦, 但结构性的问题——用确定性架构硬接不确定性需求——只能靠移动光谱点位来解决。

决策清单: 6 个问题定位你的点位

先上一张对照表, 把前面的定性判断压缩成可以贴在工位上的速查卡:

然后是这一课的核心交付物: 6 个问题, 每题二选一, 选 A 记 1 分。

1. 流程能不能提前画出来? 我能在白板上画出这个任务从输入到输出的每一步。A 能 / B 不能
2. 失败损失能不能承受? 单次执行出错造成的最大损失, 业务承受不起。A 承受不起 / B 承受得起
3. 要不要向第三方交代过程? 出了问题, 需要向监管、客户或审计方解释每一步的处理依据。A 需要 / B 不需要
4. 量大不大? 这个任务的日调用量会超过一千次。A 会 / B 不会
5. 规则稳不稳定? 未来三个月任务规则基本不变, 长尾特例也不多。A 稳定 / B 多变、长尾多
6. 有没有自动验证手段? 输出对不对, 缺少客观、自动化的检查方式, 主要靠人看。A 缺少 / B 有

计分规则: 5 到 6 个 A, 做纯工作流; 3 到 4 个 A, 工作流为主、在最不确定的环节嵌智能体节点; 1 到 2 个 A, 智能体为主、关键动作走固定管道; 0 个 A, 可以大胆放权, 但监控和预算上限要先建好。

强调一句: 这份清单评估的是当前场景, 不是永远。产品迭代半年后规则稳定了, 完全可以把智能体沉淀回工作流; 反过来, 管道僵化了也可以局部放权。光谱点位是随业务移动的。

拿清单跑两个例子

例一, 电商客服自动退款: 流程画得出(A)、失败是真金白银(A)、要向客户和财务交代(A)、日量大(A)、规则稳定(A)、金额校验可自动化(B)。5 个 A——毫无悬念做工作流, 顶多在”理解用户诉求”环节嵌一个智能体节点。

例二, 帮运营找增长机会: 流程画不出(B)、失败顶多浪费一次分析(B)、不用向监管交代(B)、一天跑几次(B)、场景天天变(B)、结果好坏靠人判断(A)。1 个 A——智能体形态, 但输出必须过人工审核这道闸。

产品视角: 怎么跟老板讲清楚这笔账

架构评审会上, 老板不关心什么是智能体循环, 他关心三件事: 靠不靠谱、多少钱、出了事怎么办。翻译成架构语言, 就是可靠性和泛化能力的取舍:

• 工作流卖的是可靠性: 结果稳定、成本可预算、出问题可追责。代价是只能处理设计过的场景, 每扩一个场景都要开发排期。
• 智能体卖的是泛化: 没设计过的场景也能接, 长尾一网打尽, 改需求只要改目标描述。代价是行为有方差、成本是个区间, 还要额外投入监控和兜底机制。

汇报模板就三句话。第一句定点位: “这个场景步骤固定/路径未知, 所以我们选工作流/智能体为主。” 第二句算账: “单次成本恒定在多少/落在什么区间, 对应的预算上限是多少。” 第三句给兜底: “失败时走人工审核/自动回滚, 影响面控制在哪个范围。” 三句话说完, 大多数质疑会自动消失, 因为你展示的是取舍, 而不是站队。

最后一个提醒: 别被供应商的词汇带偏。市面上不少自称 Agent 的产品, 拆开看是写死的工作流套了个对话壳; 也有叫”自动化流程”的产品, 内核是真放权的智能体。判断标准始终只有一个——控制流在谁手里。这也是你评估外部方案和报价时最锋利的一把刀。想持续跟进这类架构讨论, 可以看站内的 AI Agent 专题; 本系列后续课程的更新都归档在 AI 产品经理专题。

选型想明白之后, 下一个高频问题是: 模型不知道你的私有知识怎么办? 这是第07课 RAG 入门要解决的。而智能体要真正”有手有脚”, 还得学会调用外部工具, 那是第09课 Function Calling 的内容。

相关阅读

• 探讨 Agent 工作流: 需求调研阶段的上下文是否应移交给开发环节
• 通用 Agent 架构图开源: 可视化解析智能体系统设计
• 前端工程师的 AI 转型: 从 Dify 与 Coze 实战看 Agent 开发的技术门槛
• 开源项目 Kastor: 用 Terraform 风格声明式配置管理 AI 智能体

FAQ

工作流和智能体可以同时用吗?

不但可以, 而且生产系统大多就是混合形态: 要么工作流主干里嵌智能体节点, 要么智能体把工作流当工具调用。真正要想清楚的不是二选一, 而是自主性的边界画在哪一段。

智能体是不是比工作流更先进, 工作流会被淘汰吗?

不会。两者是光谱两端, 各有主场: 步骤已知、量大、要审计的场景, 工作流的确定性是刚需, 和模型多强没有关系。就算模型能力继续涨, 合规和成本约束也不会消失, 变的只是边界的位置——更多场景敢放权了, 而不是流程消失了。

团队没有工程师, 应该先做哪个?

先做工作流。低代码平台把工作流的搭建门槛压得很低, 而且确定性管道出了问题容易定位, 适合练手。等你对节点拆分、验收标准这些手感熟了, 再在单个节点里引入智能体, 风险是递进的而不是跳跃的。

怎么识别一个”Agent 产品”其实是工作流?

问三个问题: 同样的输入, 它的执行路径是否完全一致? 它能不能处理没被预设过的请求? 它有没有步数不固定的循环? 三个答案都是否, 那就是工作流套了个对话界面。这不代表产品不好, 但你要按工作流的价格和能力边界去谈, 别为”Agent”这个词付溢价。

给智能体放权之后, 怎么控制风险?

三层边界一起上: 工具白名单限制它能碰什么, 步数和 token 预算上限限制它能跑多久, 高危动作(付款、删除、对外发送)强制人工确认。再加一条事后防线——决策日志留档, 出了问题至少可以复盘归因。

结语

工作流和智能体不是路线之争, 而是同一条光谱上的点位选择: 确定性换稳定, 自主性换泛化。用 6 个问题定好点位, 把边界画清楚, 剩下的交给业务迭代去校准。