Dify入门实战：零基础搭建AI应用工作流完整指南

什么是Dify：连接大模型与业务的低代码开发平台

Dify是一款帮助开发者和企业快速构建AI应用的开源平台工具。它的核心价值在于：无论是企业级的复杂应用场景，还是个人使用的简单需求，都可以借助Dify的可视化编排能力快速搭建，大幅降低大模型应用开发的门槛。

从行业定位来看，Dify属于LLMOps（Large Language Model Operations） 平台。LLMOps是MLOps（机器学习运维）在大语言模型时代的延伸，涵盖了从Prompt设计与管理、模型接入与编排、应用构建与测试到部署监控的全生命周期管理。传统MLOps关注的是模型训练、特征工程和模型部署，而LLMOps更侧重于Prompt版本管理、上下文窗口优化、多模型切换、成本控制和输出质量评估等大模型特有的运维挑战。Dify作为开源LLMOps平台，其GitHub仓库已获得超过60,000颗星标，拥有活跃的全球开发者社区，支持超过数百种模型的接入，这使得它成为当前最受关注的AI应用开发平台之一。

过去想把大模型能力封装成一个可用的应用，需要写大量代码、处理复杂的接口调用。而Dify将这些工作抽象成了模块化组件，让你能够以「拖拉拽」的方式完成应用构建。这正是低代码AI开发趋势的典型代表。

低代码（Low-Code）开发是近年来软件工程领域的重要趋势，其核心理念是通过可视化界面和预构建模块，让开发者甚至非技术人员以最少的手写代码完成应用构建。Gartner预测到2025年，70%的新应用将使用低代码或无代码技术开发。在AI领域，这一趋势尤为显著——传统的大模型应用开发需要处理Prompt工程、API调用链路、上下文管理、向量数据库集成等大量技术细节，低代码平台将这些复杂性封装为可拖拽的模块，极大降低了开发门槛。Dify、Coze（字节跳动）、Langflow等工具都是这一趋势下的代表产品。

对于零基础的学习者，理解Dify的第一步是明确它的定位——它不是一个大模型，而是一个连接大模型、数据、工具的「中间层平台」。你可以用它来编排业务逻辑、接入外部模型、串联工作流，最终产出一个可对外发布的AI应用。换一个更直观的类比：如果大模型是「发动机」，那么Dify就是帮你把发动机组装成一辆可以上路的汽车的「装配工厂」——它提供底盘（工作流框架）、方向盘（用户交互界面）、仪表盘（监控面板）和油路系统（数据管道），让发动机的动力真正转化为可用的行驶能力。

环境搭建：基于Windows Docker部署Dify

本教程采用的部署方式是基于Windows Docker来部署Dify。除此之外，Dify还支持另外两种部署方式：

• 源码部署：适合需要深度定制的开发者；
• 官方在线页面：无需自行搭建，直接使用官方托管的Dify，界面与本地部署基本一致。

这里需要先了解Docker的基本概念。Docker是一种容器化技术，它将应用程序及其所有依赖项打包到一个标准化的「容器」中运行。与传统虚拟机不同，Docker容器共享宿主机的操作系统内核，因此启动速度快、资源占用少。对于Dify这样包含多个服务组件（Web前端、API后端、PostgreSQL数据库、Redis缓存、Weaviate向量数据库等）的复合应用，Docker Compose可以用一个配置文件定义并一键启动所有服务，避免了逐个手动安装和配置的繁琐过程。这也是为什么Dify官方推荐Docker作为最简便的部署方式。

具体来说，Dify的Docker部署涉及微服务架构的概念。在Dify的docker-compose.yaml文件中，你会看到多个服务被定义为独立的容器：API服务负责处理所有业务逻辑和模型调用；Web服务提供前端用户界面；PostgreSQL作为Dify平台自身的关系型数据库，存储应用配置、用户信息、对话历史等结构化数据；Redis作为内存缓存和消息队列，处理会话状态管理和异步任务调度；Weaviate则是Dify内置的向量数据库，专门用于存储文档的向量嵌入（Embedding），支撑知识库的语义检索功能。这些服务通过Docker内部网络互相通信，对外则只暴露Web界面和API的端口。理解这一架构有助于你在遇到问题时快速定位是哪个服务出了故障。

