Dify工作流搭建教程：从本地部署到AI应用实战

为什么选择Dify作为AI应用开发平台

在AI应用开发领域，如何快速将大模型能力落地为可用的产品，一直是开发者面临的核心问题。Dify作为一款开源的低代码AI应用开发平台，正在成为这个问题的热门答案。

据B站UP主在本期教程中的介绍，Dify本质上是一个AI平台，通过它可以快捷方便地构建从个人级到企业级的AI应用。与直接调用大模型API相比，Dify提供了可视化的编排界面、知识库管理、工具调用等完整的能力体系，大幅降低了AI应用的开发门槛。

Dify的部署方式灵活多样。教程中提到三种可选方案：基于Windows Docker本地部署、基于源码部署，以及直接使用官方在线版本。UP主特别建议采用本地Docker部署，原因在于本地部署可以让Dify直接访问本机的数据库和其他环境资源；而在线版本若要访问本机资源，则需要借助内网穿透工具将本机IP暴露到公网，配置成本更高。

低代码AI应用开发平台是一类通过可视化界面和预置组件，让开发者无需或仅需少量编写代码即可构建AI应用的工具。这类平台通常封装了大模型调用、提示词管理、上下文编排、知识库检索等底层能力，将复杂的技术细节抽象为可拖拽的节点或表单配置。其核心价值在于降低开发门槛、缩短从想法到产品的周期，同时保留一定的扩展性以供专业开发者进行深度定制。Dify正是这一赛道的代表性开源项目，它允许用户在浏览器中完成从模型接入到应用发布的全流程，并支持社区版自托管，兼顾了易用性与数据可控性。

内网穿透是一种将局域网内部服务暴露到公网的技术手段，常用于本地开发环境需要被外部访问的场景。其原理是通过一台具有公网IP的中转服务器建立隧道，将公网请求转发至内网主机。常见的工具有frp、ngrok、ZeroTier等。在Dify本地部署的场景中，如果希望将构建的应用发布到公网，就需要借助内网穿透，否则外部用户无法直接访问运行在本地Docker容器中的服务。

部署前的环境准备：Docker与MySQL

本地部署Dify需要先搭建好基础环境。教程采用的方案是在Windows系统上安装Docker来部署Dify，同时安装MySQL 8作为后续AI应用的数据存储。

MySQL的安装之所以放在Windows本机而非Docker容器中，是因为Dify中构建的AI应用需要读写数据库数据。将MySQL安装在Windows节点上，Docker中的Dify网络可以直接与Windows的MySQL通信，也能与Windows上VMware虚拟机中的MySQL通信，部署位置相当灵活。当然，MySQL同样可以基于Docker部署，选择哪种方式取决于你的实际环境。

环境准备好之后，还需要在Dify中配置MySQL连接，确保后续的AI应用能够正常读取数据库中的数据并进行交互。这部分配置虽然不复杂，但连接参数的正确性直接影响应用能否运行。

Docker是一种轻量级的容器化技术，它允许开发者将应用及其依赖打包成标准化的镜像，并在任何支持Docker的环境中一致地运行。与虚拟机不同，Docker容器共享宿主机的操作系统内核，因此启动更快、资源占用更少。在Dify的部署中，Docker负责运行Dify的核心服务（如API、Worker、Web前端）以及可能用到的中间件（如Redis、Weaviate等向量数据库）。通过Docker Compose编排，用户可以一条命令拉起整套服务，极大简化了部署流程。需要注意的是，容器内的网络与宿主机网络默认隔离，因此若MySQL安装在宿主机上，Dify容器需要通过宿主机的IP或特殊网络配置才能访问，这也是教程强调连接参数正确性的原因。

Dify的五大核心应用类型

在Dify中创建应用时，平台提供了五种应用类型。理解它们的区别，是选择正确方案的前提。

聊天助手是最基础的类型，本质就是与AI模型进行对话，适合搭建客服机器人、问答系统等场景。文本生成应用则专注于内容创作，可以生成文章、文档、小说、故事等。UP主强调，这三种基础应用在教学时都会配备实际案例，逐步演示如何操作。

Agent智能体与聊天助手、文本生成的核心区别在于工具调用能力。Agent可以自主调用外部工具来完成用户指令，比如先爬取网页内容再进行数据分析，这种多步骤任务正是Agent的强项。

