Dify：5 分钟内可视化构建生产级 AI 代理

大多数团队都在用笨办法搭 AI 聊天机器人。把 Flask 路由接到 OpenAI API 上，在 JSON 文件里手写提示词模板，从零搭建 RAG 流水线（嵌入模型、向量存储、分块逻辑全部自己来）。三个月后，原型变得没法维护，产品经理没有开发者帮忙都改不了一个提示词，知识库同步靠一个悄悄失败的 cron 任务撑着。

Dify 解决了这个问题。它是一个开源平台，把可视化工作流设计、生产级 RAG、多模型支持和 API 发布打包进单一可部署的技术栈。凭借 141,955 个 GitHub Star、1,298 位贡献者，每 2-4 周一次发布，Dify 已经成为想要发布 AI 应用、又不想手写编排样板代码的团队的默认选择。这份指南带你在 5 分钟内搭好一套生产就绪的 Dify，然后展示怎么和真实工具集成、怎么扩展。

Dify 是什么？ #

Dify 是一个生产就绪的 Agent 工作流开发平台。可以把它理解成原始 LLM API 和终端用户 AI 产品之间缺失的应用层。Dify 提供一个可视化画布，你可以拖拽、连接节点——LLM 调用、知识检索、HTTP 请求、代码执行、条件分支——组装成完整的 AI 应用。

这个平台构建在蜂巢（六边形）架构之上，由多个模块化组件构成：一个 Python Flask API 服务、一个 Celery worker 队列、一个 Next.js 前端、一个模型服务商插件守护进程，以及一个用于代码执行的安全沙箱。它支持 30+ 向量数据库（Weaviate、Qdrant、pgvector、Milvus）、20+ LLM 服务商（OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Ollama、Groq），并开箱自带混合搜索、重排序、内置可观测性和 RESTful API 生成。

你能构建的核心应用类型：

• Chatbot（聊天机器人） —— 带记忆、知识库和工具调用的对话式 AI
• Text Generator（文本生成器） —— 用于摘要、翻译、编程的单次生成应用
• Agent（代理） —— 用 ReAct、Function Calling 和思维链推理的自主 AI
• Workflow（工作流） —— 带条件逻辑和并行执行的多步骤可视化流水线

Dify 是怎么工作的 #

Dify 的架构把各项职责拆分成通过明确定义的 API 通信的独立服务。理解这一点有助于你调试、扩展和加固你的部署。

架构概览 #

数据层 #

工作流执行引擎 #

Dify 的工作流引擎用 DAG（有向无环图）执行模型，支持并行处理。工作流里的每个节点可以顺序运行，也可以在并行线程中运行，配合一套变量池系统，能在节点间共享数据的同时保持隔离性。引擎强制限制每个工作流最多 500 步，超时时间 1200 秒，以防止失控进程。

安装与配置 #

前置条件 #

开始之前，确保你的机器满足这些要求：

第一步 —— 克隆 Dify #

从 GitHub 克隆最新发布版本：

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git

这会检出最新的稳定版本标签（写这篇文章时是 v1.14.2）。

第二步 —— 配置环境 #

cd dify/docker
cp .env.example .env

编辑 .env，设置一个安全的密钥：

# 生成一个密码学安全的密钥
SECRET=$(openssl rand -hex 32)
sed -i "s/SECRET_KEY=.*/SECRET_KEY=${SECRET}/" .env

.env 里需要检查的关键变量：

# 核心设置
CONSOLE_API_URL=http://localhost:5001
CONSOLE_WEB_URL=http://localhost:3000
SERVICE_API_URL=http://localhost:5001
APP_API_URL=http://localhost:5001
APP_WEB_URL=http://localhost:3000

# 数据库
DB_USERNAME=postgres
DB_PASSWORD=difyai123456
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

# Redis
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_DB=0

# 向量存储（默认 Weaviate）
VECTOR_STORE=weaviate
WEAVIATE_ENDPOINT=http://weaviate:8080
WEAVIATE_API_KEY=WVF5YThaHlkYwhGUSmCRgsX3tD5ngdN8pkih

