Appearance
Workflow 是什么（工作流）
定义
如果只用一句话来理解 Workflow，可以先把它看成：
把一项任务拆成一组预先设计好的步骤，再由系统按照既定顺序和规则把这些步骤执行完。
比如下面这个流程：
text
用户上传文章
↓
提取正文
↓
生成摘要
↓
翻译成英文
↓
保存结果这里每一步做什么，基本都是提前设计好的。
系统真正要做的是：
按照已经确定好的流程，把任务稳定执行下去。
所以理解 Workflow 时，最重要的是两个词：
流程 和 编排。
流程描述任务需要经过哪些步骤。
编排则负责把这些步骤组织起来，决定：
- 先执行什么
- 后执行什么
- 满足什么条件走哪个分支
- 哪些步骤可以同时执行
- 某一步失败以后怎么办
只要这些规则可以在任务执行前大体确定，就很适合用 Workflow 来描述。
Workflow 是怎么运行的
Workflow 最直观的理解方式，就是把一项任务画成一张流程图。
例如一个最简单的文章处理流程：
text
开始
↓
获取文章
↓
生成摘要
↓
生成关键词
↓
保存结果
↓
结束系统从开始节点进入，然后沿着预先设计好的路径向下执行。
每执行完一步，就把结果交给下一步。
真实的 Workflow 当然不会永远只有一条直线。
它也可以根据条件走不同分支：
text
收到用户反馈
↓
判断类型
↙ ↘
Bug 建议
↓ ↓
开发 产品也可以让多个任务同时执行：
text
获取文章
↙ ↓ ↘
摘要 标签 关键词
↘ ↓ ↙
汇总结果还可以在某一步失败以后重新执行，或者等待人工确认。
但无论结构多复杂，核心思路都没有变化：
先把任务怎么执行设计出来，再让系统按照这个结构运行。
节点和连线
Dify、Coze、n8n 这一类可视化工具，看起来经常是一块画布，上面放着很多方框，再通过线连接起来。
这些方框通常就是 节点（Node）。
节点代表工作流中的一个具体动作。
例如：
text
开始节点
LLM 节点
HTTP 请求节点
代码执行节点
数据库节点
条件判断节点
结束节点假设我们要做一个简单的文章处理 Workflow。
可以有这些节点：
text
用户输入
↓
LLM 生成摘要
↓
LLM 提取关键词
↓
HTTP 请求
↓
保存结果其中：
用户输入节点负责拿到原始内容。
LLM 节点负责调用大模型处理文本。
HTTP 节点可以请求外部 API。
数据库节点可以保存结果。
而节点之间的连线，则表示执行关系。
比如：
text
节点 A → 节点 B通常意味着：
节点 A 执行完成以后，把结果交给节点 B。
如果增加条件判断：
text
内容分类
↙ ↘
技术文章 新闻
↓ ↓
技术流程 新闻流程那么同一个 Workflow 就可以根据不同输入走不同路径。
所以从最基础的角度看，Workflow 可以理解成：
节点负责做事，连线负责决定这些事情按照什么关系执行。
一个最小 Workflow 长什么样
假设现在要做一个非常简单的 AI 工具：
用户上传一篇中文文章，系统自动生成摘要，再翻译成英文，最后保存结果。
我们可以把它设计成下面这个 Workflow：
text
用户上传文章
↓
提取文章正文
↓
LLM 生成中文摘要
↓
LLM 翻译英文
↓
整理输出格式
↓
写入数据库
↓
完成这里虽然已经用了大模型，但整体流程还是非常明确的。
第一步一定是获取文章。
第二步一定是提取正文。
正文拿到以后，进入摘要节点。
摘要完成以后，再进入翻译节点。
最后保存结果。
可以把每个节点简单理解成一个函数：
text
extractArticle()
↓
summarize()
↓
translate()
↓
formatResult()
↓
save()输入进入以后，数据按照既定路径不断向后传递。
例如：
text
原始文章
↓
正文文本
↓
中文摘要
↓
英文摘要
↓
结构化结果如果某一步失败，还可以提前设计失败处理。
例如翻译接口失败：
text
翻译
↓
失败？
↙ ↘
是 否
↓ ↓
重试 保存甚至可以规定：
text
最多重试 3 次这就是一个非常典型的 Workflow。
它不需要很复杂。
只要一项任务能够被拆成一组相对明确的步骤，就已经可以通过 Workflow 来组织。
为什么 AI Workflow 曾经特别火
大模型刚开始进入应用开发以后，很多 AI 产品的结构其实都比较相似。
例如一个知识库问答应用，可能会经历：
text
用户提问
↓
改写问题
↓
搜索知识库
↓
整理检索结果
↓
调用 LLM
↓
生成回答内容生成工具也可能是：
text
输入主题
↓
生成大纲
↓
生成正文
↓
生成标题
↓
生成摘要
↓
输出结果这些 AI 应用有一个共同特点：
很多能力都可以被拆成一个个独立步骤。
于是很自然就出现了一种开发方式：
把每一个能力封装成节点，再通过画布把这些节点连接起来。
比如：
text
开始
↓
知识库
↓
LLM
↓
代码执行
↓
HTTP API
↓
结束开发者并不一定需要从零写完整代码，而是可以直接拖拽节点、配置参数，再把它们连接起来。
这也是 Dify、Coze、n8n 等产品里非常常见的一种交互方式。
它降低了构建 AI 应用的门槛。
尤其是在一些流程比较清楚的任务中，可以很快把：
- 大模型
- 知识库
- API
- 数据库
- 代码
- 消息通知
这些能力组合到一起。
所以当时经常可以看到一种开发方式：
在画布上把 AI 应用“画”出来。
实际上画出来的，就是一套 Workflow。
Workflow 适合什么任务
并不是所有任务都需要复杂的动态决策。
现实里有大量任务，本身就是一套比较明确的流程。
这类任务通常非常适合 Workflow。
文档处理
例如：
text
上传 PDF
↓
解析文本
↓
提取字段
↓
生成摘要
↓
保存结果每一步都比较明确。
内容处理
例如：
text
输入文章
↓
生成标题
↓
生成摘要
↓
提取关键词
↓
生成 SEO Description虽然中间大量使用了 LLM，但整体步骤基本固定。
数据处理
例如：
text
每天定时执行
↓
查询数据库
↓
清洗数据
↓
生成统计结果
↓
发送报表这也是非常经典的 Workflow。
工单处理
例如：
text
收到工单
↓
识别类型
↓
生成摘要
↓
分配负责人
↓
发送通知分类这一步可以使用 AI。
摘要也可以使用 AI。
但整个业务处理流程依然可以提前设计。
自动化任务
例如：
text
收到表单
↓
验证数据
↓
写入数据库
↓
发送邮件
↓
通知管理员这类任务甚至不一定需要 AI，本身就是传统工作流自动化非常典型的场景。
所以 Workflow 最适合的任务通常有几个共同特点：
- 主要步骤比较明确
- 输入和输出相对清晰
- 执行路径可以提前设计
- 同一流程需要重复运行
- 更关注稳定性和可控性
可以把它简单理解成：
如果一个任务已经知道“大概要怎么做”，那就很适合先把它设计成 Workflow。
Workflow 的价值并不是让系统看起来更智能。
它真正解决的是：
怎么把一组已经确定的步骤稳定地组织和执行起来。
Workflow 并不是 AI 时代的产物
看到这里，有些同学可能会觉得 Workflow 是大模型流行以后才出现的概念。其实并不是。
早在人工智能进入应用开发之前，很多系统里就已经有了工作流。最典型的就是各类审批流程：
text
提交请假申请
↓
直属领导审批
↓
HR 审批
↓
通过 / 驳回报销、采购、合同会签，背后往往都是一套提前设计好的流程。这类思路也早就广泛存在于企业 OA 系统、DevOps 流水线、定时数据任务里。
所以更准确地说：
Workflow 本身是一种“把任务按既定步骤组织执行”的工程思想，AI 只是让其中的某些节点变得更灵活。
总结
Workflow 可以先理解成：
一套预先设计好的任务执行流程。
它把一个完整任务拆成多个节点，再通过顺序、条件、分支等规则，把这些节点组织起来。
最简单的 Workflow 可能只是：
text
输入
↓
处理
↓
输出复杂一些以后，则可以加入：
text
条件判断
并行执行
循环
重试
人工确认Dify、Coze、n8n 等工具中常见的可视化画布，本质上也是把这种流程编排方式做得更加直观。
Workflow 特别适合那些：
步骤相对明确、路径可以提前设计，并且需要稳定重复执行的任务。
至于当任务的执行路径无法提前完全确定，需要系统根据当前结果不断判断下一步时，整个系统又会发生什么变化，就是我们上一篇介绍的 AI Agent了。