项目介绍

Dify 是一个开源的 LLM 应用开发平台,它将 Prompt 工程、RAG 检索增强生成、Agent 智能体、工作流编排、模型管理等能力整合到一个可视化界面中,让开发者和非技术人员都能快速构建生产级 AI 应用。

Dify 的名字来源于 "Define + Modify",旨在让 AI 应用的定义和迭代变得简单。项目由 LangGenius 团队维护,在 GitHub 上拥有超过 90,000 Stars,是目前最热门的开源 AI 应用开发框架之一。

项目信息详情
开发团队LangGenius(原 Dify.AI)
GitHub Stars90,000+
官方网站dify.ai
开源协议Apache License 2.0
技术栈Python(后端)/ TypeScript + React(前端)
支持模型OpenAI / Anthropic / Azure / 通义 / 文心 / Ollama / 100+ 模型
部署方式Docker Compose / 源码 / Dify Cloud
一句话理解:Dify 就像"AI 应用的 WordPress" — 你不需要从零写代码,通过可视化界面就能搭建聊天机器人、知识库问答、Agent 智能体、自动化工作流等各种 AI 应用,还能一键发布为 API 或 Web 应用。

Dify vs 其他 AI 开发平台

对比维度 Dify LangChain Flowise FastGPT Coze
开源 Apache 2.0 MIT Apache 2.0 Apache 2.0 闭源 SaaS
可视化 完整 GUI 纯代码(需 LangSmith) 拖拽式 GUI 完整 GUI 完整 GUI
RAG 能力 内置完整 RAG 流水线 需手动编排 基础支持 内置 RAG 基础知识库
工作流 可视化工作流引擎 LCEL 链式编排 拖拽工作流 简单工作流 可视化工作流
Agent 智能体 Function Call / ReAct 最灵活的 Agent 框架 基础 Agent 有限支持 内置 Agent
模型支持 100+ 模型统一接入 极广 通过 LangChain 主流模型 字节系模型为主
自托管 Docker 一键部署 自行部署 Docker 部署 Docker 部署 仅 SaaS
学习曲线 低(可视化) 高(需编程能力)
适用场景 全场景 AI 应用开发 高度定制化 AI 应用 快速原型 知识库问答 轻量 Bot 开发
选择建议:如果你需要一个开箱即用、功能全面的 AI 应用开发平台,Dify 是最佳选择。如果你是开发者且需要极致灵活性,LangChain 更合适。如果只做知识库问答,FastGPT 更专注。如果不想自己部署且在国内,Coze(扣子)零门槛。

安装部署

方式 1 Docker Compose 部署(推荐)

官方推荐的部署方式,包含所有依赖服务(PostgreSQL、Redis、Weaviate 向量数据库等):
# 克隆 Dify 源码
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 复制环境变量文件
cp .env.example .env

# 启动所有服务
docker compose up -d
启动后访问 http://localhost/install 完成初始化设置(创建管理员账号)。

关键 .env 配置项:
# .env 核心配置 SECRET_KEY=sk-your-random-secret-key # 必须修改,用于加密 CONSOLE_WEB_URL=https://dify.yourdomain.com CONSOLE_API_URL=https://dify.yourdomain.com SERVICE_API_URL=https://dify.yourdomain.com APP_WEB_URL=https://dify.yourdomain.com # 数据库(默认已配置好 PostgreSQL) DB_USERNAME=postgres DB_PASSWORD=difyai123456 # 生产环境务必修改 DB_HOST=db DB_PORT=5432 DB_DATABASE=dify # Redis REDIS_HOST=redis REDIS_PORT=6379 # 向量数据库(默认 Weaviate) VECTOR_STORE=weaviate WEAVIATE_ENDPOINT=http://weaviate:8080 # 文件存储 STORAGE_TYPE=local # 可选 s3, azure-blob 等
注意:生产环境务必修改 SECRET_KEY 和数据库密码,配置 HTTPS 反向代理(Nginx/Caddy),建议使用外部 PostgreSQL 和 Redis。

方式 2 源码部署

适合需要二次开发的场景:
# 后端(Python)
cd api
cp .env.example .env
pip install -r requirements.txt
flask db upgrade
flask run --host 0.0.0.0 --port 5001

# 前端(React)
cd web
cp .env.example .env.local
npm install
npm run build
npm run start
依赖要求:
- Python 3.11+
- Node.js 18+
- PostgreSQL 15+
- Redis 7+
- 向量数据库(Weaviate / Qdrant / Milvus / pgvector 任选)

方式 3 Dify Cloud(托管服务)

不想自己运维可以直接使用 Dify 官方云服务:
- 访问 cloud.dify.ai 注册账号
- 提供免费额度(200 次 GPT-3.5 调用)
- 付费方案从 $59/月起(Professional)
- 自动更新、备份、SSL、弹性扩缩容由官方处理
- 适合不想维护服务器的团队和个人快速验证
提示:先在 Dify Cloud 上体验功能,确认满足需求后再决定是否自托管,可以导出应用配置到私有部署。

核心功能

功能 1 Prompt 工程与编排

Dify 提供了强大的 Prompt IDE,支持可视化编写、测试和优化 Prompt:

核心特性:
- 变量插入:使用 {{变量名}} 语法动态插入用户输入或上下文信息
- Prompt 模板:预设系统 Prompt、用户 Prompt、助手 Prompt 的结构
- 多轮对话管理:自动维护对话历史,支持配置窗口大小
- 参数调优:Temperature、Top-P、Max Tokens 等参数可视化调节
- 调试与预览:实时预览 Prompt 效果,支持批量测试
- 版本管理:每次修改自动保存版本,支持回滚
# Prompt 模板示例 System Prompt: 你是一位专业的{{domain}}顾问,请基于以下知识库内容回答用户问题。 要求:用中文回答,保持专业但通俗易懂,如果不确定请说明。 Context: {{#context#}} # 自动注入知识库检索结果 User: {{query}} # 用户的输入问题