这里有一个关键区别需要注意：如果使用官方在线页面，而你的AI应用又需要访问本机数据库或本地环境，就必须借助内网穿透工具，把本机IP暴露到公网上供在线页面调用。内网穿透（NAT Traversal / Reverse Proxy Tunneling）是一种将局域网内的服务暴露到公网的技术手段。在家庭或企业网络中，设备通常位于路由器的NAT（网络地址转换）之后，外部网络无法直接访问这些设备。内网穿透工具（如frp、ngrok、花生壳等）通过在公网服务器上建立一个中转隧道，将外部请求转发到内网设备上，从而实现外网访问内网服务的效果。在Dify场景中，如果使用官方在线页面但需要访问本机MySQL数据库，就需要通过内网穿透让云端的Dify服务能够触达本地数据库。

而本地Docker部署则天然可以访问本机资源，因此生产环境中更推荐自行部署到本机或公司内部服务器，使用起来更方便、更安全。

为什么需要安装MySQL 8

教程中专门讲解了在Windows上安装MySQL 8的步骤（如果你已经掌握可以跳过）。原因在于：后续在Dify中构建的AI应用，往往需要读取数据库中的数据来完成AI交互任务，因此需要一个可用的数据库环境。

MySQL的部署位置非常灵活：可以直接装在Windows上，也可以基于Docker部署，甚至放在VMware虚拟机中都没有问题。因为Docker安装完成后，Dify的网络既能与Windows本机的MySQL通信，也能与虚拟机中的数据库通信。换句话说，MySQL放在哪里都可以，关键是能被Dify正常访问到。完成安装后，还需要配置Dify连接MySQL的相关参数，才能让AI应用顺利读取数据库数据。

需要注意的是，这里提到的MySQL是作为业务数据库供AI应用读取使用的，与Dify自身内置的PostgreSQL数据库（用于存储Dify平台的配置、应用定义等元数据）是两个不同的用途，不要混淆。在实际企业应用中，业务数据库可能不仅仅是MySQL，还可能是SQL Server、Oracle、MongoDB等各类数据库。Dify通过工作流中的数据库查询节点或自定义工具（通过HTTP API中转） 来实现与这些外部数据源的交互，这种设计使得Dify可以灵活对接企业已有的数据基础设施。

Dify的五大核心应用类型详解

打开Dify创建应用时，你会看到五种应用类型，这也是整个Dify学习体系的主干。

基础应用：聊天助手与文本生成

聊天助手是最简单的应用形式，本质就是与AI模型进行对话交互。文本生成则用于一次性生成内容，比如撰写文章、生成文档、创作小说等。这两类应用逻辑清晰、上手最快，非常适合作为Dify入门的第一站。

从技术角度看，聊天助手和文本生成的底层调用方式有所不同：聊天助手使用的是大模型的Chat Completion接口，会维护一个消息历史列表实现多轮对话的上下文记忆；而文本生成则更类似于Completion接口的单次调用，输入一段提示词后直接获得完整输出，不保留对话历史。理解这一区别有助于你在实际应用中选择合适的类型。

在构建这两类应用时，Prompt工程（Prompt Engineering） 的质量直接决定了应用效果。Prompt工程是一门研究如何设计有效提示词以引导大模型产生高质量输出的学科。在Dify中，你需要为每个应用编写系统提示词（System Prompt），它相当于给AI设定角色和行为规则。高质量的系统提示词通常包含以下要素：角色定义（你是一个专业的XX助手）、任务描述（你的职责是XX）、行为约束（不要做XX）、输出格式要求（以Markdown格式输出）。此外，Few-shot Learning（少样本学习） 技巧也很实用——在提示词中提供几个输入-输出的示例，帮助模型理解你期望的响应模式。而Chain-of-Thought（思维链） 提示则引导模型分步骤推理，对于复杂问题的处理效果显著提升。Dify的界面提供了专门的提示词编辑区和变量插入功能，让你可以方便地构建和迭代这些提示词。

