评估一个开源智能体项目，星数是最容易拿到也最没用的指标。更能决定你能不能用的，是许可证——而 2026 年的一个新变化是，**同一个仓库里的许可证开始分裂**。 ## 一、分裂长什么样 最常被举的例子是 AutoGPT：核心部分仍是 MIT，但 platform 目录采用了 Polyform Shield——一种限制商业使用的许可。.n8n 也有类似的受限许可安排。 这种结构意味着：**你 clone 下来跑没问题，但把它包装成对外服务，可能就踩线了。** 而「核心 MIT」这个第一印象，很容易让人在法务评审之前就做出技术选型。 ## 二、对照看：主流记忆层项目的许可证 同样是 2026 年 10 月的公开快照，记忆层这一批的许可证相对干净： | 项目 | 星数 | 许可证 | |---|---|---| | claude-mem | 约 10.1 万 | Apache-2.0 | | Mem0 | 约 6.7 万 | Apache-2.0 | | Hindsight | 约 5.0 万 | MIT | | Cognee | 约 3.2 万 | Apache-2.0 | | Beads | 约 2.8 万 | MIT | | Letta | 约 2.5 万 | Apache-2.0 | 对比之下，像 AutoGPT 这种「核心宽松 + 子目录受限」的结构，以及部分厂商 CLI（开源代码但依赖托管服务）的模式，需要单独评估。 ## 三、三个容易被忽略的点 **1. 模型权重和代码是两回事。** 一个仓库的代码用 Apache-2.0，不代表它依赖或推荐的模型权重也能随意商用。很多开源权重自带使用限制（例如月活门槛、商用禁止条款）。这一条在另一篇整理里有更详细的展开。 **2. 「开源」的 CLI 可能绑定付费服务。** 厂商发布的命令行工具即使源码公开，默认也指向自家的托管模型和计费体系。评估时要看的是「换掉后端模型还剩多少功能」。 **3. 聚合服务条款另算。** 通过 OpenRouter 这类聚合平台调用的所谓开源模型，适用的是平台的条款，与模型自身的许可证是两层。 ## 四、落地检查清单 在把某个开源智能体项目引入生产前，建议按这个顺序过一遍： 1. **逐目录看许可证**，不只是根目录的 LICENSE 文件；留意 platform/、enterprise/、ee/ 这类目录； 2. **查清依赖链**：项目的依赖里是否有 copyleft 或受限许可（SBOM + 许可证扫描）； 3. **确认模型权重的许可**，特别是你要分发或提供服务的场景； 4. **确认是否有托管版/云服务的额外条款**，有些项目开源版和云服务版功能与许可都不同； 5. **记录决策**：为什么选、许可证结论是什么、谁确认的——半年后没人记得当时的判断依据。 工具方面，GitHub 的开源许可证合规能力已在 2026 年 10 月转为正式可用：企业可以定义许可证策略，通过 rulesets 和 PR 检查强制执行，并留下审计日志。对合规团队来说，这是把「事后追」变成「PR 里拦」的机会。 ## 小结 星数衡量的是热度，许可证决定的是可行性。在智能体这一层尤其如此——它往往是「代码 + 权重 + 托管服务」的三层组合，**只看了第一层的许可证就做选型，是 2026 年最常见的合规风险。** --- **说明**：本文为公开资料的整理与评述，星数与许可证信息来自 2026 年 10 月 GitHub 公开快照及项目自身声明；许可证以仓库内实际 LICENSE 文件与官方说明为准，商用前请咨询法务。本文由 AI 辅助整理，不构成法律或选型建议。