功能 2 模型管理与供应商接入

Dify 支持统一接入 100+ 大语言模型,通过统一接口调用不同供应商的模型:

已支持的模型供应商:
- OpenAI:GPT-4o、GPT-4-turbo、GPT-3.5-turbo、Whisper、DALL-E 等
- Anthropic:Claude 3.5 Sonnet、Claude 3 Opus、Claude 3 Haiku 等
- Google:Gemini 1.5 Pro、Gemini 1.5 Flash 等
- Azure OpenAI:所有 Azure 部署的 OpenAI 模型
- 国产模型:通义千问、文心一言、智谱 GLM、MiniMax、月之暗面 Moonshot、DeepSeek 等
- 本地模型:Ollama、Xinference、LocalAI、LM Studio、vLLM 等
- Embedding 模型:text-embedding-3、bge-large、m3e 等
- Rerank 模型:Cohere Rerank、bge-reranker 等
省钱技巧:在 Dify 中配置多个模型供应商,简单任务用便宜模型(如 GPT-3.5 / DeepSeek),复杂任务用强模型(如 GPT-4o / Claude 3.5 Sonnet),通过工作流中的条件分支自动路由。

功能 3 Agent 智能体

Dify 的 Agent 功能允许 LLM 自主调用工具完成复杂任务:

Agent 策略:
- Function Calling:利用模型原生的函数调用能力(推荐,需模型支持)
- ReAct:思考-行动-观察循环,兼容更多模型

内置工具:
- Google 搜索 / Bing 搜索 — 实时联网搜索
- Wikipedia — 百科知识查询
- DALL-E / Stable Diffusion — 图像生成
- Wolfram Alpha — 数学计算
- 天气查询 / 股票查询 — 实时数据
- 代码解释器 — 执行 Python 代码
- 网页爬取 — 抓取网页内容

自定义工具:
- 通过 OpenAPI/Swagger 规范导入任意 API 作为工具
- 支持 API Key、OAuth 2.0 等认证方式
- 工具描述决定了 Agent 何时调用该工具,需要写清楚

功能 4 应用类型

Dify 支持创建多种类型的 AI 应用:

聊天助手(Chat):多轮对话式 AI,支持知识库增强和工具调用
文本生成(Completion):单次输入输出,适用于文案生成、翻译、摘要等
Agent(智能体):自主规划和执行任务,可调用多种工具
工作流(Workflow):可视化编排复杂 AI 流程,支持分支、循环、并行

每种应用都可以:
- 发布为独立 Web 应用(自带 UI)
- 通过 API 集成到你自己的系统
- 嵌入到网页中(iframe / JS Widget)

功能 5 日志与监控

Dify 提供完善的运行日志和监控面板:
- 对话日志:查看每次用户交互的完整记录,包含 Prompt、模型响应、Token 用量
- 标注功能:对 AI 回复进行人工标注(赞/踩),积累训练数据
- 用量统计:API 调用次数、Token 消耗、活跃用户数等可视化图表
- 成本追踪:按模型、按应用维度统计 API 花费
- LangSmith / LangFuse 集成:支持将日志导出到第三方 LLMOps 平台做更深入的分析

工作流编排

Dify 的工作流引擎是其核心差异化能力之一,通过可视化拖拽方式编排复杂的 AI 处理流程。以下是 10 个典型工作流场景:

场景 1 智能客服聊天机器人

构建一个能理解用户意图、查询知识库、多轮对话的客服机器人:
┌──────────┐ ┌──────────────┐ ┌────────────┐ ┌──────────┐ │ 开始 │───▶│ 意图分类 │───▶│ 知识库检索 │───▶│ LLM 回复 │ │ (用户输入)│ │ (LLM 分类) │ │ (RAG) │ │ (生成答案)│ └──────────┘ └──────┬───────┘ └────────────┘ └──────────┘ │ 转人工 ▼ ┌──────────┐ │ HTTP 请求│ │ (通知客服)│ └──────────┘
关键节点配置:
- 意图分类节点:用 LLM 判断用户意图(咨询/投诉/转人工)
- 知识库检索:关联产品文档和 FAQ 知识库
- 条件分支:根据意图路由到不同处理分支
- LLM 节点:基于检索结果生成自然语言回复

场景 2 长文本生成与优化

多步骤生成高质量长文本(如博客文章、报告):

工作流步骤:
1. 开始节点:接收主题、目标读者、字数要求等参数
2. 大纲生成(LLM):根据主题生成文章大纲
3. 分段撰写(循环 + LLM):逐段展开撰写内容
4. 内容审核(LLM):检查事实准确性、语法、连贯性
5. SEO 优化(LLM):添加关键词、优化标题和描述
6. 结束节点:输出完整文章
技巧:在每个 LLM 节点使用不同的 Prompt 角色(大纲专家、内容作者、审核编辑、SEO 专家),分工协作效果更好。

场景 3 Agent 自主任务执行

让 AI Agent 自主规划并完成复杂任务:

示例 — 竞品分析 Agent:
- 配置工具:Google 搜索、网页爬取、代码解释器
- System Prompt:你是一位专业的市场分析师,请对给定的竞品进行全面分析
- Agent 会自动:搜索竞品信息 → 爬取官网 → 对比数据 → 生成分析报告

Agent 迭代次数:建议设置为 5-10 次,过多会增加成本和延迟
Max Token:Agent 需要更大的上下文窗口,建议 4096+

场景 4 RAG 知识库问答应用

