八 · 开源生态地图
78 个项目、七个类别、四种采纳级别
这一章是地图，不是清单。它回答三个问题：这 78 个项目在结构上如何分布；分布本身说明了什么；以及在这张图上，一个具体的团队应该站在哪里。
口径
- 78 个项目 = 一份流传较广的公众号索引里的 59 个 + 趋势论证中引用、但未被索引收录的 19 个。
- 原索引分了 6 类；这里拆成 7 类，多出来的第 7 类（7.7 索引之外的系统）专门收纳那 19 个「被引用但没被收录」的项目。如果不补这一类，趋势章节的论证会被自己的索引证伪。
- 所有星数、建库日期、许可证、主语言取自 GitHub API，核验时间 2026-10-30。分级（S/A/B/C）是本书的判断，不是任何官方口径。
七个类别的规模与星数
| 类别 | 数量 | 星数中位 | 极值 | 2026 年新建 | 一句话判读 |
|---|---|---|---|---|---|
| 7.1 企业本体平台 | 11 | 1,045 | 108 – 2,988 | 10 | 全是 2026 年的新供给，复刻同一个模式 |
| 7.2 Agent 上下文与记忆 | 10 | 880 | 455 – 14,342 | 7 | 需求真实，但多数只做到「带类型的上下文」 |
| 7.3 建模与工具链 | 8 | 351 | 49 – 1,617 | 0 | 十年没有新增，编辑器与编译器两类 |
| 7.4 语义基础设施 | 14 | 302 | 32 – 2,542 | 0 | 沉默的地基，推理在萎缩、校验在增长 |
| 7.5 图谱检索 | 8 | 7,898 | 342 – 139,218 | 1 | 星数最高，但与本体是两件事 |
| 7.6 领域词表 | 8 | 725 | 25 – 1,254 | 0 | 是资产不是工具，借用方式决定价值 |
| 7.7 索引之外 | 19 | 329 | 11 – 89,016 | 3 | 补齐趋势论证的缺口，含三个超新星 |
合计 78 个，星数中位 698。分级：S 级 7 个、A 级 21 个、B 级 39 个、C 级 11 个。
逐个项目的名称、仓库、星数、建库时间、许可、语言与分级，汇总在附录 C 的总表里；下面七节则给出每个项目「它解决什么问题、能拿来干什么」的说明。
四个反直觉的分布事实
一、越「新」的类别，星数中位越高；越「基础」的类别，星数中位越低。
企业本体平台中位 1,045、Agent 上下文 880，而语义基础设施只有 302、建模工具链 351。这不符合「基础设施更成熟所以更受欢迎」的直觉。
解释只有一个：星数衡量的是注意力，不是成熟度。 2026 年新出现的平台类项目，在发布时就有明确的叙事（「开源版 Foundry」「Agent 的记忆层」），容易被转发；而 rdflib 这类项目建于 2012 年，功能稳定、没有新闻，星数自然停在两千多。
实操含义：用星数排序做选型，会系统性地把新项目排在老项目前面，而新项目恰恰是未经生产验证的那一批。这是一个真实存在的选型偏差。
二、21 个项目建于 2026 年，占 27%，且几乎全部集中在两个类别。
平台类 11 个里 10 个是 2026 年建的；Agent 类 10 个里 7 个是。基础设施与工具链两类，2026 年新增 0 个。
这个分布非常干净地说明：生态的增量全部在「怎么用」，没有在「怎么推」。 没有人 2026 年去写一个新的推理机（有人 2025 年停更了一个），但有十个人在复刻同一种对象-动作模型。
三、15% 的项目许可证需要法务看过再用。
78 个里，GitHub 无法识别为标准许可的有 12 个（NOASSERTION），另有 5 个没有声明许可。前者通常意味着自定义许可、多许可或源码可用（source-available）——三家图库（FalkorDB、Memgraph）都落在这一档，它们实际用的是 SSPL 与 BSL，不是 OSI 认可的开源许可。
其余分布：Apache-2.0 28 个、MIT 22 个、BSD 系 8 个、GPL/LGPL 2 个、CC BY 4.0 1 个。
实操含义：把「许可证」当技术属性会出错，它是采购属性。一个 NOASSERTION 的项目，在 PoC 阶段完全可用，在商业化前必须过法务。
四、语言分布仍是 Python + JVM 的天下。
Python 31 个、Java 12 个、TypeScript 8 个、Rust 6 个、Go 3 个。本体核心（OWL API、Jena、Protégé、ELK、ROBOT）几乎全在 JVM 上，这不是历史包袱，是因为 OWL 的类型系统与 Java 的对象模型天然接近。
Rust 的 6 个集中在「存储与推理」这一层（Oxigraph、Reasonable、open-ontologies、TerminusDB 的引擎、FalkorDB、utopia）。系统级语言重写，重写的是执行效率与部署形态，不是语义能力。
四个采纳级别
分级只看一件事：一个团队在什么情况下应该真的把它用起来。
| 级别 | 数量 | 含义 | 怎么用 |
|---|---|---|---|
| S · 核心必读 | 7 | 各自领域的事实标准，或提供了不可替代的机制 | 直接引入或作为设计基准 |
| A · 重要参考 | 21 | 有明确独到之处，但需评估契合度 | 读设计、摘机制，谨慎引入 |
| B · 观察备选 | 39 | 方向对但成熟度或体量不足 | 跟踪，PoC 用，不进主链路 |
| C · 仅作存档 | 11 | 已停更，或仅有概念价值 | 只读 README，作为反例 |
S 级的 7 个分布在四类：基础设施（rdflib、pySHACL、OWL-RL）、工具链（LinkML、Protégé）、平台（Operational Ontology）、以及作为模式参照的 Palantir 拆解。注意：S 级里没有一个是 2026 年新建的。 这不是巧合。
生态的三个结构性判断
一、供给在最后一个环节爆发，且同质化严重。
十一个平台项目里，讲的故事几乎逐字相同：对象类型、链接、动作、权限、审计、写回。真正把动作当一等公民并给出可验证机制的只有三个。推断：这个格局意味着未来 12 个月会有大量项目停止维护，选择时要假设「这个仓库两年后可能没人管」。
二、基础设施沉默，但它是唯一不可替代的一层。
你可以不用任何一个平台项目，用 rdflib + pySHACL + 一个数据库拼出自己的语义层。反过来不成立：没有解析器与校验器，任何平台都跑不起来。推断：技术选型的安全边际，来自对基础设施的掌握，而不是对平台的依赖。
三、词表是资产，抄的是劳动，不是代码。
八个词表项目里，最有价值的是那些把「建模决策」写下来的（FIBO 的域划分、AudioSet 的七字段结构、DTDL 的版本化标识符），最没价值的是链接清单。借用时永远只借三样：术语、分层、命名规范。
怎么用这七个分类页
每个分类页的结构一致：一段判读（这一类在解决什么、共同盲点是什么）、一张判据提示、然后是项目卡片。每张卡片给出四要素——它做了什么、关键机制、何时采纳、以及仓库的四项硬数据（星数、建库、语言、许可）。
三条使用建议：
- 先读判读，再看卡片。 卡片是证据，判读是观点；先有观点再读证据，效率更高。
- 看「何时采纳」这一行，而不是「做了什么」。 前者是决策依据，后者是宣传语的复述。
- C 级卡片不要跳过。 它们记录了失败方式，而失败方式比成功案例更可复用——第 11 章会用到它们。