本页速览开源 LLM 应用开发平台 Dify 深度解析：来自苏州语灵团队的 14 万星项目，覆盖可视化 Workflow/Agent 编排、RAG 引擎、插件系统与 MCP 双向支持，附自部署架构、商业化模式与 Coze/n8n/LangFlow 对比。

本页含时效性内容，数据截止于 2026-08；JD、价格、产品功能等信息可能已变化，引用前请核对原始出处。

Dify

如果说 Coze 是字节用流量生态堆出来的「零代码快车道」，Dify 走的几乎是反方向：一家创业公司，靠一个 Apache 2.0（附加条款）的开源仓库，长成了全球 LLM 应用平台里社区声量最大的玩家之一。截至 2026 年年中，Dify 的 GitHub 星数已突破 14 万（2026 年 4 月约 13.47 万，GitHub 全球排名进入前 50），星数一度超过 LangChain 本体，并且挤进了 GitHub 全球 Top 100 仓库。

这一页把 Dify 当作一个「Agent 平台案例」来解剖：它能做什么、不能做什么、内部怎么组织代码和运行时，以及什么场景该用它、什么场景该绕开它。

一、定位：开源 LLM 应用开发平台

Dify 由苏州语灵人工智能科技有限公司（对外品牌 LangGenius / Dify.AI）开发，公司 2023 年成立，同年 5 月开源第一版代码。官方给自己的定位经历过一次明显的漂移：

早期（2023-2024）：「开源 LLMOps 平台」，对标 LangChain 的「产品化封装」，卖点是可视化 Prompt 编排 + RAG + 日志运营。
现在（2025-2026）：「面向生产环境的 Agentic Workflow 平台」。首页标语已经换成 "The Platform for Production-Ready Agentic Workflows"，Agent 和 Workflow 成为一等公民，LLMOps 退居为底层能力。

几个关键节点（均来自官方博客与公开报道）：

时间	事件
2023-05	首次开源，一周内创建超 4000 个应用
2025-02	v1.0.0 发布，插件系统（Plugin Daemon）落地，工具/模型/Agent 策略全部插件化
2025-06	GitHub 星数突破 10 万
2025-07	v1.6.0 内置双向 MCP 支持
2025-09	发布 Knowledge Pipeline（可视化 RAG 数据处理管道）
2026-03	完成 3000 万美元 Pre-A 轮融资，红杉中国领投，投后估值约 1.8 亿美元
2026-03	连续第二年通过 SOC 2 Type II、ISO 27001、GDPR 合规审计
2026-05	版本迭代到 v1.14.x，上线 Creator Center 与模板市场

怎么理解 Dify 的生态位

Dify 不是 Agent 框架，它是「框架的成品房」。LangGraph 给你图编排的 SDK，你自己写代码、管状态、搭服务；Dify 把图编排做成了画布，把服务化、鉴权、日志、RAG、模型网关全部内置。代价是你接受它的抽象和运行时。选型的第一性问题永远是：你要的是「写代码的自由」还是「不写代码的速度」。详见框架选型总览。

二、核心能力拆解

2.1 应用类型与 Workflow 编排

Dify 里的「应用」分几种形态：

Chatbot / 对话型应用：经典聊天界面，带会话变量、开场白、标注回复。
Agent 应用：以 LLM 自主决策为核心的单 Agent 应用（详见第三节）。
Chatflow：带记忆的对话式工作流，多轮场景用。
Workflow：无状态的批处理/自动化流程，一次输入一次输出，通常通过 API 或 Trigger 触发。
Text Generator：最简单的单轮文本生成，正在被 Workflow 吸收。

Workflow 画布是 Dify 的心脏。节点类型大致分四类：

┌─ 输入控制 ─┐  ┌─ 推理处理 ─┐  ┌─ 数据/工具 ─┐  ┌─ 流程控制 ─┐
  Start         LLM            Knowledge      IF/ELSE
  变量聚合       Agent 节点     Retrieval      迭代 Iteration
  结束/答案      代码执行       Tool 节点      循环 Loop
  Human Input   模板转换       HTTP 请求      并行分支
  (v1.13+)      参数提取器     变量赋值       Trigger 触发器

近两年值得注意的演进：