基于企业内部文档构建智能问答系统:
┌──────────┐ ┌────────────┐ ┌────────────┐ ┌──────────┐ │ 用户提问 │───▶│ 问题改写 │───▶│ 知识库检索 │───▶│ LLM 回答 │ │ │ │ (Query │ │ (Top-K │ │ (引用来源)│ │ │ │ Rewrite) │ │ + Rerank) │ │ │ └──────────┘ └────────────┘ └────────────┘ └──────────┘
优化要点:
- 问题改写节点可以将口语化提问转为适合检索的关键词形式
- 设置 Top-K = 5-8,结合 Rerank 模型筛选最相关的片段
- 在 LLM Prompt 中要求模型引用来源,增加可信度
- 添加兜底逻辑:当检索结果相关度低时,提示用户换个方式提问

场景 5 API 驱动的自动化工作流

通过 Webhook 触发,实现与外部系统的自动化集成:

示例 — 自动处理客户反馈:
1. Webhook 接收来自表单/CRM 的客户反馈
2. LLM 分析情感倾向(正面/中性/负面)
3. LLM 提取关键问题和需求
4. 条件分支:负面反馈走紧急处理通道
5. HTTP 请求:将处理结果写回 CRM,发送通知给对应负责人
# Webhook 调用示例
curl -X POST https://dify.yourdomain.com/v1/workflows/run \
  -H "Authorization: Bearer app-xxxxx" \
  -H "Content-Type: application/json" \
  -d '{"inputs": {"feedback": "产品体验很差..."}}'

场景 6 代码解释器工作流

结合代码执行能力处理数据分析、计算类任务:

工作流设计:
- 代码节点(Python):在沙箱中执行 Python 代码,支持 pandas、numpy 等库
- 适用场景:数据清洗、统计分析、图表生成、CSV 处理
- 可以在工作流中组合多个代码节点和 LLM 节点
# 代码节点示例 — 数据分析 import json def main(data: str) -> dict: records = json.loads(data) total = sum(r['amount'] for r in records) avg = total / len(records) return { "total": total, "average": round(avg, 2), "count": len(records) }

场景 7 图像生成工作流

结合 LLM 和图像生成模型创建图文内容:

工作流步骤:
1. 用户输入主题描述
2. LLM 将描述优化为英文 Prompt(DALL-E / Stable Diffusion 用英文效果更好)
3. 调用图像生成 API(DALL-E 3 / Midjourney API / Stable Diffusion)
4. LLM 根据生成的图片描述撰写配套文案
5. 输出图片 URL + 文案
提示:Dify 内置 DALL-E 工具,只需在模型供应商中配置 OpenAI API Key 即可使用。如需 Stable Diffusion,可通过自定义工具接入 API。

场景 8 多模型对比评测

在工作流中并行调用多个模型,对比输出质量:

工作流设计:
1. 开始节点接收评测 Prompt
2. 并行节点:同时调用 GPT-4o / Claude 3.5 / 通义千问
3. 汇聚节点:将三个模型的输出合并
4. 评审 LLM:使用一个强模型评判哪个回答最好
5. 输出三个模型的回复及评分

应用场景:模型选型、Prompt 优化、质量基准测试

场景 9 定时任务与批量处理

通过外部定时触发实现批量 AI 处理任务:

实现方式:
- Dify 工作流本身不支持内置定时器,但可以通过以下方式实现:
- Linux Cron + curl:定时调用 Dify Workflow API
- n8n / Zapier:用外部自动化工具定时触发
- GitHub Actions:利用 schedule 触发器
# Cron 定时调用示例(每天早上 8 点执行)
0 8 * * * curl -X POST https://dify.example.com/v1/workflows/run \
  -H "Authorization: Bearer app-xxxxx" \
  -H "Content-Type: application/json" \
  -d '{"inputs": {"date": "$(date +\%Y-\%m-\%d)"}}'

场景 10 Webhook 集成与事件驱动

通过 Webhook 将 Dify 接入到现有业务流程中:

常见集成场景:
- 飞书/钉钉机器人:收到消息 → 调用 Dify Chat API → 返回 AI 回复
- GitHub Issue:新 Issue 创建 → Dify 分析内容 → 自动打标签
- 电商订单:新订单通知 → Dify 生成个性化感谢信 → 发送邮件
- 监控告警:告警触发 → Dify 分析日志 → 给出初步排查建议

Webhook 安全:建议使用 API Key 认证,或配合签名验证防止滥用。

RAG 知识库

RAG(Retrieval-Augmented Generation)是 Dify 最核心的能力之一,允许 AI 基于你的私有数据回答问题,而不是只依赖模型的预训练知识。

步骤 1 文档上传与数据源

Dify 支持多种数据源导入方式:

支持的文件格式:
- 文本类:TXT、Markdown、PDF、DOCX、HTML
- 数据类:CSV、Excel、JSON
- 在线数据:Notion 页面同步、网页爬取

上传限制(社区版默认):
- 单文件最大 15MB
- 每个知识库最多 50 个文档(可配置修改)
- 支持批量上传
最佳实践:PDF 文件建议先检查解析效果,复杂排版的 PDF 可能需要预处理(如转为 Markdown)。长文档建议拆分为多个主题文件,便于管理和精确检索。

步骤 2 分块策略(Chunking)

文档需要被切分成小块才能有效检索,Dify 提供多种分块策略:

自动分块:Dify 根据文档类型自动选择最优分块方式(推荐新手使用)

