从零到一的 Dify AI 工作流搭建指南

从零到一的 Dify AI 工作流搭建指南

Dify 是一个知名的 AI 工作流开发平台，官方文档里，Dify 的全称是「Do it for you」。和 Coze 这类低代码 AI 工作流开发平台类似，Dify 的大多数功能几乎不需要使用者拥有编程技能。Dify 官方设计好了众多开箱即用的工作流节点，通过插件市场提供丰富的三方生态，是快速上手 AI 工作流搭建的理想平台。

本文开题至今，Dify 已经从 1.0.0 走到了 1.8.1，即将迈进 2.0.0 (beta) 的里程碑。文章反复修改，最终我决定，还是从零到一，探讨 Dify 应用到工作流程时的基本概念和小技巧。

Dify 的定位

在 Dify 之外，节点 + 连线形态的可视化 AI 工作流产品还有很多选择。上有对于代码和可视化结合更完善、节点自定义程度更高的 n8n，下有无需自己操心模型接入和发布的 Coze，但我认为，Dify 在强大与易用之前取了一个颇为巧妙的平衡点：自托管足够简单灵活、工作流设计足够覆盖大多数 PoC 场景。

和 Dify 定位类似的，还有 MaxKB、RAGFlow 等产品。但这些产品由于主打「RAG」而非「Workflow」，因此在节点自定义能力、单步调试、复杂工作流编排和插件开发生态等方面，和 Dify 都尚有差距。如果你只是想要实现一个基础的、基于知识库的「一问一答」场景，MaxKB 们可能已经足以满足你的需求。可是，如果你想要在一个 Workflow 中实现稍复杂的业务流程的自动化处理，那么不妨看看 Dify 和 n8n。

Workflow vs Chatflow

部署好你的 Dify，新建一个应用，你会看到 Dify 的两大应用类型：工作流（Workflow）和对话工作流（Chatflow）。

Workflow 和 Chatflow 最大的区别在于，前者只能实现「一问一答」的单轮运行，适合用于翻译、总结等只需要一次输入一次输出，或多次调用之间无联系的场景；而 Chatflow 则和 Chatbot 类似，节点具备跨轮次的记忆能力，可以实现连续的、多次的对话，适合用于多轮信息收集、需要上下文保持的对话机器人等场景。

核心节点详解

强制类型转换

「模板转换」节点的输出变量只有一个 output，且类型为 string。然而，模板转换节点支持任意类型节点的输入。因此，如果你需要把数组、对象等非字符串类型的变量转换为字符串类型，增加一个模板转换节点就是最快的方法。这对于只支持插入 string 类型的场景（如 LLM 节点的 Prompt）相当有用。

代码执行

代码执行可能是 Dify Workflow 中最强大的节点。得益于 Dify 的沙盒环境，代码执行节点可以运行 Python 和 JavaScript 代码。通过在 sandbox 挂载的 volume 中修改 requirements.txt 文件，你还能提前往这个沙盒环境中安装你需要的任何第三方依赖。

对于 Python 代码执行节点，需要遵循类似 def main(arg1: type, arg2: type) -> dict 的格式。如果你懒得琢磨怎么写代码，不妨求助于 LLM。Dify 本身提供了 Code Generator 功能，点击代码输入框右上角的入口即可使用 LLM 辅助生成代码。

迭代与循环

迭代与循环是 Dify 区别于 MaxKB 这类「重 RAG 轻 Workflow」的产品的一大特色。平心而论，Dify 在迭代与循环的功能设计上不如 n8n 直观和强大，但如果你理解了 Dify 的 Workflow 哲学，相信你一定会喜欢这个功能。

LLM 节点

作为一个 AI Workflow 构建平台，LLM 节点就是 Dify 中最「AI」的一块拼图。Dify 发展至今，LLM 节点已经支持了文字、图片、音频等多模态的输入输出，具备相当高的可用性。

为了解决结构化输出的问题，OpenAI 等大模型厂商自很早开始就在增强模型的结构化输出能力。从最原始的 Prompt 约束到后训练对齐，再到通过强制选择 Token 的方式强制模型输出符合要求的 JSON，模型的结构化输出能力越来越稳定，越来越可靠。和参数解析器依赖 Function Call 不同，Dify 的结构化输出没有使用独立节点，而是直接放置在了 LLM 节点中，直接调用模型原生的 Structured Output 能力。

父子分块

实际上，我认为父子分块是一个非常聪明的功能。通过父子分块，其实相当于允许用户变相给 chunk 中的某一部分内容「增加权重」。实现类似搜索引擎一样的，使用 Keyword 召回父分块的效果。

在传统的分块检索中，如果需要在一个 chunk 内召回其中的一行文本（比如 Title），其检索置信度会受到 chunk 长度、chunk 内其他文本等因素的影响。因此，分块检索在此时难以保证召回的稳定性。而在采用父子分块并妥善设置分段标识后，Workflow 可以根据更小粒度的文本进行检索召回。在知识库检索前搭配参数提取器进行 Query 改写或字段提取，大多数情况下都可获得不错的检索效果。

插件生态

Dify 的插件生态发展至今，几乎你能想到的所有需求都已经有了现成的插件可用，哪怕确实没有现成插件，借助 Dify 官方提供的插件开发 Prompt 和 Claude Code，任何人都能用一个小时开发出一个包含基础功能的 Dify 插件。

总结

Dify 虽然属于低代码平台，但其设计使其在工作流上的体验具备比 MaxKB、Coze 这类竞品更丰富的复杂编排能力，因此也对用户的程序逻辑和计算机思维提出了更高的要求。

低代码平台往往不能用于支撑生产业务，因此许多时候被程序员嗤之以鼻。然而，从验证想法的视角而言，低代码平台，特别是以 Dify、Coze、n8n 为代表的，以工作流编排方式构建运行逻辑的产品，实则极大降低了验证的难度和成本。想法是否「能做」，相比 Figma 上一张冷冰冰的原型图，用 Dify 构建一个能够与用户交互、能够实际运行的 Demo，会让想法看起来有说服力的多。