剩下的两种就是工作流类型的应用：Chatflow（聊天流）和Workflow（工作流）。两者的区别用一句话概括：Chatflow支持与工作流进行持续对话，而Workflow只能执行一次性的输入输出。虽然听起来简单，但实际构建时需要理解每个节点的作用和连接逻辑。

Agent智能体与普通聊天助手的本质区别在于其具备“自主决策+工具调用”的能力。在Dify中，Agent可以配置多个外部工具（如搜索引擎、天气API、代码执行器、自定义HTTP接口等），并根据用户指令自动规划调用哪些工具、以什么顺序调用，最终整合结果回复用户。这种能力依赖于大模型的Function Calling或ReAct推理框架。相比之下，聊天助手仅能基于对话历史和知识库进行回复，无法主动与外部系统交互。因此，Agent更适合需要多步骤操作、动态获取实时数据的复杂场景，例如“查询明天北京天气并推荐穿搭”或“爬取某网页并总结要点”。

Chatflow与Workflow是Dify中两种工作流形态。Workflow是单向的输入到输出流程，适合处理一次性任务，如批量文档摘要、数据清洗等；Chatflow则在Workflow的基础上增加了对话记忆和循环交互能力，用户可以在流程执行过程中多次输入，系统根据上下文继续推进。简单理解：Workflow像一条自动化流水线，启动后跑完即止；Chatflow像一位可多轮对话的流程助手，能根据用户反馈调整后续步骤。选择哪种类型取决于应用是否需要持续的人机交互。

工作流节点：Dify进阶的核心

工作流是Dify中最强大的功能模块，而节点是工作流的基本组成单元。每一个节点代表一个功能模块，多个节点串联起来就构成了完整的AI处理流程。

教程中提到，Dify官方提供的节点几乎覆盖了绝大部分使用场景。常见的节点包括大模型调用、条件判断、代码执行、知识库检索、HTTP请求等。UP主计划为每种常用节点配备详细案例，帮助学习者理解节点之间的数据流转和参数配置。

整套课程在工作流部分预计配备十几个节点案例，外加Chatflow和Workflow的完整项目案例，覆盖从简单到复杂的各类应用场景。这种"节点讲解+案例实操"的结构，对于希望从入门到精通的开发者来说，路径比较清晰。

大模型接入：付费模型与本地模型的权衡

构建AI应用绕不开大模型接入这个环节。UP主给出了明确的建议：优先使用付费模型API，而非本地部署的小模型。

具体来说，DeepSeek^广告和ChatGPT是付费模型中的推荐选项。UP主用自己的实际使用情况做了说明——充值10元使用很久都没用完1元，成本远低于很多人的预期。如果想要免费方案，百度文心一言和阿里通义千问^广告在注册后会提供百万级别的免费Token，对于学习和测试来说完全够用。

本地模型方面，虽然Dify支持通过Ollama接入本地部署的模型，但UP主坦言，本地能跑的模型参数通常较小，效果难以满足生产需求。当然，如果企业拥有集群级别的算力资源，能够运行像DeepSeek开源的超大参数模型（下载体积可达数百GB），那么本地部署的模型效果也能达到较好水平，这条路对企业用户依然可行。

Ollama是一个专为本地运行大语言模型设计的开源工具，它简化了模型的下载、加载和推理服务部署。用户可以通过Ollama在个人电脑上运行Llama、Qwen、DeepSeek等开源模型，并通过兼容OpenAI的API接口对外提供服务。Dify支持直接接入Ollama作为模型供应商，从而调用本地模型。然而，本地模型的性能受限于硬件资源：消费级显卡通常只能流畅运行7B~14B参数量的模型，而更大参数的模型需要多卡或集群。因此，教程建议优先使用付费API，除非企业具备足够的算力基础设施。对于学习与测试，Ollama是零成本探索模型能力的良好起点。

应用发布：从本地到线上

Dify构建的应用并不局限于平台内部使用。教程最后介绍了几种发布方式：将应用发布为公开站点并生成可访问链接，嵌入到自有网站中，或通过API接口供其他系统调用。

这些发布方式让Dify的应用具备了对外服务的能力。不过需要注意的是，如果采用本地部署方案，将应用发布到公网同样需要内网穿透工具的配合。对于企业内部使用场景，本地部署加上局域网访问可能已经足够。

总结来看，这套教程的内容结构覆盖了从环境搭建、模型接入、应用构建到发布上线的完整链路。对于希望系统掌握Dify的开发者，课程路径从基础应用入手，逐步深入到工作流和节点编排，最终实现完整AI应用的落地交付。