Dify 为什么突然火了｜附源码

过去一年，AI 应用开发领域出现了一个非常明显的变化：大家不再满足于“调用一个大模型 API 做问答”，而是开始关注如何把大模型真正落地到业务系统里。

在这个过程中，一个开源项目频繁出现在开发者、创业者、产品经理和企业数字化团队的视野中，它就是 Dify。

如果你最近关注 AI Agent、RAG、知识库问答、工作流编排、大模型应用开发平台，大概率都听过 Dify。它不仅在 GitHub 上增长很快，也被不少团队用于内部知识库、客服机器人、企业 Copilot、数据分析助手、内容生成平台等场景。

那么问题来了：

Dify 为什么突然火了？它解决了什么问题？它适合什么人用？它和 LangChain、Coze、FastGPT、Flowise 等工具有什么区别？如果我们想自己接入 Dify，又该如何写代码？

本文就系统聊一聊。

一、Dify 是什么？

Dify 是一个开源的大模型应用开发平台。

简单来说，它把大模型应用开发中常见的能力都封装成了可视化、低代码、可扩展的平台能力，包括：

• 多模型接入
• Prompt 编排
• RAG 知识库
• AI Agent
• Workflow 工作流
• API 发布
• 应用监控
• 数据集管理
• 用户反馈
• 对话日志
• 插件与工具调用
• 私有化部署

如果用一句话概括：

Dify 不是单纯的聊天机器人平台，而是一个面向生产环境的 AI 应用开发操作系统。

很多人第一次接触大模型开发时，会直接写代码调用 OpenAI、Claude、通义千问、智谱、DeepSeek 等模型 API。刚开始很简单，一个 HTTP 请求就可以完成一次对话。

但真正进入业务场景后，你会很快遇到一堆问题：

1. Prompt 如何版本管理？
2. 不同模型如何切换？
3. 知识库文档如何上传、切片、向量化？
4. 召回效果如何调试？
5. 对话历史如何维护？
6. 用户反馈如何收集？
7. 如何发布成 API 给前端调用？
8. 工作流里如何调用外部接口？
9. 如何设置变量、条件判断、循环、工具调用？
10. 企业内部如何私有化部署并控制数据安全？

这些问题，如果全部自己从零写，成本并不低。

Dify 的价值就在于：它把这些通用问题产品化了，让开发者可以把更多时间放在业务逻辑和应用效果上。

二、Dify 为什么突然火了？

Dify 的火，不是偶然的，而是大模型应用开发进入新阶段后的必然结果。

1. 大模型应用从 Demo 进入生产阶段

2023 年很多团队做 AI 应用，大多还是 Demo 级别：

• 一个 ChatGPT 包壳工具
• 一个简单客服机器人
• 一个文案生成器
• 一个 PDF 问答助手
• 一个飞书/企业微信机器人

但到了 2024 年之后，企业开始真正考虑：

• 能不能接入公司内部知识库？
• 能不能对接 CRM、ERP、OA？
• 能不能做权限控制？
• 能不能沉淀用户问题和反馈？
• 能不能低成本调试和迭代 Prompt？
• 能不能部署在自己的服务器？
• 能不能让非技术人员也参与配置？

这时候，单纯写一个调用大模型的脚本已经不够了。企业需要的是一个完整的平台。

Dify 正好卡在这个需求点上。

它不像纯代码框架那样门槛高，也不像纯 SaaS 工具那样封闭。它既可以开箱即用，也可以私有化部署，还能通过 API 和代码深度集成，因此很容易被企业和开发者接受。

2. RAG 需求爆发，Dify 刚好解决知识库落地问题

RAG，全称 Retrieval-Augmented Generation，即检索增强生成。

简单理解就是：

用户提问时，系统先从知识库里检索相关资料，再把资料和问题一起交给大模型生成回答。

为什么 RAG 很重要？

因为大模型本身有几个明显限制：

• 不知道企业内部私有数据
• 知识可能过时
• 容易胡编乱造
• 无法直接访问业务文档
• 对长文档理解成本较高

企业想让大模型回答内部制度、产品文档、售后政策、技术手册、合同条款，就必须接入知识库。

但知识库问答看起来简单，真正做起来有很多细节：

