Dify 为什么突然火了｜附配置文件

过去一年，AI 应用开发领域出现了一个非常明显的变化：大家不再满足于“调用一次大模型 API”，而是开始关注如何把大模型真正接入业务流程，做成可持续迭代、可观测、可运营的产品。

在这个背景下，Dify 突然火了。

很多人第一次接触 Dify，是因为它可以快速搭建一个 AI 聊天机器人；但真正用过之后会发现，它并不只是一个“套壳工具”，而是一个面向大模型应用开发的完整平台。它把 Prompt 编排、知识库、工作流、插件工具、模型接入、应用发布、日志追踪等能力整合到了一起，让开发者和非开发者都可以更快地构建 AI 应用。

本文会系统聊聊：Dify 为什么突然火了，它到底解决了什么问题，适合哪些场景，以及如何通过配置文件快速部署一套可用环境。

一、Dify 是什么？

Dify 是一个开源的大模型应用开发平台，简单理解，它可以帮助你把大语言模型能力快速封装成各种 AI 应用。

它支持的应用形态包括：

• 聊天助手
• Agent 智能体
• 工作流应用
• 文本生成应用
• 知识库问答系统
• 企业内部 AI 助手
• API 形式对外提供 AI 能力

如果只从表面看，Dify 像是一个“可视化 Prompt 平台”；但从实际能力看，它更接近一个 LLMOps 平台。

所谓 LLMOps，可以理解为大模型应用的工程化与运维体系。一个真正可投入生产的大模型应用，不只是写好 Prompt 就够了，还涉及：

• 模型供应商如何管理
• Prompt 如何版本化
• 用户请求如何追踪
• 知识库如何更新
• 向量数据库如何存储
• 生成结果如何评估
• 工具调用如何编排
• 成本和 Token 如何监控
• 应用如何对接业务系统

Dify 正是围绕这些问题提供了一套完整解决方案。

二、Dify 为什么突然火了？

Dify 的流行并不是偶然，而是踩中了几个关键趋势。

1. 大模型从“玩具阶段”进入“应用阶段”

ChatGPT 刚火的时候，很多人的使用方式主要是聊天、写文案、翻译、总结、写代码。这个阶段大家关注的是：模型够不够强，回答是否惊艳。

但随着企业和开发者深入使用 AI，问题开始变了：

• 如何把 AI 接入客服系统？
• 如何让 AI 根据企业内部文档回答问题？
• 如何让 AI 自动分析用户反馈？
• 如何让 AI 调用内部接口查询订单、库存、工单？
• 如何让不同角色使用不同 AI 助手？
• 如何保证 AI 输出稳定、可控、可追踪？

这时，单纯调用 OpenAI、Claude、通义千问、智谱、DeepSeek 等模型 API 已经不够了。大家需要的是一个应用平台，而不是一个 API 示例。

Dify 恰好提供了这样的能力：它让大模型应用从“Demo”走向“产品”。

2. 可视化编排降低了开发门槛

传统开发一个 AI 应用，大致需要做这些事情：

1. 搭建后端服务；
2. 对接模型 API；
3. 设计 Prompt；
4. 处理上下文；
5. 接入向量数据库；
6. 处理文档解析；
7. 搭建前端页面；
8. 记录日志；
9. 管理用户输入和模型输出；
10. 部署上线。

这些工作对有经验的工程师来说不难，但成本不低。尤其是对于产品经理、运营、数据分析师、业务团队来说，门槛非常高。

Dify 的可视化界面把很多复杂工作封装起来。用户可以通过配置完成：

• 选择模型；
• 编写 Prompt；
• 设置变量；
• 上传知识库；
• 配置召回参数；
• 编排工作流节点；
• 发布 Web App；
• 获取 API Key；
• 查看运行日志。

这意味着，业务人员也能参与 AI 应用构建，而不是所有事情都依赖研发排期。

这点非常关键，因为 AI 应用往往需要不断调试和迭代。业务人员最懂实际问题，如果他们可以直接调整 Prompt、知识库和流程，应用迭代速度会明显提升。

