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

什么是 Dify？

Dify 是一个开源的 AI 应用开发平台，核心定位是让开发者和普通用户都能快速构建、部署生产级 AI 应用，无需从头搭建模型调用链路。无论是企业内部知识库问答、自动化文本生成，还是复杂的多步骤智能体流程，Dify 都提供了可视化的编排界面，大幅降低了 AI 应用落地的门槛。

与直接调用大模型 API 相比，Dify 的核心价值在于将「提示词管理、模型切换、工具调用、工作流编排」这些工程细节封装进图形界面，开发者可以专注于业务逻辑本身。对于希望在公司内部快速验证 AI 应用场景的团队来说，这是一个非常实用的选择。

Dify 部署方式：本地 Docker 还是在线版？

本地 Docker 部署 vs 官方在线版

Dify 提供两种主要使用方式：直接使用官方托管的在线平台，或基于 Docker 自行部署。对于个人学习和功能探索，在线版完全够用；但在生产或企业内部场景下，本地部署更为可控。

本地部署推荐基于 Windows + Docker 的方案。安装 Docker Desktop 后，拉取 Dify 官方镜像并按文档配置即可完成部署，整个过程对 Windows 用户相对友好。本地部署的一个关键优势是：Dify 容器可以直接访问宿主机上的 MySQL、Redis 等服务，无需额外的内网穿透。而在线版若要读取本机数据库，则需要将本机服务暴露到公网，带来额外的安全和配置成本。

数据库配置

部分 AI 应用需要读写结构化数据，因此配套安装 MySQL 8 是必要的准备工作。MySQL 可以安装在 Windows 本机，也可以运行在 Docker 容器或虚拟机中——Dify 的 Docker 网络默认可以与宿主机及同网段的虚拟机通信，三种方式均可行。

Dify 五种应用类型详解

理解 Dify 的产品结构，最清晰的切入点是它支持的五种应用形态。这五种类型覆盖了绝大多数 AI 应用场景，选择合适的类型是构建高质量应用的第一步。

聊天助手

最基础的应用形式，本质上是一个带有系统提示词（System Prompt）的对话界面。适合客服机器人、FAQ 问答、个人助理等场景。配置简单，上手成本最低，非常适合作为 Dify 的入门练习。

文本生成应用

面向批量内容生产的场景，如文章撰写、报告生成、邮件模板填写等。与聊天助手的核心区别在于交互模式：文本生成更接近「填写参数 → 一次性输出结果」的模式，而非多轮对话。

Agent 智能体

Agent 是五种类型中能力最强的单体应用形态。它的核心特性是可以调用外部工具——例如网页爬取、代码执行、数据库查询、API 调用等——并根据工具返回的结果动态调整下一步行动，最终完成用户指令。这种「感知-决策-执行」的循环让 Agent 能够处理需要多步骤推理和外部信息的复杂任务。

Agent 的底层实现通常基于 ReAct（Reasoning + Acting）框架：模型在每一步先输出「思考过程」，再决定调用哪个工具、传入什么参数，获得工具返回结果后继续推理，直到判断任务完成为止。这种循环机制使 Agent 能处理需要多跳推理的问题，但也带来不确定性——模型可能在某一步做出错误判断，导致整个任务失败。因此，Agent 类应用通常需要配合精心设计的系统提示词和工具描述，以减少模型的误判概率。Dify 的 Agent 支持配置最大迭代次数，可防止模型陷入无限循环消耗大量 Token。

Chatflow 聊天流

Chatflow 是基于节点连线的可视化编排方式，支持多轮对话。用户可以在流程执行过程中持续输入，适合需要上下文记忆的场景，比如多轮交互式客服、引导式表单填写等。

Workflow 工作流

Workflow 同样采用节点连线的编排方式，但与 Chatflow 不同的是，它是单次触发、线性执行的流程。接收输入后按节点顺序处理并输出结果，适合数据处理管道、批量内容生成等不需要多轮交互的场景。

Dify 工作流节点体系

工作流的核心构件是「节点」，每个节点代表一个独立的处理单元。Dify 提供了覆盖主流场景的节点类型，常用的包括：

