我选了 Oxigraph 做 AI 的大脑，然后整个系统开挂了

你有没有遇到过这种绝望：

Agent 跑了两小时，聊了几十轮，突然就忘了最初的需求；一个 Skill 的参数名换了，所有调用它的 Agent 全部炸锅；想查“当初为什么选了 JWT 认证”，结果翻了半天聊天记录。

这些问题的根源都是：数据散落在各处，没有统一的大脑。

我的解决方案是——给 Agent 装一个叫 Oxigraph 的图数据库，然后让它和 JSON-LD 组成“统一地址总线”。这一装，整个系统的智商直接上了一个台阶。

今天就来聊聊这个“图数据库 + 语义总线”的邪门组合。

---

一、为什么是 Oxigraph 而不是 Neo4j、不是 PostgreSQL？

先坦白：我选 Oxigraph，一开始是因为它太“Rust”了。

Gliding Horse 整个系统都是用 Rust 写的。如果选 Neo4j，就得配 Java 环境；选 PostgreSQL 加 pgvector，又得多部署一个服务。Oxigraph 是 Rust 原生库，直接编译进二进制文件，一行 cargo build 全搞定。 没有外部依赖，没有网络开销，没有“在我机器上能跑”的破事。

但真正让我惊艳的，是它和 JSON-LD 的化学反应。

---

二、JSON-LD + Oxigraph = 天然绝配

JSON-LD 是什么？简单说，就是给 JSON 加上语义，每个字段、每个值都对应一个全球唯一的 IRI（类似网址）。

比如一个 Skill 的参数 input_file，在 JSON-LD 里会被映射成 https://agent-os.com/skill#sourceDataURI。这样一来，不管别的 Skill 叫 source_url 还是 data_path，只要它们都指向同一个 IRI，系统就知道它们是同一回事。

而 Oxigraph 是 RDF 图数据库，RDF 的底层就是“主语-谓语-宾语”三元组——和 JSON-LD 展开后的结构一模一样。

举个栗子：

{
  "@id": "skill:python-analysis",
  "@type": "skill:AtomicSkill",
  "skill:name": "Python 数据分析"
}

JSON-LD 引擎把它展开后，会变成三条三元组：

<skill:python-analysis>  <rdf:type>          <skill:AtomicSkill>
<skill:python-analysis>  <skill:name>         "Python 数据分析"

然后 Oxigraph 直接吞下这三条三元组，存进图里。完全不需要任何中间转换层。

这种“零摩擦”的配合，让我可以把整个系统的所有数据——提示词、Skill 定义、对话记忆、任务元数据、审计日志——全部用 JSON-LD 建模，然后一股脑倒进 Oxigraph。

---

三、统一地址总线：给所有数据安个“家”

传统 AI 系统里，数据就像流浪猫：没有固定地址，靠代码里的变量名四处碰运气。

在我的系统里，任何数据生下来就有唯一的 IRI。比如：

• 一个任务：task:sales-analysis-2026
• 一个 Skill：skill:python-analysis
• 一段对话记忆：memory:session-042/block-017

这些 IRI 就是“地址总线”。Oxigraph 就是存储这些地址的门牌号数据库。

带来的第一个魔法：按需加载，Token 暴降。

LLM 的上下文窗口里，只需要存摘要和 IRI 引用。比如：

可用技能：[skill:python-analysis]，[skill:forecasting]
当前任务：task:sales-analysis-2026
历史记忆摘要：我们决定用 JWT 认证，有效期 24 小时

当 LLM 需要某个细节时，直接用内置工具沿 IRI 去 Oxigraph 里查。相当于把 LLM 的“工作记忆”无限扩展了，而 Token 消耗几乎不变。

第二个魔法：多 Agent 共享黑板，绝不冲突。

多个 Agent 同时读写 L2 黑板，这个黑板就是 Oxigraph 的内存模式。Agent A 写入 task:001 status "done"，Agent B 立刻就能读到。更骚的是，我还给每个节点加了 MESI 状态标记（对，就是 CPU 缓存一致性协议那套）。这样 Agent A 修改一个节点时，系统会自动通知其他 Agent“这个数据过期了，赶紧重读”。

第三个魔法：图查询比关系型快得多。

想查“某 Skill 的所有前置依赖”？在 SQL 里要 JOIN 好几次，在 Oxigraph 里就一行 SPARQL：

SELECT ?dep WHERE {
  skill:rust-jwt-auth skill:requiresDirect ?dep .
}

更重要的是，可以利用属性路径做递归遍历，比如“这个 Skill 依赖的所有 Skill（不限深度）”：

SELECT ?dep WHERE {
  skill:rust-jwt-auth skill:requiresDirect* ?dep .
}

这种递归查询在关系型数据库里几乎是噩梦，在 Oxigraph 里却轻描淡写。

---

四、记忆系统 + Oxigraph：让 Agent 拥有“海马体”

神经科学里，海马体负责把短期记忆转化为长期记忆。我的记忆系统里，Oxigraph 就是海马体。

• L1 短期记忆：LLM 上下文窗口里的摘要和 IRI 引用
• L2 工作记忆：Oxigraph 内存模式，存活跃任务的中间结果
• L3 记忆提取：用 SPARQL CONSTRUCT 从 L0 把相关记忆“投影”到 L2
• L0 长期记忆：Oxigraph 持久化模式，存所有历史数据和知识

这套设计的好处是：Agent 永远不会“失忆”。 哪怕上下文窗口只有 2K Token，它也能通过 L3 投影随时调出任何历史细节。

而且 Oxigraph 支持 Named Graphs（命名图），我可以把不同 Agent 的记忆、不同任务的产出、不同版本的 Skill 分开存储，互不干扰，又能联合查询。这为后面的多 Agent 联邦架构铺平了道路。

---

五、架构收益总结：图数据库给 AI 带来的三个质变

1. 从“数据孤岛”到“数据联邦”：所有数据都有 IRI，都能通过 SPARQL 互相查询。Skill 能“发现”自己需要什么前置技能，Agent 能“回忆”起历史上类似的任务是怎么做的。
2. 从“全量注入”到“按需加载”：LLM 上下文里只放摘要和 IRI，细节在 Oxigraph 里随时可取。Token 消耗从 O(n) 变成 O(1)。
3. 从“事后查证”到“实时可审计”：任何决策、任何产出都有 IRI，顺着图就能看到整个推理链。当系统出问题，不再是“不知道哪一步错了”，而是“秒级定位”。

---

六、最后说句人话

选 Oxigraph，不是因为它最流行，而是因为它和 JSON-LD 天生一对，能用 Rust 一行代码嵌入，能让 Agent 的记忆像人脑一样工作。

如果你也在做 AI Agent，或者对知识图谱感兴趣，记住这句话：“让你的数据有地址，让你的 Agent 有记忆，让你的系统有脑子。”

我这套系统叫 Gliding Horse（流马），所有代码都在 GitHub 上：https://github.com/doiito/gliding_horse

之前还写过为什么选 JSON-LD 以及为什么抄 CPU 缓存架构，感兴趣可以去翻翻。今天这篇是“Oxigraph 封神之路”，希望能帮你少走点弯路。