3. RAG 知识库能力符合企业刚需

很多企业最早落地 AI 的方向就是知识库问答，也就是 RAG。

RAG 的全称是 Retrieval-Augmented Generation，中文常叫“检索增强生成”。它的核心思想是：当用户提问时，系统先从知识库中检索相关内容，再把检索结果交给大模型生成答案。

这样可以解决两个问题：

• 大模型不知道企业内部私有知识；
• 大模型容易胡编乱造。

Dify 内置了知识库能力，支持文档上传、分段、向量化、召回、重排序等流程。用户不需要自己从零搭建 LangChain、向量数据库、Embedding 服务和文档解析服务。

典型场景包括：

• 企业制度问答；
• 产品说明书问答；
• 售后客服知识库；
• 内部培训助手；
• 合同条款问答；
• 技术文档助手；
• API 文档问答；
• 法务合规知识助手。

对于企业来说，RAG 是投入产出比很高的 AI 落地方式。而 Dify 把 RAG 的搭建流程做得足够简单，这是它火起来的重要原因。

4. 工作流让 AI 应用变得更可控

单轮对话看起来很简单，但真实业务往往不是“问一句答一句”。

例如，一个用户说：

帮我分析一下这个客户是否值得重点跟进。

这背后可能需要多个步骤：

1. 解析用户输入；
2. 查询 CRM 客户资料；
3. 获取历史沟通记录；
4. 分析客户规模和行业；
5. 判断成交概率；
6. 生成跟进建议；
7. 输出结构化结果；
8. 必要时创建任务或提醒销售。

如果全部交给一个大模型自由发挥，结果可能不稳定，也不方便调试。

Dify 的工作流能力可以把任务拆成多个节点，例如：

• 开始节点；
• LLM 节点；
• 条件判断节点；
• HTTP 请求节点；
• 代码执行节点；
• 知识检索节点；
• 参数提取节点；
• 结束节点。

这样一来，AI 应用就从“黑盒聊天”变成了“可编排流程”。每个节点的输入输出都可以查看，哪里出错也更容易定位。

对于企业级场景来说，可控性比炫酷更重要。Dify 的工作流正好满足了这一点。

5. 开源和私有化部署带来安全感

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

• 用户问题是否会泄露？
• 企业文档是否会被第三方训练？
• 内部接口能否暴露给外部平台？
• 是否可以部署在公司内网？
• 是否能接入国产大模型？
• 是否能接入私有模型？

Dify 是开源项目，并支持私有化部署。企业可以把它部署在自己的服务器、云主机、Kubernetes 集群或内网环境中。

这给了企业更大的控制权。

尤其是在金融、医疗、政务、制造、教育等行业，私有化部署往往是刚性要求。相比纯 SaaS 平台，Dify 的开源特性更容易被企业接受。

6. 多模型接入降低供应商绑定风险

AI 模型市场变化非常快。今天某个模型效果最好，明天可能另一个模型更便宜、更快、更强。

如果应用架构和某一个模型供应商强绑定，后续迁移成本会很高。

Dify 支持接入多种模型服务，包括但不限于：

• OpenAI；
• Azure OpenAI；
• Anthropic Claude；
• Google Gemini；
• DeepSeek；
• 通义千问；
• 智谱 AI；
• 文心一言；
• 月之暗面 Kimi；
• Ollama 本地模型；
• OpenAI-API-Compatible 服务。

这意味着应用层可以尽量保持稳定，而底层模型可以根据成本、速度、效果灵活切换。

对企业来说，这一点非常重要。它可以避免被单一供应商锁死，也方便根据不同场景选择不同模型。

7. API 发布能力让它不只是后台工具

Dify 创建的应用不仅可以在页面里使用，还可以直接发布成 API。

这使得它可以嵌入到各种业务系统中，例如：