进阶应用：Agent智能体

Agent智能体是基础应用中能力最强的类型。它与聊天助手、文本生成的最大区别在于——Agent可以调用外部工具，能够系统地组合多个工具来完成用户下达的复杂指令。

Agent（智能体）是当前AI应用开发中最前沿的概念之一，其理论基础可以追溯到ReAct（Reasoning + Acting）框架。传统的大模型对话只能基于已有知识生成文本，而Agent引入了「工具调用」机制——大模型在推理过程中可以判断何时需要调用外部工具（如搜索引擎、代码执行器、数据库查询、API调用等），获取实时信息后再继续推理。这一机制由OpenAI的Function Calling功能推动普及。Agent的核心循环是：观察→思考→行动→观察，这使得它能够处理远超纯文本生成能力的复杂任务。

举例来说，你可以让Agent先去爬取网页内容，再对抓取的数据进行分析总结，整个流程由智能体自主编排完成。这种「工具调用+自主决策」的能力，正是Agent区别于普通对话应用的核心优势。在Dify中，你可以为Agent配置多种内置工具和自定义工具，智能体会根据用户的输入自主决定调用哪些工具、以什么顺序执行，最终将结果整合后返回给用户。

值得注意的是，Dify中的Agent支持两种推理策略：Function Calling模式和ReAct模式。Function Calling模式依赖大模型原生的函数调用能力（如OpenAI、Claude等模型内置支持），模型会以结构化JSON格式输出工具调用指令，执行效率高且格式稳定；ReAct模式则通过提示词引导模型以「思考-行动-观察」的文本模式进行推理，兼容性更广，即使模型不原生支持Function Calling也能使用。选择哪种模式取决于你接入的大模型的能力特性。

工作流：ChatFlow与Workflow

Dify中最核心的应用类型当属工作流。工作流分为两种：

• ChatFlow（聊天流）：支持与工作流进行多轮对话交互；
• Workflow（工作流）：面向一次性任务，输入后直接输出结果。

两者的核心区别在于交互方式——ChatFlow是持续对话式的，Workflow是单次执行式的。虽然当前版本中工作流仍标注为测试版，但实际使用已经相当稳定。

构建工作流的关键在于理解**节点（Node）**的概念。所谓节点，就是组成工作流程的一个个功能模块。节点化编排（Node-based Orchestration）是一种将复杂流程拆解为独立功能单元并通过有向图连接的设计模式。每个节点负责一个特定的功能（如LLM调用、条件判断、数据转换、HTTP请求、知识库检索等），节点之间通过输入/输出参数传递数据。这种模式在软件工程中有悠久历史，从Unix管道、Apache Airflow的DAG（有向无环图）到可视化编程工具Node-RED，都采用了类似思想。在AI应用场景中，节点化编排让开发者可以精确控制数据在各个处理环节的流转方式，比如先进行意图识别，再根据结果分支执行不同的处理逻辑，最后汇总输出——这种精细化控制是纯对话式AI难以实现的。

创建ChatFlow或Workflow时，你需要把不同的节点拼接组合，形成完整的处理流程。教程中会重点讲解十几个最常用的节点，几乎覆盖官网提供的大部分节点类型，并为每个节点配备详细的实战案例。以下是Dify工作流中几个最核心的节点类型简介：

• LLM节点：调用大语言模型进行文本生成或分析，是工作流中最常用的节点；
• 知识检索节点：从已创建的知识库中检索相关文档片段，是实现RAG应用的关键；
• 条件分支节点（IF/ELSE）：根据变量值进行逻辑判断，实现工作流的分支处理；
• HTTP请求节点：调用外部API获取数据或触发外部操作；
• 代码执行节点：运行Python或JavaScript代码片段，用于数据转换和复杂逻辑处理；
• 变量聚合节点：将多个分支的结果汇总合并；
• 模板转换节点：使用Jinja2模板语法格式化输出内容。

