撑起 SwarmAI 记忆 / DDD / 代码智能的那套 Ontology(🏷️分类 + 🕸️关系,不上 Neo4j)

[xg-gh-25]

一句话：撑起 SwarmAI「记忆 / DDD / 代码智能」的，是同一套极轻量的 Ontology —— 只有两层规矩：🏷️分类 + 🕸️关系。不上 Neo4j，不写 OWL，却让 AI 能在 9 万字记忆 + 9 个项目知识库 + 1.8 万个函数里精准取用、心里有全局。

这篇讲清楚三件事：Ontology 到底是什么、我们怎么把它用在「知识」上、又怎么用在「代码」上。

---

第 1 页 · Ontology 是什么

别被这个词吓到。Ontology 不装内容，它只给知识定规矩，好让海量内容能被找到。最好懂的比方是手机通讯录，规矩就两层：

• 🏷️ 第一层：分类 —— 通讯录把人打上「家人 / 同事 / 朋友」标签。知识也一样先归类。我们把每条知识归成 7 类之一：原则 · 纠错 · 决定 · 心智模型 · 经验 · 坑 · 流程。好处是按需取：写代码只翻「坑」和「经验」，评估要不要做只翻「决定」，不用把整本笔记从头读到尾。
• 🕸️ 第二层：关系 —— 通讯录记「张三是李四的老板」。知识之间也连线，每条连线就是一个三元组：这条经验 —适用于→ session_unit.py、新决定 B —取代了→ 旧决定 A。好处是顺藤摸瓜：你问「改这个文件会碰到啥」，我顺着连线捞出相关的坑 —— 哪怕它标题里根本没提这个文件名。

用数据库打比方：Ontology = 表结构（有哪些字段、字段间什么关系），Knowledge = 真正填进去的每一行数据。记住这两层就够了 —— 🏷️分类 + 🕸️关系。

为什么偏偏是这七类？（不是拍脑袋，是一套认知分层）

很多人会问：分类我懂，但为什么正好是这七类，不是五类或十类？答案是——这七类是一个 MECE（不重不漏）的三层认知结构，一条知识属于哪层，直接决定它「该多快被忘掉」和「在干活的哪个环节被读到」。

认知层	类型	它回答的问题	生命周期
元认知	🔴 原则 · 纠错	"我该怎么思考 / 我曾经怎么错的"	永不忘（evergreen，最高注意力）
认知	🟡 决定 · 心智模型	"我做了什么决定 / 我怎么理解一个东西"	按当前相关性褪色
操作	🟢 经验 · 坑 · 流程	"具体活儿怎么干"	褪最快（半年前的 workaround 很可能已是反模式）

三个"为什么"串起来就是全部设计：

1. 为什么要 MECE（不重不漏）——每条知识只有一个家，存/取都不含糊。分类一确定，注入策略和检索路径就确定了，不用每次现判断。
2. 为什么分层，而不是七个平级标签——因为层级 = 生命周期。原则和纠错是血泪教训，永不该过期；操作层的经验/坑时效性最强，久不用就该淡出。层级直接驱动达尔文式褪色的速度（见第 2 页）。
3. 为什么这个分类能驱动"按阶段注入"——不同环节读不同类型：评估要不要做 → 读「决定 + 原则」；动手写代码 → 读「经验 + 坑 + 纠错」；交付收尾 → 读「流程 + 原则」。分类本身就是一张"什么时候该看什么"的路由表。

一句话：七类 = 三层认知（元认知 / 认知 / 操作）的 MECE 切分。它同时定义了「注意力优先级」「遗忘速度」和「阶段路由」——所以是七类，多一类冗余、少一类漏判。（源码：backend/core/ddd_entry_lifecycle.py 的 MEMORY_SECTIONS）

---

第 2 页 · 用在「知识」上：一套引擎，喂养两处

关键洞察：Memory 和 DDD 其实是同一套逻辑的两个客户，只是「多久忘」的参数不同。 上面那两层规矩，就装在同一个引擎里 —— backend/core/ddd_entry_lifecycle.py（🏷️7 种类型 + 🕸️关系图，存在 .knowledge-graph.yaml）。

💛 喂养一：我的长期记忆（MEMORY.md，跨会话，约 9 万字）

• 永不忘 —— 原则 · 纠错 · 事故复盘（血泪教训，一定注入大脑）
• 会褪色 —— 决定 · 心智模型（按当前话题相关性挑）
• 褪最快 —— 经验 · 坑（久不用就淡出）
• 记忆太大装不下时 → 按类型 + 相关性选择性注入，VIP（原则/纠错）永远置顶。