• 企业微信机器人；
• 飞书机器人；
• 钉钉机器人；
• 客服系统；
• CRM；
• OA；
• 数据分析平台；
• 自建 Web 应用；
• 移动 App；
• 小程序。

也就是说，Dify 可以作为一个 AI 能力中台存在。业务系统只需要调用 Dify 暴露的 API，就能获得大模型应用能力。

这对于团队协作非常有价值：AI 应用可以由专人维护，业务系统只需要集成接口，而不必重复开发 Prompt、知识库和模型调用逻辑。

三、Dify 适合哪些人使用？

Dify 的用户群体比较广，不只适合程序员。

1. 开发者

开发者可以用 Dify 快速验证 AI 应用原型，把很多底层重复工作交给平台处理，例如模型调用、日志记录、知识库检索和应用发布。

如果后续要深度定制，也可以通过 API、插件、工作流和私有化部署进一步扩展。

2. 产品经理

产品经理可以用 Dify 直接搭建产品原型，比如智能客服、文档助手、运营文案生成器、用户反馈分析工具等。

相比写需求文档等研发排期，用 Dify 先做一个可交互 Demo，沟通效率会高很多。

3. 运营和内容团队

运营团队经常需要处理大量文本工作，例如：

• 活动文案生成；
• 用户评论分析；
• FAQ 自动回复；
• 商品描述生成；
• 社媒内容改写；
• 邮件模板生成。

这些场景都可以通过 Dify 快速搭建工具，提高效率。

4. 企业 IT 团队

企业 IT 团队可以把 Dify 作为内部 AI 应用平台，为不同部门搭建专属 AI 助手。

例如：

• HR 助手；
• 财务制度助手；
• 法务合同助手；
• 技术支持助手；
• 销售赋能助手；
• 客服知识库助手。

通过私有化部署和权限控制，可以更好地满足企业内部使用需求。

四、Dify 的核心能力拆解

下面从应用构建角度，简单拆解 Dify 的几个核心模块。

1. 应用类型

Dify 通常支持多种应用类型：

• 聊天助手：适合客服、知识问答、角色助手；
• 文本生成应用：适合文案、摘要、翻译、提取；
• Agent 应用：适合需要工具调用和自主规划的任务；
• 工作流应用：适合流程明确、要求稳定可控的场景。

如果是企业落地，通常建议优先使用工作流应用，因为它的可控性更强。

2. Prompt 编排

Prompt 是大模型应用的核心之一。Dify 支持在界面中配置系统提示词、用户变量和上下文信息。

一个好的 Prompt 通常包括：

• 角色定义；
• 任务目标；
• 输入说明；
• 输出格式；
• 限制条件；
• 示例；
• 错误处理规则。

例如：

你是一名企业知识库助手。
你的任务是根据提供的上下文回答用户问题。
如果上下文中没有相关信息，请明确回答“根据当前知识库资料无法确认”，不要编造。
请使用简洁、准确、正式的中文回答。

这样的 Prompt 可以减少模型胡编乱造，提高回答稳定性。

3. 知识库

Dify 的知识库模块一般包括以下流程：

1. 上传文档；
2. 文档解析；
3. 文本切分；
4. 生成向量；
5. 存入向量数据库；
6. 用户提问时召回相关片段；
7. 将片段交给大模型生成答案。

知识库效果好不好，往往取决于几个因素：

• 文档质量；
• 分段策略；
• Embedding 模型；
• 召回数量；
• 重排序模型；
• Prompt 约束；
• 是否定期更新。

很多人搭建知识库后觉得效果一般，问题往往不在 Dify，而在文档结构混乱、内容重复、表述不清，或者召回参数没有调好。

4. 工作流

工作流是 Dify 最值得关注的能力之一。它让 AI 应用从“单次调用”变成“流程自动化”。

一个典型工作流可能是：

用户输入
  ↓
参数提取
  ↓
知识库检索
  ↓
LLM 分析
  ↓
条件判断
  ↓
HTTP 调用业务接口
  ↓
生成最终结果

