开源 Agent 平台的许可证差别：把它交付给客户之前必须搞清楚
选型的时候大家都在比功能：谁的知识库更好用、谁的工作流更灵活、谁的中文文档更全。
很少有人先看许可证。 但如果你是系统集成商，打算把平台部署到甲方环境里再收项目费，这一条可能比所有功能加起来都关键——功能不够可以想办法绕，许可不允许是绕不过去的。
这篇把几个常见平台的许可结构讲清楚。先说明：这是技术选型层面的提示，不是法律意见。 真要商用，请自己读一遍官方 LICENSE 原文，金额大的项目建议让法务过一遍。
「开源」这个词被用得太松了
第一个要破除的误解：能看到源码、能自己部署，不等于能拿去商用。
业界有一批项目走的是「源码公开但商用受限」的路线，英文里叫 fair-code、source-available，中文常被笼统翻译成「开源」，于是就出事了。
真正意义上的开源（OSI 认可的那些许可，比如 MIT、Apache 2.0）有一条核心特征：不歧视使用领域，也就是不能限制你用来做什么，包括不能限制你商用。而 fair-code 类许可恰恰限制的就是这个。
所以判断一个项目能不能拿去接活，不能看它 GitHub 上有多少 star、有没有 Docker 镜像，得看 LICENSE 文件本身。
三种许可模式
把常见的几个平台按许可结构分，大致是三类。
第一类：标准开源，商用无附加限制
LangFlow 用的是 MIT。
MIT 是最宽松的许可之一，基本上只要求你保留版权声明。商用、闭源二次开发、白牌交付给客户——都没有额外限制。
对集成商来说这是最省心的一类：不用担心哪天因为某个附加条款踩线，也不用为了合规去跟原作者谈授权。
代价是它在中文世界的资料相对少，遇到问题查起来更费劲。这是另一笔账，但至少不是法律风险。
第二类：Apache 2.0 加附加条款，允许商用但有边界
Dify 和 FastGPT 都属于这一类。
它们的 LICENSE 都是在标准 Apache 2.0 基础上追加了条件。好消息是，两家都在官方许可文件里明确写了允许商业化使用——包括作为其他应用的后端服务，以及作为应用开发平台交付给企业。
这句话对集成商很关键：它意味着你可以拿它给甲方做项目并收费，这是原作者写在许可里的授权，不是灰色地带。
但两家都划了两条线，越过就需要单独获得商业授权：
第一条线是多租户。 你不能用它的源码去运营一个多租户的服务——说白了，不能拿它改改就变成一个跟原产品竞争的 SaaS。Dify 的许可里还专门定义了什么叫一个租户（一个 workspace 对应一个租户），边界写得比较清楚。
第二条线是 LOGO 和版权信息。 不能移除或修改控制台里的 LOGO 与版权声明。也就是说，白牌化是不允许的——你可以拿它做项目，但不能把它包装成完全属于你自己的产品。
这两条对大多数集成项目影响不大：给甲方部署一套内部用的知识库问答系统，既不是多租户 SaaS，通常也不强求去掉 LOGO。但如果你的商业模式恰恰是「把它改成我们公司的产品去卖」，那就需要先跟官方谈授权。
第三类：只允许内部使用
n8n 用的是 Sustainable Use License，官方自称 fair-code，不自称 open source。
它的限制比前两类严格得多，核心是两条：
- 只允许用于你自己的内部业务目的，或者非商业、个人用途
- 把软件分发或提供给别人，必须免费且非商业
这两条放在一起看，结论是比较明确的：自己团队内部搭自动化流程完全没问题，但把 n8n 部署到甲方环境里、作为项目交付物收费，很可能超出许可允许的范围。
另外它的仓库里还有一批文件名或目录名带 .ee 标记的企业版代码，那部分走的是完全独立的企业许可，需要单独购买才能使用。
n8n 本身是个好工具，连接能力是这批里最强的。这里不是说它不能用，而是说用它的方式得对：内部提效随便用，交付给客户要先想清楚，必要时走官方的商业授权渠道。
这条差别到底有多要紧
举个具体场景。
你是做展厅或者弱电集成的，接了个项目，甲方要在内网上一套文档问答系统。你调研了一圈，觉得三个平台功能都够用。
如果选 Dify 或 FastGPT：许可里写明了可以作为应用开发平台交付给企业，你按项目正常收费，保留控制台的 LOGO，这条路是通的。
如果选 LangFlow：MIT 许可，怎么用都行，连 LOGO 都能改。
如果选 n8n：你把它装在甲方服务器上、收了项目费——这已经是「把软件提供给别人」且「不是免费的」，跟许可条款是冲突的。项目做完可能没人追究，但这个风险是实打实存在的，尤其当甲方是有法务的大企业、或者项目要过合规审计的时候。
风险不在于会不会被发现，在于它写在合同和交付物里，是可查的。
选型时应该怎么做
第一步，先读 LICENSE，再看功能。 这个顺序反过来的话，你可能花两周做完技术验证，最后发现方案根本不能用。
第二步，看清楚你属于哪种使用方式。 同一个工具，自己内部用和交付给客户，适用的条款可能完全不同。很多人看许可时代入的是「我能不能用」，但真正该问的是「我能不能这么用」。
第三步，注意许可会变。 Dify 和 FastGPT 的许可文件里都写了，项目方可以调整许可条款，收紧或放宽都有可能。所以不要凭一年前的记忆做判断，动手前去仓库看一眼当前版本。
第四步，拿不准就直接问官方。 这些项目基本都留了商务联系方式。一封邮件的成本，比事后扯皮低太多。
顺带说一件常被混淆的事
「可自部署」和「数据不出内网」也是两回事，跟许可问题一样常被搅在一起。
自部署解决的是应用跑在哪。如果你在自部署的平台里配置的是在线大模型，提问和检索到的文档片段照样要发给模型厂商，数据依然出网。要做到全链路不出内网，模型也必须是本地部署的开源模型，那就需要 GPU，投入结构完全不同。
这两个混淆——「开源就能商用」和「自部署就是不出网」——是我们在项目里见得最多的两个，而且都是在方案阶段就该讲清楚、却经常拖到验收才暴露的。
关于什么时候平台已经不够用、需要转向定制开发，判断标准我们写在这篇：低代码 Agent 平台的能力边界。
各平台的具体许可结构，我们也分别写在了平台页里：Dify、FastGPT、n8n、LangFlow、Flowise。
如果你正在为一个具体项目做选型，也可以直接跟我们聊聊——用现成平台能解决的，我们会直接告诉你选哪个。