Dify 工作流：当 AI 应用从“对话”走向“生产线”

如果说传统的 ChatGPT 式问答是“手工作坊”——每次交互独立、凭经验调参，那么 Dify 工作流就是一座“自动化工厂”。它将大语言模型、知识库、工具调用和自定义代码串联成有向无环图（DAG），让 AI 应用具备确定性逻辑、可复用性和工程级可观测性。本文不赘述界面操作，而是直击 Dify 工作流的核心设计模式，辅以极少量关键代码，帮你理解其“编排”而非“编码”的哲学。

一、工作流 vs. Agent：确定性与自主性的抉择

Dify 提供两种核心范式：Chatflow（对话流）和 Workflow（工作流）。前者面向多轮对话，具备记忆和自主工具调用（Agent 模式）；后者则面向批处理、数据清洗、内容生成管道等场景，强调路径固定、节点可控。

• Agent 像实习生：自己决定查哪份资料、调用哪个工具，灵活但不可预测。
• Workflow 像流水线工人：严格按照“检索 → 生成 → 校验 → 输出”的步骤执行，每一步都有输入校验和异常出口。

对于生成高质量长文、定时报告或结构化数据填充，工作流是更可靠的选型——因为它把 LLM 的“创造性”约束在业务规则的笼子里。

二、核心节点拆解：乐高积木式搭建逻辑

Dify 工作流编辑器中的每个节点，都是一个独立的执行单元。构建一篇文章生成器，通常会用到以下积木：

1. 开始节点（Start）

定义外部输入变量，如 topic（主题）、target_audience（目标读者）、word_count（字数要求）。这些变量以 {{变量名}} 的形式传递到后续节点。

2. 知识检索节点（Knowledge Retrieval）

若生成行业白皮书或产品说明书，需先查询向量数据库。该节点根据 topic 召回相关文档片段，作为 LLM 的上下文。这是 RAG（检索增强生成）在工作流中的落地。

3. LLM 节点（核心引擎）

这是“大脑”。我们填写 System Prompt 和 User Prompt，并引用上游变量。Dify 支持切换多个模型（GPT-4、Claude、本地开源模型），甚至可以在不同节点使用不同模型（例如，用便宜的模型写草稿，用顶配模型做润色）。

Prompt 模板示例（引用变量）：

System: 你是一位专业的科技主编，风格严谨但不晦涩。
User: 请根据以下素材撰写一篇关于“{{topic}}”的文章，面向{{target_audience}}，字数控制在{{word_count}}左右。
素材内容：{{knowledge_context}}

4. 代码节点（Code Node）——少量代码的用武之地

LLM 输出的 raw 文本常夹杂多余 Emoji、无序列表符号或重复空行。代码节点允许我们插入 Python 或 JavaScript 对中间结果做“手术刀式”清洗，而不必反复修改 Prompt 折磨大模型。

Python 代码节点示例：清洗 Markdown 并提取关键摘要

import re

def main(input_text: str) -> dict:
    # 1. 移除多余的空行和不可见字符
    cleaned = re.sub(r'\n\s*\n', '\n\n', input_text.strip())
    # 2. 移除可能泄露的“作为AI模型”等无关声明
    cleaned = re.sub(r'作为(一个)?AI(语言)?模型，?', '', cleaned)
    # 3. 计算字数（返回额外指标供下游条件分支使用）
    word_count = len(re.findall(r'[\u4e00-\u9fa5a-zA-Z0-9]', cleaned))
    return {
        "clean_text": cleaned,
        "word_count": word_count
    }

此节点介于 LLM 和输出之间，它不取代模型能力，而是做确定性格式化——这正是 Dify 推崇“工作流”而非“纯黑盒调用”的关键价值。

5. 条件分支节点（IF/ELSE）

根据代码节点返回的 word_count，如果字数不足 500，走“补充写作”分支；如果达标，直接进入“发布”分支。条件节点让工作流具备自适应调整能力，而非“一锤子买卖”。

6. 变量聚合与输出（End）

将最终文本、标题、标签组装成 JSON 结构，通过 HTTP 响应或飞书/钉钉机器人发送出去。

三、迭代与批处理：从单篇到规模化

如果需要生成 100 篇不同城市的旅游攻略，不必循环触发 100 次工作流。Dify 支持迭代节点（Iteration），输入一个列表，内部按顺序执行子工作流，并将结果汇聚成数组。

迭代节点中的列表变量传递示意（JavaScript 表达式）：

// 在迭代开始前，将城市列表转为数组
const cities = ["北京", "上海", "成都", "杭州"];
// 迭代内部引用当前项
return cities.map(city => ({
  topic: `${city}深度游指南`,
  audience: "自由行背包客"
}));

少量代码在这里负责“数据塑形”，让工作流从串行手工操作升级为批量生产线。

四、设计铁律：容错与可观测性

工作流一旦上线，必须处理 LLM 的不稳定性。Dify 提供了错误处理节点（Error Handling）——当 LLM 超时或返回空结果时，自动跳转至备用节点（如直接返回缓存的模板文章）。

同时，每个节点的输入输出都在运行日志中完整保留。你可以在“日志与标注”面板中查看某次运行中，knowledge_context 到底召回了哪些段落，code_node 是否成功缩减了字符。这种白盒调试能力，是手写 Python 脚本调用 API 难以比拟的。

五、实战范式：用“多轮精炼”替代“一次生成”

顶尖的文章生成工作流从不指望一次 LLM 调用就出奇迹。典型的高级 Dify 编排如下：

1. 规划节点（LLM-A）：根据主题生成文章大纲（章节标题列表）。
2. 并行写入节点（LLM-B/C/D）：将不同章节标题并发传入多个 LLM 实例，分别撰写（利用 Dify 的并行分支）。
3. 代码汇总节点：合并各部分内容。
4. 润色节点（LLM-E）：对合并后的全文进行“统一文风”润色。
5. 校验代码节点：用正则或第三方库检查敏感词、死链，通过则输出，否则打回重写。

关键代码片段：合并并行输出（Python）：

def main(chapter_a: str, chapter_b: str, chapter_c: str) -> dict:
    # 简单合并，并添加分节符
    full_article = f"## 第一章\n{chapter_a}\n\n## 第二章\n{chapter_b}\n\n## 第三章\n{chapter_c}"
    return {"final_article": full_article}

这种“规划-执行-汇总-精炼”的模式，大幅降低了单次生成的内容熵，输出质量接近人工编审水平。

六、与外部世界的握手：HTTP 请求节点

工作流不是孤岛。通过 HTTP 请求节点，你可以将生成的文章发送至 WordPress 发布、存入阿里云 OSS，或调用第三方 Grammarly 语法检查 API。这使得 Dify 工作流成为企业现有技术栈的自然延伸，而非异类插件。

结语：代码越少，逻辑越重

在 Dify 工作流中，代码比例被刻意压缩到 5%~10%，剩下的 90% 是节点连接、变量映射和 Prompt 工程。这恰恰反映了下一代应用开发的趋势：复杂逻辑通过图结构编排，代码仅用于填补 AI 能力的确定性缝隙。

当你下次需要生成周报、运营文案或技术文档时，不妨试试在工作流里把“检索 → 生成 → 清洗 → 润色 → 发布”画出来。你会发现，与其在 Notebook 里处理 JSON 地狱，不如在可视化的 DAG 管道中优雅地“连接”一切。

编排的极致不是写出更复杂的代码，而是定义出更优美的数据流动路径。 希望这篇文章为你揭开了 Dify 工作流的神秘面纱——它不仅是工具，更是一种将不可靠的智能封装为可靠服务的工程思维。