v1.8（2025 夏）：画布自动布局、OAuth 集成、执行性能优化。
v1.9（2025 秋）：执行引擎重写为基于队列的图执行引擎（Queue-based Graph Engine），长流程的并发与容错明显改善。
Trigger（2025-11）：工作流不再只能被动等 API 调用，支持定时（Schedule）、Webhook、插件事件三种触发方式，Dify 开始覆盖「无人值守自动化」。
v1.13（2026-03）：Human Input 节点，工作流可以暂停等人审批/修改/改派后再继续——这是把 Human-in-the-Loop 做成了原生节点，而不是让用户用外部回调硬拼。

2.2 RAG 引擎与 Knowledge Pipeline

RAG 是 Dify 的传统强项，能力清单基本覆盖了工程实践里的主流手法：

多种索引模式（高质量/经济模式）、父子分段检索（v0.15 引入）、混合检索（向量 + 全文）+ Rerank、元数据过滤（v1.1）。
支持外挂向量库：Weaviate、Qdrant、Milvus、pgvector、TiDB Vector 等十几种。
2026-01 上线多模态知识库，文本与图片统一进同一语义空间。
Knowledge Pipeline（2025-09，v1.9）：把「文档进来 → 清洗 → 分块 → 向量化 → 入库」这条原来黑盒的链路也做成了可视化管道，数据源、文档处理、向量优化环节全部插件化，官方在围绕它建合作伙伴生态。

Knowledge Pipeline 为什么重要

传统 Dify 的知识库是「上传文档，剩下的交给平台」，企业场景里这恰恰是最常翻车的地方——PDF 表格解析烂、分块策略不匹配、需要接内部数据源。Knowledge Pipeline 把这条链路打开成可编排的 DAG，意味着 ETL 逻辑可以按业务定制。如果你的 RAG 问题出在检索质量上，先排查的往往是这条管道而不是检索参数，参见 RAG 组件页的排障思路。

2.3 插件系统

v1.0 是 Dify 架构史上的分水岭：模型供应商、工具、Agent 策略、扩展（Endpoint）全部从主仓代码里剥离，变成运行在独立 Plugin Daemon 里的插件，通过 Dify Marketplace 分发。插件用 Python SDK 开发，支持本地调试后打包成 .difypkg。

实际影响有两点：

生态滚雪球：工具插件数量快速增长，Brave Search、Tavily、Firecrawl、Slack、飞书、钉钉等都有官方或社区插件；第三方 SaaS（Bright Data、MongoDB Atlas、Agora 等）主动来上架。
私有部署更干净：模型和工具版本升级不再需要升级整个 Dify 主程序；企业可以开发私有插件不公开。

2.4 模型供应商聚合与 API 发布

Dify 内置了主流模型供应商的接入（OpenAI、Anthropic、Gemini、xAI、DeepSeek、通义、智谱、Ollama 本地模型等，以插件形式维护），同一应用可以随时切换底层模型对比效果。这层「模型网关」能力配合用量日志，天然适合做多模型成本治理，和成本优化页讲的方法论能直接对上。

应用做好之后，Dify 提供四种交付形态：

WebApp：直接生成可分享的网页应用，可嵌入 iframe。
Service API：REST API（/v1/chat-messages、/v1/workflows/run 等），这是生产集成的主路径。
发布为工具：一个 Workflow 可以被发布成工具，供其他 Agent 应用调用——工作流即工具，这是 Dify 里做「类多 Agent」协作的主要手段。
发布为 MCP Server（v1.6+）：把整个 Dify 应用暴露给任何 MCP 客户端。

python

import requests

# 调用一个已发布的 Dify 对话型应用（Service API 形态多年来保持稳定）
resp = requests.post(
    "https://api.dify.ai/v1/chat-messages",   # 自部署时换成你的域名
    headers={"Authorization": "Bearer app-xxxxxxxx"},  # 应用级 API Key
    json={
        "inputs": {},                          # 应用编排里定义的输入变量
        "query": "帮我总结这份会议纪要",
        "response_mode": "streaming",          # 或 "blocking"
        "user": "user-001",                    # 终端用户标识，用于会话与日志隔离
    },
    stream=True,
)
for line in resp.iter_lines():
    if line:
        print(line.decode("utf-8"))

