最近我一直在关注一个词Ontology本体。很多人第一次看到“本体”这个词会觉得它很学术甚至有点抽象。但如果你把它放到 AI、知识图谱、Agent 这些技术里就会发现它其实非常重要。简单来说本体解决的是一个问题一个领域里到底有哪些东西这些东西之间是什么关系。比如一个电商系统里有用户、订单、商品、支付、物流。它们之间可能是这样的User ├── owns → Order ├── belongsTo → Organization └── hasPermission → Role Order ├── contains → Product ├── paidBy → Payment └── deliveredBy → Logistics这其实就是一个非常简单的“业务世界模型”。以前本体更多出现在 Semantic Web、知识图谱这些领域。但到了 AI Agent 时代我觉得它可能会重新变得非常重要。因为现在最大的问题已经不是“大模型会不会说话”而是怎么让 AI 真正理解一个业务世界。这篇文章就整理一些目前比较值得关注的本体相关开源项目。1. Protégé本体领域最经典的工具项目https://github.com/protegeproject/protegeProtégé 基本算是本体领域绕不开的工具。它是斯坦福开发的一套开源 Ontology 编辑器可以用来创建和维护ClassIndividualObject PropertyData PropertyOWLRDF你可以把它理解成本体领域的 IDE。如果你是第一次接触 Ontology我觉得可以先打开 Protégé 玩一下。比如定义Person Developer Company Project然后继续定义Developer isA Person Developer worksFor Company Developer develops Project这样一个最简单的 Ontology 就出来了。2. OWL APIJava 操作本体项目https://github.com/owlcs/owlapi如果说 Protégé 是一个 GUI 工具那么 OWL API 就属于开发者工具。它是一套 Java API可以直接通过代码创建、读取、修改 OWL Ontology。例如你的程序可以自动创建Class: User Class: Order Class: Product然后添加关系User → create → Order Order → contains → Product对于 Java 开发者来说这个项目非常值得研究。未来如果要做LLM ↓ 自动识别业务模型 ↓ OWL API ↓ 生成 OntologyOWL API 就可以成为底层基础设施。3. Apache JenaJava 知识图谱老牌框架项目https://github.com/apache/jenaApache Jena 也是 Semantic Web 领域非常经典的项目。它支持RDF RDFS OWL SPARQL同时还提供自己的 RDF 数据存储。如果你想自己做一个类似Ontology Server Knowledge Graph Server Semantic Query Server这样的系统Jena 非常值得研究。比如Agent ↓ SPARQL ↓ Apache Jena ↓ Knowledge Graph这条链路完全可以直接跑起来。4. Owlready2Python 玩本体非常舒服项目https://github.com/pwin/owlready2这个项目我个人非常推荐。原因很简单Python。Owlready2 可以直接把 OWL Ontology 映射成 Python Object。例如fromowlready2import*ontoget_ontology(http://example.org/ontology.owl)withonto:classPerson(Thing):passclassDeveloper(Person):passclassworks_for(ObjectProperty):domain[Developer]对于现在的 AI 项目来说Python 生态明显更方便。因此非常容易做成LLM ↓ Python ↓ Owlready2 ↓ Ontology比如让 AI 自动分析一个数据库 Schema然后自动生成 Ontology。这个方向我觉得非常有意思。5. pySHACL给 AI 生成的本体加规则项目https://github.com/RDFLib/pySHACLSHACL 是一个很重要但经常被忽略的东西。它主要负责验证知识图谱中的数据是不是符合规则。例如你可以规定User 必须有 name Employee 必须属于 Company Order 必须有 amount age 必须是 Integer然后运行 SHACL Validator 检查数据。这件事情在 AI 时代特别重要。因为未来很可能是文档 ↓ LLM ↓ 自动抽取实体 ↓ 自动生成关系 ↓ Knowledge Graph但是 LLM 会犯错。所以需要LLM 生成 ↓ SHACL 验证 ↓ 修复 ↓ 入库这其实就是一种非常典型的 AI 数据治理流程。6. Ontop让数据库直接变成知识图谱项目https://github.com/ontop/ontopOntop 是我觉得非常值得后端工程师关注的项目。它提出的是Virtual Knowledge Graph。什么意思正常做知识图谱你可能需要MySQL ↓ ETL ↓ RDF ↓ Graph Database但是 Ontop 不一定要求你搬数据。它可以变成MySQL / PostgreSQL ↓ Mapping ↓ Ontology ↓ SPARQL也就是说数据库还是数据库。但是上层看起来已经变成一个知识图谱了。这个思路特别适合企业场景。因为很多企业的数据本来就在MySQL PostgreSQL Oracle SQL Server不可能为了做 AI就把所有业务数据重新复制一遍。因此未来完全可能是企业数据库 ↓ Ontology Mapping ↓ Virtual Knowledge Graph ↓ Agent7. OntoEKG让 LLM 自动生成企业知识图谱项目https://github.com/LiberAI/OntoEKG这个项目已经开始进入比较新的方向了。它研究的是使用 LLM 从企业非结构化数据里构建 Ontology 和 Knowledge Graph。比如企业里有很多PDF Word Wiki 产品文档 技术文档 制度 合同以前做知识图谱需要人工定义大量实体和关系。现在可以变成企业文档 ↓ LLM ↓ Concept Extraction ↓ Relation Extraction ↓ Ontology ↓ Knowledge Graph这也是我觉得 LLM 真正能够推动 Ontology 普及的地方。以前做本体人工成本太高。现在 AI 可以帮忙做第一版。8. LLM4VKGLLM Virtual Knowledge Graph项目https://github.com/HomuraT/LLM4VKG这个项目的思路也非常有意思。它把LLM Ontology Virtual Knowledge Graph结合到了一起。其中一个非常现实的问题就是数据库 Schema 怎么映射成 Ontology以前可能需要专家自己写 Mapping。未来完全可以Database Schema ↓ LLM ↓ 理解表结构 ↓ 生成 Ontology ↓ 生成 Mapping例如userid name company_idAI 自动理解成User User.name User belongsTo Company再往后就可以直接做自然语言 ↓ Ontology ↓ SPARQL / SQL ↓ 数据库这其实已经非常接近 Data Agent 了。9. OntoRAGOntology RAG现在绝大多数 RAG本质上还是问题 ↓ Embedding ↓ Vector Search ↓ 找到几个文本块 ↓ LLM这个方案很好用但问题也很明显它不真正理解业务关系。例如张三是谁的经理 A 公司有哪些项目 这个订单对应哪个供应商这些问题本质上更像 Graph Query。所以出现了 Ontology-driven RAG 的方向。架构可能会变成Question ↓ Ontology ↓ Entity Linking ↓ Knowledge Graph ↓ Document Retrieval ↓ LLM这类项目通常也会被叫做Ontology RAG GraphRAG Knowledge Graph RAG Semantic RAG我觉得这是未来非常值得关注的一条路线。10. TrustGraph把知识图谱变成 AI 的 Context Layer项目https://github.com/trustgraph-ai/trustgraphTrustGraph 已经不只是传统意义上的知识图谱项目了。它更想解决的是怎么给 LLM / Agent 提供长期、结构化、可信的上下文。里面会涉及Knowledge ingestion Graph Vector RAG LLM Agent Context这些模块。这其实代表了一个很重要的趋势。过去Knowledge Graph是一个单独的系统。现在Knowledge Graph ↓ Agent Context可能会逐渐变成 AI 基础设施的一部分。11. Graphiti给 Agent 做实时知识图谱项目https://github.com/getzep/graphitiGraphiti 最近几年在 Agent 圈子里的关注度比较高。它主要解决的是Temporal Knowledge Graph。也就是知识不仅有关系还有时间。比如2024 年 张三在 A 公司 2025 年 张三加入 B 公司如果只是普通知识图谱张三 → worksFor → A 张三 → worksFor → B就冲突了。但是加上时间张三 ↓ 2024 A 张三 ↓ 2025 B就合理了。这对于 Agent Memory 非常重要。因为 Agent 记住的不应该只是发生过什么。还应该知道什么时候发生的。12. PyGraft自动生成 Ontology 和 Knowledge Graph项目https://github.com/Orange-OpenSource/pygraft-genPyGraft 是一个比较有意思的工具。它可以生成Ontology Knowledge Graph Synthetic Dataset这种项目特别适合做实验。比如你准备开发一个Ontology Agent但是手上没有几十万条知识图谱数据。就可以用这种工具生成测试数据。我更关注 Ontology AI Agent如果只是学习传统本体其实路线已经非常成熟了RDF ↓ RDFS ↓ OWL ↓ SPARQL ↓ Protégé ↓ Reasoner这些东西已经研究很多年。但现在真正让我感兴趣的是另外一条路线Ontology ↓ Knowledge Graph ↓ GraphRAG ↓ Agent Memory ↓ Agent Context ↓ Agent Reasoning因为大模型本身拥有非常强的语言能力。现在缺少的反而是业务世界的结构。比如我要做一个电商 Agent。如果什么都不给它它看到的只是100 万条订单 几十万用户 几万个商品 大量文档但是如果有 OntologyUser ↓ Order ↓ Product ↓ Supplier ↓ Logistics ↓ PaymentAgent 就拥有了一个相对明确的“世界模型”。它知道什么东西是什么什么东西和什么东西有关系。Ontology 可能会成为 Agent 的业务操作系统我现在越来越觉得未来很多企业 Agent不会只是LLM RAG而可能变成LLM │ ↓ Agent │ ┌────────┼────────┐ ↓ ↓ ↓ Tools Memory Ontology │ ↓ Knowledge Graph │ ┌────────┴────────┐ ↓ ↓ Database Documents其中 Ontology 做的事情就是告诉 AI这个世界应该怎么被理解。数据库负责事实。文档负责知识。向量数据库负责搜索。Knowledge Graph 负责关系。Ontology 负责定义整个世界的结构。而 Agent 在这个世界上运行。最值得关注的一条路线如果今天让我重新学习 Ontology我不会只停留在 Protégé。我会按照这条路线研究OWL / RDF ↓ Owlready2 / Jena ↓ Knowledge Graph ↓ Ontop ↓ LLM 自动构建 Ontology ↓ GraphRAG ↓ Graphiti ↓ Agent Memory ↓ Ontology-driven Agent我甚至觉得Ontology-driven Agent很可能会成为一个新的 Agent 技术方向。以前我们让 AI“读更多文档。”现在可能应该进一步让 AI“理解这个世界。”而 Ontology可能正是连接这两件事情的桥梁。现在真的是一个很好的时代。人工智能以前所未有的速度发展中国又有全世界性价比最高的一批制造业和供应链再加上发达的互联网、支付和全球物流。以前很多事情普通人根本没有机会做。现在不一样了。你可以用 AI 写代码、做设计、做内容可以在中国找到工厂把产品做出来也可以通过互联网把东西卖到全世界。很多过去只有大公司才能做的事情现在一个人或者几个人的小团队也有机会做。所以我一直觉得这几年最重要的不是围观 AI也不是天天讨论哪个模型更强。而是想办法真正用起来做点东西赚点钱。时代已经把工具摆在我们面前了剩下的就是看我们自己怎么用。我是王仕宇关注技术但不只做技术人。