提示

本文的对比时间在 2025 年 8 月，对比的分别是 Dify 开源版本 v1.6.0 与 BISHENG 开源版本 v1.3.1。

很久不见，今天单独开一篇文章来聊聊 Dify 和 BISHENG 这两个开源 AI 应用框架。你问我为什么不一起说说字节的 Coze？幼儿园小朋友可不该来瞎掺和。

简述

Dify 和 BISHENG 都是目前较为完善的开源大模型应用框架，具有良好的官方、社区支持和简单的上手门槛。

省流在前，二者各有优劣，没有一个是绝对开箱即用的“完善的”框架。如果你是个人非商业用户，无脑选用 Dify 即可；但如果你是企业用户，二者的选择就需要根据你的需求、具体商业模式、开发能力来综合决定了。

接下来我将会从协议、功能、生态、易用性等维度来详细对比这两个框架。

协议

在开源协议上，BISHENG 胜过 Dify。

Dify

Dify 使用了其修改版的 Apache 2.0 协议，相较于原始协议，做出了这些更改：

场景	Apache License 2.0	Dify 修改版
✅ 商业使用	允许	✅ 允许（但有条件）
🔄 修改代码	允许	✅ 允许
📦 分发代码	允许	✅ 允许（受附加条款约束）
☁️ SaaS / 多租户服务	无限制	❌ 禁止，除非获得授权
🖼️ 去除 LOGO 或版权信息	可去除（不强制保留）	❌ 不允许在前端中去除或修改
🧩 贡献者协议	一般归属项目维护者	要求同意：可变更协议 + 代码可用于云商业运营

你可以前往这里查看 Dify 的协议原文。

简单来说：

1. 禁止未经许可的“多租户服务”运营。本质上是禁止将 Dify 作为 SaaS 平台提供给第三方用户使用（避免与 Dify 原生云服务竞争）。
2. 禁止移除前端 LOGO 与版权信息。除非你获得了 Dify 官方的特别许可，否则不能去除或修改 Dify 的 LOGO 或版权信息。
3. 代码贡献者协议。Dify 要求所有代码贡献者同意其单方面可变更协议，并且贡献的代码可以用于 Dify 的云商业运营或其他盈利服务。

BISHENG

BISHENG 的协议分布稍微复杂一些。简单来说，你能够直接获取到的、部署的开源组件，全部基于原始的 Apache 2.0 协议。同时，BISHENG 提供了一系列可选组件，这些可选组件是闭源的，使用时需要购买对应的商业授权。

这样的协议设计使得 BISHENG 在开源社区中更为友好，允许用户自由使用、修改和分发其开源组件，修改 Logo，而不受商业限制。

功能

Dify 与 BISHENG 在功能上有很多相似之处，但也有一些显著的差异，我将针对主要的常用功能模块进行对比。

应用构建

二者均支持工作流和 Agent 的应用构建方式，在 Agent 的设计上基本一致，但在工作流的架构上有所不同。工作流，即通过图形化界面设计任务流程，可以将多个节点（如 API 调用、数据处理等）连接起来，形成一个完整的任务执行流程。有着“节点化”的特点，低代码的优点，上手门槛不高，自由度较高，上限相较于大量的代码工作也低一些。

Dify

Dify 的工作流设计更为直观，内置节点类型丰富，开箱即用的上手门槛要低不少。加之其允许工作流互相调用（将工作流发布为工具），使得复杂工作流的可读性与维护性更好（模块化设计）。内置迭代节点，很大程度方便了数组等可迭代结果的处理。

BISHENG

BISHENG 相较于 Dify，工作流的节点类型更少，缺少了模板转换、变量聚合、HTTP 操作等预设功能性节点。这使得复杂的工作流构建相较于 Dify 会更困难，大量的操作会需要通过代码执行来实现（低代码的优势被淡化）。

并且 BISHENG 中没有迭代与循环节点，其循环设计是通过节点互联来实现的：

在 Dify 中，循环通过循环节点实现，操作上类似于“在工作流内写一个小的工作流”，看起来更为直观，也与常规代码结构更为一致。但在 BISHENG 中，循环是通过节点的输出允许连接到更早的节点的输入来实现的，这种设计虽然灵活，并且允许了更复杂的逻辑（例如输出结果复用前序逻辑），但在复杂工作流中会导致可读性下降。属于一个取舍问题。

BISHENG 循环

知识库

Dify 和 BISHENG 都支持知识库的构建与管理，以我个人的经验来看，二者的侧重点不同，都是“偏科选手”。