三、Agent 能力：比看起来克制

3.1 Agent 策略：Function Call 与 ReAct

Dify 的 Agent 不是写死的一套循环，而是可插拔的「Agent 策略」：

经典 Agent 应用里，内置 Function Calling 和 ReAct 两种策略——前者依赖模型原生的工具调用能力，后者用 Thought/Action/Observation 文本协议兼容不支持 Function Call 的模型（背后的思想见 ReAct 论文精读和 Agent Loop）。
v1.0 之后 Agent 策略本身也是插件，社区可以做自己的推理策略上架（例如支持 MCP 工具发现的策略插件）。
Agent 节点（2025-03 引入）把 Agent 塞进了 Workflow：工作流里某个环节需要自主决策时，挂一个 Agent 节点，选好策略和工具集，LLM 在这个节点内部自主跑多轮工具调用，跑完把结果交还给确定性的流程。这是「确定性流程 + 局部自主」的务实组合，比全自主 Agent 靠谱得多。

3.2 工具生态与 MCP 现状

Dify 应用能调用的工具来源有四类：市场插件工具、自定义 OpenAPI 工具（贴一个 OpenAPI Schema 即可）、已发布为工具的 Workflow、以及 MCP Server。

MCP 支持是 v1.6.0（2025-07）落地的「双向」能力：

作为 MCP Host：把任意 MCP Server（SSE / Streamable HTTP 传输）配进来，其工具自动出现在 Agent 和工作流的工具列表里。
作为 MCP Server：把 Dify 应用反向暴露成 MCP 端点，让 Claude Code、Cursor 这类 MCP 客户端直接调用你的 Dify 应用。

至此 Dify 在工具与 MCP 这条线上基本补齐了。但要清醒：MCP 工具进了 Dify 之后，仍然受 Dify 运行时约束（鉴权、超时、审计都在平台层），这既是企业要的管控，也意味着你不能完全照搬 MCP 生态里那些面向本地 IDE 的用法。

Dify Agent 的天花板

Dify 的 Agent 能力定位是「够用」而不是「极致」。它没有 LangGraph 那样细粒度的状态机控制，也没有 Claude Agent SDK 那种与编码环境深度耦合的执行循环。需要复杂多 Agent 博弈、长程状态管理、精细 checkpoint 的场景，应该用代码框架（参见 LangGraph、多 Agent 架构），把 Dify 当交付和运营层，而不是硬在画布里模拟框架能力。

四、自部署与企业版

Dify 的商业模式决定了它必须把自部署体验做好，事实也确实如此：git clone 之后进 docker/ 目录，cp .env.example .env，一条 docker compose up -d 就能拉起完整环境。Compose 编排包含的容器大致是：

nginx（网关）→ web（Next.js 前端）
            ↘ api（Flask 后端）
            ↘ worker（Celery 异步任务：索引构建、批量任务）
            ↘ plugin_daemon（插件运行时）
            ↘ sandbox（代码执行沙箱，DifySandbox）
            ↘ ssrf_proxy（外发请求的 SSRF 防护代理）
基础设施：PostgreSQL / Redis / 向量库（默认 Weaviate，可换）

生产环境官方支持 Helm Chart 部署到 Kubernetes。资源门槛不高（官方建议 2C4G 起步），但要认真扛生产流量，Celery worker 数量、向量库规格、PostgreSQL 都要按量规划。

社区版与企业版的差异主要在治理层：

能力	社区版（开源）	企业版
核心编排 / RAG / 插件	全部可用	全部可用
工作空间	单一	多工作空间 + 企业管理
SSO / 审计日志	无	有
商业授权	附加条款限制（多租户 SaaS 转售受限）	商业 License
SLA / 官方支持	社区	有
部署形态	Docker / K8s 自托管	自托管 / VPC / 云市场（AWS、Azure Marketplace 均有上架）

企业版有真实的大客户背书：日本 Kakaku.com 用 Dify Enterprise 让 75% 的员工创建了近 950 个内部 AI 应用——这个案例值得记住，它说明 Dify 企业版的主战场是「全公司范围的平台化推广」，不是单个高技术团队。

五、技术架构速览