• 文档格式解析
• 文档切片策略
• Embedding 模型选择
• 向量数据库存储
• TopK 召回
• 召回相似度阈值
• 重排序
• 引用来源
• 文档更新
• 多知识库管理
• 问答效果评估

Dify 把这些复杂环节做成了比较友好的界面。用户可以上传 PDF、Markdown、TXT、网页等内容，配置索引方式和检索参数，然后直接在应用里使用知识库。

对于很多中小团队来说，这极大降低了 RAG 应用落地门槛。

3. 工作流能力补齐了复杂业务场景

早期很多 AI 工具只能做“单轮问答”或“简单多轮对话”。但真实业务往往不是一句 Prompt 就能解决的。

例如一个“合同审查助手”，可能需要执行以下步骤：

1. 上传合同文件；
2. 提取合同关键条款；
3. 判断合同类型；
4. 检查风险点；
5. 根据公司模板生成审查意见；
6. 对高风险条款给出修改建议；
7. 输出结构化 JSON；
8. 调用外部系统保存结果。

这显然不是简单聊天机器人能完成的。

Dify 的 Workflow 工作流能力，让用户可以通过可视化节点编排复杂流程，包括：

• 开始节点
• LLM 节点
• 知识检索节点
• 条件分支节点
• 代码执行节点
• HTTP 请求节点
• 参数提取节点
• 模板转换节点
• 结束节点

这就让 Dify 从“聊天机器人构建器”升级成了“AI 业务流程编排平台”。

对于企业来说，这一点非常重要。因为真正有价值的 AI 应用，往往不是单独存在的，而是嵌入业务流程中。

4. 开源、可私有化部署，降低企业顾虑

很多企业使用 AI 产品时都会担心数据安全：

• 文档会不会被第三方拿去训练？
• 内部知识库是否会泄露？
• 用户对话记录是否可控？
• 是否符合公司合规要求？
• 能不能部署在内网环境？

Dify 的开源属性让它具备明显优势。

企业可以选择：

• 使用 Dify 云服务；
• 使用 Docker Compose 私有化部署；
• 在内网服务器部署；
• 接入本地大模型；
• 接入企业自己的向量数据库和对象存储；
• 根据源码进行二次开发。

这对企业级客户非常有吸引力。

尤其是金融、政务、医疗、制造、教育等行业，对数据安全要求较高，纯 SaaS 方案往往推进困难，而 Dify 这类开源可部署方案更容易进入试点。

5. 兼顾开发者和非技术人员

Dify 很重要的一点是，它不是只给程序员用的。

对于开发者来说，Dify 提供：

• API 调用能力
• 后端集成能力
• 工作流编排能力
• 模型供应商配置
• 插件扩展
• 源码可读可改

对于产品经理、运营、业务专家来说，Dify 提供：

• 可视化 Prompt 编辑
• 知识库上传
• 应用调试
• 对话日志查看
• 用户反馈分析
• 工作流配置

这使得 AI 应用开发不再完全依赖工程团队。

一个典型协作方式是：

• 业务人员整理知识库和场景需求；
• 产品经理设计问答流程；
• Prompt 工程师优化提示词；
• 开发者负责系统集成；
• 运维人员负责部署和监控。

Dify 让不同角色可以在同一个平台上协作，这也是它容易火起来的重要原因。

三、Dify 适合做哪些应用？

Dify 可以做的应用非常多，下面列一些典型场景。

1. 企业知识库问答

这是最常见的场景。

例如：

• 公司制度问答
• 产品手册问答
• 售后政策问答
• 技术文档问答
• 培训资料问答
• 法务合规问答

员工可以像问 ChatGPT 一样查询内部知识，不再需要到处翻文档。

2. 智能客服

Dify 可以结合知识库和工作流做客服机器人。

例如电商客服可以回答：

• 订单如何查询？
• 退换货政策是什么？
• 发票如何开具？
• 某商品是否支持保修？
• 物流异常如何处理？

如果结合 HTTP 请求节点，还可以调用订单系统、物流系统、工单系统，实现更完整的客服自动化。

3. 内容生成工具

比如：

• 小红书文案生成
• 公众号文章生成
• 短视频脚本生成
• 商品标题优化
• SEO 文章生成
• 广告创意生成