二者的具体对比如下（加号代表仅 Dify 支持，减号代表仅 BISHENG 支持，圆圈代表二者均支持）：

• 非嵌入知识库（无需向量化）
• 知识库的外部 API 调用
• 向量、全文、混合检索支持
• 召回结果重排*
• 父子分块、传统分块
• Notion 同步，Web 站点同步
• 知识文档的元数据管理和检索过滤功能
• 使用外部知识库
• 内置召回测试
• 召回参数（Top n、阈值等）可调节
• QA 知识库
• 分段的编辑、管理
• 文本文档支持
• 导入本地文件
• 图像类知识支持
• 多种分块规则支持（定义多个正则，按优先级执行）

并不确定 BISHENG 是否支持重排，但其没有提供显式配置位置。

可以看出，BISHENG 虽然相较于 Dify，内置了对图像类知识的支持（需要使用其闭源可选组件），但在其他方面的功能上，Dify 的知识库功能更为全面，尤其是在召回功能上，更加丰富且内置了测试工具。

模型管理

二者只有 BISHENG 在内部支持了模型操作，Dify 仅能配置其使用的模型，并不能对模型进行管理。

在这一点上，BISHENG 更像是一个一站式平台，提供了从本地模型部署到模型应用开发的完整链条，甚至内置了部分模型微调、数据集管理的功能，而 Dify 则更像是一个应用框架，专注于应用的构建与管理。

这同样是一个取舍，BISHENG 在模型管理上的优势对新手更为友好，但内置这些服务很大地提高了其硬件需求。

同时，Dify 从 1.0.0 开始，引入了插件系统的设计，模型提供商也进行了插件化设计，这使得其外部模型的扩展选择更为丰富，灵活度也大幅提升；而 BISHENG 的模型提供商管理仍是内置设计，虽然原生提供了多种模型的支持，但灵活度不如 Dify。

MCP

随着 MCP (Model Context Protocol) 的发布，各个大模型框架的工具能力似乎得到了起跑线的统一。但实测下来，二者均是残废。

Dify

Dify 对于 MCP 的支持很不自由，在 1.6.0 版本中，其仅支持连接无身份验证或使用 OAuth 验证的 MCP 服务，且传输似乎 仅能是 Streamable HTTP。不支持自定义 Header，也似乎不支持已被弃用的 SSE 传输。同时也无法使用 STDIO 传输服务（虽然对于云平台来说，STDIO 传输服务并不常用，更别说是容器化部署了）。

但正确连接了的服务是可用的。

BISHENG

BISHENG 则更像是很久没有更新。其对 MCP 的支持似乎停留于上一个协议版本，虽然自由度高（使用了类似 Claude Desktop 的官方格式 JSON 配置），但其不支持 Streamable HTTP 传输，且不支持 OAuth 验证。

实测中，部分 MCP 服务即使使用 SSE 传输也无法正常工作，可能是 BISHENG 的实现有问题。同时，其 MCP 调用在 Agent 中有可能无法正常输出结果（调用成功了，但模型未能输出调用结果）。

总得来说，BISHENG 对于 MCP 的支持更为糟糕，甚至可以说是不支持。

外部工具

二者仅支持外部工具的调用。其中 BISHENG 的外部工具支持更类似于 Dify 版本 0 中的实现，支持通过 HTTP Schema 定义的工具。而 Dify 显然更为先进，其插件系统生态良好、开发简单，同时也保留了一部分旧版本中 HTTP 工具的实现。

生态

Dify 和 BISHENG 的生态系统都在不断发展，但二者的侧重点和成熟度有所不同。

Dify

Dify 的生态系统更为社区化，有着丰富的插件和大规模的社区使用人群。很多时候，需要什么功能，只要前往 Github 搜索开源插件，存在什么问题，在各大社交平台搜一搜很有可能就能找到解决方案。

但我个人认为，Dify 的官方文档写的是真的 💩。

BISHENG

BISHENG 的生态系统更适合国内用户，尤其是企业用户。其本身主打的就是 ToB 市场，提供了更为完善的商业支持和服务。扩展时开发工作会更多，但其官方文档很好，且有着更为完善的商业支持与官方的社区支持（飞书社群）。

易用性

二者在易用性上，显然是 Dify 更为友好。其设计上就更为针对 个人用户和小型团队，提供了更为直观的界面和更少的配置需求。

在硬件要求上，Dify 对于本地部署的要求低很多，组件较少，适合个人用户和小型团队使用。而 BISHENG 则需要更高的硬件配置，尤其是在处理大规模数据、完整利用其全部功能时，对服务器的要求更为严格。