Dify 主仓是典型的大厂级 monorepo，代码结构清晰，适合当全栈参考项目读：

dify/
├── api/                  # Python 后端（Flask + SQLAlchemy + Celery）
│   ├── core/             # 核心域逻辑：rag、workflow、agent、model_runtime
│   ├── services/         # 应用服务层
│   └── ...
├── web/                  # Next.js + TypeScript 前端（画布基于 React Flow 生态）
├── docker/               # docker-compose 与 env 模板
└── sdks/                 # 客户端 SDK

独立仓库还有：plugin-daemon（Go 写的插件运行时，负责插件生命周期与反向调用）、dify-sandbox（代码执行隔离）、dify-plugin-sdks。

架构上几个值得借鉴的设计决策：

任务队列解耦：所有重活（文档索引、批量标注、异步调用）走 Celery + Redis，API 进程只做同步编排。1.9 的队列化图引擎也是同一思路的深化——节点执行变成消息，天然支持并发和重试。
模型运行时抽象：model_runtime 层把几十家供应商的 API 差异抹平成统一接口，v1.0 后进一步插件化。这是「模型网关」类系统的标准解法。
插件反向调用：插件运行在独立 daemon，可以反向调用 Dify 主程序的能力（调模型、读写知识库），让插件不是孤岛。
安全边界单独成服务：代码执行走沙箱容器，外发 HTTP 走 SSRF 代理，这两个组件在企业审查里是被问得最多的。

对可观测性，Dify 内置了日志与标注，同时官方对接了 Langfuse、LangSmith、Arize Phoenix 等第三方 tracing——生产环境的 trace 与评估建议直接接外部专业工具，内置日志更多用于调试。

六、商业化模式

Dify 是教科书式的 open-core，三条收入线：

Dify Cloud（SaaS）：免费 Sandbox 档（200 message credits、5 个应用、日志保留 30 天）做漏斗入口；Professional / Team 档按 workspace 年费订阅（年付有折扣），差异在成员数、应用数、知识库容量、Trigger 事件额度和执行优先级。注意 message credits 只是让你零配置试用各家模型的额度，用完可以切自己的 API Key——Dify 不靠转卖 token 赚钱。
Enterprise 授权：商业 License + 企业功能（SSO、多工作空间、审计）+ 支持服务，客单价定制。云市场（AWS/Azure Marketplace）上架降低了大客户的采购摩擦。
生态与合作伙伴：围绕 Knowledge Pipeline 和 Marketplace 建伙伴网络（数据连接器、文档处理、向量优化厂商），2026 年又上线了 Creator Center 和模板市场，让创作者发布模板变现——这是向「平台抽成」模式试探的一步。

融资侧：2026 年 3 月宣布 3000 万美元 Pre-A 轮，红杉中国领投，高瓴创投（GL Ventures）、Alt-Alpha Capital（Bessemer 孵化基金）、五源资本、瑞穗力合、NYX Ventures 跟投，投后估值约 1.8 亿美元。官方口径资金用途是：提升 Agent 可靠性、企业级管控、降低构建门槛、建设开源生态。

七、与 Coze / n8n / LangFlow 的对比

维度	Dify	Coze（扣子）	n8n	LangFlow
出身	苏州语灵（创业公司）	字节跳动	柏林团队，2019 年起做自动化	LangChain 团队
开源	修改版 Apache 2.0	2025 年开源核心（Coze Studio）	fair-code（Sustainable Use License）	MIT
核心抽象	LLM 应用 + Agentic Workflow	Bot + 插件 + 技能包	通用自动化节点（400+ SaaS 连接器）	LangChain 组件的可视化壳
目标用户	开发者和产品混合团队	运营/非技术用户为主	自动化/集成工程师	已在用 LangChain 的开发者
自部署	一等公民，体验最好	开源版可部署但生态绑定云上	一等公民	可自部署
RAG	强（Knowledge Pipeline）	够用	需自己拼	依赖 LangChain 生态
商业化	Cloud + Enterprise 双轮	字节生态导流，Coze 3.0（2026-06）推多人多 Agent 协作	云订阅 + 企业版	被 LangChain 云产品线吸收

一句话判断：