这类场景通过 Prompt 模板和变量配置就可以快速完成。

4. 数据分析助手

通过工作流和外部接口，Dify 可以连接数据库查询服务，让用户用自然语言提问：

• 上个月销售额是多少？
• 哪个地区增长最快？
• 最近 7 天新增用户趋势如何？
• 哪些商品退货率最高？

当然，直接让大模型生成 SQL 存在安全风险，生产环境通常要增加权限控制、SQL 审核、查询白名单等机制。

5. 内部流程助手

例如：

• 报销助手
• HR 政策助手
• IT 运维助手
• 会议纪要助手
• 项目周报助手
• 代码审查助手

这些场景的共同特点是：规则明确、重复性高、信息分散，非常适合用 Dify 做第一版 AI 应用。

四、Dify 和 LangChain 有什么区别？

很多人会问：既然有 LangChain，为什么还需要 Dify？

它们不是同一种东西。

LangChain 更像是一个面向开发者的代码框架，适合用 Python 或 JavaScript 构建复杂的大模型应用。它灵活、底层、可编程能力强，但对非技术人员不友好。

Dify 更像是一个产品化平台，提供可视化配置、应用发布、知识库管理、工作流编排、监控和 API 能力。

可以简单对比：

如果你要快速做一个企业可用的 AI 应用，Dify 更合适。

如果你要从底层完全控制 Agent、Memory、Retriever、Tool、Chain 等逻辑，LangChain 更合适。

当然，两者也不是互斥的。你完全可以用 Dify 做应用管理和工作流，用 LangChain 写某些复杂工具服务，再通过 HTTP API 接入 Dify。

五、Dify 的核心架构理解

从应用开发角度看，Dify 可以拆成几层：

1. 模型接入层

Dify 支持多种模型供应商，例如：

• OpenAI
• Azure OpenAI
• Anthropic Claude
• Google Gemini
• DeepSeek
• 通义千问
• 智谱 AI
• Moonshot
• Ollama
• LocalAI
• Xinference
• OpenRouter

这意味着开发者可以在不同模型之间切换，根据成本、速度、效果选择合适模型。

2. 数据集与知识库层

这一层负责文档上传、切片、Embedding、索引、检索等能力。

RAG 应用效果很大程度取决于这一层。

同样一个问题，不同切片策略、不同 Embedding 模型、不同召回参数，效果可能差别很大。

3. 应用编排层

这是 Dify 最核心的部分，包括：

• Chatbot
• Agent
• Text Generator
• Workflow

你可以创建一个简单聊天应用，也可以创建一个复杂的工作流应用。

4. 发布与集成层

Dify 应用可以通过多种方式对外提供能力：

• WebApp
• API
• 嵌入网站
• 对接企业微信/飞书/钉钉
• 后端服务调用

这让 Dify 不只是一个后台配置工具，而是可以真正嵌入业务系统。

六、快速部署 Dify

如果你想本地体验 Dify，最简单的方式是使用 Docker Compose。

注意：以下命令仅作为示例，实际部署请以 Dify 官方文档为准。

git clone https://github.com/langgenius/dify.git
cd dify/docker

cp .env.example .env

docker compose up -d

启动完成后，浏览器访问：

http://localhost

如果你是在服务器上部署，需要开放对应端口，并根据实际情况配置域名、HTTPS、数据库、Redis、对象存储等。

查看容器状态：

docker compose ps

查看日志：

docker compose logs -f

停止服务：

docker compose down

七、附源码：用 Node.js 调用 Dify API

下面给一个简单示例：在自己的 Node.js 后端服务中调用 Dify 应用 API，实现一个聊天接口。

假设你已经在 Dify 中创建了一个 Chatbot 应用，并获得了 API Key。

1. 安装依赖

mkdir dify-demo
cd dify-demo
npm init -y
npm install express axios cors dotenv

2. 创建 .env

PORT=3000
DIFY_API_KEY=app-xxxxxxxxxxxxxxxx
DIFY_API_URL=https://api.dify.ai/v1/chat-messages

如果你是私有化部署，把 DIFY_API_URL 改成自己的地址，例如：