这种方式特别适合企业场景，因为企业业务不是纯聊天，而是流程。

5. 日志与调试

Dify 可以查看应用运行日志，包括用户输入、模型输出、Token 消耗、节点执行情况等。

这对优化 AI 应用非常重要。

因为大模型应用不是一次写完就稳定运行，它需要持续观察、分析和调整。例如：

• 用户经常问什么？
• 哪些问题回答错误？
• 哪些知识库片段被频繁召回？
• Token 成本是否过高？
• Prompt 是否需要优化？
• 是否存在敏感输出？

没有日志，很难做持续优化。

五、Dify 的局限性

虽然 Dify 很强，但它不是万能的。

1. 复杂业务仍然需要工程能力

如果只是搭建知识库问答或简单工作流，Dify 非常方便。但如果涉及复杂权限、复杂数据同步、高并发、深度定制 UI、强事务业务逻辑，仍然需要专业开发。

Dify 可以帮你快速搭建 AI 能力层，但不一定能替代完整业务系统。

2. 知识库效果依赖数据治理

很多团队以为上传文档就能得到一个完美 AI 助手，实际并不是。

如果文档本身质量差，结构混乱，存在过期内容或相互矛盾的说明，那么 AI 回答自然也会受影响。

RAG 的核心不是“上传文件”，而是“知识治理”。

3. 模型成本仍需控制

Dify 可以帮助管理和观察 Token 消耗，但不能天然让模型调用变便宜。

如果应用访问量大，仍然要做好：

• 模型选择；
• Prompt 精简；
• 缓存策略；
• 知识召回优化；
• 长上下文控制；
• 用户限流；
• 成本监控。

六、Dify 部署方式概览

Dify 支持多种部署方式，其中最常见的是 Docker Compose 部署。

基本组件通常包括：

• API 服务；
• Web 前端；
• Worker；
• PostgreSQL；
• Redis；
• 向量数据库；
• Sandbox；
• Nginx。

如果只是个人体验，可以使用单机 Docker Compose。
如果是企业生产环境，建议使用更稳定的服务器资源，并做好数据备份、HTTPS、访问控制和监控。

七、Dify Docker Compose 配置文件示例

下面提供一份适合学习和测试使用的 Docker Compose 配置示例。实际生产环境中，建议以官方最新配置为准，并根据业务情况调整。

说明：不同版本 Dify 的配置项可能会变化，下面配置主要用于理解部署结构。正式上线请结合官方仓库的 .env.example 和 docker-compose.yaml。

1. .env 配置文件示例

# =========================
# 基础配置
# =========================

CONSOLE_API_URL=http://localhost:5001
CONSOLE_WEB_URL=http://localhost
SERVICE_API_URL=http://localhost:5001
APP_WEB_URL=http://localhost

# 应用密钥，生产环境必须修改为高强度随机字符串
SECRET_KEY=please-change-this-secret-key

# 日志级别
LOG_LEVEL=INFO

# =========================
# 数据库配置
# =========================

DB_USERNAME=postgres
DB_PASSWORD=dify_postgres_password
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

# =========================
# Redis 配置
# =========================

REDIS_HOST=redis
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=dify_redis_password
REDIS_USE_SSL=false
REDIS_DB=0

# =========================
# Celery 配置
# =========================

CELERY_BROKER_URL=redis://:dify_redis_password@redis:6379/1

# =========================
# 向量数据库配置
# 可选：weaviate / qdrant / milvus / pgvector 等
# =========================

VECTOR_STORE=weaviate
WEAVIATE_ENDPOINT=http://weaviate:8080
WEAVIATE_API_KEY=

# =========================
# 文件存储配置
# 本地测试可使用 local
# 生产环境可使用 S3、阿里云 OSS、腾讯云 COS 等
# =========================

STORAGE_TYPE=local
STORAGE_LOCAL_PATH=storage

# =========================
# Sandbox 配置
# =========================

CODE_EXECUTION_ENDPOINT=http://sandbox:8194
CODE_EXECUTION_API_KEY=dify-sandbox-key