自定义分块:
- 分隔符:按段落(\n\n)、标题(#)、自定义分隔符切分
- 块大小:推荐 500-1000 tokens(过小信息不完整,过大检索精度下降)
- 重叠大小:推荐 50-100 tokens(保证相邻块之间的上下文连贯)

问答模式(Q&A):对于 FAQ 类文档特别有效,Dify 会自动从文档中提取问答对
注意:分块质量直接决定了 RAG 效果的好坏。如果发现回答不准确,优先检查分块是否合理,而不是调整 Prompt。

步骤 3 Embedding 模型选择

Embedding 模型将文本转为向量,是 RAG 检索的基础:

模型维度多语言适用场景
text-embedding-3-large3072优秀通用场景(推荐)
text-embedding-3-small1536良好控制成本
bge-large-zh-v1.51024中文优秀中文为主场景
m3e-base768中文良好本地部署免费
nomic-embed-text768英文为主Ollama 本地部署
省钱方案:使用 Ollama 本地部署 nomic-embed-text 或 bge 系列模型,完全免费且无 API 调用限制。在 Dify 模型供应商中添加 Ollama,配置 Embedding 模型即可。

步骤 4 检索优化与 Rerank

检索质量直接决定 RAG 应用的回答质量,Dify 提供多种检索优化手段:

检索模式:
- 向量检索:基于语义相似度匹配(默认,适合大多数场景)
- 全文检索:基于关键词匹配(BM25 算法,适合精确术语查询)
- 混合检索:向量 + 全文结合,取两者优势(推荐生产环境使用)

Rerank 重排序:
- 在初步检索后,使用 Rerank 模型对结果进行精排
- 支持 Cohere Rerank、bge-reranker-v2 等模型
- 显著提升检索准确率,尤其是混合检索场景

参数调优:
- Top-K:初步检索返回的文档块数量(推荐 5-10)
- Score 阈值:过滤相关度低于阈值的结果(推荐 0.5-0.7)
- Rerank Top-N:重排序后保留的文档块数量(推荐 3-5)
常见误区:不要一味增大 Top-K,过多的检索结果会引入噪声,反而降低回答质量。关键是提升每条检索结果的相关性,而不是数量。

API 集成

接口 1 REST API 调用

每个 Dify 应用都会自动生成 API 端点,在应用设置页面获取 API Key 后即可调用:

Chat 类应用 API:
# 发送消息(流式响应)
curl -X POST 'https://api.dify.ai/v1/chat-messages' \
  -H 'Authorization: Bearer app-xxxxxxxxxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {},
    "query": "如何部署 Dify?",
    "response_mode": "streaming",
    "conversation_id": "",
    "user": "user-123"
  }'
Completion 类应用 API:
# 文本生成
curl -X POST 'https://api.dify.ai/v1/completion-messages' \
  -H 'Authorization: Bearer app-xxxxxxxxxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {"topic": "AI 应用开发趋势"},
    "response_mode": "blocking",
    "user": "user-123"
  }'
Workflow API:
# 执行工作流
curl -X POST 'https://api.dify.ai/v1/workflows/run' \
  -H 'Authorization: Bearer app-xxxxxxxxxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {"data": "要处理的内容"},
    "response_mode": "streaming",
    "user": "user-123"
  }'

接口 2 嵌入网页(Web Widget)

Dify 支持将 AI 应用以聊天气泡的形式嵌入任意网站:

iframe 嵌入:
<iframe
  src="https://udify.app/chatbot/xxxxxxxx"
  style="width: 100%; height: 100%; min-height: 700px"
  frameborder="0"
  allow="microphone">
</iframe>
JS Widget 嵌入(聊天气泡):
<script>
  window.difyChatbotConfig = {
    token: 'xxxxxxxx',
    baseUrl: 'https://api.dify.ai'
  }
</script>
<script
  src="https://udify.app/embed.min.js"
  id="xxxxxxxx"
  defer>
</script>
自定义外观:可以通过 CSS 变量自定义聊天气泡的颜色、位置、大小等。如需更深度定制,可以 Fork 官方的 webapp-conversation 项目。

接口 3 SDK 使用

Dify 提供官方 SDK,简化 API 调用:

Python SDK:
pip install dify-client
from dify_client import ChatClient client = ChatClient( api_key="app-xxxxxxxxxxxxxxxx", base_url="https://api.dify.ai/v1" ) # 发送消息 response = client.create_chat_message( inputs={}, query="如何使用 Dify 构建 RAG 应用?", user="user-123", response_mode="blocking" ) print(response.json())

JavaScript/TypeScript SDK:
npm install dify-client
import { DifyClient } from 'dify-client'; const client = new DifyClient({ apiKey: 'app-xxxxxxxxxxxxxxxx', baseUrl: 'https://api.dify.ai/v1' }); // 发送消息 const response = await client.createChatMessage({ inputs: {}, query: '如何使用 Dify 构建 RAG 应用?', user: 'user-123', responseMode: 'blocking' });

常见问题(50 个)