第三步 —— 启动 Dify #

docker compose up -d

这会启动 11 个容器：5 个核心服务 + 6 个依赖。验证一切正常运行：

docker compose ps

你应该能看到所有容器都是 Up (healthy) 状态。首次启动需要 60-90 秒，因为 API 服务要跑数据库迁移。

第四步 —— 初始化管理员账号 #

打开浏览器，访问：

http://localhost/install

用你的邮箱和密码完成配置向导。配置完成后在这里登录：

http://localhost

第五步 —— 添加你的第一个模型服务商 #

进入 Settings → Model Provider，为至少一个服务商添加 API key。以 OpenAI 为例：

1. 从服务商列表里选择 “OpenAI”
2. 粘贴你的 API key（sk-...）
3. 点击"保存"

用 Ollama 做本地开发：

1. 确保 Ollama 在本地运行（ollama serve）
2. 从服务商列表里选择 “Ollama”
3. 把 base URL 设为 http://host.docker.internal:11434
4. 选择一个已下载的模型（比如 llama3.1:8b）

# 拉取一个轻量模型用于测试
ollama pull llama3.1:8b

你的 Dify 实例现在已经可以开始构建 AI 应用了。

与主流工具集成 #

OpenAI / Anthropic Claude #

接入主流 LLM 服务商只是改配置，不需要重新部署。在 Settings → Model Provider 添加好 API key 后，创建你的第一个聊天应用：

1. 进入 Studio → Create App → Chatbot
2. 命名为"客服助手"
3. 在提示词编辑器里写你的系统提示词
4. 从下拉菜单选择你的模型（GPT-4o、Claude Sonnet 等）
5. 点击发布

通过 API 访问这个应用：

curl -X POST 'http://localhost/v1/chat-messages' \
  -H 'Authorization: Bearer YOUR_APP_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {},
    "query": "How do I reset my password?",
    "response_mode": "streaming",
    "conversation_id": "",
    "user": "user-123"
  }'

Ollama（本地 LLM） #

对于网络隔离或成本敏感的环境，Ollama 集成让你能跑本地模型：

# 启动 Ollama
ollama serve

# 拉取模型
ollama pull llama3.1:8b
ollama pull qwen2.5:14b

在 Dify 里，进入 Settings → Model Provider → Ollama 并配置：

开发阶段用本地模型，生产环境切到云端模型，应用逻辑不用改。

Qdrant 向量存储 #

用 Qdrant 替换 Weaviate，获得更好的大规模性能：

cd dify/docker
cp envs/vectorstores/qdrant.env.example envs/vectorstores/qdrant.env

编辑 envs/vectorstores/qdrant.env：

VECTOR_STORE=qdrant
QDRANT_URL=http://qdrant:6333
QDRANT_API_KEY=your-api-key
QDRANT_CLIENT_TIMEOUT=20

把 Qdrant 加进你的 docker-compose.override.yaml：

services:
  qdrant:
    image: qdrant/qdrant:latest
    ports:
      - "6333:6333"
    volumes:
      - qdrant_data:/qdrant/storage
    environment:
      - QDRANT__SERVICE__API_KEY=your-api-key

volumes:
  qdrant_data:

重启 Dify：

docker compose down
docker compose up -d

Weaviate #

Weaviate 是默认的向量存储，开箱即用。生产环境建议用外部 Weaviate 集群：

# 在 .env 里
VECTOR_STORE=weaviate
WEAVIATE_ENDPOINT=https://your-cluster.weaviate.network
WEAVIATE_API_KEY=your-api-key

Claude Code 集成 #

把你的 Dify 应用导出成 MCP（Model Context Protocol）服务，接入 Claude Code：

1. 在你的 Dify 应用里，进入 API Access → MCP Server
2. 开启 MCP 发布
3. 复制 MCP 服务器 URL
4. 在 Claude Code 里运行：

