一 · 四个被混用的「本体」
哲学本体论 / 形式本体 / 语义层 / 操作本体
所有关于本体的争论，第一步都错在同一件事：把四个不同的东西叫成了同一个名字。这一章把它们拆开，给每个东西一个可验收的标准和一个典型的失败样子，然后给一个五问判别流程。
四种「本体」，四种验收标准
| 谁在用 | 交付物 | 验收标准 | 失败的样子 | |
|---|---|---|---|---|
| 哲学本体论 | 分析哲学、信息科学、部分国防与医疗标准 | 范畴清单（上层本体） | 争议可被引用、范畴能互相定义 | 永远吵不完，产不出一行代码 |
| 形式本体 | W3C、生物医学、图书馆情报 | OWL 文件 + 稳定 IRI | 逻辑一致、可被推理机分类 | 推理完美，但没人查、没人改、三年后无人能懂 |
| 语义层 | BI、指标平台、财务 | 指标定义 + 维度 + 口径 | 同一指标在任何报表里是同一个数 | 两套口径并存，对账会开成政治会议 |
| 操作本体 | 数据平台、Agent 系统 | 对象类型 + 链接 + 动作 + 权限 | 非法写入被拒、变更可审计可回滚 | 退化成 ER 图 + 一堆没人调的接口 |
这四件事经常被同一个项目同时许愿，但它们的技术前提互相冲突。下面逐条说清楚。
一、哲学本体论：它产出的是「该拆到哪一层」
哲学上，本体论研究「存在什么」。工程上借用这个传统，是为了回答一个很实际的问题：一个概念该继续往下拆，还是到此为止？
Quine 的那句判词最常被引用：to be is to be the value of a variable——一个东西存在，当且仅当它需要被量化。翻译成工程语言：如果没有任何一条陈述需要单独指称它，它就还不该成为一个类。
上层本体（BFO、DOLCE、SUMO）的价值不在于公理数量，而在于它们提供了一套分工协议：哪些词属于「独立 continuant」，哪些属于「依赖 occurrent」，哪些是「质量」而非「对象」。有了这套协议，两个团队各自建的模型才有可能对齐。
但它在工程上有两个硬限制：
- 上层本体不产生可执行的东西。你没法拿 BFO 去校验一条订单记录。
- 上层本体的争议是真实存在的、且在短期内不会收敛。把项目成败押在「选对上层本体」上，是把哲学争论引入交付周期。
可用产出：一张范畴清单，加每条范畴的边界反例。例如「客户是角色还是实体」——如果同一个法人在不同业务里既是客户又是对手方，那它是角色，挂在一个「法人」实体上。这类决定一旦写下，能省掉后面几个月的返工。
二、形式本体：它产出的是「隐含事实」
形式本体是 OWL 那一套。核心机制是 TBox / ABox 二分：术语公理（类、属性、包含关系）与断言（个体属于哪个类、有什么值）分开存放，推理机从公理中导出断言里没有写的事实。
三个必须理解的性质：
- 开放世界假设（OWA）：没说「不是」，就不等于「是」。因此「没填 owner」不等于「没有 owner」，而是「未知」。这一条会让所有从 SQL 转过来的人第一次踩坑。
- 无唯一命名假设：两个 IRI 可以指同一个东西，除非显式声明不同。这带来对齐的自由，也带来去重的麻烦。
- 可判定性是有代价的：表达力越强，推理越慢甚至不可判定。这就是 OWL 2 分出 EL / QL / RL 三个 profile 的原因。
形式本体的验收标准是逻辑一致，不是「有用」。这两个标准可以同时成立，也可以完全脱钩：一个本体可以完美一致，同时没有任何系统消费它。这是生物医学之外，形式本体最常见的结局。
三、语义层：它产出的是「同一个数」
语义层的目标极其朴素：同一个指标，在任何地方都是同一个数字。
它和形式本体的技术前提正好相反：语义层默认封闭世界（没记录就是没有）、要求唯一命名（一个指标一个 ID）、并且必须能对账（每个数字能追到一条 SQL 或一张源表）。
判据只有一条，但非常锋利：当两个部门对同一个指标给出不同数字时，你能不能在三十分钟内定位到分歧发生在定义、口径、还是数据？ 能，就有了语义层；不能，就只是有了一堆图表。
语义层的失败方式也很有辨识度：指标越建越多，血缘越来越长，最后没人敢改任何一个定义，因为不知道谁会炸。这直接引出了第五章的治理问题。
四、操作本体：它产出的是「一次被拒绝的写入」
这是 2026 年真正热的那一个，也是 Palantir 模式被反复复刻的原因。它有四条性质，建议直接当验收清单用：
- 语义对象与链接。对象类型不是表，链接不是外键——链接本身带语义（「供应」「担保」「归属」），可以带属性，可以多对多。
- 动作门控写入。所有写操作必须经过一个声明式动作：动作声明参数、前置条件、副作用、权限；没有绕过动作的直接写入。
- 规则挂在动作上。校验不是独立跑的报表，而是动作的前置条件——不满足就不执行，而不是执行完再报警。
- 写回权威源。本体不是新的真相源，它把变更写回系统 of record，自己保留语义与审计。
这四条里，第 2 和第 3 是分水岭。绝大多数自称「操作本体」的项目只做到了第 1 条，本质上是一个带类型的图数据库。
为什么会混：三组同形不同义的词
| 词 | 形式本体里 | 关系库里 | 操作本体里 |
|---|---|---|---|
| 类 | 由公理定义的集合，成员可推理得出 | 一张表的结构 | 对象类型：一组属性 + 一组允许的动作 |
| 关系 | 二元关系，可带定义域值域约束 | 外键，约束引用完整性 | 链接类型：带语义、带属性、可被查询与授权 |
| 规则 | 公理，产生新事实 | 约束、触发器 | 策略：作用于动作，可版本化、可审计 |
把这三列混着说，会得到看起来很完整、实际无法实现的需求文档。例如「用 OWL 表达权限」——权限是策略，作用于动作，需要版本与审计；OWL 能表达「谁属于哪个组」，但表达不了「这次操作在昨天生效的策略下是否被允许」。
一个五问判别流程
按顺序问，第一个「是」决定你该做哪一种：
- 你要解决的是「同一个词有两个意思」，还是「同一个数字有两个值」？ 前者指向形式本体/术语表，后者指向语义层。
- 需不需要从已有事实推出新事实？（例如「有心脏」推「是脊椎动物」）需要，才值得上推理机。
- 需不需要拒绝一次写入？ 需要，就必须有可执行约束（SHACL 一类），且必须放在写入路径上。
- 需不需要回答「在某个历史时点上，它是什么样」？ 需要，就要求双时态或版本化存储，这会淘汰掉大部分图库。
- 谁维护它？ 如果答案是「项目组，上线后移交给业务」，那么请把表达力降到最低——移交出去的本体，表达力会随时间单调衰减。
结论：2026 年热的是第四个
这轮热度的实质不是「大家开始重视语义」，而是Agent 需要一份可执行的语义。
模型不缺知识，缺的是边界：哪些对象存在、它们之间允许什么关系、什么操作合法、操作失败时该退回哪一步。这正好是操作本体的四条性质。而形式本体的那套东西——公理、一致性、可判定性——在这条需求上几乎不出场。
这个判断有代价：它意味着这一轮的技术债会在「表达力不足」上积累。当业务开始问「能不能推出这个」，而你的对象模型只能查不能推时，你会需要一个真正的本体层。推断：合理的顺序是先建可执行的约束层，再在需要推理的地方局部引入形式本体，而不是反过来。