AI Agent知识图谱系统设计：给智能体装上世界模型 | 流马架构解析

前几篇文章聊了记忆系统（怎么记）、技能图谱（怎么干活）、工具系统（手脚怎么用）。今天聊一个更底层的东西——知识图谱。

你可能会问：“技能图谱不是已经能干活了吗？还要知识图谱干嘛？”

打个比方：技能图谱是“怎么开车”（踩油门、打方向盘、看后视镜），知识图谱是“你车开在哪个城市、哪条路上、目的地是哪”。没有后者，你就是一个车技很好但瞎开的老司机。

流马的知识图谱系统，就是给 AI Agent 装上了一个“世界模型”——让它知道自己身在何处，周围有什么，要往哪走。

一、知识图谱存什么？不只是“东西”，还有“关系”

传统 Agent 框架里，“知识”大多存成向量，靠相似度检索。这能解决“模糊搜索”，但解决不了“精确关系”。

比如：“帮我查一下张三的经理是谁”——向量搜索能给你一堆关于“张三”、“经理”的文档片段，但没法直接告诉你“张三 → 汇报给 → 李四”这个确定的关系。

流马的知识图谱用 Oxigraph 做底层存储，数据全是 RDF 三元组（主语-谓语-宾语）。比如：

<张三> <任职于> <研发部>
<张三> <汇报给> <李四>
<李四> <管理> <研发部>
<研发部> <属于> <ABC公司>

这玩意儿最牛逼的地方是：你可以在里面做逻辑推理。 问“研发部有哪些人？”→ 沿着 <任职于> <研发部> 反查。问“张三的老板是谁？”→ 沿着 <张三> <汇报给> ? 直接出结果。这在向量数据库里得绕半天。

更关键的是，知识的来源不止一种。 流马能自动从三种渠道填充这张图：

1. 非结构化文本：用户需求文档、聊天记录、设计文档 → LLM 自动抽取实体和关系（knowledge_extract 工具）
2. 代码文件：用 tree-sitter 解析 AST，9 种语言（Rust/Python/Go/Java…）→ 自动提取函数调用关系、类继承关系（knowledge_extract_code 工具）
3. 结构化 JSON：API 返回数据、配置文件 → 直接映射为 RDF 节点

而且代码解析做了增量更新。 文件 SHA256 哈希不变，直接跳过不解析，零开销。改动的文件才重新提取。

二、不是一张图，是五张图

流马的知识图谱不是一锅乱炖。它用 Oxigraph 的 命名图 机制分了五个区：

命名图	存什么	谁来写
graph:world	通用知识（需求、设计、对话中提取的实体）	LLM 抽取
graph:code	代码结构（函数、类、模块、调用关系）	tree-sitter AST 提取
graph:skill	技能图谱（怎么干活，5W2H 元数据）	SkillGraphStore
graph:ontology	本体定义（实体类型、关系类型）	系统预置 + 用户扩展
graph:bridge	知识-技能桥接（什么实体适用什么技能）	系统自动或手动创建

分开存有什么好处？

• 隔离：改代码不会污染需求文档的知识，Agent 各自读写自己的区，不打架。
• 高效：查技能时只查 graph:skill，不用在代码结构里翻垃圾。
• 可追溯：任何一条数据都知道“它是从哪来的”——因为命名图本身就是来源标签。

三、知识桥接：让“知识”和“技能”手拉手

这是流马知识图谱里最让我兴奋的设计——知识-技能桥接。

简单说：知识图谱存的是“什么是什么”（概念、实体、关系），技能图谱存的是“怎么干活”（步骤、依赖、工具）。

桥接层把这两张图连起来：

实体: 研发部
  └── [ontology:bridge/hasSkill] → 技能: 代码审查
  └── [ontology:bridge/applicableIn] → 场景: 需求评审

实体: Python 数据分析
  └── [ontology:bridge/hasSkill] → 技能: Pandas 数据清洗
  └── [ontology:bridge/hasSkill] → 技能: Matplotlib 可视化

这意味着：Agent 在处理任务时，不只是“调用一个技能”，而是能顺着知识图谱，自动发现“这个实体相关的技能有哪些”、“这个技能适用的场景是什么”。

比如用户说：“帮我分析一下研发部的代码质量。”Agent 沿着知识图谱找到 实体:研发部 → 沿着桥接找到 技能:代码审查 + 技能:静态分析 → 自动编排执行。

这就是“理解领域”和“执行指令”的本质区别。 前者是 Agent 自己在知识图谱里导航，后者是被动地接受一段上下文。

四、与记忆系统的结合：让知识“长记性”

知识图谱不是独立的——它和流马的四层记忆系统深度绑定：

• L0 持久化：所有知识节点存进 Oxigraph 持久化图，命名图归档。任务完成后，知识不丢。
• L2 黑板：当前任务相关的知识子图被投影到内存黑板，Agent 通过 SPARQL 实时查询。
• L3 投影：当 Agent 引用的实体不在 L2 时，L3 自动从 L0 加载相关子图（包括该实体的所有邻居、桥接的技能、历史关联记忆）。
• L1 上下文：只放知识实体的摘要和 IRI 引用，细节在图里按需加载。

举个例子：用户说“上次我们讨论的那个 JWT 认证项目，后来怎么设计的？”

1. Agent 在 L1 上下文里看到 project:auth-project 这个 IRI。
2. 查 L2 黑板，没有这个 IRI 的详情 → 触发 L3 投影。
3. L3 从 L0 拉出 project:auth-project 的知识子图：关联的实体（研发部、张三）、桥接的技能（JWT 认证、安全审计）、相关的记忆块（那几次讨论 JWT 的对话摘要）。
4. 把子图摘要注入 L1 上下文，Agent 秒回：“我们当时决定用 256 位密钥，有效期 24 小时……”

整个过程，LLM 上下文窗口只增加了几个 IRI 和摘要，Token 消耗几乎不变。

五、架构收益总结

维度	只有技能图谱	技能图谱 + 知识图谱 + 记忆系统
技能发现	靠 5W2H 匹配	5W2H + 知识实体关联 + 历史经验推荐
上下文理解	只看当前任务	理解任务相关的实体、人员、历史决策
经验复用	无	知识实体关联历史记忆，自动注入
跨领域关联	无	桥接层连接知识实体和技能，自动发现适用场景
代码理解	无	tree-sitter AST 提取，代码结构可查询
增量更新	无	SHA256 哈希跳过，零开销
Token 效率	全量加载	IRI 索引 + 按需投影，Token 消耗减少 70%+

六、最后说句人话

技能图谱教 AI “怎么干活”，知识图谱告诉 AI “这是什么、这跟什么有关、以前碰到过类似情况该怎么处理”。

两者一结合，AI 就不再是“照着菜谱炒菜的厨师”，而是“进了你家厨房、知道冰箱里有什么、记得你上次说太咸了这次少放盐的管家”。

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

之前还写过 JSON-LD、CPU 缓存记忆、Oxigraph、丰田安灯绳、技能图谱、工具系统…… 这个系列快写完了，下一篇可能是总结篇，聊聊把所有这些拼在一起，到底能做什么。