# =========================
# 邮件配置，可选
# =========================

MAIL_TYPE=
MAIL_DEFAULT_SEND_FROM=
SMTP_SERVER=
SMTP_PORT=587
SMTP_USERNAME=
SMTP_PASSWORD=
SMTP_USE_TLS=true

# =========================
# 模型供应商配置
# 通常也可以在 Dify 控制台中配置
# =========================

OPENAI_API_KEY=
ANTHROPIC_API_KEY=

2. docker-compose.yml 示例

version: "3.8"

services:
  api:
    image: langgenius/dify-api:latest
    container_name: dify-api
    restart: always
    env_file:
      - .env
    volumes:
      - ./storage:/app/api/storage
    depends_on:
      - db
      - redis
      - weaviate
      - sandbox
    ports:
      - "5001:5001"

  worker:
    image: langgenius/dify-api:latest
    container_name: dify-worker
    restart: always
    env_file:
      - .env
    command: celery -A app.celery worker -P gevent -c 1 --loglevel=INFO
    volumes:
      - ./storage:/app/api/storage
    depends_on:
      - db
      - redis
      - weaviate
      - sandbox

  web:
    image: langgenius/dify-web:latest
    container_name: dify-web
    restart: always
    env_file:
      - .env
    depends_on:
      - api
    ports:
      - "3000:3000"

  db:
    image: postgres:15-alpine
    container_name: dify-db
    restart: always
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: dify_postgres_password
      POSTGRES_DB: dify
    volumes:
      - ./volumes/db/data:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  redis:
    image: redis:6-alpine
    container_name: dify-redis
    restart: always
    command: redis-server --requirepass dify_redis_password
    volumes:
      - ./volumes/redis/data:/data
    ports:
      - "6379:6379"

  weaviate:
    image: semitechnologies/weaviate:1.19.0
    container_name: dify-weaviate
    restart: always
    environment:
      QUERY_DEFAULTS_LIMIT: 25
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: "true"
      PERSISTENCE_DATA_PATH: "/var/lib/weaviate"
      DEFAULT_VECTORIZER_MODULE: "none"
      CLUSTER_HOSTNAME: "node1"
    volumes:
      - ./volumes/weaviate:/var/lib/weaviate
    ports:
      - "8080:8080"

  sandbox:
    image: langgenius/dify-sandbox:latest
    container_name: dify-sandbox
    restart: always
    environment:
      API_KEY: dify-sandbox-key
      GIN_MODE: release
      WORKER_TIMEOUT: 15
    volumes:
      - ./volumes/sandbox/dependencies:/dependencies
    ports:
      - "8194:8194"

  nginx:
    image: nginx:stable-alpine
    container_name: dify-nginx
    restart: always
    depends_on:
      - api
      - web
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