• LLM 节点：调用大模型进行文本生成或推理
• 知识检索节点：从向量数据库中检索相关文档片段（RAG）
• 代码节点：执行自定义 Python/JavaScript 逻辑
• HTTP 请求节点：调用外部 API
• 条件分支节点：根据变量值走不同的处理路径
• 数据库节点：读写 MySQL 等关系型数据库
• 变量聚合节点：合并多路分支的输出结果

节点之间通过连线传递变量，整个工作流形成一个有向无环图（DAG）。掌握节点的组合方式，是构建生产级 Dify 应用的关键技能。

有向无环图（DAG）是工作流引擎的核心数据结构，它确保流程中不存在循环依赖，每个节点在其所有前驱节点执行完毕后才会被触发。Dify 的节点变量传递遵循这一模型：上游节点的输出结果可以作为下游节点的输入参数，通过 {{节点名.输出字段}} 的语法引用。知识检索节点（RAG）是其中较为特殊的一类，它会将用户查询转化为向量，在预先构建的文档向量库中做相似度检索，返回最相关的文本片段，再交由 LLM 节点综合生成答案——这正是「检索增强生成」（Retrieval-Augmented Generation）的典型实现路径，也是企业知识库问答场景的核心技术支撑。

大模型接入策略

所有 Dify 应用都依赖底层大模型，因此模型的选择和接入方式直接影响应用效果和成本。

优先考虑云端付费模型

对于大多数场景，推荐接入 DeepSeek、通义千问、文心一言等云端 API。以 DeepSeek 为例，充值 10 元即可支撑相当长时间的开发测试——据实际使用反馈，10 元使用很长时间后消耗不到 1 元，性价比极高。阿里云通义千问和百度文心也为新注册用户提供百万级别的免费 Token，足以完成前期开发验证。

本地模型的适用场景

Dify 同样支持通过 Ollama 接入本地部署的开源模型。这条路径适合对数据隐私有严格要求、或拥有充足算力资源的团队。如果本地部署了 DeepSeek 开源版的大参数模型（如 671B 量化版），结合 Dify 完全可以构建企业级应用。但对于大多数个人用户而言，本机模型受硬件限制，参数量普遍偏小，实际效果不如云端模型。

Ollama 是一个轻量级的本地大模型运行时，支持在 macOS、Linux 和 Windows 上一键拉取并运行 Llama、Mistral、DeepSeek 等主流开源模型，对外暴露与 OpenAI 兼容的 HTTP 接口。Dify 通过配置 Ollama 的本地地址即可将其作为模型供应商接入，整个过程无需修改代码。本地模型的主要瓶颈在于显存：以 7B 参数模型为例，FP16 精度需要约 14GB 显存，Q4 量化后约需 4-5GB，普通消费级显卡勉强可以运行，但推理速度和效果均与同量级云端模型存在明显差距。

Dify 应用发布与分发方式

在 Dify 中构建好的应用，并不局限于在本地平台内部使用。Dify 提供了三种主要的分发方式：

1. 发布为公开 Web 站点：生成一个可公开访问的链接，配合内网穿透工具即可让外部用户直接使用。
2. 嵌入已有网站：通过 iframe 或 Web 组件将 AI 应用嵌入现有产品页面。
3. API 调用：以标准 REST API 的形式暴露应用能力，供后端服务或其他系统集成。

这三种分发方式覆盖了从个人展示到企业集成的完整链路，使 Dify 不只是一个「做 demo 的工具」，而是可以真正走向生产的 AI 应用平台。

总结

Dify 的价值在于把 AI 应用工程化中最繁琐的部分——提示词版本管理、模型切换、工具编排、流程调试——统一收敛进一个可视化平台，让团队把精力集中在业务逻辑和用户体验上。从聊天助手到复杂工作流，从本地 Docker 部署到云端模型接入，Dify 提供了一条相对完整的 AI 应用落地路径。对于希望在企业内部推动 AI 应用实践的团队，Dify 是值得优先评估的平台选项。