Dify

1. 调研缘由

Dify 是 Agent 工作流、RAG 应用开发和企业 AI 应用交付这几个领域的交叉项目，有代表性。官方把它定位成一个协作式工作区，覆盖 Agent 工作流、RAG 管线、模型与工具接入，并且支持云端、VPC 和自托管部署。[S1]

2026 年 3 月，Dify 宣布完成 3,000 万美元 Series Pre-A 融资；本次复查时，其 GitHub 仓库显示最新版本为 1.15.0，发布于 2026 年 6 月 25 日。[S10][S11]

这篇简调重点回答三件事：Dify 的主要生态位是否已经超出“可视化 Agent 搭建器”；在把原型推向可交付应用时，它整合了哪些环节，又还剩下哪些运维工作；以及源码公开与商业授权的边界，会怎样影响自托管、二次开发和多租户服务。

2. 简介与产品工作流

Dify 是 LangGenius 推出的 AI 应用与 Agent 工作流平台。团队可以把模型、知识库、外部工具和业务流程放进一个可视化画布，再以网页应用、嵌入式组件、API 或 MCP Server 的方式发布出去。[S1][S2][S4]

这里的“Agent 工作流”可以简单理解为：开发者不光是做一次模型问答，而是把资料检索、工具调用、条件判断和后续动作串成一条流程。RAG 是“检索增强生成”，意思是模型在回答前，先到指定资料里找上下文，降低只靠模型自身记忆回答的比例。[S1][S2]

典型使用流程是：团队先接入模型服务商或自己的 API Key，然后建立知识库和工作流；调试完成后，Dify 可以生成网页应用和 API，也支持把应用嵌入现有网站，或者发布为 MCP Server。[S3][S4]

因此，Dify 的核心生态位仍然是开发工具，但产品形态已经跨到 AI 应用交付层：它既帮开发者搭流程，也提供团队协作、应用发布、使用日志和资料管理等产品化能力。[S1][S2][S6]

3. 团队与资本背景

Dify 于 2023 年 3 月成立。官方融资公告显示，Luyu Zhang 是创始人兼 CEO。[S10]

Dify 官网披露，其团队分布在 Menlo Park、东京、苏州和上海；Menlo Park 是总部，东京负责研发和亚洲企业合作，苏州偏工程，上海偏亚太市场和企业销售。[S9]

2026 年 3 月，Dify 宣布完成 3,000 万美元 Series Pre-A 融资，由 HSG 领投，GL Ventures、Alt-Alpha Capital、5Y Capital、Mizuho Leaguer Investment 和 NYX Ventures 参与。官方称 5Y Capital 是此前投资方，本轮继续加注。[S10]

本次没有找到足够公开资料来完整拆解 Dify 的历史融资总额、收入结构或企业版合同规模。

4. 技术基础与生态位

Dify 的产品路线是多模型混合。官方文档显示，Dify Cloud 提供一部分模型额度，团队也可以接入自己的模型服务商账户、API Key 或自定义模型；同一个工作区内可以为团队共享模型配置。[S3]

Dify 的技术重心放在应用层编排与交付上。官方文档把模型提供商、工具、数据源、外部服务、网页应用、API、MCP Server、日志与标注系统，都放在同一套产品体系里。[S2][S4][S6]

部署方面，Dify 同时提供云端服务、VPC 和自托管路径。官方 Docker Compose 指南显示，默认部署会启动 api、worker、worker_beat、web、plugin_daemon 五项核心服务，以及 Weaviate、PostgreSQL、Redis、Nginx、SSRF Proxy、Sandbox 等六项依赖组件。[S1][S5]

这意味着 Dify 的“自托管”不是只下载一个单体应用，而是需要打理一组运行服务与数据依赖。该结论来自官方部署结构，不能直接等同于对部署难易程度做绝对判断。[S5]

源码仓库采用 Dify Open Source License。其文本基于 Apache 2.0，并附加了多租户和前端标识限制：未经书面授权，不得使用 Dify 源码运营多租户环境；使用前端时，不得移除或修改 Dify 的 Logo 与版权信息。[S6][S7]

5. 市场与外部信号

Dify Cloud 的 Professional 年付方案，公开价格为每个工作区每年 590 美元，包含 3 名团队成员、50 个应用、每月 5,000 条 message credits、500 份知识库文档和 5GB 知识库存储。额度用完后，官方说明用户可切换至自己的 API Key。[S8]

官方在 2026 年 3 月称，Dify 已运行在超过 140 万台机器上，覆盖 175 个以上国家和地区，已有超过 2,000 个团队和 280 家企业使用。以上都是公司自己披露的数据，还没有找到独立审计资料来说明统计口径。[S10]

官网展示的使用方或客户标识包括 Maersk、Thermo Fisher Scientific、Panasonic、Novartis、Anker 等。这能说明 Dify 正在面向企业市场宣传和销售，但不等于能单独证明每家机构的部署规模或业务效果。[S1]

本次复查时，GitHub 仓库显示约 14.8 万 Star、2.33 万 Fork、165 个 Release；最新版本为 1.15.0，发布日期是 2026 年 6 月 25 日。Star、Fork 与版本更新可以看成开发者关注度和项目维护活跃度的信号，不等同于付费客户数或商业收入。[S6][S11]

6. 公开评价与主要分歧

官方宣传、客户案例和投资方观点不作为独立评价依据。以下内容按来源类型拆分。

正面评价（独立工具公司分析）：

