Dify 是什么
Dify 是用于构建 LLM 应用的开源平台。它提供可视化工作流画布、从摄取到检索的 RAG 管道、可使用其市场、MCP 服务器或自定义 API 中工具的智能体、提示词 IDE、后端即服务 API，以及与 Langfuse、Opik 和 Arize Phoenix 等可观测性工具的集成。你可以使用 Dify Cloud，也可以用 Docker Compose 自行托管社区版，或咨询 Dify Enterprise，后者增加了 SSO、RBAC 和支持 SLA。它的 Code node 在沙箱中运行 Python 或 JavaScript，Human Input node 则会暂停工作流，等待人员响应。
应用构建器与受治理的智能体平台
Dify 和 EDDI 在 RAG、工具和智能体方面有重叠，但它们优化的对象不同。Dify 优化的是希望以可视化方式组装应用并快速上线的构建者，以 Code node 作为应急出口。EDDI 优化的是需要让智能体行为成为声明式、可评审配置并带有治理保障的运营者。许多团队理所当然地从 Dify 起步，一些团队在出现多租户、许可证或审计要求后会转向别处。
构建便利性与运营能力
| 维度 | Dify | EDDI |
|---|---|---|
| 核心抽象 | 可视化工作流和 chatflow 画布，外加提示词 IDE | 配置即代码：在 Manager 或 API 中编写的 JSON 资源，像源代码一样做版本管理 |
| 许可证 | Dify Open Source License：Apache 2.0 加附加条件。对源代码进行多租户运营需要书面授权，且前端的徽标和版权信息必须保留 | Apache 2.0，OSI 认证 |
| 自定义逻辑 | Code node 在沙箱中运行 Python 或 JavaScript，沙箱会阻止文件系统访问、出站网络和系统命令，并使用固定的软件包集合 | 没有运行时代码求值；逻辑通过声明实现，或放在 MCP 工具或 HTTP 调用之后 |
| 人工介入 | Human Input node 会暂停工作流，等待在 Web 应用中或通过电子邮件回答的表单；默认等待 3 天，然后进入超时分支 | 对话轮次、工具调用和群组阶段均有关卡；超时策略包括 WAIT_INDEFINITELY、AUTO_APPROVE、AUTO_REJECT 和 ABORT；支持 Manager 和 Slack 审批 |
| 工具与集成 | 市场、MCP 服务器和自定义 API | 84 个 MCP 工具、MCP 客户端、OpenAPI 导入、httpCall、A2A |
| RAG | 内置知识管道，含文档提取 | 8 个嵌入提供商、6 个向量存储，外加零基础设施的 httpCall RAG |
| 多智能体 | 在画布上组合智能体和工作流节点 | 支持 7 种风格的群组讨论，记录决策和异议，每个阶段可选人工审批 |
| 身份与访问 | 工作空间；SSO 和 RBAC 通过 Dify Enterprise 提供 | 开源版本中提供可选的 Keycloak/OIDC，含 eddi-admin 和 eddi-approver 角色 |
| 可观测性与审计 | 日志和监控，与 Langfuse、Opik 和 Arize Phoenix 集成 | Prometheus 指标，外加 HMAC 签名、仅追加、带序号校验的审计账本 |
| 部署 | Dify Cloud、Docker Compose，企业版按需提供 | Docker、Helm、Kustomize、OpenShift（Red Hat 认证镜像，通过 OperatorHub 提供 Operator） |
关于对方工具的信息，已于 2026 年 10 月对照其官方文档和代码仓库核实。这些项目更新很快，决策前请向厂商确认当前行为。
如何在两者之间选择
Dify 更合适的场景
- 你想要非工程师也能读懂并扩展的可视化画布，并在构建时获得快速反馈。
- 插件市场和现成的工作流模板能为你节省实实在在的集成时间。
- 你想要托管选项（Dify Cloud），不想自己运维任何东西。
- Code node 正是你想要的功能：在工作流内部用 Python 或 JavaScript 做小型数据转换。
- 你只为自己的团队运行一套内部部署，因此多租户的许可证条件对你不适用。
EDDI 更合适的场景
- 你的法务团队需要一份明确的 Apache 2.0 许可证，包括在一套部署中服务众多租户或客户的情形。
- 安全评审禁止在自动化平台内部执行代码，无论是否有沙箱。
- 特定的工具调用或群组阶段需要人工决策，并记录在带签名的账本中。
- 智能体行为必须作为配置进行版本管理、差异比较，并在各环境之间推进。
- 你需要 Kubernetes、OpenShift 或搭配本地模型的离线隔离部署。
从 Dify 迁移应用
Dify 应用是可视化的图，而 EDDI 智能体是配置，因此这是转换而不是导入。最需要斟酌的是 Code node，它们将变为配置或已声明的工具。
| Dify | EDDI |
|---|---|
| Chatflow 或工作流 | EDDI 智能体：管道加行为规则 |
| LLM 节点和提示词 | 带系统消息和带版本提示词片段的 LLM 任务 |
| 知识库 | 带嵌入提供商和向量存储的 EDDI RAG 知识库 |
| 工具、插件或 MCP 服务器 | MCP 客户端连接、httpCall，或通过 OpenAPI 导入的 API |
| Code node | 行为规则和提示词逻辑；如果需要真正的代码，则使用 MCP 工具 |
| Human Input node | 带超时策略的 PAUSE_CONVERSATION 规则或 toolApprovals |
| 提供商 API 密钥 | Secrets Vault 条目，以 ${vault:key} 引用 |
常见问题
Dify 是开源的吗？
Dify 以 Dify Open Source License 发布源代码，这是带有附加条件的 Apache 2.0：未经书面授权，不得使用该源代码运行多租户环境，也不得移除前端的徽标或版权信息。这与 EDDI 使用的纯 Apache 2.0 不同，因此如果这两项条件可能适用于你，请与你的法务团队一起阅读。
EDDI 有像 Dify 那样的可视化构建器吗？
EDDI Manager 是用于构建、部署和监控智能体的生产级 React 界面，支持 11 种语言。它是一个管理界面，而不是节点画布：你配置智能体、提示词、工具和管道，每一次变更都是带版本的资源，而不是一张图。
为什么 EDDI 不提供代码节点？
沙箱化的代码节点是合理的功能，Dify 也限制了它能访问的范围。但平台内的任何代码执行都是安全评审必须检查的攻击面。EDDI 让智能体行为保持声明式，因此工具能做的事，就是你声明并批准的事。
我们可以同时使用 Dify 和 EDDI 吗？
可以。Dify 可以使用 MCP 服务器和自定义 API，而 EDDI 提供 MCP 服务器和 REST API，因此 Dify 工作流可以把 EDDI 智能体作为受治理的步骤来调用。EDDI 也可以通过 httpCall 调用 Dify API。