为什么选 Dify
2026 年，用 LLM 构建 AI 应用已经不是技术问题了——真正的瓶颈是工程化。
你需要：知识库管理、Prompt 版本控制、多模型切换、使用量监控、A/B 测试、API 网关… 这些加在一起就是一个 LLMOps 平台的工作量。
Dify 把这些全部打包成了一个开源产品：
- 50K+ GitHub Star，2026 年最活跃的 AI 开源项目之一
- 可视化工作流编排——拖拽式构建 Agent 和 RAG 应用
- 内置知识库——上传文档即可检索，混合检索 + 重排序
- 多模型支持——一键切换 Claude、GPT、DeepSeek、本地 Ollama
- API 即发布——构建完成后一键生成 REST API
本文用一个客服 RAG 问答系统演示完整开发流程。
Step 1: Docker Compose 部署
系统要求
- CPU: 4 核+
- 内存: 16 GB+（知识库索引需要较多内存）
- 磁盘: 50 GB+
- Docker + Docker Compose
一键启动
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d等待约 2-3 分钟，访问 http://localhost/install 完成初始化设置。
核心组件
部署后 Docker 会启动以下服务：
| 服务 | 端口 | 作用 |
|---|---|---|
| Web 前端 | 80 | 可视化操作界面 |
| API Server | 5001 | 后端 API 服务 |
| Worker | - | 异步任务处理（文档索引等） |
| PostgreSQL | 5432 | 主数据库 |
| Redis | 6379 | 缓存和消息队列 |
| Weaviate | 8080 | 向量数据库（默认） |
生产环境建议
# docker-compose.override.yml
services:
api:
environment:
# 使用外部 PostgreSQL（生产级别）
DB_HOST: your-rds-endpoint.amazonaws.com
DB_PORT: 5432
DB_DATABASE: dify
# 使用外部 Redis
REDIS_HOST: your-elasticache-endpoint
# 限制文件上传大小
UPLOAD_FILE_SIZE_LIMIT: 50 # MB
deploy:
resources:
limits:
memory: 8GStep 2: 接入 LLM 模型
部署完成后，首先配置 LLM 供应商。
进入 设置 → 模型供应商：
推荐配置：
├── Claude 4.7 Sonnet — 主力模型（高质量回答）
├── GPT-4o-mini — 备选模型（低成本场景）
├── text-embedding-3-large — Embedding 模型
└── Ollama (localhost:11434) — 本地模型（开发测试用）接入 Ollama 本地模型
如果你按照上一篇文章部署了 Ollama：
模型供应商: OpenAI-API-compatible
模型名称: llama3
API Base URL: http://host.docker.internal:11434/v1
API Key: ollama（任意字符串）host.docker.internal 让 Docker 容器内的 Dify 可以访问宿主机上的 Ollama。
Step 3: 创建知识库
这是 RAG 应用的核心——把你的文档变成 LLM 可检索的知识。
上传文档
进入 知识库 → 创建知识库 → 上传文件
支持的格式：PDF、Word、TXT、Markdown、HTML、CSV、Excel
分段策略配置
分段设置:
分段标识符: \n\n # 按双换行分段
最大分段长度: 1000 # 每个 chunk 1000 字符
分段重叠: 200 # 相邻 chunk 重叠 200 字符
索引方式: 高质量（推荐） # 使用 embedding 模型索引
检索设置:
检索模式: 混合检索 # 向量 + 关键词
TopK: 5 # 返回 5 个最相关的段落
Score 阈值: 0.5 # 过滤低相关度结果
Rerank 模型: bge-reranker-v2-m3 # 重排序提升精度分段策略的经验法则
| 文档类型 | chunk_size | overlap | 说明 |
|---|---|---|---|
| 技术文档 | 800-1000 | 200 | 按段落自然分段 |
| FAQ 列表 | 300-500 | 50 | 每个 Q&A 独立成段 |
| 长篇报告 | 1200-1500 | 300 | 保留更多上下文 |
| 代码库 | 500-800 | 100 | 按函数/类分段 |
Step 4: 构建工作流
Dify 的工作流编辑器是其最强大的功能——用可视化拖拽构建复杂的 AI 逻辑。
客服问答系统的工作流
开始
↓
[意图分类] — LLM 节点，判断用户问题的类型
↓
[条件分支]
├── 产品咨询 → [知识库检索] → [LLM 回答] → 结束
├── 订单查询 → [HTTP 请求 (订单 API)] → [LLM 格式化] → 结束
├── 投诉反馈 → [LLM 安抚回复] + [通知人工] → 结束
└── 其他 → [通用 LLM 回答] → 结束意图分类节点配置
模型: Claude 4.7 Sonnet
System Prompt:
你是一个客服意图分类器。根据用户输入，输出以下分类之一：
- product_inquiry（产品咨询）
- order_query（订单查询）
- complaint（投诉反馈）
- other（其他）
只输出分类标签，不输出其他内容。
输出变量: intent (string)知识库检索节点配置
知识库: 产品文档知识库
查询变量: {{user_input}}
检索模式: 混合检索
TopK: 5
Score 阈值: 0.5LLM 回答节点配置
模型: Claude 4.7 Sonnet
System Prompt:
你是 YOMXXX 公司的客服助手。
根据以下知识库检索结果回答用户问题。
如果检索结果中没有相关信息，诚实说明并建议联系人工客服。
检索结果：
{{knowledge_retrieval.result}}
用户输入: {{user_input}}Step 5: 发布 API
工作流测试通过后，一键发布为 API：
进入 应用 → 访问 API → 获取 API Key 和端点
# 调用你的 AI 客服 API
curl -X POST 'https://your-dify-domain/v1/chat-messages' \
-H 'Authorization: Bearer app-xxxxxxxxxxxx' \
-H 'Content-Type: application/json' \
-d '{
"inputs": {},
"query": "你们的退款政策是什么？",
"response_mode": "streaming",
"user": "user-123"
}'在前端集成
async function askCustomerService(question: string): Promise<string> {
const response = await fetch("https://your-dify-domain/v1/chat-messages", {
method: "POST",
headers: {
Authorization: "Bearer app-xxxxxxxxxxxx",
"Content-Type": "application/json",
},
body: JSON.stringify({
inputs: {},
query: question,
response_mode: "blocking",
user: "web-user",
}),
});
const data = await response.json();
return data.answer;
}Dify 也提供开箱即用的嵌入式聊天组件，一行代码嵌入到你的网站：
<script src="https://your-dify-domain/embed.min.js"
id="dify-chatbot-bubble-button"
data-app-url="https://your-dify-domain"
data-app-id="your-app-id">
</script>Step 6: 生产监控
内置日志
Dify 自动记录每次对话的完整日志：
- 用户输入
- 知识库检索结果
- LLM 原始输出
- Token 消耗量
- 响应延迟
进入 日志与标注 查看，可以按时间、用户、满意度筛选。
标注和优化
对于回答不准确的对话，可以直接标注正确答案。标注的数据会用于：
- 知识库补充——自动将标注内容添加到知识库
- Prompt 优化建议——根据标注数据生成优化建议
- 模型评估——对比不同模型在标注数据上的表现
关键指标
| 指标 | 健康范围 | 优化方向 |
|---|---|---|
| 检索命中率 | > 80% | 优化分段策略和 embedding 模型 |
| 回答满意度 | > 85% | 优化 System Prompt 和知识库 |
| 平均延迟 | < 3s | 考虑更快的模型或缓存 |
| Token 成本/对话 | < $0.05 | 缩短 Prompt 或用更便宜的模型 |
进阶：自定义工具节点
Dify 支持通过 OpenAPI Schema 导入自定义工具：
openapi: 3.0.0
info:
title: 订单查询 API
version: 1.0.0
paths:
/api/orders/{orderId}:
get:
summary: 查询订单状态
operationId: getOrderStatus
parameters:
- name: orderId
in: path
required: true
schema:
type: string
responses:
'200':
description: 订单信息
content:
application/json:
schema:
type: object
properties:
status:
type: string
enum: [pending, shipped, delivered, cancelled]
tracking_number:
type: string
estimated_delivery:
type: string导入后，LLM 可以在对话中自动调用这个 API 查询订单。
什么时候不用 Dify
- 需要极致性能和定制：Dify 的抽象层会带来约 100-200ms 的额外延迟
- 团队全是强开发者：直接用 LangGraph + 自研可能更灵活
- 只需要简单的 Chatbot：直接用 Claude/GPT 的 API 更简单
- 需要端侧部署：Dify 是服务端方案，不适合移动端或边缘设备
总结
Dify 把”从 0 到 AI 应用上线”的时间从几周压缩到了几十分钟。核心价值不是技术创新，而是工程效率——它让非 AI 专家也能构建生产级 AI 应用。
对于大多数企业场景（客服、知识问答、文档分析、内部助手），Dify 是 2026 年 ROI 最高的选择。