Dify 深度实践：从 RAG 到 Agent 工作流的全流程低代码平台

如果说 WordPress 让建站变得人人可及，那么 Dify 正在做同一件事——把 LLM 应用开发从"写代码"变成"拖画布"。

Dify 是目前全球最受欢迎的开源 LLM 应用开发平台（GitHub 145k+ Stars），由 LangGenius 团队开发并于 2023 年 5 月 15 日在 GitHub 开源。2026 年 3 月 9 日完成 $30M Series Pre-A 融资，由 HSG（Hongshan，原红杉中国）领投，GL Ventures、Alt-Alpha Capital、5Y Capital、Mizuho Leaguer Investment、NYX Ventures 跟投，投后估值约 1.8 亿美元。

它的核心能力矩阵覆盖了 LLM 应用从原型到上线的三个关键层次：

RAG 知识库层：文档解析 → 分块 → 向量化 → 检索 → 排序
Agent 编排层：Function Calling / ReAct → 工具调用 → MCP 扩展
Workflow 自动化层：可视化拖拽 → 条件分支 / 循环 / 并行 → 发布

三者在同一平台内闭环，无需切换到不同工具链。

快速部署：5 分钟启动

Dify 的部署是目前所有 LLM 平台中最为成熟的方案之一。官方提供完整的 Docker Compose 配置，一条命令即可启动全部服务：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

启动后访问 http://localhost/install 完成初始化设置。

这套 docker-compose 自动编排了以下服务：

组件	技术栈	职责
前端	Next.js	Web UI、管理后台、聊天 Widget
API 服务	Python (Flask)	业务逻辑、API 端点
Worker	Python RQ Worker	异步任务（文档解析、索引构建）
PostgreSQL	—	应用数据、用户、对话记录
Redis	—	缓存、任务队列、会话管理
Weaviate	向量数据库	默认向量存储（可选 Qdrant/Milvus/PGVector）

Worker 的异步架构设计是 Dify 区别于纯前端平台的关键——所有耗时操作（PDF 解析、向量索引、大文件处理）都在后台队列完成，API 不阻塞。

生产环境建议

对于生产部署，Dify 官方推荐以下调整：

更换向量数据库：生产环境推荐使用独立的 Qdrant 或 Milvus 集群，而非 Weaviate 容器（默认配置更适合开发）
使用外部 PostgreSQL：避免数据丢失
配置 S3 兼容存储：文件存储从本地卷迁移到 MinIO / AWS S3
HTTPS + 反向代理：Nginx 前置 + Certbot 自动续签

Dify 也提供 Kubernetes Helm Chart 和 AWS / GCP 一键部署模板。

多租户与空间隔离

Dify 内置 Workspace 机制：一个实例可以创建多个 Workspace，每个 Workspace 有独立的成员、知识库、应用和配置。企业可以一个部署服务多个团队，通过 Workspace 实现租户级别的数据和配置隔离。

RAG 知识库：从文档到检索

Dify 的 RAG 能力覆盖了"文档上传 → 分块 → 向量化 → 检索 → 排序"的完整链路。

支持的输入格式

文档：PDF、TXT、Markdown、JSON、DOCX、XLSX、CSV、HTML
网页：内建网页爬取功能，输入 URL 即可抓取
Notion / Confluence：通过 API 同步
API 导入：通过知识库 API 批量写入

Dify 的文档解析引擎可以处理带表格的 PDF、带格式的 Word 文档、以及多层嵌套的 JSON 结构。对于 PDF，它支持 OCR 预处理，能够提取扫描件中的文字内容。

Chunking 策略对比

Dify 提供了三种分块策略，适用于不同的文档类型：

策略	原理	适用场景
固定大小分块	按 token 数量切分，可设重叠窗口	结构简单的文本、新闻文章
段落分块	按换行符 / 标题分段	结构清晰的文档（说明书、论文）
父子分块	先分段（父），再从段中切小块（子）；检索命中子段后返回父段	长文档问答、技术支持文档

父子分块是 Dify RAG 的差异化能力：子段用于精确匹配，父段用于提供完整上下文。例如检索到一个代码片段（子段），返回的是整个函数定义（父段），这让 LLM 的理解更准确。

每个策略都可以配置：chunk 大小（token 数）、chunk 重叠（token 数）、分隔符选择。Dify 还提供了"预览"功能，在上传文档后可以实际查看分块效果，调整参数后重新切分。

检索策略

Dify 当前支持三种检索方式：