claude config add mcp.dify http://localhost:5001/your-mcp-endpoint

你的 Dify 工作流现在可以直接从 Claude Code 对话中调用了。

性能测试 / 真实使用场景 #

性能特征 #

基于社区基准测试和压力测试数据：

注：实际吞吐量很大程度上取决于 LLM 服务商的延迟和工作流复杂度。

文档索引性能 #

成本对比（自托管，按月） #

真实部署案例 #

客服聊天机器人 —— 一家 40 人的 SaaS 公司部署了一个基于 800 页产品文档训练的 Dify 聊天机器人。解决率从 45% 提升到 78%，第一个月内客服工单量下降了 35%。

内部知识助手 —— 一支金融科技团队基于 5 万份内部文档搭建了一个 RAG 驱动的助手。员工平均 2.3 秒就能拿到带来源引用的答案，取代了原本要花 5-10 分钟的手动 Wiki 搜索。

销售线索评分代理 —— 一家 B2B 创业公司搭建了一套工作流，用 GPT-4o 给入站线索打分，查询 PostgreSQL 数据库里的历史转化数据，再把高质量线索通过 Slack 路由给销售团队。每条线索的响应时间在 10 秒以内。

进阶用法 / 生产环境加固 #

环境隔离 #

生产环境永远不要用默认的 .env 值。创建环境专属配置：

# 生产环境
cp .env .env.production

生产环境的关键改动：

# 安全
SECRET_KEY=$(openssl rand -hex 48)
CONSOLE_API_URL=https://dify.yourcompany.com
CONSOLE_WEB_URL=https://dify.yourcompany.com
SERVICE_API_URL=https://dify.yourcompany.com

# 数据库（外部）
DB_HOST=your-rds-endpoint.amazonaws.com
DB_USERNAME=dify_prod
DB_PASSWORD=<strong-password>

# Redis（外部）
REDIS_HOST=your-elasticache-endpoint
REDIS_PASSWORD=<strong-password>
REDIS_USE_SSL=true

# 文件存储（S3）
STORAGE_TYPE=s3
S3_USE_AWS_MANAGED_IAM=false
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET_NAME=dify-prod-uploads
S3_ACCESS_KEY=AKIA...
S3_SECRET_KEY=...
S3_REGION=us-east-1

带 SSL 的反向代理 #

用 Nginx 或 Traefik 做 TLS 终止：

server {
    listen 443 ssl http2;
    server_name dify.yourcompany.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass http://localhost: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;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /v1/ {
        proxy_pass http://localhost:5001;
        proxy_set_header Host $host;
        proxy_read_timeout 300s;
    }
}

监控与可观测性 #

Dify 通过 API 服务暴露指标。生产环境监控可以这样配置：

# docker-compose.monitoring.yaml
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    volumes:
      - grafana_data:/var/lib/grafana

  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"

volumes:
  grafana_data:

需要追踪的关键指标：

备份策略 #

#!/bin/bash
# backup-dify.sh —— 每天通过 cron 运行

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR=/backups/dify

# PostgreSQL 备份
docker exec dify-db pg_dump -U postgres dify > $BACKUP_DIR/dify_db_$DATE.sql

# Redis 备份
docker exec dify-redis redis-cli BGSAVE

# 文件存储备份（如果用本地卷）
tar czf $BACKUP_DIR/dify_uploads_$DATE.tar.gz /var/lib/docker/volumes/dify_uploads/

# 上传到 S3（可选）
aws s3 sync $BACKUP_DIR/ s3://your-backup-bucket/dify/ --delete

Worker 扩展 #

面对大批量文档处理，水平扩展 Celery worker：

# docker-compose.override.yaml
services:
  worker:
    deploy:
      replicas: 3
    environment:
      - CELERY_WORKER_CONCURRENCY=8

  worker-beat:
    deploy:
      replicas: 1  # 保持恰好 1 个 beat 实例

与其他方案对比 #

该怎么选 #