DIFY_API_URL=http://your-domain/v1/chat-messages

3. 创建 server.js

require("dotenv").config();

const express = require("express");
const axios = require("axios");
const cors = require("cors");

const app = express();

app.use(cors());
app.use(express.json());

const PORT = process.env.PORT || 3000;
const DIFY_API_KEY = process.env.DIFY_API_KEY;
const DIFY_API_URL = process.env.DIFY_API_URL;

if (!DIFY_API_KEY || !DIFY_API_URL) {
  throw new Error("请在 .env 中配置 DIFY_API_KEY 和 DIFY_API_URL");
}

/**
 * 调用 Dify Chat API
 */
async function callDify({ query, user, conversationId }) {
  const response = await axios.post(
    DIFY_API_URL,
    {
      inputs: {},
      query,
      response_mode: "blocking",
      conversation_id: conversationId || "",
      user: user || "demo-user"
    },
    {
      headers: {
        Authorization: `Bearer ${DIFY_API_KEY}`,
        "Content-Type": "application/json"
      },
      timeout: 60000
    }
  );

  return response.data;
}

/**
 * 对外提供聊天接口
 */
app.post("/api/chat", async (req, res) => {
  try {
    const { message, user, conversationId } = req.body;

    if (!message) {
      return res.status(400).json({
        success: false,
        message: "message 不能为空"
      });
    }

    const result = await callDify({
      query: message,
      user,
      conversationId
    });

    res.json({
      success: true,
      answer: result.answer,
      conversationId: result.conversation_id,
      messageId: result.message_id,
      raw: result
    });
  } catch (error) {
    console.error("Dify API 调用失败：", error.response?.data || error.message);

    res.status(500).json({
      success: false,
      message: "Dify API 调用失败",
      error: error.response?.data || error.message
    });
  }
});

app.listen(PORT, () => {
  console.log(`Server is running at http://localhost:${PORT}`);
});

4. 启动服务

node server.js

5. 测试接口

curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "message": "请介绍一下 Dify 的核心功能",
    "user": "user-001"
  }'

返回结果示例：

{
  "success": true,
  "answer": "Dify 是一个开源的大模型应用开发平台，核心功能包括...",
  "conversationId": "xxxx",
  "messageId": "xxxx"
}

八、附源码：前端页面调用自己的后端接口

下面再给一个极简 HTML 页面，用来调用刚才的 Node.js 服务。

创建 index.html：

  
  
  


  
Dify Chat Demo

  


  

    
    发送
  

  

打开这个 HTML 页面，就可以通过自己的前端页面与 Dify 应用对话。

九、附源码：Python 调用 Dify Workflow API

如果你创建的是 Workflow 应用，可以使用下面的 Python 示例调用。

1. 安装依赖

pip install requests python-dotenv

2. 创建 .env

DIFY_WORKFLOW_API_KEY=app-xxxxxxxxxxxxxxxx
DIFY_WORKFLOW_URL=https://api.dify.ai/v1/workflows/run

3. 创建 run_workflow.py

import os
import requests
from dotenv import load_dotenv

load_dotenv()

DIFY_WORKFLOW_API_KEY = os.getenv("DIFY_WORKFLOW_API_KEY")
DIFY_WORKFLOW_URL = os.getenv("DIFY_WORKFLOW_URL")

if not DIFY_WORKFLOW_API_KEY or not DIFY_WORKFLOW_URL:
    raise Exception("请配置 DIFY_WORKFLOW_API_KEY 和 DIFY_WORKFLOW_URL")


def run_workflow(topic: str, style: str):
    headers = {
        "Authorization": f"Bearer {DIFY_WORKFLOW_API_KEY}",
        "Content-Type": "application/json"
    }

    payload = {
        "inputs": {
            "topic": topic,
            "style": style
        },
        "response_mode": "blocking",
        "user": "python-user-001"
    }

    response = requests.post(
        DIFY_WORKFLOW_URL,
        headers=headers,
        json=payload,
        timeout=60
    )

    response.raise_for_status()
    return response.json()


if __name__ == "__main__":
    result = run_workflow(
        topic="Dify 为什么突然火了",
        style="深入、通俗、适合技术公众号"
    )

    print(result)

运行：