向量相似度：基于 embedding 的语义检索，适合模糊匹配和语义理解
全文搜索（关键词）：基于倒排索引的精确匹配，适合专有名词、编号、代码
混合检索：向量 + 全文搜索加权合并，兼顾语义和精度

实际使用中，混合检索的效果通常最优。Dify 允许为每种检索方式设置权重（滑块调节向量 vs 关键词的比例），并可以对检索结果进行 Rerank（接入 Cohere Rerank、Jina Reranker 或 BGE Reranker 模型等），进一步提升 top-k 结果的排序质量。

向量数据库选择

Dify 支持的向量数据库及选型建议：

数据库	部署方式	适合场景
Weaviate	Docker	默认配置，开发阶段首选
Qdrant	Docker / 独立	生产环境，高性能向量搜索
Milvus	集群	大规模知识库（百万级文档）
PGVector	PostgreSQL 插件	不想引入额外基础设施

通过 .env 中配置 VECTOR_STORE 变量即可切换。

Agent 编排：从工具到智能体

Dify 的 Agent 引擎支持两种核心策略：

Function Calling 模式

当底层 LLM 支持 Function Calling（如 GPT-4、Claude 3、GLM-4 等），Dify 会自动使用原生 Tool Call API。用户只需在界面中"添加工具"——选择内置工具或导入自定义工具——Agent 就能根据用户输入自动选择合适的工具执行。

ReAct 模式

对于不支持 Function Calling 的模型（如部分开源模型），Dify 使用 ReAct（Reasoning + Acting）提示词框架：模型首先思考需要什么信息，然后生成工具调用指令，系统执行后将结果反馈给模型继续推理。这种方式虽然多了一次交互轮次，但对模型兼容性更好。

50+ 内置工具

Dify 提供 50 多个预置工具，覆盖常见场景：

网页搜索：Bing Search、Google Search、SearXNG、Serper、SerpAPI
代码执行：在 Dify Sandbox 中安全执行 Python / Node.js 代码
图像生成：Stable Diffusion、DALL-E、Flux
数据获取：Yahoo Finance、Wikipedia、YouTube Transcript
通信：Slack、Email、Discord 通知
文件处理：文档提取、表格读取

每个工具都有独立的入参定义和错误处理逻辑，可以在 Agent 提示词中自定义工具调用时的指令。

自定义工具：OpenAPI / API Definition

在实际项目中，内置工具往往不够。Dify 支持通过以下方式添加自定义工具：

OpenAPI / Swagger 规范：导入任意 REST API 的 OpenAPI 3.0 规范，自动生成工具定义
API Definition 手动配置：手动填写 endpoint、参数、认证方式
插件市场工具：从 Dify 插件市场安装社区贡献的工具

这意味着任何现有系统的 REST API 都可以在一分钟内变成 Dify Agent 的一个工具——不需要写一行代码。这也是 Dify 被称为"LLM 应用 WordPress"的原因之一。

MCP Client：接入 MCP 生态

Dify 在 2026 年前后全面支持 MCP（Model Context Protocol）双向模式——既是 MCP Client 也是 MCP Server。

作为 MCP Client，Dify 可以连接任何标准 MCP Server，通过 SSE（Server-Sent Events）或 Streamable HTTP 传输协议：

# 在 Dify 的 .env 中配置 MCP Server
MCP_SERVER_URL=http://localhost:8000/sse
MCP_SERVER_NAME=my-custom-server

配置后，该 MCP Server 暴露的工具会自动注册到 Dify Agent 的工具列表中，Agent 可以根据任务自动调用。这大幅扩展了 Dify 的工具生态——不再依赖官方内置工具或手动导入 OpenAPI spec，而是通过 MCP 的标准化接口接入社区中的大量 MCP Server。

目前 MCP 生态中已有数百个可用的 Server，包括：GitHub API、Jira、Notion、Slack、PostgreSQL 数据库查询、Google Calendar、Figma 等。通过 Dify 的 MCP Client，这些能力可以在一分钟内接入 Agent 工作流。

Dify Sandbox：安全代码执行

Dify 的代码执行工具依赖 langgenius/dify-sandbox，这是一个隔离的代码执行环境。Sandbox 使用 gVisor 或 nsjail 容器沙箱，限制：

文件系统访问（只读白名单）
网络请求（白名单域名）
系统调用（禁用危险 syscall）
执行时间（可配置超时）
内存使用（上限限制）

