Dify入门教程：五大应用类型与AI工作流搭建全指南

什么是 Dify

Dify 是一款低代码 AI 应用开发平台，核心价值在于让开发者甚至非技术人员都能快速构建基于大语言模型的 AI 应用。无论是企业级的复杂业务场景，还是个人自用的轻量级工具，Dify 都能提供完善的支持。

简单来说，Dify 将大模型应用开发中繁琐的底层工作（提示词管理、模型调用、上下文处理、数据检索等）封装成可视化模块，用户通过拖拽和配置就能完成过去需要大量代码才能实现的功能。这也是它区别于纯代码开发框架（如 LangChain）的最大特点——门槛低、上手快、可视化程度高。

Dify 部署方式：三种选择

Dify 的部署方式相当灵活，主要有以下三种路径：

官方在线版

最简单的方式是直接使用 Dify 官方提供的在线平台。在线版与本地自建版界面几乎完全一致，功能也基本相同。不过需要注意，如果构建的 AI 应用需要访问本机数据库或本地环境，在线版需要借助内网穿透工具将本机 IP 暴露到公网，才能正常访问本地资源。

Docker 本地部署

基于 Windows Docker 的部署方案是许多开发者的首选。这种方式的优势在于，Dify 运行在本机后可以直接与本机安装的 MySQL 等服务无缝通信。

Docker 是一种基于容器技术的虚拟化方案，与传统虚拟机（如 VMware）的核心区别在于：容器共享宿主机操作系统内核，启动速度更快、资源占用更少。Dify 官方提供了 docker-compose.yml 配置文件，其中预先定义了 Dify 所需的全部服务（Web 前端、API 服务、Worker 进程、PostgreSQL 元数据库、Redis 缓存、Weaviate 向量数据库等），执行一条 docker compose up -d 命令即可一键拉起全部依赖。在 Windows 上，推荐通过 Docker Desktop 来管理容器，它提供了图形化界面，方便查看各服务的运行状态和日志。容器内部服务之间通过 Docker 虚拟网络通信，而容器访问 Windows 宿主机上的 MySQL 时，需要使用特殊地址 host.docker.internal 代替 localhost，这是初学者最常遇到的连接问题。

源码部署

对于有深度定制需求的开发者，也可以选择基于源码部署 Dify。这种方式灵活性最高，但配置门槛也相对更高。

在生产环境中，建议采用本地自行部署的方式。部署到公司内部服务器后，团队协作更加方便，数据安全也更加可控。

数据库配置：Dify 为什么需要 MySQL

很多初学者会疑惑：搭建 Dify 为什么还要单独安装 MySQL？

原因在于，在 Dify 中构建的 AI 应用往往需要读取和交互业务数据库中的数据。比如做一个能查询公司订单的智能助手，就必须让 AI 应用与数据库打交道。因此 MySQL 8 在 Windows 上的安装配置是搭建过程中不可跳过的一步。

MySQL 的部署位置非常灵活：

• 直接安装在 Windows 本机
• 基于 Docker 部署
• 安装在 VMware 虚拟机中

Docker 安装完成后，Dify 的网络既能与 Windows 本机的 MySQL 通信，也能与虚拟机中部署的数据库通信，数据库放在哪里都可以正常工作。安装完数据库后，还需要在 Dify 中进行连接配置，AI 应用才能顺利读取数据。

Dify 五大核心应用类型详解

Dify 在创建应用时提供了五种主要类型，这是整个平台功能的核心所在：

聊天助手（Chatbot）

最基础的应用形态，本质是与 AI 大模型进行对话交互，适合构建客服机器人、知识问答等场景。

文本生成（Text Generation）

专注于内容生产，比如撰写文章、生成文档、创作小说等一次性的文本输出任务。

Agent 智能体

Agent 智能体是五种类型中能力最强的一类。与聊天助手和文本生成不同，Agent 智能体最大的特点是能够调用外部工具，系统性地完成用户输入的复杂指令。例如，让它先爬取网页内容，再对内容进行分析总结——这一系列多步骤操作，Agent 都能自主规划并执行。