3. nginx.conf 示例

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        server_name localhost;

        client_max_body_size 50M;

        location /console/api {
            proxy_pass http://api:5001;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /api {
            proxy_pass http://api:5001;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /v1 {
            proxy_pass http://api:5001;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location / {
            proxy_pass http://web:3000;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

八、部署步骤

假设你已经安装好 Docker 和 Docker Compose，可以按照下面步骤启动。

1. 创建目录

mkdir dify-deploy
cd dify-deploy

2. 创建配置文件

在当前目录下创建：

.env
docker-compose.yml
nginx.conf

并分别填入上文示例配置。

3. 启动服务

docker compose up -d

如果你的环境使用旧版 Docker Compose，也可以执行：

docker-compose up -d

4. 查看服务状态

docker compose ps

查看日志：

docker compose logs -f api
docker compose logs -f worker
docker compose logs -f web

5. 访问 Dify

浏览器打开：

http://localhost

如果部署在服务器上，则访问：

http://服务器IP

首次进入后，按照页面提示创建管理员账号即可。

九、生产环境部署建议

如果你打算把 Dify 用在正式业务中，不建议只按测试配置直接上线。至少要注意以下几点。

1. 修改所有默认密码

包括：

• PostgreSQL 密码；
• Redis 密码；
• Sandbox API Key；
• Dify Secret Key；
• 各类模型 API Key。

不要使用示例中的密码，也不要使用简单密码。

2. 启用 HTTPS

生产环境建议使用 HTTPS，可以通过 Nginx 配合 Let’s Encrypt 证书实现。

如果放在企业内网，也建议至少做好访问控制，避免管理后台暴露在公网。

3. 做好数据备份

Dify 的关键数据包括：

• PostgreSQL 数据；
• 向量数据库数据；
• 本地上传文件；
• 配置文件；
• 应用配置；
• 知识库数据。

建议定期备份数据库和挂载目录。

4. 控制访问权限

如果是企业内部使用，建议：

• 配置统一登录；
• 限制管理员数量；
• 区分不同应用权限；
• 避免普通用户接触敏感知识库；
• 对外部访问接口设置限流和鉴权。

5. 监控成本与性能

大模型应用上线后，最容易被忽略的是成本。

建议关注：

• 每日请求量；
• 平均 Token 消耗；
• 模型调用失败率；
• 用户高频问题；
• 知识库召回命中率；
• 响应时间；
• API 调用成本。

当访问量增长后，可以考虑：

• 使用更便宜的模型处理简单任务；
• 对重复问题做缓存；
• 精简 Prompt；
• 降低召回片段数量；
• 优化知识库分段；
• 对复杂任务使用高阶模型。

十、一个典型应用示例：企业制度问答助手

为了更直观地理解 Dify 的价值，可以设想一个企业制度问答助手。

员工经常会问：

• 年假怎么计算？
• 报销流程是什么？
• 出差补贴标准是多少？
• 试用期转正需要哪些材料？
• 加班调休怎么申请？
• 婚假、产假、病假分别是多少天？

传统方式是员工自己查制度文档，或者反复问 HR。HR 每天回答大量重复问题，效率很低。

用 Dify 可以这样做：

1. 创建一个聊天助手；
2. 上传员工手册、报销制度、考勤制度等文档；
3. 配置知识库检索；
4. 设置 Prompt，要求只基于知识库回答；
5. 发布成 Web App 或企业微信机器人；
6. 员工直接提问；
7. HR 定期查看日志，补充遗漏文档。

这样，一个内部 HR 助手就搭建完成了。

这个应用不一定复杂，但非常实用。它节省的是大量重复沟通成本。

十一、Dify 的真正价值是什么？

Dify 火起来，并不是因为它能“让 AI 变聪明”，而是因为它让 AI 应用开发变得更简单、更快、更可控。

它的价值可以概括为四点：

1. 降低门槛：不需要从零写后端、前端、知识库和模型调用逻辑；
2. 提升效率：可视化搭建，快速验证业务想法；
3. 便于迭代：Prompt、知识库、工作流都可以持续优化；
4. 适合落地：支持私有化部署、多模型接入、API 发布和日志追踪。

在 AI 技术快速发展的阶段，真正稀缺的不是“会调用模型 API”，而是“能把 AI 变成业务产品”的能力。

Dify 正好站在了这个位置上。

十二、总结

Dify 之所以突然火了，本质上是因为大模型应用开发进入了新阶段。

早期大家关注模型本身，后来关注 Prompt，现在越来越多团队开始关注：如何把 AI 稳定地接入真实业务。

Dify 解决的正是这个问题。

它通过可视化编排、知识库、工作流、多模型接入、API 发布和私有化部署，把大模型应用开发从零散的技术实验，推进到可复用、可运营、可交付的平台化阶段。

当然，Dify 不是万能的。复杂业务仍然需要工程能力，知识库效果仍然依赖数据治理，生产环境也需要认真做好安全、备份和成本控制。

但如果你想快速搭建一个 AI 应用，验证一个业务想法，或者为企业内部建立 AI 助手平台，Dify 无疑是目前非常值得尝试的选择。