Dify 工作流：把 AI 从“对话玩具”变成“业务引擎”

想象一下：你让 AI 撰写一份竞品分析报告，它需要先搜索最新资讯，再读取昨天上传的销售数据，接着对照历史策略生成对比表格，最后自动发送到飞书群——并且每一步你都能看见、能干预、能调试。这在纯对话界面中几乎不可能，但在 Dify 工作流中，只需拖拽 10 个节点。

一、为什么需要工作流，而不是“一问一答”？

大语言模型（LLM）本质上是无状态的概率函数——输入一段文本，输出下一段文本。它记不住上一步的结果，也主动不去查数据库，更不会定时执行任务。

而真实的业务场景恰恰相反：有状态、多步骤、依赖外部数据、需要确定性分支。

Dify 工作流正是在这个裂缝中架起的桥梁。它将 LLM 的推理能力与传统的逻辑编排（顺序、分支、循环、聚合） 结合，让 AI 不再是“聊完即忘的顾问”，而成为“按流程作业的虚拟员工”。

二、核心抽象：节点即“函数”，画布即“程序”

Dify 工作流采用有向无环图（DAG）模型。每一个节点是一个最小执行单元，节点之间的连线定义了数据流向。官方提供了四大类节点：

每个节点通过 输入 引用上游节点的输出（使用 {{节点名.字段名}} 语法），节点自身产出 输出，供下游消费。

三、三种核心编排范式

1. 顺序管道（Pipeline）

最常见的模式，数据像流水线一样依次经过预处理 → LLM 推理 → 格式化。

# 伪代码逻辑示意（实际在画布上通过连线实现）
开始(用户输入) -> 代码节点(清洗文本) -> LLM节点(生成摘要) -> 结束(返回摘要)

2. 条件路由（Branching）

根据变量值走向不同分支。典型场景：根据用户情绪分发至不同处理策略。

开始(用户反馈) -> 分类节点(判断情绪) 
   -> 正面分支：LLM(生成感谢回复)
   -> 负面分支：LLM(生成安抚话术) + HTTP(创建工单)

3. 循环聚合（Iteration + Aggregation）

处理列表数据时，循环节点逐个处理子项，最后通过变量聚合器合并结果。例如：输入 10 条新闻标题，循环调用 LLM 生成每条的热点评分，最后汇总排序。

四、少量代码的“关键落点”

Dify 工作流推崇“配置优先，代码辅助”。代码只出现在三个最需要灵活性的地方：

1. 代码节点（Code Node）——处理“确定性逻辑”

LLM 处理非结构化文本很强，但做数学计算、JSON 解析、日期格式化却很弱。这时用 Python/JS 代码节点补齐。

# 代码节点示例：解析上游 HTTP 返回的嵌套 JSON，提取关键字段
import json

def main(input_data: dict) -> dict:
    # 假设上游节点名为 "http_request"，返回体在 text 字段中
    raw = json.loads(input_data.get("http_request", {}).get("text", "{}"))
    
    items = raw.get("data", {}).get("list", [])
    # 只保留价格大于 100 的商品名
    filtered = [item["name"] for item in items if float(item.get("price", 0)) > 100]
    
    return {
        "count": len(filtered),
        "names": ", ".join(filtered[:5])  # 最多取前5个
    }

2. 模板语法（Jinja2）——动态构造提示词

在 LLM 节点中，提示词不是静态的，需要动态注入变量。

你是一位资深产品经理。请根据以下用户画像数据，生成 3 条个性化的推荐理由。

用户信息：
- 年龄：{{ age }}
- 最近浏览类目：{{ recent_category }}
- 客单价区间：{{ price_range }}

输出要求：
1. 每点不超过 30 字
2. 语气亲切

3. DSL 导出（YAML）——版本化与 CI/CD

Dify 支持将工作流导出为 YAML 文件，便于 Git 管理。这本身也是“代码”的一部分，虽然不常手工修改，但在批量迁移或环境同步时非常有用。

# 工作流 DSL 片段（导出版本，仅示意）
version: 1.0
nodes:
  - id: start
    type: start
    params:
      inputs:
        - variable: query
          type: string
  - id: llm_1
    type: llm
    model: gpt-4
    prompt: "请回答：{{start.query}}"
    inputs:
      - start.query

五、与“传统互联网架构”的本质差异

这意味着：Dify 工作流的性能瓶颈往往不在编排引擎，而在 LLM 的响应速度。因此，设计时普遍采用“轻量前置过滤 + 大模型按需调用”的策略。

六、生产环境中的关键设计权衡

1. 颗粒度划分：代码节点 vs LLM 节点

• 能用确定逻辑（代码）解决的，绝不用 LLM（省钱、省时、可预期）。
• 需要语义理解或生成的，才交给 LLM。

2. 超大上下文处理

当文档超过 200k token 时，不要一次性塞入 LLM。正确做法：知识检索节点先做向量召回，只将 Top-K 相关片段注入提示词。

3. 人工干预节点（Human-in-the-loop）

关键操作（如付款、发布、删除）前插入“人工审批”节点，工作流暂停，等待外部回调。这是企业级应用的安全底线。

4. 错误处理与重试

Dify 支持节点级别的错误捕获。建议对 HTTP 请求、LLM 调用等不稳定节点开启指数退避重试，并在连续失败后跳转到“兜底回复”节点，而不是直接崩溃。

七、可观测性：工作流不再是“黑盒”

相比传统代码，工作流的可观测性要求更高，因为逻辑散落在画布上。Dify 提供了：

• 执行日志：每个节点的输入输出完整留存
• 耗时分析：精准定位哪个节点（通常是 LLM）消耗了 80% 的时间
• 变量追踪：查看任意时刻变量池中的具体值

推荐在生产环境接入外部监控，将核心指标（工作流成功率、平均耗时、LLM Token 消耗）上报至 Prometheus/Grafana。

八、演进路线：从固定工作流到自主 Agent

Dify 工作流本身是确定性的 DAG——路径在设计时已固定。但未来的趋势是向 Agent 化演进：

• ReAct 模式：工作流不再由人画线，而是由 LLM 动态决定下一步调用哪个工具
• 多智能体协作：不同工作流之间通过事件机制相互触发，形成网状执行图谱

当下，建议从固定工作流起步，待业务边界清晰后，逐步将部分分支节点替换为“提问分类器”或“工具选择器”，向半自主模式过渡。

九、落地建议：别急着画复杂的图

作为架构设计者，我建议遵从“三步走”策略：

1. 复制手工流程：先把团队线下的人工操作（查数据 → 写草稿 → 审核 → 发送）原样映射为工作流节点
2. 替换确定性环节：将“查数据”替换为 HTTP 节点，将“写草稿”替换为 LLM 节点
3. 增加容错与分支：加上异常处理、超时重试、条件分流

每增加一个节点，都要问自己：如果这个节点挂掉，用户感知到什么？ —— 这能帮你决定哪些节点需要冗余配置，哪些节点可以降级。

结语

Dify 工作流不是低代码玩具，而是一种AI 时代的架构范式。它将非确定性的语言模型，封装进确定性的业务管道中，让 AI 的“智慧”与代码的“精确”各司其职。

优秀的 Dify 工作流设计，看起来像一张清晰的电路图：信号从左到右流动，经过放大（LLM）、整流（代码节点）、反馈（迭代），最终输出稳定的结果。它不会让 AI 胡言乱语，也不会让开发者陷入繁琐的胶水代码——它是工程化 AI 最务实的落脚点。