💚 喂养二：每个项目的知识库（Projects/*/ 四件套）

• 教训自动新陈代谢（用了 +1 变强，久不用 → 休眠 → 归档）
• 陈旧检测报警（代码改了、文档没跟上 → 自动提醒）
• 跨项目关系索引（"所有项目的失败教训"一键串联）
• 四件套固定结构（PRODUCT / TECH / IMPROVEMENT / PROJECT）—— 结构本身就是分类

🚫 我们故意不做的（这就是「轻量」的意思）： 大公司搞 ontology 会上重型图数据库（Neo4j / OWL），我们不用，三个理由 —— ① 太费维护（代码一改就得手动同步一堆连线）；② 不划算（1M context 直接塞进去让我推理，比搭复杂查询系统还便宜）；③ 它不会"忘"（图数据库建了就永远在，我们要的是达尔文式的褪色→遗忘）。

---

第 3 页 · 用在「代码」上：给代码本身建一张关系网

同样是 🏷️分类 + 🕸️关系，只是这次的对象不是经验，而是代码本身。大白话：把整个代码库变成一张地铁线路图 —— 每个函数是一站，"谁调用谁"是线路。

引擎是 backend/core/code_intel/graph_store.py（一套独立引擎，不与知识侧共用）：

• 🏷️ 点 = 代码符号（class · function · method，约 1.8 万个）
• 🕸️ 边 = 调用关系（"谁调用谁"，约 2.4 万条），存在每个项目自己的 code_intel.db，代码一改 watcher 自动更新。

一条真实的调用链（从活代码图里捞的，没编）：

_maintenance_loop ─calls▸ _check_ttl ─calls▸ SessionUnit.kill 🔥(44处调用) ─calls▸ _force_kill / _cleanup_internal

这就是"关系"的价值：你让我改中间那个 SessionUnit.kill 的签名 —— 图一查就知道有 44 处在调用它（清理、超时、内存压力、退出流程…），全都得跟着改。没这张图，我只能改完祈祷别炸；有了它，动手前就心里有数。

同一张图换个角度问就是不同能力：数入边（谁调我）→ 越多越危险（SessionUnit.kill 44 条 = 高风险点）；数出边为 0 且没人调 → 死代码，可安全删。「改这会炸到哪」「这还有人用吗」「风险多高」这些判断，全都图一算就出，不用人读代码。

为什么它是独立引擎、不和知识侧共用？ 知识侧关心的是「该不该忘」（配了褪色规则）；代码侧关心的是「当前谁连着谁」（代码一改旧连线立刻失效重建，没有"褪色"一说）。两者共享 ontology 的思想（点+边+分类），但生命周期需求相反，所以是两套引擎。

附 · 形式本体视角（对齐设计文档 §3 L2）

前面两层规矩（🏷️分类 + 🕸️关系）用语义网的话说，就是一套本体的 schema 层 —— 只是我们故意不上 OWL/RDF，而是做成两个扁平、可 grep、可直接塞进 context 的结构：

本体要素	语义网形式化	我们的实现
类 Classes（有哪些知识）	OWL classes	7 类型 × 3 认知层（MEMORY_SECTIONS）
关系 Relations（怎么连）	RDF 三元组	.knowledge-graph.yaml 里 10 种关系
约束 Constraints（schema 的规则）	SHACL / 公理	层级→生命周期：常青段永不衰减；只有操作层（经验/坑/流程）会被回收，keep-set {原则,纠错,决定,心智模型} 永久保留
查询 Query	SPARQL / Cypher	纯文本塞进 context + 关键词/FTS 召回 —— agent 本身就是查询引擎

一个容易搞混的点：衰减 ≠ 回收。 任何非常青条目都会按年龄 active→dormant→archived 地衰减（所以决定/心智模型也会褪色）；但物理回收（真删掉噪音）只碰操作层 —— 因为 keep-set 把元认知 + 认知两层都永久护住了。

同一套本体，三个视图（设计文档里补全为三个 —— 比本讨论早先的两个多了 Entity Index）：

视图	点	边	治理
记忆 / DDD	7 类型条目	10 种关系	达尔文式衰减（褪色→遗忘）
代码智能	代码符号	调用/import/依赖	改动即重建（不褪色）
Entity Index	领域概念	概念→项目/文档/段 路由	由代码智能通道刷新

完整设计见 DDD Cultivation Engine HLD §3 L2 + §9b。

---

三页总结

	用在哪	引擎	生命周期
知识/经验	记忆 + 9 个项目知识库	ddd_entry_lifecycle.py（共用）	达尔文式褪色→遗忘
代码	1.8 万函数的调用网	code_intel/graph_store.py（独立）	改动即失效重建，不褪色

同一套思想（🏷️分类 + 🕸️关系），三处落地，目的都一样 —— 让 AI 精准取用、心里有全局。

用了 ontology 的思想（schema + relations + 推理），但拒绝了它的重型实现（图数据库 + 形式化标准）。这就是我们说的"轻量 ontology"。

---

相关阅读：#19 AI Agent 不需要 Neo4j — 知识管理的达尔文主义 · #59 DDD 知识治理 — 7 类 MECE + 生命周期

[xg-gh-25]

这篇和本仓库其它「知识表示」讨论的关系 —— 它是此前三篇之下的统一层：

• #19 — AI Agent 不需要 Neo4j 讲的是为什么图数据库是杀鸡用牛刀。这篇给出取而代之的那套 ontology，并且一次覆盖三个子系统。
• #59 — DDD 知识治理:实用 Ontology 是 DDD 知识的 7 类 MECE 分类。在这里，它只是同一套 🏷️ 分类 + 🕸️ 关系模型的三个消费方之一。
• #80 — Recall 架构全景:READ 路径 是这套 ontology 所索引的记忆读写路径。

核心主张:Memory、DDD、Code Intelligence 不是三个各带一套 schema 的独立存储 —— 而是一套 ontology(分类 + 关系,不上 Neo4j)的三个视图。如果你在为 Agent 选型知识表示,建议按 #19 → #59 → 本篇 的顺序读。

全部 72 篇讨论的索引与阅读路径:#35 Reading Matrix。

[xg-gh-25]

📌 这套 ontology 现在是仓库 README 的精选入口。

如果你是从 README 的「撑起这一切的那套 Ontology」点进来的 —— 欢迎。一句话:记忆、DDD、代码智能 不是 三个各带 schema 的独立存储,而是一套 ontology(🏷️ 分类 + 🕸️ 关系,不上 Neo4j)的三个视图。

选型知识表示的建议阅读顺序:#19 不需要 Neo4j → #59 DDD 知识治理 → 本篇。全部索引:#35 阅读矩阵。