理解这些节点的功能和组合方式，是掌握Dify工作流开发的核心。

接入大模型：推荐使用付费API

所有Dify AI应用都需要与大模型交互，因此接入模型是绕不开的一步。这里给出的建议非常务实：优先接入付费的外部模型API，例如DeepSeek、ChatGPT，或阿里通义千问、百度文心一言（后两者通常提供百万级别的免费token额度）。

这里需要理解Token的概念及其计费机制。Token是大语言模型处理文本的基本单位，并非简单等同于一个字或一个词。对于英文，一个token大约对应4个字符或0.75个单词；对于中文，一个汉字通常被编码为1-2个token。大模型API的计费基于输入token和输出token的数量分别计价。以DeepSeek-V3为例，其API价格约为输入0.5元/百万token、输出2元/百万token（缓存命中时更低），这意味着一次包含数百字的对话成本可能不到0.01元。

不要因「付费」二字而紧张——以DeepSeek为例，充值10元可以用相当长的时间。实测充值10元后使用了很久才消耗不到1元，成本极低。

在Dify中接入模型API的过程也很简单：进入「设置」→「模型供应商」页面，选择你要接入的模型厂商（Dify已预集成了OpenAI、Anthropic、DeepSeek、阿里云百炼、智谱AI等数十家供应商），填入API Key即可完成配置。API Key的安全管理至关重要——API Key相当于你账户的访问密码，一旦泄露，他人可以用你的额度调用模型产生费用。建议遵循以下安全实践：不要将API Key硬编码在代码中或上传到GitHub等公开仓库；定期轮换密钥；在模型供应商后台设置调用速率限制（Rate Limit）和月度预算上限，防止异常调用产生高额账单。Dify平台本身会将API Key加密存储在其PostgreSQL数据库中，本地部署时数据不会离开你的服务器，这也是本地部署比在线平台更安全的原因之一。

那为什么不推荐使用本机模型？Dify确实支持整合Ollama本地模型（比如通过Ollama管理本地部署的开源模型），但对于普通个人电脑而言，本地能跑的模型参数量通常较小，实际生成效果不够理想。

Ollama是一款开源的本地大模型管理工具，它简化了在个人电脑上下载、运行和管理开源大语言模型的流程。通过Ollama，用户可以一键部署Llama、Qwen、Mistral等开源模型。然而，大模型的推理能力与参数量密切相关——参数量越大，模型通常越「聪明」，但对显存和算力的需求也越高。一台配备8GB显存的消费级显卡通常只能流畅运行7B（70亿参数）级别的模型，而效果较好的模型往往需要70B甚至更大的参数量。这就形成了一个现实矛盾：个人电脑能跑的模型效果有限，效果好的模型个人电脑跑不动。

当然，如果你拥有企业级GPU集群，能部署像DeepSeek开源的大参数模型（最大版本下载后可达400多GB），那么本地大模型的效果同样出色，完全可以用来构建企业级AI应用。对于企业而言，本地部署大模型的优势在于数据不出域、延迟更低、长期使用成本可控，但前期硬件投入较大，需要根据实际业务量和安全合规需求综合评估。目前企业级本地部署常见的方案包括使用NVIDIA A100/H100 GPU集群配合vLLM或TGI（Text Generation Inference）等高性能推理框架，通过OpenAI兼容接口对外提供服务，Dify可以无缝对接这些本地推理服务。

应用发布：从本地开发到公网上线

在Dify中构建好的应用，并不局限于在本地Dify页面内使用。Dify提供了多种发布方式，让应用真正具备对外服务的能力：