Docker 部署问题 (#1 - #10)

#1 Docker Compose 启动失败 — 端口占用

Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use
端口 80 被其他服务(如 Nginx、Apache)占用:
1. 查看占用进程:sudo lsof -i :80sudo netstat -tlnp | grep :80
2. 停止占用的服务,或修改 docker-compose.yaml 中 nginx 服务的端口映射:
# 将 80:80 改为其他端口
ports:
  - "8080:80"

3. 如果用外部 Nginx 反向代理,可以只暴露内部端口而不映射 80。

#2 Docker Compose 版本不兼容

ERROR: Version in "./docker-compose.yaml" is unsupported
Dify 需要 Docker Compose V2(即 docker compose 而非 docker-compose):
1. 检查版本:docker compose version(需要 v2.0+)
2. 如果使用旧版,升级 Docker Desktop 或安装 Docker Compose Plugin:
sudo apt-get update
sudo apt-get install docker-compose-plugin

#3 容器启动后无法访问页面

浏览器访问 http://localhost 提示连接被拒绝或空白页
排查步骤:
1. 检查所有容器是否正常运行:docker compose ps(状态应该都是 running)
2. 查看 api 容器日志:docker compose logs api
3. 查看 web 容器日志:docker compose logs web
4. 确认 .env 文件已正确复制(cp .env.example .env
5. 等待几分钟让服务完全启动,首次启动需要初始化数据库

#4 数据库迁移失败

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "db" port 5432 failed
PostgreSQL 容器未就绪就开始迁移了:
1. 确认 db 容器已启动:docker compose ps db
2. 重启 api 服务:docker compose restart api
3. 如果持续失败,检查 .env 中数据库配置是否与 docker-compose.yaml 一致
4. 清理重来:docker compose down -v && docker compose up -d(注意 -v 会删除数据)

#5 Redis 连接失败

redis.exceptions.ConnectionError: Error 111 connecting to redis:6379. Connection refused.
Redis 容器未启动或配置错误:
1. 检查 Redis 容器状态:docker compose ps redis
2. 确认 .envREDIS_HOST=redis(Docker 网络中用服务名)
3. 如果使用外部 Redis,确认地址、端口、密码是否正确
4. 查看 Redis 日志:docker compose logs redis

#6 Weaviate 向量数据库启动失败

weaviate: Failed to start up: failed to connect to vector index
Weaviate 需要足够的内存和磁盘空间:
1. 确认服务器至少有 4GB 可用内存
2. 检查磁盘空间:df -h
3. 如果内存不足,可以切换到 Qdrant 或 pgvector(在 .env 中设置 VECTOR_STORE=qdrant
4. 清理 Weaviate 数据后重试:docker compose down weaviate && docker volume rm docker_weaviate_data && docker compose up -d

#7 磁盘空间不足

no space left on device
Docker 镜像和数据占用大量磁盘空间:
1. 清理无用 Docker 资源:docker system prune -a
2. 清理旧镜像:docker image prune -a
3. 检查 Docker 数据目录大小:du -sh /var/lib/docker/
4. Dify 完整部署(含向量数据库)建议至少 20GB 可用空间

#8 容器内存不足(OOM Killed)

Container killed: OOMKilled
Dify 包含多个服务,建议服务器至少 4GB 内存(推荐 8GB):
1. 检查内存使用:docker stats
2. 如果内存紧张,可以禁用不需要的服务(如 Sandbox)
3. 使用 swap 扩展:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

4. 考虑使用轻量级向量数据库(如 pgvector 复用 PostgreSQL)

#9 Docker 镜像拉取超时(中国大陆)

Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection
国内拉取 Docker Hub 镜像经常超时:
1. 使用国内镜像源,编辑 /etc/docker/daemon.json
{
  "registry-mirrors": [
    "https://docker.1panel.live",
    "https://hub.rat.dev"
  ]
}

2. 重启 Docker:sudo systemctl restart docker
3. 或使用代理拉取

#10 升级 Dify 后数据丢失

升级版本后应用、知识库等数据消失
正确的升级流程:
1. 备份数据docker compose down,然后备份 volumes 目录和 .env 文件
2. 拉取新代码git pull origin main
3. 检查 .env 变更:对比 .env.example 是否有新增配置项
4. 重新启动docker compose up -d(会自动执行数据库迁移)
绝对不要使用 docker compose down -v 升级,-v 参数会删除所有数据卷!
模型连接问题 (#11 - #20)

#11 OpenAI API Key 无效

Error code: 401 - Incorrect API key provided

1. 确认 API Key 以 sk- 开头,复制时没有多余空格
2. 检查 Key 是否已过期或被撤销:访问 OpenAI API Keys 页面
3. 确认账户有余额(OpenAI 预付费模式,余额为 0 时 Key 不可用)
4. 如果使用代理/转发地址,确认 API Base URL 配置正确

#12 OpenAI API 调用超时

Request timed out: HTTPSConnectionPool(host='api.openai.com', port=443): Read timed out
国内访问 OpenAI API 不稳定:
1. 使用 API 代理/转发服务,在模型供应商设置中修改 API Base URL
2. 使用 Azure OpenAI(微软 Azure 在国内有节点)
3. 在服务器上配置代理:.env 中设置 HTTP_PROXYHTTPS_PROXY
4. 考虑切换为国产模型(通义千问、DeepSeek 等)

#13 Ollama 本地模型连接失败

Connection refused: http://localhost:11434
Docker 容器内的 localhost 指向的是容器自身,不是宿主机:
1. 将 Ollama 地址改为宿主机 IP:http://host.docker.internal:11434(Docker Desktop)
2. 或使用宿主机实际 IP:http://192.168.x.x:11434
3. 确认 Ollama 允许外部访问:设置 OLLAMA_HOST=0.0.0.0
4. Linux 用户使用 --network host 或在 docker-compose 中配置网络

#14 Azure OpenAI 配置错误

InvalidAuthenticationError: Access denied due to invalid subscription key or wrong API endpoint
Azure OpenAI 需要配置 4 个信息:
1. API Key:在 Azure Portal → 资源 → Keys and Endpoint 获取
2. API Base:格式为 https://你的资源名.openai.azure.com/
3. API Version:2024-02-01
4. Deployment Name:在 Azure OpenAI Studio 中创建的部署名称(不是模型名)

#15 模型调用返回空结果

模型返回空内容或 finish_reason 为 "content_filter"

1. 内容审核触发:某些模型(尤其 Azure OpenAI)有严格的内容过滤,尝试调整 Prompt 避免敏感词
2. Max Tokens 设置过小:增大 Max Tokens 参数
3. Prompt 过长超出上下文窗口:检查总 Token 数是否超出模型限制
4. 模型不支持中文:部分小模型中文能力弱,切换为支持中文的模型

#16 API 调用额度超限

Error code: 429 - Rate limit reached for model
API 请求频率或 Token 用量超限:
1. OpenAI 有分钟/天的调用频率限制,等待后重试
2. 在 Dify 中配置模型负载均衡:添加多个相同模型的 API Key
3. 降低并发请求量:适当增加请求间隔
4. 申请提升 API 额度限制(OpenAI 在用量页面可申请)

#17 通义千问 API 接入失败

InvalidParameter: The model is not supported

1. 在阿里云 DashScope 控制台开通模型服务
2. 确认选择了正确的模型名称(如 qwen-maxqwen-plus
3. API Key 从 DashScope 控制台获取,不是阿里云主账号的 AccessKey
4. 确认所选模型已在 DashScope 控制台中开通使用

#18 Anthropic Claude 模型 400 错误

Error code: 400 - messages: at least one message is required
Claude 模型对 Prompt 格式有特殊要求:
1. System Prompt 不能为空(至少写一句)
2. 消息列表必须以 user 角色开始
3. 确认 API Key 以 sk-ant- 开头
4. 确认选择了正确的模型版本(claude-3-5-sonnet-20241022 等)

#19 本地模型推理速度慢

Ollama 或 vLLM 推理响应时间超过 30 秒

1. 确认 GPU 是否被正确识别:nvidia-smi(应显示 GPU 型号和显存)
2. Ollama 默认使用 CPU,需要安装 CUDA 版本
3. 选择合适大小的模型:7B 模型需要约 8GB 显存,13B 需要约 16GB
4. 启用量化模型减少资源需求:ollama pull llama3:8b-q4_0
5. 对于 vLLM,使用 --gpu-memory-utilization 0.9 最大化显存利用

#20 DeepSeek 模型接入配置

无法在 Dify 中找到 DeepSeek 模型供应商
Dify 新版本已内置 DeepSeek 供应商:
1. 进入 设置 → 模型供应商 → 找到 DeepSeek
2. 输入从 platform.deepseek.com 获取的 API Key
3. 如果使用旧版 Dify 未内置,可以通过 OpenAI 兼容模式接入:
- API Base:https://api.deepseek.com/v1
- 模型名称:deepseek-chatdeepseek-reasoner
知识库问题 (#21 - #30)

#21 文档上传失败 — 文件过大

File size exceeds the maximum limit

1. 默认单文件限制 15MB,可在 .env 中修改 UPLOAD_FILE_SIZE_LIMIT
2. 大 PDF 建议拆分为多个文件后分别上传
3. 检查 Nginx 的 client_max_body_size 配置是否足够大
# nginx.conf
client_max_body_size 50m;

#22 PDF 解析内容乱码或缺失

上传的 PDF 文件解析结果内容缺失、表格错乱或中文乱码
PDF 解析质量取决于文件本身的结构:
1. 扫描件 PDF 需要 OCR 支持,确认 Dify 已启用 OCR(需安装相关依赖)
2. 复杂排版的 PDF 建议先转为 Markdown 再上传
3. 使用专业工具预处理:markerpdf2textunstructured
4. 表格内容建议单独提取为 CSV 格式上传

#23 知识库索引构建失败

Embedding indexing failed: Connection to vector database failed
向量数据库服务不可用:
1. 检查向量数据库容器状态:docker compose ps weaviate(或 qdrant、milvus)
2. 确认 .envVECTOR_STORE 配置和对应的连接参数正确
3. 查看向量数据库日志:docker compose logs weaviate
4. 重启向量数据库:docker compose restart weaviate

#24 知识库检索不到相关内容

AI 回复"我无法找到相关信息",但文档中明明有答案
检索效果差的常见原因和解决方案:
1. 分块太大:减小 chunk size 到 500-800 tokens
2. Embedding 模型不适合:中文场景换用 bge-large-zh 或 text-embedding-3-large
3. 检索模式:切换到混合检索(向量 + 全文)
4. 开启 Rerank:添加 Rerank 模型进行二次排序
5. Top-K 太小:增大到 8-10
6. Score 阈值太高:降低到 0.3-0.5 观察效果
7. 在知识库 → 命中测试中输入问题验证检索结果

#25 Embedding 调用报错 — 维度不匹配

Vector dimension mismatch: expected 1536, got 3072
知识库创建后不能更换 Embedding 模型(维度不同):
1. 这是因为已有文档用旧模型生成了向量,新模型维度不同
2. 解决方案:创建新知识库 → 选择新 Embedding 模型 → 重新上传文档
3. 删除旧知识库释放存储空间
建议:创建知识库前先确定 Embedding 模型,避免后续重新索引的成本。

#26 Notion 数据源同步失败

Failed to sync Notion pages: NotionAPIResponseError: Could not find page

1. 确认 Notion Integration 已被添加到目标页面(页面右上角 ... → Add connections)
2. 检查 Integration 的 Capabilities 是否包含 "Read content"
3. 子页面需要单独授权,父页面授权不会自动继承到子页面
4. 重新授权:在 Dify 设置中断开并重新连接 Notion

#27 知识库处理队列堵塞

文档状态一直显示 "Queuing" 或 "Processing",长时间不完成
文档索引是异步任务,由 Celery Worker 处理:
1. 检查 worker 容器是否正常:docker compose ps worker
2. 查看 worker 日志:docker compose logs worker
3. 重启 worker:docker compose restart worker
4. 检查 Redis 连接是否正常(Celery 依赖 Redis 作为消息队列)
5. 如果上传了大量文档,耐心等待或分批上传

#28 知识库检索结果质量差 — 答非所问

检索到的文档片段与问题不相关,导致 AI 回答偏题

1. 优化文档质量:删除无关内容(目录、页眉页脚、广告等)
2. 添加元数据:在文档开头添加标题和摘要,帮助检索定位
3. 使用 Q&A 分块模式:适合 FAQ 类文档,自动提取问答对
4. Prompt 优化:在 System Prompt 中添加"如果检索结果与问题无关,请说明无法回答"
5. 开启引用显示:让用户看到 AI 引用了哪些文档片段,便于反馈调优

#29 向量数据库磁盘占用过大

Weaviate / Qdrant 数据目录占用超过 10GB

1. 清理已删除知识库的残留数据:在 Dify 界面中删除不需要的知识库
2. 如果使用 Weaviate,可以执行压缩:通过 API 触发 compact 操作
3. 考虑切换到 pgvector(复用 PostgreSQL,减少一个服务的开销)
4. 设置 VECTOR_STORE=pgvector 并配置 pgvector 扩展

#30 多知识库检索冲突

关联多个知识库后,不同知识库的内容相互干扰

1. 在应用中可以关联多个知识库,Dify 会从所有知识库中检索并合并结果
2. 如果某个知识库干扰严重,考虑降低它的权重或解除关联
3. 使用 Rerank 模型对多知识库结果进行统一排序
4. 在 Prompt 中明确指示"只基于提供的上下文回答"
5. 如需更精细控制,在工作流中使用知识库检索节点并添加条件分支
工作流问题 (#31 - #38)

#31 工作流执行超时

Workflow execution timeout: exceeded maximum execution time

1. 默认工作流执行超时为 300 秒(5 分钟)
2. 优化工作流:减少串行的 LLM 节点数量,改为并行
3. 对于长时间运行的任务,使用异步模式(response_mode: streaming
4. 在 .env 中调整 WORKFLOW_MAX_EXECUTION_TIME 参数
5. 检查是否有死循环或不合理的迭代次数

#32 变量传递失败 — 上下文丢失

工作流节点之间的变量值为 null 或 undefined

1. 确认变量引用路径正确:{{#node_id.output_key#}}
2. 检查前置节点是否成功执行(失败的节点不会产生输出)
3. 注意变量类型:字符串、数字、对象、数组类型需要匹配
4. 使用工作流调试功能,查看每个节点的输入输出
5. 条件分支后的节点只能引用该分支路径上前置节点的变量

#33 代码节点执行报错

Code execution failed: ModuleNotFoundError: No module named 'requests'
Dify 的代码节点在沙箱中运行,仅支持有限的 Python 标准库:
1. 支持的库:jsonmathdatetimere 等标准库
2. 不支持 requestspandas 等第三方库(使用 HTTP 请求节点替代 requests)
3. 如果需要复杂计算,可以外置为独立 API 服务,通过 HTTP 节点调用
4. Sandbox 环境可以在 docker-compose.yaml 中配置允许的依赖

#34 HTTP 请求节点返回错误

HTTPConnectionPool: Max retries exceeded with url

1. URL 不可达:确认目标 API 地址正确且可从 Dify 服务器访问
2. Docker 网络隔离:如果调用宿主机上的服务,使用 host.docker.internal
3. 超时:增大 HTTP 请求节点的超时时间设置
4. 认证失败:检查 Header 中的 Authorization 配置
5. SSL 错误:如果目标使用自签名证书,可能需要禁用 SSL 验证

#35 条件分支不按预期执行

IF 条件判断结果与预期不符

1. 使用工作流调试功能查看条件判断时变量的实际值
2. 注意字符串比较和数字比较的区别("10" > "9" 为 false,因为是字符串比较)
3. LLM 输出的结果可能包含额外空白字符,使用 contains 而不是 equals
4. 对于 LLM 分类输出,明确要求模型只输出指定的关键词(如 "A" 或 "B")

#36 迭代节点处理大数据集卡住

迭代处理 100+ 条数据时超时或失败

1. 迭代节点每次循环都会调用 LLM,大量数据成本高且耗时长
2. 设置合理的并行度(如一次处理 10 条)
3. 对于大批量处理,建议通过外部脚本循环调用 Dify API
4. 为迭代节点设置错误处理,跳过失败项而不是中止整个流程

#37 工作流发布后行为与调试不同

调试时正常,发布后返回结果异常

1. 调试模式使用的是最新草稿,发布后运行的是发布版本
2. 确认修改后已重新发布(点击"发布"按钮)
3. 检查变量默认值:调试时手动输入的变量,API 调用时可能为空
4. 确认 API 调用传入了所有必需的 inputs 参数

#38 工作流导入导出失败

Failed to import DSL: Invalid workflow format

1. Dify 使用 DSL(YAML 格式)导出工作流配置
2. 确认导入的 DSL 版本与当前 Dify 版本兼容
3. 检查 DSL 文件中引用的模型和工具在目标实例中是否可用
4. 导入后需要重新配置模型供应商的 API Key(出于安全考虑不会导出)
应用与 API 问题 (#39 - #45)

#39 API 调用返回 401 Unauthorized

{"code": "unauthorized", "message": "Invalid token"}

1. 确认使用的是应用的 API Key(以 app- 开头),不是模型的 API Key
2. 在 Header 中正确传递:Authorization: Bearer app-xxxxxxxx
3. 检查 API Key 是否已被删除或重新生成
4. 确认请求的 URL 正确(自托管时使用自己的域名,不是 api.dify.ai)

#40 流式响应(SSE)无法正常接收

使用 streaming 模式但客户端收不到实时数据

1. Nginx 缓冲:需要关闭代理缓冲,添加配置:
proxy_buffering off;
proxy_cache off;
proxy_set_header X-Accel-Buffering no;

2. 客户端处理:使用 EventSource API 或 SSE 库接收
3. CDN 缓存:Cloudflare 等 CDN 可能缓冲 SSE,需要配置 bypass
4. 确认 response_mode 设置为 "streaming"

#41 对话历史记录丢失

多轮对话中 AI 不记得之前的内容

1. 确认传递了 conversation_id:首次调用返回的 conversation_id 需要在后续请求中传入
2. 检查对话窗口大小设置:过小会导致历史消息被截断
3. 确认应用类型是"聊天助手"而非"文本生成"(后者不支持多轮对话)
4. 如果是 Web 嵌入,确认浏览器没有清除 LocalStorage

#42 Web 应用嵌入跨域错误

Access to XMLHttpRequest has been blocked by CORS policy

1. 在 .env 中配置 WEB_API_CORS_ALLOW_ORIGINS=*(或指定你的域名)
2. 如果使用 Nginx 反向代理,添加 CORS 头:
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
add_header Access-Control-Allow-Headers "Authorization, Content-Type";

3. 使用 iframe 嵌入方式可以规避部分 CORS 问题

#43 文件上传 API 报错

{"code": "unsupported_file_type", "message": "File type not supported"}

1. 检查文件类型是否在支持列表中(图片:jpg/png/gif/webp,文档:pdf/txt/md/docx 等)
2. 确认 multipart/form-data 格式正确
3. 文件名需要包含正确的扩展名
4. 检查文件大小是否超出限制
# 上传文件示例
curl -X POST 'https://api.dify.ai/v1/files/upload' \
  -H 'Authorization: Bearer app-xxxxx' \
  -F 'file=@/path/to/document.pdf' \
  -F 'user=user-123'

#44 应用并发量上不去

高并发时 API 响应变慢或返回 503

1. 增加 Worker 数量:.env 中设置 SERVER_WORKER_AMOUNT=4(根据 CPU 核数调整)
2. 增加 Celery Worker:通过 docker compose scale worker=3 扩展
3. 使用外部数据库和 Redis:独立部署 PostgreSQL 和 Redis,减轻单机压力
4. Nginx 优化:增加 worker_connections 和连接超时设置
5. 考虑多节点部署:使用负载均衡器分发请求到多个 Dify 实例

#45 自定义工具接入失败

Invalid OpenAPI schema: Failed to parse tool specification

1. 确认 OpenAPI 规范格式正确(支持 3.0 和 3.1 版本)
2. 使用 Swagger Editor 验证 YAML/JSON 格式
3. 每个 API 端点必须包含 operationIddescription
4. 参数的 description 字段非常重要,Agent 根据描述决定何时调用
5. 测试 API 端点是否可从 Dify 服务器直接访问
运维与安全问题 (#46 - #50)

#46 HTTPS 配置不生效

浏览器显示"不安全"或 SSL 证书错误
Dify 本身不处理 SSL,需要通过反向代理配置:
1. Nginx 反向代理配置:
server {
    listen 443 ssl;
    server_name dify.yourdomain.com;
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_buffering off;
    }
}

2. 免费 SSL 证书:使用 Let's Encrypt + Certbot 自动申请和续期
3. 更新 .env 中所有 URL 为 https:// 开头

#47 数据备份与恢复

如何备份 Dify 的所有数据?
需要备份三部分数据:
1. PostgreSQL 数据库:
# 备份
docker compose exec db pg_dump -U postgres dify > dify_backup.sql
# 恢复
docker compose exec -T db psql -U postgres dify < dify_backup.sql

2. 向量数据库:备份对应的 Docker Volume(docker_weaviate_data 等)
3. 文件存储:备份 volumes/app/storage 目录
4. .env 配置文件:单独备份
5. 建议使用 cron 定时自动备份

#48 多租户与权限管理

如何实现团队内不同角色的权限控制?
Dify 支持工作空间级别的权限管理:
1. Owner(所有者):完全控制权,管理成员和计费
2. Admin(管理员):管理应用、模型、知识库,邀请成员
3. Editor(编辑者):创建和编辑应用,不能管理成员
4. Normal(普通成员):只能使用应用,不能编辑
5. 路径:设置 → 成员管理 → 邀请成员并分配角色
6. 如需更细粒度的权限(如按应用控制访问),需要通过 API Key 隔离

#49 日志分析与性能监控

如何监控 Dify 的运行状态和性能?

1. Docker 日志:docker compose logs -f api 实时查看 API 日志
2. Dify 内置监控:管理后台 → 概览页面查看用量统计
3. LangFuse 集成:.env 中配置 LangFuse,获得详细的 LLM 调用链追踪
# .env LangFuse 配置
LANGFUSE_PUBLIC_KEY=pk-xxxxx
LANGFUSE_SECRET_KEY=sk-xxxxx
LANGFUSE_HOST=https://cloud.langfuse.com

4. Prometheus + Grafana:可以监控 Docker 容器的 CPU、内存、网络等系统指标
5. 告警:通过外部监控工具检测 API 端点可达性

#50 Dify 的局限性与适用边界

什么场景不适合用 Dify?
Dify 并非万能,以下场景可能需要其他方案:
- 极致灵活的定制:Dify 可视化编排有一定局限,超复杂逻辑用 LangChain/LlamaIndex 更灵活
- 实时音视频处理:Dify 不支持实时语音/视频流处理 → 考虑专门的多模态平台
- 超大规模生产:千万级日请求需要自研服务 → Dify 适合中小规模
- 端侧推理:Dify 是服务端平台 → 移动端/IoT 推理考虑 ONNX Runtime 等
- 模型训练/微调:Dify 专注于应用层 → 训练用 HuggingFace / Axolotl
- 通用自动化工作流:非 AI 的业务自动化 → n8n / Zapier 更合适
总结:Dify 最适合需要快速构建、迭代 AI 应用的团队。从 PoC 验证到中等规模生产环境,Dify 都能胜任。当规模超出 Dify 能力时,可以将 Dify 中验证的逻辑迁移到自研系统。