Dify、n8n、Coze、FastGPT、RAGFlow 五个平台横向对比
三句话：
- “Coze 是闭源的”已经不成立——Coze Studio 在 2025 年 6 月就开源了。但更值得警惕的是后半句：它的开源仓库近 4 周提交数为 0，代码基本停在原地。
- 体量排序变了——n8n 以 20.8 万 star 反超 Dify 的 16.0 万，而且它是这五个里提交最活跃的（近 4 周 1,412 次）。但它不是纯开源项目，
.ee目录走企业许可。 - RAGFlow 涨得最凶（+75%），但它的 1.0 到现在还是
rc2。这意味着引擎还在大版本切换期，生产环境必须锁版本。
如果你只想要一张推荐表，直接翻到最后。想搞清楚为什么，往下看。
复核的口径
为了避免”凭感觉对比”，先说清三个口径：
- 数据源：GitHub REST API（
repos/{owner}/{repo}、/stats/participation、/releases、/tags、contents/{LICENSE}），取数时间 2026-10-26。 - 指标选择：star 只反映”关注度”，不反映”能不能长期用”。所以我加了近 4 周提交数（
stats/participation的最后 4 个周桶求和）作为维护活跃度的代理指标。 - 基准：2025-05-22 那篇文章里给出的 star 数（Dify 98.3K、FastGPT 24.2K、RAGFlow 53.1K、Coze 判定为闭源、n8n 未给数值）。
另外说明一句：star 数不是能力评分。一个平台 star 多，可能只是因为它诞生的时间更早、社区更爱点星。下面所有判断我都尽量基于”提交 + 版本 + 许可证”这类更难刷的指标。
一张表看清变化
| 平台 | 2025-05 star | 2026-10 star | 增幅 | 近 4 周提交 | 最新版本 | 许可证 |
|---|---|---|---|---|---|---|
| n8n | 原文未给 | 208,597 | — | 1,412 | n8n@1.123.87（10-23） | Sustainable Use（非 OSI） |
| Dify | 98.3K | 159,536 | +62% | 803 | 1.18.0（10-23） | Apache 2.0 + 附加条款 |
| RAGFlow | 53.1K | 92,859 | +75% | 695 | v1.0.0-rc2（10-16） | Apache 2.0 |
| FastGPT | 24.2K | 29,910 | +24% | 188 | v4.17.2（10-09） | Apache 2.0 + 附加条款 |
| Coze Studio | 判定为「闭源」 | 21,760 | 从 0 起 | 0 | v0.5.1（02-05） | Apache 2.0 |
这张表里最刺眼的两格是 n8n 的 208,597 和 Coze Studio 的 0。下面逐个说。
Coze 开源了，但”开源”要拆开看
coze-dev/coze-studio 这个仓库 2025-06-26 就建了，许可证是 Apache 2.0。也就是说，那篇文章发布一个月后，Coze 就开源了。原文作者当时不可能知道，但今天再照搬这句话，就是硬错。
但后半句的隐含担心，现在反而被数据证实了。 我把它的维护状态拉出来：
| 指标 | 数值 |
|---|---|
| 累计 star | 21,760 |
| 最近一次提交 | 2026-07-29（fix(infra): align statefulset servicename...） |
| 近 4 周提交 | 0 |
| 近 8 周提交 | 0 |
| 最新 release | v0.5.1，发布于 2026-02-05 |
近三个月没有一次 push，最新正式版本停在今年 2 月。这不是”开源了”，这是开源后进入了低频维护状态。
对选型的实际含义很直接：如果你打算自托管 Coze Studio，先问自己一个问题——你能接受一个已经半年没动的代码库作为生产依赖吗？ 上游不合并你的补丁、不发安全更新，出问题时你只能自己扛。
这里我要说句公平的话：这只说明开源仓库的活跃度，不能直接推断 Coze SaaS 版的产品状态。商业产品线是否仍在迭代，我从仓库里看不到证据，所以不下结论。但对你选型来说，”我能不能自己维护”这个问题，答案已经摆在这里了。
体量排序变了，且 star 最多的那个不是纯开源
原文没给 n8n 的 star 数（只提了”400+ 预置集成”），可能是因为作者主要把它当工作流工具，没放在同一坐标系里比。
今天的数据是：n8n 208,597，Dify 159,536。n8n 反超了，而且不是小幅。
更值得注意的是活跃度，不是 star：
| 平台 | 近 4 周提交 | 近 52 周提交 |
|---|---|---|
| n8n | 1,412 | 10,183 |
| Dify | 803 | 6,782 |
| RAGFlow | 695 | 6,192 |
| FastGPT | 188 | 1,252 |
| Coze Studio | 0 | 50 |
stats/participation，取数 2026-10-26。n8n 的提交量是 Dify 的 1.76 倍。这是一个”产品在快速进化”的强信号，比 star 可信得多。
但这里有个原文没提、也很少有人提的坑：n8n 不是纯开源项目。
它的 LICENSE.md 明确写了三件事：
- 除
master之外的分支内容不授权； - 文件名带
.ee.或以.ee结尾的目录，不适用 Sustainable Use License，要用必须持有 n8n Enterprise License； - 其余部分走 Sustainable Use License——这不是 OSI 认可的开放源代码许可。
而 Dify 和 FastGPT 走的是另一套：“修改版 Apache 2.0”，附加条款集中在两处——多租户和 logo：
a. Multi-tenant service: Unless explicitly authorized by Dify in writing, you may not use the Dify source code to operate a multi-tenant environment.
也就是说，你想拿它做个对外的 SaaS 卖给别人用，得先拿商业授权。内部系统、企业内部应用平台，随便用。
这条对做产品的人比功能对比重要得多。功能不够可以自己加，许可证踩雷是法律问题。
第三条：RAGFlow 涨得最凶，但 1.0 还没 GA
RAGFlow 是这五个里增幅最大的：53.1K → 92,859，+75%。近 4 周 695 次提交，几乎追平 Dify。
原文对它的定位——”知识库专家”、”深度文档理解”——这条我核下来认为仍然成立，它是这五个里唯一把重心放在”文档解析质量”而不是”应用编排”上的。
但有个原文没写、现在很关键的事实：它的 1.0 还没正式发布。
v1.0.0-rc2 (2026-10-16)
v1.0.0-rc1
v0.27.3
v0.27.2
rc2 意味着什么？意味着从 0.27 到 1.0 是一次破坏性的大版本切换，接口、数据结构、部署方式都可能变。这个阶段用它上生产，只有一种正确姿势：锁死镜像 tag，永远不要用 latest 或 nightly（它的 release 列表里现在挂着的就是 nightly）。
另外它的部署门槛也值得单独说，README 里写得很直白：
Recommended starting configuration: 4 CPU cores, 16 GB RAM, and 50 GB of available disk space.
对照一下 Dify 的 README：
CPU >= 2 Core, RAM >= 4 GiB
4 倍内存、至少 8 倍磁盘的差距。而且 RAGFlow 当前源码构建链要求 Go 1.27、Clang 20、LLD 20、CMake ≥ 4.0、PCRE2——这不是一个”小团队随手跑起来”的东西。原文说它”比较重，需要 4 核 16G”，这个判断是对的，方向和量级都对。
分工没变，变的是边界
原文按”问答 / 工作流 / 应用平台”给三家定位，17 个月后这套分工不但没模糊，反而更清楚了。变的是各自的边界在哪。
| 平台 | 它真正擅长的事 | 什么情况下别用它 |
|---|---|---|
| RAGFlow | 复杂格式文档的解析与溯源问答（合同、研报、扫描件） | 你只需要一个轻量问答页，不想背 16G 内存 |
| FastGPT | 快速起一个知识库问答 + 对外提供 OpenAI 兼容 API | 你要的是复杂多步编排，而不是问答 |
| Dify | 一个平台装下 Agent、工作流、RAG、模型管理 | 你只要一个功能，Dify 的平台层对你是负债 |
| n8n | 跨系统自动化的编排（400+ 集成），把 LLM 当一个节点 | 你的主诉求是”把文档喂进去问得准”，那不是它的战场 |
| Coze Studio | 想自托管一套 Coze 形态的 Agent 平台 | 你需要持续的安全更新和上游支持 |
我自己的一句话总结：FastGPT 和 RAGFlow 抢的是”问答质量”，Dify 抢的是”应用托管”，n8n 抢的是”系统之间的连接”。 这四件事没有替代关系，混着比功能表一定得不出结论。
选型第一道坎其实是许可证，不是功能
这是原文完全没覆盖、但企业落地最容易踩的一节。同样是”开源”，五家的边界差得很远：
| 平台 | 许可证 | 内部商用 | 对外多租户 SaaS | 能否去掉控制台 logo |
|---|---|---|---|---|
| RAGFlow | Apache 2.0 | ✅ | ✅ | ✅ |
| Coze Studio | Apache 2.0 | ✅ | ✅ | ✅ |
| Dify | Apache 2.0 + 附加条款 | ✅ | ❌ 需书面授权 | ❌ 不得移除 web/ 前端标识 |
| FastGPT | Apache 2.0 + 附加条款 | ✅ | ❌ 类似 FastGPT 的多租户 SaaS 需授权 | ❌ 不得移除 |
| n8n | Sustainable Use + EE 许可 | ✅ | 受限，.ee 代码需企业许可 |
— |
三条实操提醒：
- “开源”不等于”随便商用”。 Dify 和 FastGPT 的附加条款都只卡两件事：多租户、logo。做企业内部平台完全没问题；做成 SaaS 卖给第三方，就要先谈授权。
- n8n 的
.ee目录是个隐形边界。 你 clone 下来能跑，但某些企业级功能（SSO、外部密钥管理等）的代码不在 Sustainable Use License 覆盖范围内。 - 许可证会变。 Dify 的条款里就明写了”producer can adjust the open-source agreement to be more strict or relaxed”。所以选型时锁版本、留证据，别指望今天的条款永远有效。
与其比功能，不如先回答四个约束
一、能不能完全离线？
如果你在金融、医疗或任何有数据合规要求的场景里，问题不是”它支不支持私有部署”，而是”断网状态下它能不能跑完一条完整链路”——模型、依赖、甚至前端静态资源。这一条会直接砍掉一部分 SaaS-only 的方案。
二、谁来背运维？
平台型工具（Dify）装上只是开始，后面还有升级、备份、日志、以及它自己的升级带来的破坏性变更。RAGFlow 一次 1.0 的 RC 就够你加几个夜班。算 ROI 的时候，把”谁负责升这个版本”也算进去。
三、出口形态是什么？
如果你的应用要对外提供服务，关键问题变成”它暴露的是不是标准协议”。FastGPT 提供 OpenAI 兼容 API，这一点在集成时省的事最多；平台自有协议的，通常得在前面加一层网关做转换。这一条原文提到了「Dify 的 API 没有兼容 OpenAI，对接困难」——这个判断方向上仍然需要注意，具体现状请以各项目当前文档为准，我没有逐版本复核这一条。
四、交付给谁，决定许可证。
内部系统随便用；对外 SaaS 先看条款。这一条上一节已经展开，不重复。
一支命令，自己核一遍再选型
star 数好刷，提交数难刷。如果你正在做技术选型，别只看官网首页那个 star 徽章，用这两条命令自己核：
# 关注度
gh api repos/langgenius/dify --jq '.stargazers_count'
# 维护活跃度：近 4 周周桶求和
gh api repos/langgenius/dify/stats/participation --jq '.all[-4:] | add'
# 最新正式版本及其日期
gh api repos/langgenius/dify/releases?per_page=1 --jq '.[0] | "\(.tag_name) \(.published_at[0:10])"'
三个数一起看才有意义：star 高但提交为 0，说明社区在关注一个不再前进的项目；star 一般但提交稳定，往往更值得押注。
按场景的直接推荐
| 你的场景 | 首选 | 备选 | 理由 |
|---|---|---|---|
| 企业文档问答、要求答案可溯源 | RAGFlow | FastGPT | 文档解析深度是它的护城河；但要接受 4C16G 起步 + 锁版本 |
| 快速起一个知识库问答对外服务 | FastGPT | Dify | 轻、OpenAI 兼容、集成成本低 |
| 要做一整套 AI 应用平台（Agent + 工作流 + 模型管理） | Dify | n8n | 1.18.0 迭代稳定，平台完整度最高；注意多租户授权条款 |
| 系统之间自动化为主，LLM 只是其中一环 | n8n | Dify | 提交最活跃、集成最多；注意 .ee 边界 |
| 想自托管一套 Coze 形态的平台 | Coze Studio（谨慎） | Dify | 功能形态对，但上游近 3 个月无提交，要有自己维护的准备 |
最后三句实话
第一，这个赛道的”对比文章”半衰期很短。 这篇写于 2026 年 10 月，我给它估的有效期是 6 个月——不看功能，只看上面那张表里的”最新版本”和”近 4 周提交”两列，半年后大概率要重算。
第二，五个平台里没有”全能冠军”，只有”当前阶段最省事”。 原文那句”没有绝对完美的工具，只有最适合当前需求和发展阶段的选择”，17 个月后依然成立。这是它整篇文章里最经得起时间的一句。
第三，别用 star 数做决策。 21,760 star 的开源仓库可以三个月不动，208,597 star 的项目可以有一半代码不开放。star 是民意，提交才是产能。
数据与取数说明
- 所有 star、提交数、版本号、许可证内容均来自 GitHub REST API，取数时间 2026-10-26。
- “近 4 周提交数”取
GET /repos/{owner}/{repo}/stats/participation返回的 52 周周桶中最后 4 项之和；该接口统计的是默认分支提交，不含合并前的分支提交。 - 许可证条款引用自各仓库根目录
LICENSE/LICENSE.md/LICENSE-APACHE原文；许可证在表述上按”是否 OSI 认可的开源许可”区分，具体授权请以原文为准。 - 硬件门槛引用自各仓库 README（RAGFlow / Dify 有明确数值；FastGPT、n8n 的 README 未给出具体配置，本文不做推测）。
- 2025-05-22 的基准数据引自原文，版权归原作者所有，本文仅作时间对照引用。
- 本文为独立复核，与上述任何平台及其厂商无利益关系。