python run_workflow.py

这个示例适合用在内容生成、数据处理、自动审查、信息提取等工作流场景中。

十、使用 Dify 的一些实践建议

Dify 虽然降低了 AI 应用开发门槛，但不代表只要上传文档、写一句 Prompt 就能得到完美效果。想把应用做好，仍然需要一些工程实践。

1. 不要迷信大模型，先定义业务边界

很多团队一开始就想做“万能助手”，最后效果往往不好。

更推荐从明确场景入手，例如：

• 只回答售后政策；
• 只处理合同审查；
• 只生成商品标题；
• 只解答公司 HR 制度；
• 只辅助一线客服回答标准问题。

边界越清晰，效果越容易控制。

2. 知识库质量比模型更重要

在 RAG 场景中，很多问题不是模型不行，而是知识库不行。

常见问题包括：

• 文档太乱；
• 标题结构不清晰；
• 多个版本内容冲突；
• PDF 解析效果差；
• 文档切片过大或过小；
• 关键术语不统一；
• 缺少标准问答样例。

如果知识库本身质量差，再强的模型也很难稳定回答。

3. Prompt 要持续迭代

Prompt 不是一次写完就结束的。

建议建立一套迭代机制：

• 收集用户真实问题；
• 查看回答失败案例；
• 分析是召回问题还是生成问题；
• 调整 Prompt、知识库、检索参数；
• 加入反例和边界约束；
• 定期回归测试。

Dify 的对话日志和用户反馈功能，对于持续优化非常有帮助。

4. 生产环境要重视安全

如果你要把 Dify 用在真实业务中，至少要考虑：

• API Key 不要暴露在前端；
• 私有化部署要做好访问控制；
• 用户输入要做审计；
• 敏感数据要脱敏；
• 外部工具调用要限制权限；
• SQL 查询类应用要防止危险操作；
• 日志要有保留和清理策略。

AI 应用越接近业务核心，安全问题越不能忽视。

十一、Dify 会不会只是昙花一现？

我认为不会。

原因很简单：Dify 背后对应的是一个长期趋势——AI 应用开发平台化。

大模型能力越来越强，但企业真正需要的不是“一个模型”，而是“一个能把模型接入业务流程的平台”。

未来 AI 应用开发很可能会形成几类基础设施：

1. 模型层：OpenAI、Claude、Gemini、DeepSeek、通义、智谱等；
2. 编排层：Dify、LangChain、LlamaIndex、Semantic Kernel 等；
3. 数据层：向量数据库、知识库、数据湖、企业搜索；
4. 工具层：API、插件、RPA、业务系统连接器；
5. 应用层：客服、营销、办公、研发、数据分析、行业 Copilot。

Dify 所在的位置，正是模型与业务应用之间的关键中间层。

只要企业继续需要快速构建 AI 应用，类似 Dify 的平台就会持续有价值。

当然，Dify 也面临挑战：

• 工作流复杂后如何维护？
• Agent 稳定性如何提升？
• RAG 效果如何进一步优化？
• 企业权限体系如何更完善？
• 多租户和大规模部署能力如何增强？
• 与云厂商和行业系统如何竞争？

但从目前的发展节奏看，Dify 已经抓住了 AI 应用开发的核心痛点。

十二、总结

Dify 之所以突然火了，核心原因不是营销，而是它踩中了大模型落地的关键需求。

它解决了几个非常实际的问题：

• 让非技术人员也能参与 AI 应用配置；
• 让开发者不用重复造知识库、工作流、API 发布的轮子；
• 让企业可以私有化部署，降低数据安全顾虑；
• 让 RAG、Agent、Workflow 等能力以更低门槛进入生产环境；
• 让 AI 应用从 Demo 走向可维护、可迭代、可集成。

如果你只是想体验大模型，直接使用 ChatGPT 或各类 AI 助手就够了。

但如果你想把大模型真正接入自己的产品、业务系统或企业知识库，那么 Dify 是非常值得研究的开源项目。

它不一定是所有场景的最终答案，但一定是目前构建 AI 应用最值得关注的工具之一。

最后，用一句话收尾：

Dify 火的背后，是 AI 应用开发从“写 Prompt”进入“搭系统”的时代。