Dify

Dify 是由 LangGenius 构建的开源 LLM 应用开发平台，于 2023 年 5 月 15 日开源。它填补了原生 LLM API 与全栈 AI 框架之间的空白：提供了一个可视化的生产级环境，开发者和产品团队可以在这里编排工作流、构建 RAG 流水线、部署智能体，并将所有内容作为 REST API 开放，而无需从零开始管理底层基础设施。截至 2026 年 5 月，该平台已更新至 v1.14.0 版本，在 GitHub 上拥有 14 万颗星标、500 万次下载量以及 800 多名贡献者。

其核心功能集涵盖五个领域：包含 50 多个内置节点的拖拽式工作流画布；支持 BM25 与向量混合检索、可调分块、可选重排及元数据过滤的可配置 RAG 流水线；采用 ReAct 和 Function Calling 策略的智能体构建器；拥有 120 多项集成的插件市场（涵盖 OpenAI o1 系列、Gemini 2.0、DeepSeek-R1、Perplexity、Firecrawl 和 ComfyUI）；以及生产级 LLMOps 工具（包括单步计时、对话日志和 OpenTelemetry 导出）。每个工作流都会自动生成一个 REST API 端点，这使得 Dify 成为连接 n8n 或其他自动化层团队的理想后端。

2026 年 5 月的 Dify 实际功能解析

Dify 的工作流画布是其主要交互界面。你可以将节点拖拽到可视化画布上并进行连接：起始（Start）节点接收参数，LLM 节点调用任何已配置的模型，知识检索（Knowledge Retrieval）节点查询你的 RAG 数据集，代码（Code）节点内联运行 Python 或 JavaScript，模板（Template）节点则为下游使用格式化输出。并行分支允许同时运行多个 LLM 调用，其执行时间接近最长分支的耗时，而非所有分支耗时的总和（这是 v1.8.0 中发布的一项性能改进）。v1.13.0 中新增的人工输入（Human Input）节点，允许工作流在执行中途暂停，等待人工审核后再继续。

与轻量级构建工具相比，RAG 流水线可以说是 Dify 最具差异化的能力。文档摄取支持 PDF、网页抓取、Notion 同步和 GitHub 仓库。分块是可配置的：分块大小、重叠度以及索引策略均可调整，这对于技术手册或法律合同等复杂的文档类型至关重要。检索支持语义向量搜索和 BM25 关键词搜索，并可在检索后应用可选的重排（Reranker）模型。v1.1.0 中新增的元数据过滤功能，允许你将查询范围限定在文档子集内，而无需重新构建向量嵌入。

智能体构建器将这些组件封装在一个自主循环中。智能体根据模型的能力使用 ReAct（推理-行动循环）或 Function Calling 策略，策略选择权交由用户而非硬编码。每个智能体均可配置思维链（Chain-of-Thought）和思维树（Tree-of-Thought）推理方法。Dify 内置了 50 多种工具（网络搜索、代码执行沙盒、计算器、时间工具），而插件市场则进一步扩展了这一生态。

2025 年 2 月 17 日发布的 v1.0.0 版本标志着 Dify 自发布以来最重大的架构转变。模型和工具从核心平台中解耦，转变为支持热插拔的插件；Dify Marketplace 上线首日即提供 120 多款插件；同时，智能体（Agent）节点被引入为工作流的一等公民。Dify 在公告中称其为“颠覆性”的更新，因为它允许第三方在不修改核心代码的情况下扩展功能，这在 1.0 之前的架构中是难以实现的。

“我们的后端工程师非常喜欢这款工具，因为它非常灵活” —— Mingji Zhang，Product Hunt，2024 年

“我从产生想法到打造出可用的助手，只用了不到 48 小时。我将提交的差异代码（commit diffs）上传到 RAG 节点，运行两个并行的 LLM 节点进行总结和问题检测，在模板节点中合并结果，并将其部署为一个 API，每周通过 Slack 进行调用。” —— 匿名开发者，Skywork.ai 评论，2025 年

Dify 与 Langflow 及 Flowise 的定位对比

开源 LLM 应用构建领域有三大主要竞争者，它们之间的差异在于底层架构，而非表面形式。

Langflow 是 LangChain 的可视化包装器，可将流程直接编译为 LangChain Python 代码。这使得它对已经在生产环境中使用 LangChain 的团队非常实用：你可以将流程导出为 Python 模块，并将其嵌入到现有服务中。代价是其设计上采用单租户架构——没有内置的工作空间原语，没有基于角色的访问控制，也没有异步队列。Langflow 于 2024 年被 DataStax 收购，获得了 Dify 这种初创模式所缺乏的企业级商业支持和云托管服务。2025 年初，它在 GitHub 上拥有约 4.2 万颗星标，而同期的 Dify 为 5.8 万颗。最适合：进行快速原型设计并计划将流程嵌入现有 Python 服务的 LangChain 原生工程团队。

Flowise 是最轻量级的选择。它只需 1GB 内存即可运行（而 Dify 至少需要 4GB），这使得在基础机器上进行本地部署变得非常实用。Flowise 基于 LangChain 构建，优先考虑通过拖拽创建带有可嵌入小组件的聊天机器人。其妥协也是显而易见的：没有内置的异步队列，在三者中可观测性最弱，且逻辑控制仅限于 If/Else 条件（不支持并行迭代）。2025 年初，它在 GitHub 上拥有约 3 万颗星标。最适合：可嵌入的聊天机器人小组件、快速的概念验证演示，以及需要将基础设施开销保持在接近零的内部工具。