Agent 智能体的底层逻辑基于 ReAct（Reasoning + Acting）或 Function Calling 机制：模型先对任务进行推理分解，决定调用哪个工具、传入什么参数，获得工具返回结果后再继续推理，直到任务完成。这个「思考→行动→观察→再思考」的循环使 Agent 能够处理需要多步决策的复杂任务，而不仅仅是单次问答。Dify 中内置了搜索引擎、网页爬取、代码解释器、图表生成等常用工具，也支持开发者通过 HTTP 请求节点或自定义插件的方式接入第三方 API，极大扩展了 Agent 的能力边界。与 Workflow 相比，Agent 的执行路径是由模型动态规划的，而 Workflow 的节点顺序是开发者预先编排好的——这是两者最本质的区别。

Chatflow（聊天工作流）与 Workflow（任务工作流）

工作流是 Dify 中最重要也最强大的功能模块，包含两个部分：

• Chatflow（聊天流）：在工作流基础上支持多轮对话交互，适合需要持续沟通的场景
• Workflow（工作流）：执行一次性的任务处理，直接输出最终结果，适合批量处理场景

两者的核心区别在于交互方式——Chatflow 支持持续对话，Workflow 更偏向一次性的批处理输出。

Dify 工作流节点：搭建流程的基本单元

构建 Chatflow 或 Workflow 时，需要将一个个功能模块串联起来组成完整的流程，这些模块称为节点（Node）。

Dify 提供了丰富的节点类型，几乎涵盖了平台的大部分功能。常见的节点包括 LLM 节点、条件判断节点、代码执行节点、HTTP 请求节点等，每个节点在工作流中承担不同的职责。通过合理组合这些节点，就能搭建出满足各种业务需求的 AI 工作流。

模型接入建议：优先选择付费云端 API

所有 AI 应用都需要与大模型交互，接入模型是搭建 Dify 应用的第一步。以下是经过实践验证的接入建议：

优先使用付费的云端大模型 API，比如 DeepSeek、ChatGPT，或者百度文心一言、阿里通义千问等提供免费 token 额度的国产模型。这些平台通常赠送百万级别的免费 token，足够学习阶段使用。

对于「付费」二字不必紧张——以 DeepSeek 为例，充值 10 元可以使用很长时间，实际开发测试中消耗往往不到 1 元。相比之下，不建议初学者使用本机小模型（如通过 Ollama 部署的模型），因为参数量较小的本地模型生成效果往往不够理想，容易影响学习体验。

当然，如果拥有高性能机器或企业级集群，完全可以部署大参数开源模型来构建企业级应用，Dify 同样支持接入本机 Ollama 部署的模型。

Token 是大模型计费和上下文管理的基本单位，并非严格等同于字数或词数。对于中文，通常 1 个汉字约对应 1.5–2 个 token；对于英文，1 个单词大约对应 1–1.3 个 token。模型的「上下文窗口」（Context Window）也以 token 数量衡量，例如 DeepSeek-V3 支持 64K token 的上下文，意味着单次对话可以携带约 3–4 万汉字的历史记录和文档内容。在 Dify 工作流中，每次节点调用 LLM 都会消耗 token，因此合理设计提示词长度和对话历史截断策略，是控制成本的关键。对于学习阶段，阿里通义千问、百度文心一言等国产模型提供的免费额度通常在百万 token 以上，足以完成大量实验而不产生实际费用。

Dify 应用发布：从本地走向生产

Dify 构建的应用不只能在本地平台内部使用，还提供了多种发布方式将应用推向实际用户：

• 发布为公开 Web 站点：生成一个所有人都能访问的链接（需配合内网穿透）
• 嵌入到现有网站：将 AI 应用以组件形式集成到自己开发的网站中
• 通过 API 方式调用：以标准接口形式对接其他业务系统

这意味着在 Dify 中搭建的应用可以真正走向生产环境，服务于实际用户和业务场景。

总结

Dify 作为一款低代码 AI 应用开发平台，将大模型应用开发的门槛大幅降低。从聊天助手、文本生成、Agent 智能体，到 Chatflow 和 Workflow 两类工作流，五大应用类型覆盖了绝大多数实际业务需求。配合灵活的部署方式（在线版、Docker、源码）、清晰的数据库集成方案和多样的应用发布渠道，Dify 是零基础入门大模型应用开发的理想选择。

对于想要快速将 AI 能力落地到业务中的开发者和团队，建议从 Docker 本地部署开始，接入 DeepSeek 等云端模型 API，逐步掌握工作流节点的搭建技巧，最终构建出能真正服务于生产的 AI 应用。