要模型中立 + 私有部署 + 开发者可控，选 Dify。
要非技术人员最快出活 + 字节系渠道分发，看 Coze。
业务本质是跨 SaaS 的数据搬运和自动化（LLM 只是其中一环），n8n 更顺手；Dify 的 Trigger 在追这个方向，但连接器数量差着量级。
团队已经深度用 LangChain/LangGraph 写代码，LangFlow 只是补充，不值得为它换栈。

八、局限与适用边界

诚实地说，Dify 的问题和它的优点一样清晰：

画布复杂度陷阱：Workflow 超过几十上百个节点后，可维护性急剧下降。画布没有函数、没有模块化 import（只能靠「发布为工具」间接复用），版本管理和 diff 审查远不如代码。复杂系统请回到代码框架，Dify 页面级别的问题参考实践避坑。
开源协议不是纯 Apache 2.0：附加条款限制你拿 Dify 做多租户 SaaS 转售，商用前法务要看一眼；前端改 Logo 也受约束。
企业治理功能割裂：SSO、审计这些「正经企业刚需」锁在企业版，社区版到规模阶段会撞墙。
性能与稳定性：Python + Celery 栈在高并发下需要认真调优；社区对偶发的执行超时、升级破坏兼容（尤其是插件体系大改期间）一直有抱怨。把 Dify 当关键路径基础设施前，自己做压测。
深度定制成本：一旦需求超出画布和插件能表达的范围，二开 Dify 本体的成本不低——它是个不小的系统，不是玩具项目。

适合用 Dify 的场景：企业内部知识库问答/客服助手、需要非工程师参与编排的 AI 应用、快速 PoC 到中小规模生产、把 LLM 能力 API 化交付给业务系统。不适合的场景：极致性能要求的 C 端高并发产品、复杂多 Agent 研究型系统、需要深度定制模型行为的训练/推理一体化需求。

对学习者来说，Dify 还有一个隐藏价值：它是一份「如何设计 Agent 平台」的开卷答案——插件化、任务队列、模型网关、沙箱、MCP 双向接入，每一块的代码都能读。想自己造一个时，先读它再动手，参见动手构建你的第一个 Agent。

参考资料

langgenius/dify · GitHub —— 官方仓库，14 万+ 星，含发布历史与部署文档。
Dify 官方博客 —— 版本发布与功能公告的一手来源（v1.0 插件化、v1.6 双向 MCP、v1.13 Human Input 等）。
Dify 定价页 —— Cloud 各档配额与 Enterprise/Community 功能划分。
Dify 完成 3000 万美元 Pre-A 轮融资（界面新闻） —— 2026 年 3 月融资快讯，红杉领投。
Docker Compose 自部署文档 —— 官方自托管快速上手指南。
Dify Marketplace —— 插件市场，可直观察看工具/模型/Agent 策略生态。
Dify 1.9.0：知识编排与工作流引擎的全新升级（知乎） —— Knowledge Pipeline 与队列化图引擎的第三方解读。

Dify

Dify ​

一、定位：开源 LLM 应用开发平台 ​

二、核心能力拆解 ​

2.1 应用类型与 Workflow 编排 ​

2.2 RAG 引擎与 Knowledge Pipeline ​

2.3 插件系统 ​

2.4 模型供应商聚合与 API 发布 ​

三、Agent 能力：比看起来克制 ​

3.1 Agent 策略：Function Call 与 ReAct ​

3.2 工具生态与 MCP 现状 ​

四、自部署与企业版 ​

五、技术架构速览 ​

六、商业化模式 ​

七、与 Coze / n8n / LangFlow 的对比 ​

八、局限与适用边界 ​

参考资料 ​

Dify

一、定位：开源 LLM 应用开发平台

二、核心能力拆解

2.1 应用类型与 Workflow 编排

2.2 RAG 引擎与 Knowledge Pipeline

2.3 插件系统

2.4 模型供应商聚合与 API 发布

三、Agent 能力：比看起来克制

3.1 Agent 策略：Function Call 与 ReAct

3.2 工具生态与 MCP 现状

四、自部署与企业版

五、技术架构速览

六、商业化模式

七、与 Coze / n8n / LangFlow 的对比

八、局限与适用边界

参考资料