• ZenML 在比较多种 Langflow 替代方案时认为，Dify 把工作流、知识库、RAG、部署与可观测能力放进同一个平台，可以减少团队为把应用推上线而拼接多套工具的工作量。[S12]
• Argon & Co 的开发者评测认为，Dify 的组件集合比较集中，组件之间较容易理解和组合，适合把注意力放在流程逻辑上。[S13]

主要批评／质疑（独立工具公司分析／开发者实测）：

• ZenML 同时也指出，一体化平台带来便利，也会让部分组件的可配置空间变少；比如，Dify 内置的向量检索能力，未必能替代专用向量数据库在大规模调优场景下的灵活性。[S12]
• Argon & Co 的评测把 Dify 与 Langflow 放在可扩展性上做了对比：该文认为，Dify 与 Flowise 主要把代码扩展限制在特定沙箱环境中，而 Langflow 允许直接修改组件代码及其输入输出结构。[S13]
• 部分 GitHub 社区用户围绕许可证提出了疑问，讨论焦点是多租户限制与 Logo 条款，是否意味着这个项目应被理解为“source-available”，而非严格意义上的 OSI 开源。这是社区对许可术语的讨论，不构成法律结论。[S14]

存在分歧之处：

公开评价里的核心分歧，不在于 Dify 能不能搭建 Agent 工作流，而在于“一体化”该怎么取舍。支持者把知识库、发布、日志和模型接入集中到一个平台，看成是减少工程拼装的方式；持保留意见的一方则认为，平台预设较多时，团队在替换底层组件、深度自定义和扩展运行环境上受到的约束也会更多。[S12][S13]

许可证是另一个明确的边界。源码可访问、可自托管，与能不能把它包装成多租户 SaaS 或修改前端标识，是需要分别对照许可证条款来确认的。[S7][S14]

7. 同类对比（与头部／高知名度同类项目）

主要对标项目： Flowise、Langflow。

关键维度对比（事实，标来源）：

维度	Dify	Flowise	Langflow
主要定位	可视化 Agent 工作流、知识库、模型与工具接入、应用发布和监控平台。[S1][S2]	官方定位为“可视化构建 AI Agents”的项目，提供 Cloud 与自托管方式。[S15][S17]	官方定位为开源、基于 Python、可定制的 AI 应用框架，提供可视化编辑器。[S18]
发布与应用接入	可发布为网页应用、网站嵌入、API 或 MCP Server。[S4]	仓库包含服务端、前端与自动生成的 API 文档模块，并提供 Cloud 与自托管部署。[S15]	支持 API、嵌入式聊天组件、MCP Server 与 OpenAI Responses 兼容端点。[S19]
自托管结构	Docker Compose 默认启动 5 项核心服务与 6 项依赖组件。[S5]	官方仓库提供 Docker Compose、Docker Image 和多云自托管说明。[S15][S17]	支持 Docker、远程服务器、Nginx、Kubernetes 等多种部署路径。[S20]
许可证结构	Dify Open Source License：基于 Apache 2.0，附加多租户与前端标识限制。[S6][S7]	packages/server/src/enterprise 等企业代码采用商业许可证，其余未列入限制的内容采用 Apache 2.0。[S16]	MIT License。[S21]

公开评价中的对比（标源，非个人裁决）：

Argon & Co 的开发者评测将 Dify、Flowise 和 Langflow 放在同一类低代码 AI Agent 平台中比较。该文认为，Dify 的组件集合较集中、较易组合；同时指出，Langflow 在直接修改组件代码和组件输入输出方面给开发者留下的空间更大。[S13]

ZenML 的对比则把 Dify 的差异归纳为“把生产与交付工具放到同一个平台”，同时提醒，这种设计也会牺牲一部分对单点基础设施的深度可配置性。[S12]

8. 信息缺口与后续观察

• 还没有足够公开资料，来对比 Dify Cloud、Community Edition 与 Enterprise 版本在权限、审计、扩展与支持服务上的完整功能边界。
• 没有公开的统一基准测试，在相同模型、相同知识库、相同负载条件下，对 Dify、Flowise、Langflow 的延迟、稳定性、成本和运维工作量进行横向比较。
• 官方披露的机器数、团队数和企业数，缺少独立统计口径说明。
• 没有找到完整的公开报价，来拆解企业私有部署、商业授权、多租户授权与售后支持的成本结构。
• 后续可观察：许可证是否会调整；企业版与社区版的功能边界是否变化；自托管在升级、备份和迁移上的实际经验；以及 Dify 对 MCP、人工审核、可观测性和知识库质量控制的后续更新。

9. 归纳洞察 ★

Dify 的产品逻辑不是只提供一个拖拽画布，而是把模型接入、知识库、工作流、应用发布和运行监控集中在一个应用交付层里。它试图解决的，是团队从 Demo 走向可调用、可维护应用时，通常需要自己拼装多种工具的问题。

这也解释了它与单纯流程画布工具的区别：Dify 同时提供网页、API、嵌入和 MCP Server 等发布出口，并把日志、资料和团队配置放进同一个工作区。前端体验上，它更接近一个 AI 应用平台，而不是一个只产出工作流文件的编辑器。

与此同时，Dify 的源码公开与许可证限制并存。面对内部自托管、为单一组织部署、提供多租户 SaaS、修改前端标识等不同场景，不能只用“是否开源”这一个标签来概括，实际需要分别核对部署模式和授权条款。

10. 来源与更新时间

• 信息截至(as_of): 2026-07-07
• 最后复查(last_checked): 2026-07-07
• 最后更新(last_updated): null