Dify 的优势在于生产级基础设施。它内置了 Celery 加 Redis 用于异步队列管理——长流程开箱即用地支持异步运行和状态轮询。它具有明确的工作空间原语，支持基于角色的访问控制和原生 SSO（v1.7.0 中添加了 Azure AD、Okta、GitHub、Gmail、Notion OAuth）。每个流程都会自动暴露一个 REST 端点，无需额外配置。OpenTelemetry 导出和 Langfuse 集成是原生内置的，而非勉强拼凑。这些功能的代价是复杂性：Dify 需要使用 Docker Compose 部署 PostgreSQL、Redis 和工作节点容器。对于非技术用户来说，这绝不是一个周末就能轻松搞定的自托管项目。

与使用工作空间范围 RAG 模型（专为快速构建内部聊天机器人而优化）的 AnythingLLM 相比，Dify 将 RAG 视为更广泛的编排流水线中的一个节点。AnythingLLM 在设置文档问答时速度更快，但缺乏 Dify 提供的可配置分块、重排以及更广泛的工作流功能。对于用例是“与文档对话”的团队来说，AnythingLLM 更简单。而对于构建碰巧包含 RAG 组件的多步 AI 应用的团队来说，Dify 才是正确的选择。同样值得比较的还有：专注于本地 LLM 聊天界面而非应用开发的 Open WebUI，以及针对具有深度解析需求、文档密集型 RAG 工作负载的 RAGFlow。

工作流的实际体验

对于具备中等技术水平的开发者来说，可视化画布确实非常实用。非技术用户无需编写代码即可组装简单的聊天机器人和知识库助手。但对于超出这些模式的任何需求，“无代码”的定位就显得有些夸大其词了。自定义代码节点需要 Python 或 TypeScript 知识。并行分支调试涉及阅读单步日志和计时数据。插件开发需要了解 Dify 的插件 SDK。该工具在 GitHub 和 Discord 上的社区非常活跃（800 多名贡献者），但文档更新滞后于发布节奏——随着 2025 年至 2026 年每月发布次要版本，某些功能的文档显得稀缺或过时。

云端套餐的限制是一个反复出现的摩擦点。Sandbox（沙盒）层的 200 条消息额度勉强够用于评估。每月 59 美元的 Professional（专业）层施加了有效载荷大小限制，并限制了隐藏变量注入，这阻碍了特定的生产模式。论坛帖子中的多位用户描述了相同的轨迹：从云端开始，触及限制，迁移到自托管，然后发现自托管有其自身的基础设施开销。能够投入精力进行 Docker 设置的团队，通常最终会选择自托管作为务实的生产选择。

多租户许可的注意事项值得提前了解。尽管带有 Apache 2.0 徽章，但 Dify 的许可限制在没有商业许可的情况下，使用自托管社区版构建服务于多个租户的商业 SaaS 产品。这在 GitHub 讨论中反复出现，让那些已经在开源版本上进行构建的团队措手不及。为自身使用构建内部工具的团队不受此限制；而构建托管多个最终客户租户的产品的团队，则需要购买企业许可或使用 Dify Cloud 的团队套餐。

Dify 适合哪些人群

对于没有完整 AI 工程团队但需要构建 LLM 驱动功能的产品团队和初创公司来说，Dify 是正确的选择。如果你需要交付一个生产级 RAG 系统、一个调用外部 API 的智能体，或者一个结合了多次模型调用与自定义逻辑的工作流，并且你不想从零开始将 LangChain、Celery、Redis、向量数据库和可观测性技术栈拼凑在一起，Dify 为你提供了预先组装好的架构。

构建具有合规要求的内部知识库的企业 IT 团队，将受益于 Dify 的 SSO 集成、基于角色的访问控制以及自托管选项。已经在使用 n8n 或 Make.com 进行自动化的团队会发现，Dify 自动生成的 API 端点非常契合——Dify 负责 AI 编排，而 n8n 负责事件触发和下游集成。

社区版 14 万颗 GitHub 星标和 500 万次下载量反映了超越炒作的真实采用率。2025 年 6 月 5 日宣布达到 10 万颗 GitHub 星标，使 Dify 跻身全球前 100 大开源项目之列——这一指标反映了活跃的使用情况，而不仅仅是随手的收藏。

Dify 不适合哪些场景

如果你的首要需求是尽可能简单的设置，请跳过 Dify。Flowise 仅需 1GB 内存和单个 Docker 容器即可运行。而 Dify 需要 4GB 内存和多容器技术栈。对于构建个人工具的独立开发者来说，这种开销是不划算的。

如果你们是希望留在 Python 环境中的 LangChain 原生工程团队，请跳过 Dify。Langflow 可将可视化流程编译为你可以检查和修改的 LangChain 代码。而 Dify 的可视化输出只能留在 Dify 中。

如果你正在构建商业多租户 SaaS 产品，且不准备协商企业许可，请跳过 Dify。其许可限制是真实存在且被严格执行的。

如果你的最终用户期望一个精美、完全自定义的聊天界面，请跳过 Dify。内置的 Web 应用 UI 功能齐全，但不易更换皮肤。需要品牌专属前端的团队通常使用 Dify 的 API 后端搭配自定义前端——这效果很好，但增加了一层开发工作。

对于主要需求是通过精美界面与本地 LLM 聊天而非构建应用的团队来说，Open WebUI 是更好的选择。对于需要高级 PDF 解析的纯文档密集型 RAG 场景，RAGFlow 能更直接地满足这一细分需求。