TrustGraph 详解：把知识图谱、Ontology、GraphRAG 和 AI Agent 串成一套系统
如果说普通 RAG 是“帮 AI 找资料”，那么 TrustGraph 更想做的事情是：给 AI Agent 建立一层统一、结构化、可追踪的上下文。
项目名称：
TrustGraph
GitHub：
https://github.com/trustgraph-ai/trustgraph
官网：
https://trustgraph.ai/
一、TrustGraph 是什么？
TrustGraph 是一个开源的 AI Context / Knowledge Graph 基础设施项目。
它现在给自己的定位是：
The Context Interoperability Layer for Agentic AI
翻译一下：
面向 Agentic AI 的上下文互操作层。
这个名字看起来有点抽象。
我们先用最简单的方式理解。
传统 AI 应用：
用户
↓
LLM
↓
回答
后来有了 RAG：
用户
↓
Vector Search
↓
Documents
↓
LLM
↓
回答
再后来有了 GraphRAG：
用户
↓
Vector Search
↓
Knowledge Graph
↓
Graph Traversal
↓
LLM
↓
回答
而 TrustGraph 想进一步做成：
AI Agent
|
↓
Context Layer
|
┌────────────────────────┐
| |
↓ ↓
Knowledge Graph Vector Search
| |
└───────────┬────────────┘
↓
Ontology
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Documents Database APIs
也就是说：
把企业里的各种数据统一整理成 AI 能理解的 Context。
二、为什么普通 RAG 不够？
先看普通 RAG。
假设公司里有 10 万份文档：
合同
产品文档
会议纪要
用户反馈
财务报告
技术文档
传统方法：
Document
↓
Chunk
↓
Embedding
↓
Vector Database
用户问：
A 客户现在使用哪个产品？
系统：
问题
↓
Embedding
↓
Vector Search
↓
找到几个 Chunk
↓
LLM
这种方式最大的优点：
简单。
但是问题也很多。
三、第一个问题：Chunk 之间没有关系
例如：
文档 A：
阿里巴巴购买了产品 X。
文档 B：
产品 X 使用 PostgreSQL。
文档 C：
PostgreSQL 数据库部署在服务器 Server-01。
用户问：
阿里巴巴使用的数据库部署在哪台服务器？
这个问题需要：
Alibaba
↓
Product X
↓
PostgreSQL
↓
Server-01
至少三跳关系。
普通 Vector RAG 很可能只找到：
Alibaba → Product X
或者：
PostgreSQL → Server-01
但是它不一定知道：
这三件事情其实属于同一条关系链。
四、Knowledge Graph 就开始发挥作用了
如果把这些知识变成图：
Alibaba
|
| purchased
↓
Product X
|
| uses
↓
PostgreSQL
|
| deployedOn
↓
Server-01
现在问题：
Alibaba 使用的数据库在哪台服务器？
就可以沿着图：
Alibaba
↓
Product
↓
Database
↓
Server
一路查询。
这就是：
Multi-Hop Reasoning。
也就是：
多跳推理。
五、TrustGraph 的 GraphRAG
TrustGraph 一个很重要的能力就是：
GraphRAG
它并不是完全放弃 Vector Search。
而是把：
Vector Search
+
Knowledge Graph
组合起来。
整个流程大概是：
Document
↓
Chunking
↓
Entity Extraction
↓
Relationship Extraction
↓
Embedding
↓
Knowledge Graph
查询：
Question
↓
Vector Search
↓
找到相关 Entity
↓
Graph Traversal
↓
找到相关子图
↓
Subgraph Context
↓
LLM
↓
Answer
这比：
问题
↓
找几个 Chunk
多了一层：
关系理解。
六、举一个更具体的例子
假设有三份文档。
第一份：
王仕宇创建了 JavaPub。
第二份：
JavaPub 主要发布 AI 和编程相关内容。
第三份：
AI 编程课程属于 JavaPub 的内容体系。
普通 RAG：
Document 1
Document 2
Document 3
三个 Chunk。
TrustGraph：
王仕宇
|
| created
↓
JavaPub
|
| publishes
↓
AI / 编程内容
|
| includes
↓
AI 编程课程
于是用户问：
王仕宇创建的品牌主要有哪些 AI 内容？
GraphRAG 可以沿着关系找到答案。
这就是：
Graph + RAG
七、TrustGraph 还有一个更重要的能力：Ontology RAG
如果只是自动抽取知识图谱，会出现一个问题：
LLM 想抽什么就抽什么。
例如：
Apple
到底是什么？
可能是：
Company
Fruit
Product Brand
再例如：
Java
可能是：
ProgrammingLanguage
Island
Coffee
如果没有统一 Schema：
不同文档可能抽出完全不同的结构。
八、Ontology 解决什么问题？
Ontology 解决的是：
世界里有什么，以及这些东西之间可以有什么关系。
例如企业系统：
Customer
Product
Order
Employee
Company
定义关系：
Customer
|
| purchases
↓
Product
再定义：
Employee
|
| worksFor
↓
Company
于是：
Customer
不能随便：
worksFor Product
因为这不符合 Ontology。
九、TrustGraph 支持 Ontology RAG
TrustGraph 可以使用 OWL Ontology 指导知识抽取。
流程：
Document
↓
Chunk
↓
Ontology
↓
LLM Extraction
↓
Typed Entity
↓
Typed Relationship
↓
Knowledge Graph
↓
GraphRAG
这比普通 GraphRAG 多了一步：
Ontology Constraint
什么意思？
普通 GraphRAG：
LLM：
我觉得这是一个实体。
Ontology RAG：
Ontology：
允许的实体类型：
Customer
Order
Product
Supplier
LLM：
那我按照这些类型抽。
十、举一个电商 Ontology
比如我们定义：
Customer
Order
Product
Supplier
Payment
关系：
Customer
|
| places
↓
Order
Order
|
| contains
↓
Product
Product
|
| suppliedBy
↓
Supplier
Order
|
| paidBy
↓
Payment
现在给 AI 一份文档：
王先生在 8 月 10 日购买了 MacBook，
订单由 Apple Store 提供，
使用支付宝完成付款。
TrustGraph 可以按照 Ontology 抽取：
Customer:
王先生
Product:
MacBook
Supplier:
Apple Store
Payment:
支付宝
建立：
王先生
↓ places
Order-001
↓ contains
MacBook
↓ suppliedBy
Apple Store
以及：
Order-001
↓ paidBy
支付宝
这就变成了一套真正可查询的业务知识。
十一、Ontology RAG 和普通 GraphRAG 有什么区别？
可以直接看：
| 能力 | RAG | GraphRAG | Ontology RAG |
|---|---|---|---|
| Vector Search | ✅ | ✅ | ✅ |
| Knowledge Graph | ❌ | ✅ | ✅ |
| Relationship | ❌ | ✅ | ✅ |
| Multi-Hop | 弱 | 强 | 强 |
| Schema | ❌ | ❌ | ✅ |
| 类型约束 | ❌ | ❌ | ✅ |
| OWL | ❌ | ❌ | ✅ |
可以简单理解：
RAG
↓
找内容
GraphRAG：
找内容
+
找关系
Ontology RAG：
找内容
+
找关系
+
理解关系的业务含义
十二、为什么 Ontology 对企业 Agent 特别重要？
假设一个企业数据库里面有：
客户
合同
订单
员工
供应商
项目
资产
如果没有统一语义：
CRM 叫：
customer
ERP 叫：
client
财务系统可能叫：
payer
实际上：
可能都是：
Customer
Ontology 可以把：
customer
client
payer
统一到：
Customer
这就是：
Semantic Layer。
十三、TrustGraph 想做的，其实就是 Context Layer
这个概念很重要。
现在 AI 领域越来越多人讨论：
Context Engineering
以前我们关心：
Prompt Engineering
也就是：
Prompt 怎么写？
现在越来越多系统开始关心：
到底应该给模型什么 Context？
因为模型本身已经越来越强。
真正影响 AI 输出的往往变成：
Context
例如：
哪些文档？
哪些实体？
哪些关系？
哪些历史？
哪些权限？
哪些业务规则？
TrustGraph 就想解决这件事情。
十四、Context Graph
TrustGraph 现在非常强调：
Context Graph
可以简单理解：
为 AI Agent 服务的知识图谱。
传统知识图谱更多是：
存知识
Context Graph 更强调：
给 Agent 提供正确上下文
例如：
Agent
↓
Context Graph
┌──────────┼──────────┐
↓ ↓ ↓
User Order Contract
↓ ↓ ↓
Role Product Policy
Agent 不需要一次读取：
100 万条数据
而是从图中选择：
当前问题真正需要的 Context
十五、TrustGraph 为什么开始强调 Hypergraph？
TrustGraph 现在还在强调一个概念：
Hypergraph
传统 Knowledge Graph 通常：
A → B
也就是二元关系。
例如：
User
↓
purchased
↓
Product
但是企业业务往往更加复杂。
比如：
张三
在 2026 年 8 月 1 日
通过支付宝
以 9999 元
购买 MacBook
订单属于 JavaPub 公司
这其实涉及：
Person
Time
Payment
Amount
Product
Company
很多实体。
如果只用：
A → B
表达起来会越来越复杂。
十六、Hypergraph 是什么？
Hypergraph 可以理解成：
一条关系可以连接多个对象。
传统 Graph：
A ─── B
Hypergraph：
A
|
┌─────┼─────┐
↓ ↓ ↓
B C D
比如一次采购事件：
Purchase Event
┌────────┼─────────┬────────┐
↓ ↓ ↓ ↓
User Product Payment Time
整个：
Purchase Event
可以作为一个完整 Context。
这对 AI Agent 很有价值。
十七、TrustGraph 的数据处理流程
我们可以把整个流程简化为：
Raw Data
|
┌────────┼─────────┐
↓ ↓ ↓
PDF Wiki Database
\ | /
Ingestion
↓
Chunking
↓
LLM
↓
Entity / Relationship Extraction
↓
Ontology Mapping
↓
Knowledge Graph
↓
Vector Index
↓
GraphRAG
↓
AI Agent
十八、TrustGraph 可以处理哪些数据？
典型包括：
PDF
Text
企业文档
Wiki
API 数据
数据库数据
结构化信息
系统会把这些原始信息：
Unstructured Data
逐渐转换成：
AI-Ready Context
这其实就是 TrustGraph 的核心价值之一。
十九、TrustGraph 中的 Collection
TrustGraph 可以通过 Collection 组织知识。
例如：
AI Research
Customer Support
Finance
Product Docs
分别建立：
Collection
例如：
tg-set-collection \
-n "AI Research" \
-d "AI 研究资料" \
ai-research
这样不同业务领域的数据可以分开管理。
二十、添加文档
可以将文档加入 Library。
例如：
tg-add-library-document \
--name "AI Research Report" \
--description "AI research report" \
--tags "ai,research" \
--id ai-report-001 \
--kind text/plain \
./report.txt
进入系统之后：
Document
↓
Library
↓
Processing Flow
↓
Knowledge Graph
二十一、创建 GraphRAG Flow
TrustGraph 使用 Flow 来组织数据处理 Pipeline。
例如：
tg-start-flow \
-n graph-rag \
-i graph-rag \
-d "Graph RAG processing flow"
这个 Flow 可以负责：
Document Chunking
↓
Entity Extraction
↓
Relationship Extraction
↓
Embedding
↓
Graph Construction
二十二、开始处理文档
例如：
tg-start-library-processing \
--flow-id graph-rag \
--document-id ai-report-001 \
--collection ai-research \
--processing-id process-001
然后系统开始：
文档
↓
Chunk
↓
LLM 抽取
↓
Graph
↓
Vector
二十三、查询 GraphRAG
处理完成之后，可以直接查询：
tg-invoke-graph-rag \
-f graph-rag \
-C ai-research \
-q "2026 年 AI Agent 主要发展方向是什么？"
查询过程：
Question
↓
Semantic Search
↓
找到相关实体
↓
Graph Traversal
↓
提取 Subgraph
↓
LLM
↓
Answer
二十四、什么是 Subgraph Context？
这个概念很重要。
普通 RAG 给 LLM：
Chunk 1
Chunk 2
Chunk 3
GraphRAG 给 LLM：
OpenAI
/ \
↓ ↓
Model Agent
| |
↓ ↓
GPT-X Tool Use
也就是说：
不是几个孤立文本。
而是一张：
小型关系网络
这就是：
Subgraph Context
二十五、TrustGraph + MCP
TrustGraph 还有一个很有意思的能力：
MCP
项目仓库里面已经包含：
trustgraph-mcp
也就是说：
未来：
Claude Code
Cursor
Codex
AI Agent
理论上都可以通过 MCP 调用 TrustGraph 提供的知识能力。
架构：
Claude / Codex
|
↓
MCP
|
↓
TrustGraph
|
↓
Context Graph
二十六、为什么 MCP + Knowledge Graph 很有意思？
普通 MCP：
Agent
↓
Tool
↓
API
比如：
查询数据库
发邮件
查天气
但是 TrustGraph：
Agent
↓
MCP
↓
Context Graph
↓
企业知识
这就相当于：
给 Agent 增加一个“理解企业”的工具。
例如 Coding Agent 可以问：
这个项目为什么当初选择 PostgreSQL？
Graph 里面可能有：
Project
↓
Architecture Decision
↓
PostgreSQL
↓
Reason
↓
JSONB + Transaction
于是 Agent 不只是：
看代码
还可以：
理解项目历史。
二十七、TrustGraph 和 Graphiti 有什么区别？
前面我们介绍过 Graphiti。
两者确实有一些重叠。
但是侧重点不同。
Graphiti 更强调：
Temporal Knowledge Graph
Agent Memory
Fact History
也就是：
世界发生了哪些变化？
TrustGraph 更强调：
Context Graph
Ontology
GraphRAG
Enterprise Context
也就是：
AI Agent 应该如何理解整个企业上下文？
简单来说：
Graphiti
↓
Memory
TrustGraph：
Context
二十八、TrustGraph 和 Ontop 有什么区别？
Ontop：
Database
↓
Ontology
↓
Virtual Knowledge Graph
它重点解决：
如何让关系数据库变成虚拟知识图谱。
TrustGraph：
Documents
Database
APIs
↓
Knowledge Extraction
↓
Context Graph
重点解决：
如何把各种企业数据变成 Agent Context。
所以三者可以这样理解：
Ontop
企业结构化数据
↓
TrustGraph
企业上下文
↓
Graphiti
长期动态记忆
二十九、这三个项目甚至可以组合
可以设想：
AI Agent
|
↓
TrustGraph
|
Context / Ontology
/ \
↓ ↓
Graphiti Ontop
↓ ↓
Agent Memory Enterprise DB
↓ ↓
Temporal Graph MySQL / Oracle
这是一个非常有意思的企业 Agent 架构。
其中：
Ontop
负责：
当前业务数据。
Graphiti
负责：
历史变化和长期记忆。
TrustGraph
负责：
给 Agent 组织统一 Context。
三十、TrustGraph 最大的价值是什么？
我觉得不是：
又一个 GraphRAG 框架
真正值得关注的是它背后的思想：
AI Agent 需要的不是更多 Token，而是更好的 Context。
以前我们想：
上下文 128K
↓
上下文 1M
↓
上下文 10M
似乎：
上下文越大越好。
但是企业 AI 真正的问题可能不是：
Context 不够长
而是：
Context 不够准确。
真正需要的是：
正确的数据
正确的实体
正确的关系
正确的时间
正确的权限
正确的业务语义
这才是：
Context Engineering
三十一、Ontology 在这里扮演什么角色？
Ontology 相当于：
Agent 的世界说明书。
例如：
Customer
Product
Order
Supplier
这是：
概念。
然后：
Customer purchases Product
这是：
关系。
再进一步：
Customer
必须是 Person / Organization
这是：
约束。
因此：
Ontology
↓
定义世界
Knowledge Graph：
↓
记录世界
TrustGraph：
↓
组织 Context
Agent：
↓
理解世界并行动
三十二、未来企业 Agent 很可能是这种结构
我觉得未来很多企业 Agent 不会只是：
LLM + Vector DB
而会变成：
AI Agent
|
↓
Context Engine
|
┌──────────────┼──────────────┐
↓ ↓ ↓
Ontology Knowledge Memory
Graph
| | |
↓ ↓ ↓
Schema GraphRAG Temporal
\ | /
Enterprise Data
┌─────────┼─────────┐
↓ ↓ ↓
DB Docs APIs
TrustGraph 正在尝试做的事情：
其实就是中间这层。
三十三、TrustGraph 更适合什么项目？
我觉得它比较适合：
1. 企业知识 Agent
例如：
员工助手
销售助手
客服 Agent
财务 Agent
2. GraphRAG
特别是需要：
Multi-Hop Reasoning
的场景。
3. Ontology RAG
例如：
金融
医疗
制造业
法律
这种有明确 Schema 的领域。
4. 企业 Context Layer
大量系统：
CRM
ERP
OA
Wiki
Database
需要统一语义。
5. Coding Agent Memory
把：
架构设计
PR
Issue
文档
代码
技术决策
组织成图。
三十四、它不适合什么？
如果你的项目就是：
100 个 PDF
然后：
问答
那我觉得：
完全没必要一开始就上 TrustGraph。
一个简单的：
Embedding
+
Vector DB
+
LLM
就够了。
TrustGraph 更适合：
数据复杂
关系复杂
需要多跳查询
需要 Ontology
需要 Agent
需要企业 Context
这样的场景。
三十五、普通 RAG、GraphRAG、Ontology RAG 怎么选？
可以记住：
简单文档问答
↓
RAG
如果问题大量涉及：
谁和谁有什么关系？
选择：
GraphRAG
如果业务还有明确：
实体类型
业务模型
数据规范
选择：
Ontology RAG
最终：
RAG
↓
GraphRAG
↓
Ontology RAG
↓
Context Graph
↓
AI Agent
这条路线其实越来越清晰。
三十六、我怎么看 TrustGraph？
我认为 TrustGraph 最值得研究的并不是：
GraphRAG API
而是：
Context Layer
这个概念。
现在的大模型已经很聪明。
真正的问题变成：
如何把正确的信息，在正确的时间，以正确的结构交给 AI？
传统方法：
Prompt
后来：
Prompt + RAG
未来可能变成：
Agent
+
Context Graph
+
Ontology
+
Tools
+
Memory
所以我觉得：
TrustGraph 本质上更像一个 Agent 的上下文基础设施。
三十七、总结
一句话总结 TrustGraph：
TrustGraph 是一个开源的 AI Context 基础设施，通过 Knowledge Graph、GraphRAG、Ontology、Vector Search 和 MCP 等能力，把企业原始数据组织成 AI Agent 可以理解和使用的结构化上下文。
如果用一张图表示：
Documents
Database
APIs
Wiki
↓
TrustGraph
↓
Ontology
↓
Knowledge Graph
↓
GraphRAG
↓
Context Graph
↓
AI Agent
前面我们讲了：
Graphiti
解决：
Agent Memory
然后：
Ontop
解决：
Enterprise Data Layer
这次的：
TrustGraph
更像是在解决：
Agent Context Layer
三者放在一起：
AI Agent
|
↓
TrustGraph
Context Layer
/ \
↓ ↓
Graphiti Ontop
↓ ↓
Memory Enterprise DB
而最上面贯穿这一切的，其实就是：
Ontology
因为它负责告诉 AI：
这个业务世界到底是什么样的。
我认为这也是 Ontology 在 AI Agent 时代重新值得研究的真正原因。
项目地址
GitHub：
https://github.com/trustgraph-ai/trustgraph
官网：
https://trustgraph.ai/
王仕宇 JavaPub
浙公网安备 33010602011771号