Dify 是一个产品形态很重的开源 LLM 应用平台。它不只是 prompt playground。这个仓库把可视化工作流、RAG pipeline、Agent 工具、模型供应商管理、观测、托管云、自托管、API 和企业版包装放在一起。
这就是它值得写单页的原因。搜索 Dify 的读者通常不是想知道某个模板文件有什么用，而是想判断 Dify 能不能跑真实的内部 AI 应用，自托管是否可行，和 Langflow、Flowise 怎么取舍，以及插件、tracing、离线部署进来后会出什么问题。
截至 2026-06，站内本地数据记录为 144,836 star、22,793 fork、747 个 open issues，最近一次 push 是 2026-06-11。GitHub 把 license 报为 NOASSERTION，因为项目使用 Dify Open Source License。README 说明这个许可证基于 Apache 2.0，但带额外条件。公司使用时要读真实 license 文本，不能只按 Apache-2.0 处理。
Dify 解决什么问题
Dify 面向的是想交付 LLM 应用、又不想从零拼所有后端部件的团队。README 列出的核心能力包括可视化 workflow、模型供应商支持、Prompt IDE、RAG、Agent、LLMOps 和 API。
更有用的区分是：Dify 想做应用平台，不只是图编辑器。它给你一个地方定义 app、连接模型、导入文档、构建检索流程、添加工具、观察运行日志、暴露 API，并把结果交给其他系统。它更像 AI 应用控制台，而不是 notebook 或小型库。
功能越全，重量也越大。一个带插件、RAG、tracing、模型供应商、数据集、租户和多种部署模式的可视化工作流产品，必然比简单聊天 UI 多很多活动部件。多人运营同一个 AI 应用时，这个代价可以接受。一次性原型未必需要它。
自托管路径
README 的 quick start 使用 Docker Compose，并列出最低要求：2 CPU cores 和 4 GiB RAM。安装流程是：
cd dify
cd docker
cp .env.example .env
docker compose up -d启动后，README 指向 http://localhost/install 做初始化。配置在 docker/.env，可选变量按主题拆在 docker/envs/ 下。README 还链接了 Kubernetes、Terraform、AWS CDK、Azure、Google Cloud、阿里云和社区部署方案。
这些部署选项本身就是信号。Dify 可以自托管，但它不是一个小二进制文件。如果团队要搭私有 RAG 或 Agent 平台，需要预留 Docker 网络、持久化存储、plugin daemon、模型供应商凭证、迁移、备份和观测时间。安装命令只是开始，不是运维方案。
它强在哪里
Dify 最适合需要共享 AI 应用工作台的团队。产品经理可以看流程，工程师可以接 API，运维或平台团队可以看日志和模型行为。Dashboard 很重要，因为 LLM 应用经常坏在代码以外的地方：检索切片差、prompt 弱、供应商报错、成本异常、工具权限缺失、用户边界条件。
RAG 是另一个考虑它的理由。README 说它支持文档导入和检索，并覆盖 PDF、PPT 等常见格式。对有内部文档的公司来说，把检索变成应用工作流，通常比手工拼向量库、队列、抽取管线、API 层和 UI 更省启动成本。
Agent 和 workflow 也有现实价值。Dify 支持 Function Calling 和 ReAct 风格 Agent，支持内置工具、自定义工具和工作流编排。当应用需要调用服务、按数据分支、插入人工输入或暴露 API 时，这些能力会比单纯聊天更有用。
团队要小心什么
issue tracker 展示了大型 AI 平台的运行成本。近期问题包括 plugin daemon 离线安装失败、插件版本不匹配、离线部署静态资源加载失败、重复模型供应商调用导致 workflow 延迟、数据库连接池耗尽，以及 Langfuse tracing 状态 bug。这些不是否定 Dify 的理由，而是提醒你上线前要测试真实部署路径。
插件要特别关注。Dify 的插件生态很有用，但 plugin daemon 在近期 issues 中反复出现。如果环境不能联网，要尽早测试离线打包和依赖安装。如果 workflow 会并发运行，要压测供应商查询延迟和 daemon 连接池。
观测也要验证。README 提到 Opik、Langfuse、Arize Phoenix 等集成。近期 Langfuse 相关 issues 表明，配置和开关状态在边界场景下仍可能失败。如果 tracing 是合规或调试必需项，就应该把它列入发布门槛。
最后是许可证。这个仓库在 GitHub 元数据里不是普通 Apache-2.0。它使用 Dify Open Source License。很多使用场景可能没问题，但商业再分发、托管衍生品、企业内嵌都应该走法律审查。
和 Langflow、Flowise、Open WebUI、n8n 对比
| Project | Stars as of 2026-06 | Language | License | Best fit |
|---|---|---|---|---|
| Dify | 144,836 | TypeScript | Dify Open Source License，API 报 NOASSERTION | 带 RAG、workflow、Agent、API 和产品 UI 的 LLM 应用 |
| Langflow | 149,540 | Python | MIT | Python 优先的 Agent 和 LLM flow 可视化构建 |
| Flowise | 53,482 | TypeScript | API 报 NOASSERTION | 低代码 LangChain 风格 flow 和 chatbot builder |
| Open WebUI | 141,076 | Python | API 报 NOASSERTION | 自托管 LLM Web UI，尤其适合 Ollama 一类用法 |
| n8n | 192,025 | TypeScript | API 报 NOASSERTION | 通用工作流自动化，AI 是其中一种节点能力 |
当产出是一个有用户、数据集、模型供应商、workflow、日志和 API 的 AI 应用时，选 Dify。团队更偏 Python，且核心需求是可视化 flow graph 时，选 Langflow。TypeScript 低代码 flow builder 已经够用时，Flowise 更轻。主要需求是模型聊天和 Web UI 时，Open WebUI 更直接。核心问题是通用业务自动化，AI 只是众多节点之一时，看 n8n。
增长和发布节奏
抽样 star history 有 36 个点，到 2026-06-11 达到 144,842 star。增长仍然伴随活跃发布。GitHub 列出的 latest release 是 2026-05-19 的 v1.14.2，说明包括安全修复、Agent groundwork、workflow reliability 和部署更新。
对快速变化的 AI 产品来说，这种节奏是好信号。它也意味着升级要有纪律。自托管时要看 release notes，备份数据，固定版本，并在升级生产前测试插件和 workflow。
谁适合用
如果你需要共享平台来做内部 RAG 应用、面向客户的 AI workflow、模型供应商管理，或带 API 的 Agent 工具，Dify 值得评估。非工程角色需要查看或调整流程，而工程团队仍要掌握部署时，它尤其合适。
如果环境离线、监管要求高，或许可证约束敏感，要谨慎使用。这些场景不一定不能用，但需要比本地 demo 更多验证。
如果只是个人聊天 UI、短期原型，或单条脚本管线，用更小的工具更合适。Dify 的价值出现在应用有用户、有数据、有运维和持续变化之后。
FAQ
Dify 适合生产环境吗？
它的定位就是生产级 LLM 应用，发布历史也很活跃。但 issue tracker 里能看到插件、tracing、离线安装和并发工作流等生产问题。依赖它前，要用自己的 workload 测试。
怎么自托管 Dify？
README 使用 Docker Compose。clone 仓库后进入 docker 目录，把 .env.example 复制为 .env，再运行 docker compose up -d。README 写的最低要求是 2 CPU cores 和 4 GiB RAM。
Dify 只是 RAG 工具吗？
不是。RAG 是主要能力之一，但它还包括可视化 workflow、Agent、模型供应商管理、观测、应用 API、Cloud 和自托管。
Dify 是开源吗？
仓库公开，使用 Dify Open Source License。README 说它基于 Apache 2.0 并带额外条件。GitHub API 报 NOASSERTION，商业用户应直接阅读 license 文本。
Dify 和 Langflow 怎么选？
要一个带数据集、workflow、观测、API 和部署选项的产品化 LLM 应用平台，选 Dify。团队想要 Python 中心的 LLM 与 Agent flow 可视化构建器，选 Langflow。
自托管 Dify 的主要风险是什么？
近期 issues 指向 plugin daemon、离线插件打包、tracing 设置、数据库连接使用和并发 workflow 延迟。生产使用前应重点验证这些地方。