• 如果你在做面向客户的 AI 应用、需要强大的 RAG、想让非技术团队成员也能管理提示词和知识库，或需要自动生成的 API，选 Dify。Dify 是从想法到部署上线最快的路径。
• 如果你是喜欢 LangChain 抽象层、想要可视化原型层的开发者，选 Flowise。Flowise 有最干净的"脱离"路径——把你的流程导出成 JSON，再翻译成 Python LangChain 代码。
• 如果你的 AI 代理只是更大自动化工作流中的一环，选 n8n。n8n 的 400+ SaaS 连接器，以及久经考验的调度、重试和错误处理能力，在运维密集型集成场景中无可匹敌。
• 如果你需要完整的代码级控制、CI/CD 集成、亚秒级延迟，或低代码工具表达不了的复杂多代理编排，选 LangChain。

局限性 / 真实评估 #

Dify 并不适合所有 AI 项目。以下是它不擅长的地方：

1. 亚秒级延迟负载 Dify 简单工作流的 P95 延迟约 1.2 秒，主要因为节点之间有数据库查询。如果你需要 500ms 以内的响应（比如实时推荐引擎），用 LangGraph 这样的代码优先框架，或部署一个专用的 FastAPI 服务。

2. 复杂数据结构 工作流画布对深度嵌套对象的支持比较浅。当你需要带嵌套数组和条件字段的复杂输入/输出模式时，Dify 会迫使你用一些代码里本不需要的变通方案。

3. 重度工作流自动化 Dify 的工作流是以 AI 为中心的。如果你的自动化主要是在 Salesforce、HubSpot、Slack 和数据库之间搬运数据、AI 成分很少，n8n 更合适。相比 n8n 的 400+ 集成，Dify 的非 AI 连接器库比较有限。

4. 大规模多代理系统 虽然 Dify 支持 Agent 节点，但带共享状态和动态规划的复杂多代理协作，用 LangGraph 或 CrewAI 处理得更好。Dify 的 Agent 能力对大多数场景够用，但达不到研究级的多代理编排水准。

5. 内存受限的文档处理 数据集索引是同步的，大批量上传可能要花几分钟。处理超大知识库（10 万+文档）时会出现内存压力，需要仔细规划 worker 扩容。

常见问题 #

问：怎么在云端 VPS 上安装 Dify？ 流程和本地安装完全一样。开一台至少 4GB 内存的 VPS（DigitalOcean、Hetzner 或 AWS Lightsail 都可以），安装 Docker 和 Docker Compose，克隆仓库，运行 docker compose up -d。想要一键部署，可以用 DigitalOcean Dify 应用市场 。

问：Dify 能完全离线运行吗？ 能。把 Ollama 配置成你的模型服务商，跑 Llama 3.1、Qwen 2.5 或 Mistral 这类本地模型。所有 Dify 服务都在 Docker 内运行，不需要任何外部依赖。唯一的限制是没有联网就用不了云端 LLM API。

问：怎么把 Dify 升级到新版本？

cd dify/docker
docker compose down
git fetch --tags
git checkout $(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)
docker compose pull
docker compose up -d

升级前一定要检查发布说明里的破坏性变更和新增的必需环境变量。

问：Dify 的 Chatbot 和 Agent 应用类型有什么区别？ Chatbot 应用遵循固定的提示词模板，可选配知识检索。Agent 应用用 ReAct 或 Function Calling 推理，自主决定调用哪些工具、按什么顺序调用。直接问答用 Chatbot，需要工具调用和推理的复杂任务用 Agent。

问：我能用自己的嵌入模型而不是 OpenAI 的吗？ 能。Dify 支持多个嵌入模型服务商，包括 Ollama（本地）、Cohere、Jina 和 Hugging Face。进入 Settings → Model Provider 添加你偏好的嵌入模型。你甚至可以给嵌入和生成用不同的模型。

问：Dify 怎么处理数据隐私和安全？ Dify 是自托管的——除非你选择使用云端 LLM API，否则你的数据永远不会离开你的基础设施。所有文件存储、向量嵌入和对话历史都存在你自己的 PostgreSQL 和向量数据库里。SSRF 代理隔离出站请求，沙箱在受限环境中运行不受信任的代码。

