夜雨聆风📌 一句话总结：你跟 AI 助手聊了半小时的项目，到第五条对话它就开始装失忆。一个 18.5万 下载的 Skill，把这事儿彻底解决。
最近评论区被问得最多的就是「我家龙虾也这样，聊几轮就忘了」。
绝大多数 AI 助手根本没有「记忆」，它们只有「上下文窗口」。窗口一滚动，记忆就清零。再大的上下文也就 200k tokens，用完一样抓瞎。很多人以为「我换了 1M 上下文的产品就解决了」——其实 1M 也只是把窗口拉长，窗口是先进先出队列，本质还是「塞历史」。
这个 Skill 在做什么
ontology 是 ClawHub 下载榜 Top 5 的常青树，作者 oswalpalash。18.5万 下载、1,072 真安装——安装一行：
openclaw skills install ontology
一句话：给 AI 助手一个带类型约束的「记忆仓库」。
普通「向量化记忆」把文本塞向量库，靠相似度搜出来——「这条有点像那条」。ontology 把信息套进带类型的关系图：人、任务、项目各是一类，用「A 负责 B」「B 阻塞 C」这种有语义的边连起来。15 种默认类型（人 / 项目 / 任务 / 事件 / 文档），也能自定义规则。
类型错了不让你存，关系断了不让你连。这个「强制体检」比所有「AI 请严谨」都管用。
实战演示
我自己的感受：30 秒就够验证。装好 ontology，跟 AI 说：「记住，我叫张三，是产品经理，负责商城项目，技术栈是前端加后端，3 月底上线。另外我的工作偏好是早上不开会、周三固定写代码、提测前必须自测。」
它自动把这段话拆成结构化数据。故意把状态字段写成「进行中」（不在默认枚举里），它直接拒绝保存——不是「温柔提醒」，是强制守卫。
下次不管隔几天、隔几条对话，你问「张三在做什么」——它走图遍历，秒答。
更直接的对比：你在群里给 AI 发了三个人的不同任务「张三负责选品算法、李四负责后端接口、王五负责前端界面」，下周问「选品算法谁在做」——它不会把李四或王五的事混进张三的。向量记忆因为都是文本相似度，搜「选品算法」经常返回所有三个人的事。
我自己用 ontology 做过两个真实场景。第一个场景是跟跨部门项目组成员对每周进度。我在 ontology 里建了「项目 - 任务 - 负责人」三层结构，每周更新一次「已完成的事」「下周的预期」。第六周回看这个图，能一眼看出「张三负责的测试任务已经在第 3 周逾期了 3 周」——如果用向量记忆，它就是一堆零散文字，得人工重新过一遍。
第二个场景是销售团队对客户信息的事实库。100 个客户、每个客户 5 个联系人、每个联系人 6 个沟通记录——这种「实体少但关系密集」的场景，ontology 跑得比任何向量库都稳。向量库会在「上次联系时间」这种结构化查询上翻车，但 ontology 走图遍历只要 30 毫秒以内。还有一点很冷酷：销售团队离职换人时，新人接手这个 ontology 5 分钟就能上手——这件事在向量记忆里几乎不可能。
内部机制
ontology 工作拆 3 步——定义类型、写入实体、建立关系，每步都强制校验字段类型，错了不让存。这跟雇人查简历一个道理：HR 不光看「有这个人」，还要看「这个人真的是工程师、真的是本科、真的没被开除过」。
跟普通「向量记忆」最关键的区别：ontology 不是搜索引擎，是「事实数据库」。前者靠相似度检索会编造——你问「张三上的哪个大学」，向量库会给你「和李四差不多的大学」；后者只回答它有证据的——你说过的就是你说过的，没说过的它直接说「不知道」。
它还有一个让企业用户心动的点：它不调外部 API，不上传数据。所有内容存在本地记忆目录，重启不丢。换句话说，公司内部的项目事实，可以放心让 AI 助手用，它不会把这些信息传出去。风险等级属于低——本地运行、零外网、无 token 消耗。
机制深一层：写错了可以追溯。它存的是「事件流」而不是「快照」——每次写入都是一个独立事件，包含时间戳、来源、字段值。3 个月前写错了一个事实，半年后想追溯谁写的、什么时候写的，都能告诉你「这是 6 月 3 日从某段对话提取的」。向量记忆看到的就是「一段文本」，你不知道它从哪里来的。
我的折中经验：默认类型宽松 + 关键类型严格。比如「任务」这种核心实体严格校验，但「文档」这种边角料留宽松。graph 增长失控也是真问题——半年后不清理几千个「过时事实」，查询性能会明显下降，初次加载都要等十几秒。
还有一个事我踩过坑：如果你自己写了 5 个自定义类型（比如「产品需求」「技术方案」「上线清单」），最好配套写一个「关系约束」——什么类型必须连接到另一个类型？比如「产品需求」必须关联到「技术方案」，「技术方案」必须关联到「上线清单」。不会自动帮你写这些关系约束，但你写完后整个图谱就「活」起来了——任何试图跳过中间环节的写入都会被拦住。
总结
推荐用，但场景要选对。
这 2 个场景值得优先装：第一，长期项目管理——多模块、多人协作、跨周迭代，记忆丢了就翻车；第二，团队协作的事实对齐——产品、技术、运营各说各的，每次开会重新同步一遍效率最低。
它不适合：临时聊天、灵感速记、单次问答。这几种场景塞上下文就够了，装 ontology 反而是「用大炮打蚊子」。还有一类场景——多人协作但所有人都想要「真实事实库」而不是「总结性描述」——ontology 是真有用。
它潜在的风险：graph 增长失控需要定期清理；类型定义本身会过期，比如「任务」字段业务变了，ontology 不会自动帮你做迁移；和其他 Skill 协同可能冲突，写入两边记录不一致；AI 助手「误读」你的意思，把不相关的事写进了同一个实体，导致后续查询返回错误关联。预防方法是定期审查 graph，人工剔除噪声。
还有一点对个人开发者尤其重要：ontology 不依赖任何外部服务、不需要额外付费额度、没有 token 消耗。所有数据本地存储，开发者可以随时打开看一眼「这个 AI 助手到底记住了什么」。这种透明度在金融、医疗、法律场景是硬要求——你不能让 AI 助手凭「相似度」编造一个事实出来。
规则你自己写——「每个任务必须有状态，状态只能是待办、进行中、已完成」——写完它替你挡。
它的底层哲学：AI 助手的长久价值，不是它能编多长的上下文，而是它能记住多少「真实发生过的事」。能力越大，责任越大。Agent 时代，记忆不再是「能聊多少」的代名词，而是「能信多少」的入场券。
