OpenClaw 进阶实战:用 Ontology 构建知识关系图谱

今天就来解决这个问题。

一、为什么需要知识关系图谱？

举个例子：

二、Ontology 是什么？

Ontology 是 OpenClaw 的一个技能，它的核心思路很简单：

三个核心概念：

用图来理解：

[张三] --负责--> [项目A] --依赖--> [项目B] --有任务--> [任务1]

[李四] --承担--> [任务1]                              截止：4月20日

有了这个图，你可以回答：

• 项目 A 被谁负责？→ 张三
• 项目 B 依赖什么？→ 项目 A
• 李四在做什么？→ 任务 1（属于项目 B）
• 任务 1 的截止日期？→ 4 月 20 日

这就是知识图谱的力量：从"信息孤岛"到"关系网络"。

三、五分钟上手：创建你的第一个图谱

第一步：初始化存储

在 OpenClaw 工作区创建 Ontology 存储目录：

第二步：创建实体

对 AI 说：

AI 会在后台执行类似这样的操作：

再创建一个项目：

第三步：建立关系

第四步：查询图谱

四、核心类型一览

Ontology 内置了丰富的实体类型，覆盖日常场景：

👤 人员与组织

💼 工作管理

📅 时间与地点

📄 信息资源

🔐 安全提醒

schema.yaml 中的安全约束

Credential:

五、实战案例：检察院项目管理图谱

以实际工作场景为例，构建一个数据项目管理图谱。

场景描述

• 需要查询到全省 186 家单位的距离
• 项目涉及多个任务、多个人员
• 需要追踪任务依赖和完成状态

第一步：创建人员和组织

对 AI 说：

第二步：创建项目和任务

第三步：建立关系

第四步：查询关系

现在你可以问各种关系型问题了：

六、进阶：约束与验证

定义约束规则

运行验证

如果有数据违反约束（比如任务状态写成了 "pending" 而不是 "in_progress"），验证会报错。

约束的价值

• 防止脏数据污染图谱
• 保证关系方向的正确性
• 检测循环依赖（项目管理中的大忌）

七、图谱可视化（脑补版）

虽然 Ontology 目前没有内置的可视化界面，但你可以用简单的方式"看到"图谱：

方法一：文本导出

AI 返回：

项目A (Project, active)

├─ has_owner → 张三 (Person)

├─ has_task → 任务1 (Task, done)

├─ has_task → 任务2 (Task, in_progress)

│    └─ has_owner → 李四 (Person)

│    └─ blocks → 任务3 (Task, open)

└─ has_task → 任务3 (Task, open)

方法二：导出为 Mermaid 格式

如果你想把图谱放到文档或网页中，可以让 AI 生成 Mermaid 图表代码：

graph LR

A[项目A] -->|has_owner| B[张三]

A -->|has_task| C[任务1]

A -->|has_task| D[任务2]

D -->|has_owner| E[李四]

D -->|blocks| F[任务3]

粘贴到支持 Mermaid 的编辑器（如 Typora、Obsidian、GitHub Markdown），就能看到可视化图谱。

八、与其他技能联动

🔗 与 Cron 联动：定期更新图谱

设置每天定时检查任务状态：

🔗 与百度搜索联动：补充外部信息

🔗 与 Memory 系统联动：同步长期记忆

九、最佳实践

✅ 推荐做法

• 从小做起：先建 3-5 个核心实体，验证流程走通后再扩展
• 统一命名：实体 ID 用有意义的格式（如 proj_001、task_api_config）
• 定期验证：每周运行一次 validate，保持图谱健康
• 追加不覆盖：修改实体时追加新记录，不删除旧记录，保留历史
• 关系要双向：如果 A 依赖 B，考虑同时记录 B 被 A 依赖（方便反向查询）

❌ 避免踩坑

• 不要在图谱中存储密码和密钥（用 secret_ref 间接引用）
• 不要创建过于复杂的关系网络（单项目关系超过 20 条就该拆分）
• 不要忽略约束验证（脏数据比没数据更危险）
• 不要把图谱当数据库用（超大场景建议迁移到 SQLite）

十、总结

觉得有用？关注公众号「私享斋」，更多实操文章持续更新。