问：知识库或应用数量有上限吗？ 开源版本没有硬性限制。实际限制取决于你的基础设施：文档占用的磁盘空间、向量数据库的嵌入容量，以及 API worker 处理查询的吞吐量。大多数团队在一台 8GB 内存的实例上跑 50+ 应用和 20+ 知识库都没问题。

问：我能给 Dify 贡献代码或开发自定义插件吗？ 能。Dify 有一个活跃的插件生态。你可以用 Python 开发自定义模型服务商插件、工具插件或 Agent 策略插件。插件守护进程在开发阶段支持热重载，让迭代循环很快。详见插件开发文档。

自托管小贴士 #

想在自己的 VPS 上跑这个？可以试试 DigitalOcean，200 美元免费额度 ——足够无风险试用 2 个月中等负载的自托管配置。适合中低流量场景；用量超出后再扩展到专用实例。

结语 #

Dify 填补了纯框架和简单聊天机器人构建工具之间的空白。它把可视化工作流构建器、生产级 RAG、自动生成的 API 和多模型支持打包进单一可部署的技术栈。对于要真正发布 AI 应用（而不只是做原型）的团队来说，这套组合能省下几周的集成工作。

5 分钟内，你克隆了 Dify、启动了 11 个容器、创建了管理员账号、接入了第一个 LLM 服务商。从这里开始，你可以构建聊天机器人、代理、文本生成器和复杂工作流——全部用一个非技术团队成员也能用的可视化画布完成。

本周行动清单：

1. 用上面的 Docker Compose 配置，把 Dify 部署到你的基础设施上
2. 用你的产品文档创建一个知识库
3. 搭建一个聊天机器人应用，用 REST API 测试它
4. 在 Telegram 的 dibi8 开发者社区 分享你的部署经验

本文包含联盟链接。如果你通过这些链接购买服务，我们可能会获得佣金，你不用多花一分钱。这能帮助我们维护这样的开源工具指南。

推荐的托管与基础设施 #

在把上面这些工具部署到生产环境之前，你需要靠谱的基础设施。以下两个是 dibi8 实际在用、并推荐的方案：

• DigitalOcean — 60 天 200 美元免费额度，覆盖 14+ 全球区域。独立开发者跑开源 AI 工具的默认选择。
• HTStack — 香港 VPS，大陆访问低延迟。dibi8.com 本身就托管在这家 IDC——生产环境实测过硬。

以上为联盟链接——不会让你多花一分钱，但能帮 dibi8.com 持续运营下去。

来源与延伸阅读 #

1. Dify 官方文档 — https://docs.dify.ai/
2. Dify GitHub 仓库 — https://github.com/langgenius/dify
3. Dify Docker Compose 部署指南 — https://docs.dify.ai/en/self-host/quick-start/docker-compose
4. Dify API 参考 — https://docs.dify.ai/en/use-dify/publish/developing-with-apis
5. Dify 插件开发 — https://docs.dify.ai/en/plugins
6. Dify 架构博客文章 — https://dify.ai/blog/dify-rolls-out-new-architecture
7. Dify v1.14.2 发布说明 — https://github.com/langgenius/dify/releases/tag/1.14.2
8. Flowise GitHub 仓库 — https://github.com/FlowiseAI/Flowise
9. n8n GitHub 仓库 — https://github.com/n8n-io/n8n
10. LangChain 文档 — https://python.langchain.com/
11. 对比：Dify vs Flowise vs n8n — https://rapidclaw.dev/blog/low-code-ai-agent-platforms-compared-2026
12. Ollama 本地 LLM 配置 — https://ollama.com/download

参考与来源 #

• Dify
• Dify Documentation
• Flowise
• n8n
• LangChain
• Ollama
• Qdrant
• Weaviate
• Milvus
• PostgreSQL
• Redis
• Prometheus
• Grafana