Dify 工作流编排实战：调多个模型完成任务
Dify 工作流怎么搭？这篇手把手讲清楚 Dify workflow 节点编排、多模型路由、并行串行、错误重试，附 1 个完整的内容生产工作流案例
30 秒了解：Dify 工作流是什么
Dify 工作流（Workflow）是 Dify 里把多个节点串成有向流程图的应用类型，你可以让一个任务先经过「检索」→「LLM 改写」→「条件分支」→「另一个 LLM 校验」→「HTTP 推送」，整条流水线无人值守地跑下去。
和单纯的 Chatbot 相比，Dify 工作流的核心差异有 3 点：
- 多节点串联，每一步可以用不同的模型、不同的工具
- 支持并行 + 循环 + 分支，复杂业务可以拆细
- 可以被定时触发或 API 调用，不必有人坐在前面对话
如果你只是想做单轮 QA，用 Chatbot 就够。只要任务超过 3 步、要切模型、要发外部接口，就该上 Workflow。
这篇是 Dify 怎么用 的进阶教程，假设你已经能注册账号、配好模型 API Key。如果还没跑通基础流程，先回去看基础篇。
准备工作
| 项目 | 要求 |
|---|---|
| Dify 账号 | 云版或自部署皆可（建议 v0.15 及以后） |
| 模型 API Key | 至少 2 个不同厂商（如 DeepSeek + 通义，便于演示多模型路由） |
| 外部接口（选做） | 飞书 / 钉钉 / 企微 webhook，用来推送结果 |
| 知识库（选做） | 想串「检索 → 生成」就提前建好一个 |
详细操作步骤
第 1 步：新建 Workflow 应用
进入 Dify 工作室，点 创建应用 → 选 工作流（Workflow） → 命名「多模型内容生产线」→ 写一句描述，点创建。
进入应用后会看到一个空白画布，左上角是节点工具栏，右上角是「试运行」「发布」按钮。
[此处放截图：Dify 新建 Workflow 后的空白画布]
第 2 步：认识 8 类核心节点
工具栏里的节点分 4 类，先把概念记住，再开始拖：
| 节点 | 作用 | 常见用法 |
|---|---|---|
| 开始 / 结束 | 流程入口和出口 | 定义输入变量、最终返回结果 |
| LLM | 调一次大模型 | 写文、改文、抽信息、分类 |
| 知识检索 | 查知识库 Top K | 给 LLM 提供上下文 |
| HTTP 请求 | 调任意 RESTful 接口 | 拉数据、推 webhook |
| 代码执行 | 跑 Python 或 Node 片段 | 数据清洗、格式转换 |
| 条件分支 | if-else 逻辑 | 按分类走不同路径 |
| 迭代 | 循环处理列表 | 批量处理多条数据 |
| 工具 | 调第三方插件 | 联网、绘图、Notion 等 |
记住一句话：节点之间靠「上一个节点的输出变量」往下传。
第 3 步：拖出最小可用流程（3 节点）
最小可用 Workflow 长这样：开始 → LLM → 结束。
操作：
- 在「开始」节点里加一个输入变量
topic（类型选 String） - 拖一个 LLM 节点，模型选 DeepSeek-V3，把 prompt 写成「请围绕主题「{{topic}}」写一段 200 字介绍」
- 拖一个 结束 节点，输出变量绑定 LLM 节点的
text字段 - 点右上角 试运行，输入
topic = AI 智能体，看是否返回正常结果
跑通就证明你的 Dify 工作流环境是好的，接下来才能往复杂走。
[此处放截图：3 节点最小工作流试运行结果]
第 4 步：加多模型路由（核心场景）
真实业务里经常需要「便宜模型先分类，贵模型再深度处理」。在 Workflow 里这样做：
- 在 开始 节点输入
user_query字符串变量 - 加 LLM 节点 A，模型选最便宜的（如 DeepSeek、豆包 Lite），prompt 写「判断这段话属于哪类：客服咨询 / 投诉建议 / 商务合作 / 其他。只输出分类名」
- 加 条件分支 节点，按 LLM 节点 A 的输出走 4 个分支
- 每个分支后面挂一个 LLM 节点 B/C/D/E，按业务选不同模型——客服用 Doubao Pro，投诉用 Claude（更稳重），商务用 GPT-5（更正式），其他用 DeepSeek
- 4 个分支最后都汇到 结束 节点，统一输出
answer
这样简单意图用便宜模型分流，复杂任务才用贵模型，月成本能砍掉一半以上。
第 5 步：加并行节点（提速）
如果你有 3 个独立子任务（比如同时翻译成英 / 日 / 韩），可以用「并行」节点拆开同时跑：
- 主流程到「分发」的地方，连出 3 条线分别接 3 个 LLM 节点
- 这 3 个节点没有先后依赖，会并行执行，整体耗时按最慢那条算
- 3 条线最后用一个 代码执行节点 合并结果，输出 JSON
并行不是免费的：会同时消耗 3 次模型 Token，注意预算。但对响应时间敏感的场景，省时间比省钱重要。
第 6 步：加错误处理 + 重试
LLM 偶尔会超时或返回格式错误。Workflow 节点都支持错误处理：
- 点任意 LLM 节点 → 右侧面板 → 错误处理 标签
- 勾选 失败时重试，重试次数填 2，每次间隔 5 秒
- 仍失败可以选 走备用分支（比如降级到便宜模型）或 直接结束并返回错误信息
生产环境的 Workflow，每个 LLM 节点都该配错误处理，不然单点失败整条流程就挂了。
第 7 步：发布 + 触发
调试好后点右上角 发布。Dify 给 3 种触发方式：
| 触发方式 | 适合场景 |
|---|---|
| 在线试用 URL | 内部测试、客户演示 |
| API 调用 | 接到你自家产品 / 后端服务 |
| 定时任务（部分版本） | 每天 9 点自动跑 |
API 调用最常用，调用方式就是带上 Workflow App API Key 的 POST 请求，请求体里写 inputs（输入变量字典）和 response_mode（streaming 或 blocking）。完整字段以 Dify 控制台的 API 文档为准。
# Python 示例：调用一个 Dify Workflow
import requests
url = "https://api.dify.ai/v1/workflows/run"
headers = {
"Authorization": "Bearer YOUR_APP_API_KEY",
"Content-Type": "application/json",
}
payload = {
"inputs": {"topic": "AI 智能体"},
"response_mode": "blocking",
"user": "user-001",
}
resp = requests.post(url, json=payload, headers=headers, timeout=60)
print(resp.json())自部署版的 URL 改成你的 Dify 服务地址即可。
5 个让 Dify 工作流更香的技巧
| 技巧 | 怎么做 |
|---|---|
| 变量复用 | 用全局会话变量保存中间状态，跨节点共享 |
| 用模板提示词 | 复杂 prompt 抽成模板节点，多个 LLM 节点共用 |
| HTTP 节点接外部 LLM | 想用 Dify 不直接支持的模型？走 HTTP + OpenAI 兼容接口 |
| 用代码节点做 JSON 解析 | LLM 输出 JSON 后用 Python 节点抽字段，避免下一个 LLM 重新解析 |
| 配合 MCP 工具 | Dify 已支持 MCP，把企业内部数据接入 Workflow |
常见坑 + 解决办法
| 现象 | 原因 | 解决 |
|---|---|---|
| 变量取不到值 | 变量名拼错 / 上游节点没跑成功 | 用试运行模式逐节点查输出，按 ID 而非名字引用变量 |
| LLM 输出 JSON 解析失败 | 模型没严格按 JSON 格式回 | prompt 里强调「只输出 JSON，不要任何额外文字」+ 用代码节点 try/except 兜底 |
| 工作流执行很慢 | 串行节点过多 / 用了大模型 | 能并行的并行 + 简单任务降级到 Doubao Lite / DeepSeek |
| HTTP 节点超时 | 外部接口慢 / 没设超时 | 调高超时阈值（默认 30 秒）+ 加重试 |
| 自部署 Workflow 偶发挂 | 后台 worker 不够用 | 调大 WORKER_REPLICAS 环境变量 + 监控容器 CPU |
| API 调用返回 401 | App API Key 错 / 已禁用 | 控制台 → 应用 → API 访问，重新生成 Key |
一个完整实战案例：多模型内容生产线
下面这个 Workflow 流程已经在实际项目里跑了好几个月，每天产 50 多篇运营文案，可直接套用到你自家场景：
流程总览：
- 开始 节点接收
topic（选题）、audience（目标读者）2 个输入 - LLM 节点 1（DeepSeek）：根据 topic 生成 5 个不同角度的标题
- LLM 节点 2（GPT-5）：让人工或 AI 选 1 个最优标题（这里走自动模式 + 评分）
- 知识检索节点：从「公司品牌资料库」检索相关素材
- LLM 节点 3（Claude）：基于标题 + 检索素材写 1000 字正文
- LLM 节点 4（DeepSeek）：检查正文是否含禁用词、品牌口径
- 条件分支：通过 → 走推送；不通过 → 回到节点 5 重写
- HTTP 节点：把成品推送到飞书机器人通知运营
下面是节点 3 的核心 prompt 模板，你可以直接复制到 Dify 的 LLM 节点：
你是一名资深运营内容编辑。
上下文
- 选题：{{topic}}
- 目标读者：{{audience}}
- 已选定标题：{{best_title}}
- 品牌素材：{{retrieved_context}}
任务
基于以上信息，写一篇 800-1200 字的运营文，要求：
- 第一段 50 字以内抓眼球，不能用「在数字化时代」这类八股开头
- 全文分 3-5 个小标题，每段 200 字左右
- 必须自然引用至少 2 处「品牌素材」中的具体数据或案例
- 结尾给读者一个明确的下一步动作（关注公众号 / 加企微 / 试用产品 等任选一个）
输出格式
直接输出正文 Markdown，不要任何前缀说明。
整个 Workflow 用 4 个不同模型互补：DeepSeek 干杂活省钱、GPT-5 选优、Claude 写主稿、DeepSeek 校审。月成本约几百块，比纯用 GPT-5 砍掉了 70%。
进阶 / 下一步
- Dify 怎么用？开源 LLMOps 平台 0 基础上手：Dify 基础教程
- Dify 知识库怎么搭？文档 RAG 5 步入门：把知识库接进 Workflow
- 扣子 Coze 工作流实战：对比另一种工作流引擎
- 扣子 vs Dify vs FastGPT 对比：选型参考
- AI Agent 工作流是什么：理解 workflow 在 Agent 体系里的角色
常见问题
Q：Dify 工作流和扣子 Coze 工作流有啥本质差别？ A：Dify 工作流偏「开发者友好」——支持代码节点、HTTP 任意接口、私有部署、模型自由切换。扣子工作流偏「业务友好」——节点更少更简单、和字节生态深度整合、不需要懂技术。复杂业务和私有数据选 Dify，轻量场景和小白选扣子。
Q：Workflow 一次能调用几个 LLM？有上限吗？ A：理论无上限。但单次执行所有 LLM 调用总时长建议控制在 60 秒内，超过就该考虑拆成多个 Workflow 异步串联，或者把简单步骤合并到一个 LLM 调用里。
Q：能不能在 Workflow 里调用另一个 Workflow？ A：可以。用 HTTP 节点调子 Workflow 的 API，或者用 Dify 较新版本的「工作流嵌套」节点。复杂业务拆成多个小 Workflow 比堆一个大的更好维护。
Q：Workflow 的运行日志怎么看？ A：控制台 → 你的应用 → 日志 标签，能看每次运行的输入、每个节点的输出、耗时、Token 消耗。生产环境每周扫一遍日志，能找出最贵和最慢的节点。
Q：自部署 Dify 跑大量 Workflow 性能怎么样？ A：取决于你的 worker 数量。单机 8 核 16GB 大约能扛每分钟 50-100 次 Workflow 调用，更多就要加机器或上 Kubernetes 横向扩展。可以先压测再决定配置。
Q：Workflow 能做 Agent 那种「自主决定下一步」的能力吗？ A：可以，但不是它的强项。Workflow 是「预定义流程图」，路径基本固定。真要 Agent 那种自主推理就用 Dify 的 Agent 应用类型，或者在 Workflow 里嵌一个 Agent 节点。两种范式可以混搭。