这意味着用户可以在 Dify Workflow 中执行 Python 或 Node.js 代码处理数据，而不会威胁宿主安全。

工作流 Workflow：可视化拖拽编排

Workflow 是 Dify 区别于大多数 Agent 平台的杀手级能力。它提供了一个基于 React Flow 的拖拽画布，用户通过连接节点来构建复杂的 AI 处理流程。

节点类型

Dify Workflow 目前支持的节点类型：

节点类型	功能	典型用途
LLM	调用大模型生成文本	对话、翻译、摘要
Knowledge Retrieval	从知识库检索相关文档	RAG 问答
Code	执行 Python / JavaScript 代码	数据清洗、格式化
Condition	if/else 条件分支	根据输入走不同路径
Loop	循环执行子流程	批量处理
HTTP	发送 HTTP 请求	调用外部 API
Agent	内嵌 Agent 节点	复杂推理任务
Template	Jinja2 模板转换	文本组装
Variable	变量声明与赋值	中间结果存储
Parameter Extract	从输入中提取结构化参数	实体识别
Iteration	遍历列表执行子流程	逐条处理
TTS	文本转语音	语音输出
S3 Storage	文件上传到 S3	结果存档
Answer	设定最终输出	返回给用户

每个节点都可以引用前面节点的输出作为变量（通过 {{节点ID.输出字段}} 语法），形成数据流。Condition 节点支持多分支，Loop 和 Iteration 支持嵌套——这让 Dify 可以构建从简单 QA 到复杂多步处理的各类工作流。

Workflow 设计技巧

在实际使用中，以下设计原则可以显著提升 Workflow 的稳定性和可维护性：

黄金法则：一个 Workflow 只做一件事。不要用一个巨型 Workflow 处理所有场景，拆成多个子 Workflow 并通过 HTTP 节点互相调用
Condition 节点作为 Guard。在 LLM 节点前加 Condition 检查输入是否合法（空值校验、格式校验），无效输入提前返回错误消息，避免浪费 token
Iteration 节点的批处理。批量数据优先用 Iteration 而非 Loop——Iteration 可以并行执行子流程（受底层限制），效率比 Loop 高一个数量级
使用 Code 节点做数据清洗。LLM 输出不稳定，先用 Code 节点（Python/JS）做格式校验和转换，再传给下一个节点
设置合理的超时和重试。HTTP 节点和 LLM 节点都可能超时，设置 30-60s 超时 + 1-2 次自动重试
变量管理。复杂 Workflow 中避免使用超过 20 个变量节点，用 Code 节点做数据聚合可以显著简化画布

发布方式

Workflow 创建完成后，Dify 提供三种发布渠道：

API Endpoint — 每个应用生成独立的 REST API，支持 POST 调用，返回 JSON 结果。这是最灵活的接入方式，适合与现有系统集成
Web App — 自动生成面向用户的 Web 页面，支持对话式交互和表单交互，无需额外开发
嵌入式 Widget — 通过 <iframe> 或 JS SDK 嵌入到现有网站中，常用于客服机器人场景

每个发布渠道都可以独立配置访问权限（公开 / 私有 / 白名单），并设置速率限制和 Token 用量上限。

2026 新特性

2026 年，Dify 发布了一系列重要更新，进一步拉大了与竞品的差距。

MCP 双向支持

Dify 在 2026 年实现了 MCP 的双向支持：

MCP Client：连接外部 MCP Server，将外部工具注册到 Dify Agent 工具列表中
MCP Server：将 Dify 应用本身暴露为 MCP Server，外部系统可以通过 MCP 协议直接调用 Dify Workflow

这一设计让 Dify 不仅仅是 MCP 的消费者，也是 MCP 生态的生产者。企业可以将 Dify 接入统一的 MCP 工具目录，让内部所有 LLM 应用共享同一个工具和知识库网络。

Supervisor 多 Agent 模式

Supervisor 模式引入了一个"管理者 Agent"：用户输入任务后，Supervisor Agent 负责拆解任务、分派给多个子 Agent 执行、汇总结果。每个子 Agent 可以有不同的模型、工具集和提示词配置。

这种模式适用于：

复杂研究任务：一个 Agent 搜索资料，一个 Agent 分析数据，一个 Agent 撰写报告
多步骤客服流程：一个 Agent 处理身份验证，一个 Agent 查询订单，一个 Agent 生成回复
代码生成 + 审查：一个 Agent 写代码，一个 Agent 做代码审查