• 发布为公开Web站点：生成一个所有人都能访问的链接（本地部署需配合内网穿透工具）；
• 嵌入到已有网站：将AI应用以组件形式（如iframe或JavaScript SDK）集成到你自己的网站中，用户可以直接在你的网站上与AI交互，体验与原生功能无异；
• 以API形式调用：Dify会为每个应用生成RESTful API接口，供外部程序直接调用你构建好的AI应用能力。这意味着你可以在移动App、微信小程序、企业内部系统等任何支持HTTP请求的环境中集成Dify应用。

关于API调用方式，这里值得进一步展开。Dify为每个应用生成的API遵循RESTful设计规范，支持流式（Streaming）和阻塞式（Blocking）两种响应模式。流式模式通过Server-Sent Events（SSE）协议实时推送模型生成的每个token，用户可以看到文字逐字出现的「打字机效果」，体验更加流畅；阻塞式模式则等待模型完整生成后一次性返回结果，适合后端系统间的集成调用。在调用API时，你需要在请求头中携带Dify分配的API Key进行认证，并通过请求体传入用户输入、会话ID（用于多轮对话的上下文关联）等参数。Dify还提供了Python和JavaScript的官方SDK，进一步简化了API集成的开发工作。

这一环节实现了从「开发」到「落地」的完整闭环，让Dify构建的AI应用真正产生业务价值。值得一提的是，Dify还提供了应用监控和日志功能，你可以在后台查看每次用户交互的详细信息，包括token消耗、响应时间、用户满意度等指标，为后续的应用优化提供数据支撑。这些监控数据对于持续改进应用质量至关重要——例如，通过分析用户标记为「不满意」的对话记录，你可以发现提示词的不足之处并进行针对性优化；通过统计token消耗趋势，你可以预估成本并及时调整模型选择策略。

Dify学习路径总结

综合来看，Dify入门的完整学习路径可以概括为以下六个阶段：

1. 认识Dify——理解平台定位与核心特点；
2. 环境搭建——基于Windows Docker部署Dify，安装并配置MySQL数据库；
3. 接入大模型——推荐使用低成本的付费API（如DeepSeek、通义千问）；
4. 掌握五大应用类型——聊天助手、文本生成、Agent智能体、ChatFlow、Workflow，每个类型都配备实战案例；
5. 工作流节点精讲——十几个节点案例覆盖核心用法；
6. 应用发布——将构建好的AI应用对外部署上线。

对于想入门大模型应用开发的开发者而言，Dify是一个从零起步、门槛极低的切入点。相比直接调用API编写代码，Dify用可视化编排的方式让你把精力集中在业务逻辑本身，非常适合作为AI应用开发的起步工具。

在掌握Dify的基础用法之后，你还可以进一步探索以下进阶主题，逐步构建更强大的AI应用：

• RAG（Retrieval-Augmented Generation，检索增强生成）知识库搭建：RAG是解决大模型「知识截止」和「幻觉」问题的核心技术方案。其原理是在用户提问时，先从企业知识库中检索出与问题最相关的文档片段，然后将这些片段作为上下文与用户问题一起传递给大模型，让模型基于真实资料生成回答，而非仅凭训练数据「编造」内容。在Dify中构建RAG应用的流程是：首先上传文档（PDF、Word、网页等）到Dify的知识库模块，Dify会自动完成文档的分块（Chunking）、向量嵌入（Embedding）并存入Weaviate向量数据库；随后在工作流中使用「知识检索」节点，系统会将用户的问题转换为向量，与知识库中的文档向量进行相似度匹配，找出最相关的文本片段，再将其注入到LLM节点的上下文中。这一流程使得你的AI应用能够基于企业私有知识回答问题，是当前最实用的大模型企业落地方案之一。

• 多Agent协作：让多个具有不同专长的Agent协同完成复杂任务，例如一个Agent负责信息收集，另一个负责数据分析，第三个负责报告撰写。

• 复杂工作流编排：包括并行处理、循环迭代、错误处理和人工审核节点等高级功能，构建生产级别的自动化流程。

核心要点