Supervisor 与 Workflow 的结合是 Dify 2026 年最值得关注的方向——在 Workflow 画布中嵌入 Supervisor Agent 节点，实现"外部可视化编排 + 内部自主规划"的分层架构。

插件系统

2026 年上线的插件市场为 Dify 引入了可扩展的生态能力。插件以 .difypkg 格式打包，包含：

工具定义（类似自定义工具的 OpenAPI spec）
节点类型（新的 Workflow 节点）
模型接入（新的 LLM / embedding / rerank 模型）
UI 扩展（自定义配置界面）

插件通过 Dify 管理后台的"插件市场"浏览和安装，社区贡献的插件经过 Dify 团队的审核后上架。这一机制使 Dify 从"功能固定的平台"变为"可扩展的 LLM 操作系统"。

Prompt 版本管理与 A/B 测试

对线上应用来说，Prompt 的修改可能直接影响用户体验。Dify 的 Prompt 版本管理支持：

每次 Prompt 修改自动保存历史版本
版本间对比（diff 视图）
一键回滚到任意历史版本
A/B 测试：同时运行两个 Prompt 版本，按流量比例分配，自动统计关键指标（响应时间、Token 消耗、用户反馈）

A/B 测试功能对运营团队尤其重要——不用猜测"哪个 Prompt 更好"，用数据说话。测试结束后，效果更好的版本可以一键从测试提升为正式版。

Dify vs 竞品

维度	Dify	Open WebUI	LobeChat	LangChain
产品定位	LLM 应用开发平台	LLM 聊天界面 + 工具	现代化 AI 聊天客户端	开发框架（Python/TS SDK）
RAG 知识库	内置完整管线	内置基础 RAG	插件支持	需自行搭建
Workflow 编排	可视化拖拽画布	无	无（仅聊天流程）	LangGraph（代码级）
Agent 模式	Function Calling + ReAct	Function Calling	插件 Agent	自定义 Agent
MCP 支持	双向（Client + Server）	只读工具调用	仅 Client	需扩展
部署复杂度	Docker Compose / K8s	Docker 单容器	Docker / Vercel	SDK 集成
企业功能	Workspace、日志、监控、API	基础用户管理	无	无
最适合	企业级 LLM 应用开发	个人/团队 LLM 聊天	个人使用、多模型对比	深度定制开发

Open WebUI 定位为"更好的 ChatGPT 界面"，在聊天体验和轻量工具集成上表现出色，但缺乏 Workflow 和企业级能力。如果你的需求是"给团队一个好用的 LLM 聊天界面"，Open WebUI 是最轻量的选择。

LobeChat 聚焦于个人用户体验和插件生态，在多模型聊天场景体验优秀，但不适合做复杂应用开发。更适合个人用户。

LangChain 是开发框架而非产品，提供了最大的灵活性，但需要开发团队自己搭建前端、API 层、知识库管理等所有基础设施。适合有专业团队且需要深度定制的场景。

Dify 的唯一性在于：它把 RAG + Agent + Workflow + MCP 整合在可视化界面中，让非工程人员也能构建 LLM 应用。这是"产品"与"框架"的本质区别。

小结

Dify 不是万能的——对于极度定制化的场景，LangChain + 自研前端仍然不可替代。但在 90% 的 LLM 应用开发场景中，Dify 提供的可视化管线足以满足需求，且开发速度是写代码的 3-5 倍。

Dify 的演进方向也值得关注：从最初的"Chatbot 构建器"到现在的"LLM 应用开发平台"，再到 MCP 双向支持和插件生态，Dify 正在从单一产品向平台+生态转型。对于正在选择 LLM 技术栈的团队来说，Dify 是目前门槛最低、覆盖面最广的起点。

如果你还没有试过 Dify，建议从 Docker 部署开始，创建一个简单的 RAG 问答应用——你会惊讶于 30 分钟就能从一个 PDF 文档变成一个可交互的知识问答系统。这正是 Dify 最大的价值：让 LLM 应用开发不再需要从零开始。

最后提醒许可证细节：Dify 采用 Dify Open Source License（以 Apache 2.0 为基础，附加禁止未授权多租户 SaaS 和保留前端 Logo/版权的条件）。个人使用、企业内部部署通常不受影响；若计划基于 Dify 提供面向多租户的商业托管服务，需要联系 LangGenius 取得商业授权。

仓库: langgenius/dify · 文档: docs.dify.ai · 在线体验: cloud.dify.ai