01 什么是 Ontology：从一张表到一个业务世界
适合谁读：第一次接触"本体（Ontology）"的产品、业务、数据和工程同学。读完你应该能用自己的话讲清楚：本体是什么、它从哪里来、为什么今天企业又开始谈它。
1. 先看一张表
假设你刚加入一家电商公司（下文称"示例商城"），拿到售后数据库里的一张表：
| order_id | user_id | sku_id | status | amount | refund_flag | updated_at |
|---|---|---|---|---|---|---|
| O-1001 | U-88 | S-301 | 5 | 299.00 | 1 | 2026-10-12 |
| O-1002 | U-88 | S-517 | 3 | 59.90 | 0 | 2026-10-13 |
这张表"什么都有"，但你几乎什么都不知道：
status = 5是"已签收"还是"已完成"？客服系统里的"已完成"和财务口径的"已完成"是一回事吗？refund_flag = 1表示"申请过退款"、"正在退款"还是"已退完"？部分退款算不算？user_id指向的"客户"，和会员系统里的"会员"、客服工单里的"联系人"是不是同一个人？- 最关键的：如果我要"给这笔订单发起退款"，应该改哪几张表、调哪个接口、要谁批准？
老员工靠经验回答这些问题；新同事要问一圈；而一个 AI Agent（能自己调用工具完成任务的大模型程序）只能"猜"。本体要解决的，就是把这些藏在人脑、代码和文档里的业务含义，写成一份人和机器都能读懂、而且能被执行的共同说明书。
2. 一句话定义
本体（Ontology）：对某个业务领域的一份明确、共享、可被机器处理的描述——这个领域里有哪些东西、它们有什么特征、彼此是什么关系、能被怎样改变、以及必须遵守哪些规则。
拆开看，有三层意思：
- 像词典：统一说法。"订单""售后单""退款"各指什么，一次讲清，所有系统和团队共用。
- 像地图：讲清关系。客户"下了"订单，订单"包含"订单行，订单行"对应"商品，售后单"针对"某个订单行……你可以沿着关系一路走下去。
- 像操作手册：讲清动作和规矩。"发起退款"需要什么参数、满足什么前置条件、谁有权做、做完会连带改变什么。
很多入门材料只讲前两层（词典 + 地图）；而近几年企业实践，尤其是 Palantir 一类平台，把第三层（动作、规则、权限）也算进本体。本系列采用后一种"宽口径"，但会在需要时说明区别（详见第 04 篇）。
2.1 定义里的三个关键词
定义里有三个词值得逐个推敲，它们分别排除了三种"看起来像本体、其实不是"的东西：
- 明确：写下来，而且没有歧义。只存在于老员工脑子里的"行规"不算；写在 PPT 里但"已完成"一词有三种解释，也不算。明确意味着每个概念都有一句准确的定义、每条关系都有方向和数量约束。
- 共享：被多个团队、多个系统共同认可和使用。如果售后组有一套"售后单状态"、财务组另有一套，各自都很明确，也只是两份私有词典，而不是本体。共享往往需要有人拍板，这是本体项目里最难的部分之一（见第 02、08 篇）。
- 可被机器处理：不仅人能读懂，程序和 AI 也能读取、校验、执行。一份写得再好的 Word 版业务手册，机器也无法据此拦下一笔超额退款；而本体里的规则可以在"发起退款"时被自动检查。
三个词合在一起，才让本体既是"大家说同一种话"的工具，又是"系统按同一套规矩办事"的基础。
3. 名字从哪里来：哲学源头
"Ontology"原本是哲学词汇，研究的是"什么东西存在、存在者可以怎样分类"。古希腊的亚里士多德提出过"范畴"——实体、数量、性质、关系、时间、地点等——试图给世间万物找一套最基本的分类框架。中文把它译作"本体论"，"本体"一词在中国思想史里也早有使用，指事物的根本。
20 世纪的哲学家蒯因（Quine）提出过一个对今天很有启发的说法，常被概括为"本体论承诺"：你选择用什么词汇来描述世界，就等于承认了哪些东西"存在"。放到企业里：如果你的系统里根本没有"售后单"这个概念，只有订单表上的一个 refund_flag，那么"售后单"在你的系统里就"不存在"——它的状态、历史、责任人也就无处安放。
记住这一点就够了：本体首先是一种"承认什么存在"的选择，而不仅仅是技术格式。
4. 进入计算机科学：从"概念化"到 OWL
计算机科学借用这个词，是从知识工程和人工智能开始的。几个值得知道的里程碑：
- 1993 年，Gruber 的经典定义：斯坦福的 Thomas Gruber 在论文里写道，本体是"对概念化的明确规约"（an explicit specification of a conceptualization）。"概念化"指为了某个目的，对世界做的一种抽象、简化的看法；"明确规约"指把这种看法用术语、定义和公理（必须成立的逻辑约束）写下来，让不同系统可以共享和复用。他同时指出：对知识系统来说，"存在"的就是"能被表示"的。
- 2001 年前后，《Ontology Development 101》：斯坦福的 Noy 和 McGuinness 写了一份影响很大的入门指南，用"葡萄酒与菜品"做例子，把本体说成"对某个领域中概念（类）、概念的特征（属性）以及对属性的限制的形式化明确描述"；本体加上一组具体实例，就构成"知识库"。他们强调三条原则：建模没有唯一正确答案、建模必然是迭代的、概念应当贴近领域里的对象和关系——描述领域的句子里，名词多半对应对象（类），动词多半对应关系。注意：本系列沿用 Palantir 的说法，把"动作"称为动词、把关系归入名词层，和 101 的用法不同。第 06、07 篇的方法会大量借用它。
- 语义网标准：W3C（万维网联盟）先后发布了 RDF（用"主语—谓语—宾语"三元组表达事实的数据模型）、OWL（Web 本体语言，带有形式化含义，可以做逻辑推理）、SHACL（形状约束语言，用来校验数据是否符合预期结构）。OWL 2 在 2009 年成为 W3C 推荐标准，2012 年发布第二版；SHACL 在 2017 年成为推荐标准。
这一时期的本体，重心是"表达含义、支持推理、跨组织共享"，典型应用在医学术语、生物信息、图书情报、金融监管词表等领域。
5. 进入企业：从"描述世界"到"运行世界"
最近几年，"本体"这个词在企业软件圈重新变热，很大程度上和 Palantir 有关。Palantir 在官方文档里把它的 Ontology 定位为"组织的运营层"：它坐在已经接入平台的数据集、虚拟表和模型之上，把它们连接到现实世界中的对应物——工厂、设备、产品，乃至客户订单、金融交易这类概念——在很多场景下充当组织的"数字孪生"（对现实业务的数字化镜像）。
关键在于，Palantir 把本体拆成两类元素：
- 语义元素：对象、属性、链接（关系）——回答"世界里有什么"；
- 动能元素（kinetic）：动作、函数、动态安全——回答"世界能怎样被改变、由谁改变"。
它的另一份文档说得更直白：本体表达的是企业的决策，而不只是数据；每个业务决策由数据、逻辑、动作、安全四部分组成。微软的 Fabric IQ 也推出了本体能力（截至本文写作仍为预览版），把它描述为"对业务的一种共享、机器可理解的表示"，包含实体类型、属性、关系、规则、指标，并通过"数据绑定"连到企业真实数据上，供人、应用和 AI Agent 使用同一套词汇。
于是今天谈"企业本体"，通常指的是一个运行时的业务模型：它不只解释数据，还约束和承载业务动作。
6. 从一张表到一个业务世界
回到开头那张表。用本体的眼光重新整理，它会变成下面这样（这是贯穿本系列的电商售后例子，第 10 篇会完整搭一遍）：
变化有三点：
- 表变成了对象。不再是"订单表的一行"，而是"一个订单"，它有稳定的身份（主键）、有含义明确的属性（例如"订单状态"，取值是"待支付 / 已支付 / 已发货 / 已签收 / 已完成 / 已关闭"这样带名字的枚举，而不是数字 5）。
- 外键变成了关系。"订单行对应商品"不再是一次技术上的表连接（Join），而是一条有名字、有方向、有数量约束的业务关系：一个订单行恰好对应一个商品。
- 散落的逻辑变成了动作与规则。"发起退款"成为一个正式定义的动作：输入是哪个售后单、退多少钱；前置条件是"退款金额不超过可退金额"；执行者必须有相应权限；执行后售后单状态改变、退款单被创建、客户收到通知，并留下审计记录。
7. 本体不是什么
为了避免一开始就形成误解，先划几条边界（细节见第 05 篇的对比）：
| 常见误解 | 实际情况 |
|---|---|
| 本体就是数据库表结构 | 表结构描述"数据怎么存"，本体描述"业务是什么、能做什么"；一张表可能对应多个对象，也可能只是一个关系 |
| 本体就是知识图谱 | 知识图谱更偏"具体事实的网络"（张三买了某商品）；本体更偏"世界允许怎样被描述"的蓝图，两者常配合使用 |
| 本体就是一个产品或平台 | 本体是一种建模成果和方法；同一份本体可以用 OWL、YAML、平台元数据等多种形式落地 |
| 有了本体，AI 就不会出错 | 本体能大幅减少"理解错"和"做错事"，但不解决数据质量问题，也不能替代业务专家判断（见第 08 篇） |
| 本体越全越好 | 本体是现实的抽象，不是现实的镜像；范围应由要回答的问题决定（见第 06 篇） |
8. 三种常见口径
不同文章说"本体"时，指的东西大小不一。读资料时先分辨对方用的是哪种口径：
| 口径 | 包含什么 | 典型出处 | 适合场景 |
|---|---|---|---|
| 窄口径（静态本体） | 类、属性、关系、公理 | 语义网、OWL 教程 | 术语统一、跨组织数据交换、推理 |
| 中口径（指标语义层） | 业务实体与维度 + 指标、口径、数据映射（通常不含公理与推理） | 数据分析类 Agent、指标语义层产品（如 dbt MetricFlow、Cube） | 问数、报表、Text-to-SQL（把自然语言问题翻译成 SQL） |
| 宽口径（运营本体） | 对象、属性、关系 + 数据映射 + 动作、函数、规则、权限、审计 | Palantir、Fabric IQ、国内本体平台 | 让人和 Agent 在受控条件下"把事办了" |
本系列默认使用宽口径，并把它分成两半：名词层（对象、属性、关系；Palantir 称为语义元素）与动能层（动作、函数、规则、权限）。注意：这里的"名词层"不是上表中的"指标语义层"，后者特指管理指标口径的产品。第 04 篇会逐个展开。
还有一个容易混淆的用法：在物联网和数字孪生领域，例如微软的 Azure Digital Twins，"本体"指的是一整套用 DTDL（数字孪生定义语言）写成的模型集合，用来描述楼宇、能源、制造等行业里的设备与空间；官方建议的做法有四种——直接采用行业现成本体、在其上扩展、从其他格式转换、或自己从头编写。微软文档也特意说明，这和 Fabric IQ 里的"本体"不是同一个东西。可见同一个词，在不同产品里大小和形态都不同；读到"本体"二字时，先问一句"它包含哪些要素、用来干什么"，比纠结名字更有用。
8.1 一条连续谱：你的数仓里已经有一部分本体
读到这里，你可能会问：我们已经有数据仓库，也有统一的报表口径，这些和本体是什么关系？一个好用的看法，是把企业的数据模型放在一条连续谱上：
业务数据库 → 维度模型 → 指标语义层 → 本体
每往右走一步，就有更多原本藏在人脑子里、写在文档里的业务含义，被写成机器能读懂、能执行的结构。
| 阶段 | 显式写下了什么 | 示例商城的样子 | 还缺什么 |
|---|---|---|---|
| 业务数据库 | 表、字段、主键外键、非空等约束 | 售后申请表 refund_apply；status=5 是什么意思要去问开发 | 业务含义几乎都在文档和人脑里 |
| 维度模型 | 事实、度量、维度、粒度、层级、一致性维度 | 退款事实表按"订单行 × 天"记录退款金额；商品维度有"品类 → 子品类 → 商品"层级 | 主要服务分析，不描述动作和规则 |
| 指标语义层 | 指标公式、聚合方式、可用维度、口径和权限 | "退款率"统一定义，所有报表算法一致（第 05 篇第 4 节） | 只管"这个数字怎么算" |
| 本体 | 对象、关系、状态、规则、动作、权限 | 售后单针对订单行；超过阈值的退款要审批 | 需要持续治理（第 07、08 篇） |
维度模型里的几个词，用示例商城翻译一下：
- 事实（Fact）：业务过程中发生的一件件事，比如"一笔退款成功了"。
- 度量（Measure）：事实上可以加总的数字，比如退款金额。
- 维度（Dimension）：看事实的角度，比如时间、商品、客户、渠道。
- 粒度（Grain）：一行事实到底代表什么。示例商城的退款事实以"订单行"为粒度，而不是"订单"；粒度定错了，一单退一件的情况就会被算成整单退款，退款率随之失真。
- 层级（Hierarchy）：维度内部的上下级，比如"年 → 季度 → 月 → 日"、"品类 → 商品"。
- 一致性维度（Conformed Dimension）：多张事实表共用同一份维度。销售和退款都用同一张"客户"维度，两边的数字才能放在一起比。
这些都不只是存储技巧，它们已经在回答"业务里有什么、怎么关联、怎么汇总"。所以，一个设计良好的数仓里，本体的一部分其实已经存在了：一致性维度几乎就是对象类型的雏形，粒度声明就是对"一行代表什么"的定义，维度层级就是一种关系。建本体时不必从零开始，可以先把这些已有约定整理出来（第 05 篇第 15 节讲了怎样从已有资产长出本体）。
关键不是"表还是图"，而是"事实还是意义"。 讨论本体时，常有人把问题变成"关系数据库好还是图数据库好"。其实表和图都能存事实：订单表里一行"O-1001，客户 C-88"，和一条"C-88 下单 O-1001"的三元组（主语、谓语、宾语形式的一条事实），说的是同一件事。真正的区别在于，这条事实背后的意义有没有被写下来："下单"是客户与订单之间的一种关系；一个订单只属于一个客户；两个账号归并成同一个客户后，订单要跟着归到这个人名下；只有下单的客户本人或有权限的客服，才能对它申请售后。这些意义写清楚了，数据存在表里还是图里都可以；没写清楚，换成图数据库也只是换了个地方存数字。
9. 本系列的例子与约定
为了让概念落地，十篇文章都围绕同一个虚构的"示例商城"售后业务展开。它足够常见，几乎每个人都有退货退款的经历；又足够复杂：一笔订单可能拆成多个包裹，一个售后单可能只退其中一件商品，退款要经过支付渠道原路返回，客服、仓库、财务、主管各有各的权限。文中出现的金额阈值、退货时限等都是示例规则，用来说明建模方法，不代表任何平台的真实政策。
术语上，本系列固定使用以下说法：对象类型（一类东西的定义，如"订单"）与对象（具体某一个，如订单 O-1001）；属性；关系；动作；函数（只计算、不改数据的逻辑）；规则；权限。核心术语第一次出现时都会配一句白话解释，完整术语表见第 10 篇。
10. 一张对照表：同一件事的两种说法
把第 6 节的变化再落细一点，看同一条业务信息在"表的世界"和"本体的世界"里分别怎么表达：
| 业务信息 | 表的世界 | 本体的世界 |
|---|---|---|
| 这笔订单已签收 | order.status = 5 | 订单.状态 = 已签收；签收时间来自物流系统的签收记录 |
| 这单申请过退款 | order.refund_flag = 1 | 存在至少一个针对该订单某个订单行的售后单（任意状态）；它当前处于哪个状态、已经退了多少，分别由售后单和退款单回答 |
| 这位客户是老会员 | user.level = 3 | 客户.会员等级 = 金卡；它是一个会变化的资格，不是另一类客户 |
| 退款不能超过实付 | 写在某个服务的代码里 | 规则 R01：订单行累计退款不超过实付金额，被"创建售后单""发起退款"两个动作引用 |
| 客服可以发起退款 | 客服后台有一个按钮 | 动作"发起退款"：一线客服在阈值内可执行，超阈值需主管审批；AI 客服对它只有建议权（AI 可以"申请"创建售后单，但不能发起退款，见第 07 篇） |
可以看到，右列并没有发明新的数据，它做的是三件事：给数据起业务名字、把隐含的关系和规则写出来、把"谁能做什么"变成定义。这也是后面各篇反复使用的思路。
11. 读完这一篇，你可以做的小练习
拿你熟悉的一张业务表，回答三个问题：
- 这张表的每一行，是一个"东西"（对象）、一段"关系"，还是某个时刻的"快照"？
- 表里有没有用数字或缩写编码的状态？它们在业务上各叫什么、能怎样流转？
- 业务上最常对这类数据"做"的一件事是什么？做这件事需要谁同意、会连带改变什么？
如果你答不上来，或者不同同事答案不一样——这正是本体要发挥作用的地方。下一篇（第 02 篇）讲企业为什么愿意为此投入。
12. 常见问题
问：本体和我们常说的"数据模型"有什么区别？
数据模型（例如 ER 图、表结构设计）主要回答"数据怎么组织、怎么存"，服务于开发和存储；本体主要回答"业务世界里有什么、能做什么"，服务于人、应用和 AI 的共同理解。两者有很大重叠，一个好的数据模型往往是建本体的重要素材，但本体还会包含数据模型通常不管的东西：业务含义、规则、动作、权限，以及跨系统的统一身份。
问：做本体必须用 OWL 这类语义网技术吗？
不必须。OWL 和 SHACL 是成熟的国际标准，适合需要严格推理、跨组织交换的场景。企业实践里，本体也常用 YAML、JSON、平台自带的元数据或者干脆用表格来写。有实践者说过，本体不依赖某种数据库，用 Excel 也能起步。选什么形式，取决于你要不要推理、要不要和外部交换、团队熟悉什么。
问："本体"和"本体论"是一回事吗？
在哲学里，"本体论"是一门研究存在的学问；在计算机和企业语境里，"本体"通常指某个具体领域的一份模型，比如"示例商城售后本体"。日常交流中两个词常被混用，本系列统一用"本体"指后者。
问：本体和"知识库"是什么关系？
按《Ontology Development 101》的说法，本体加上一组具体的实例，就构成了知识库。也就是说，本体是"结构和规则"，知识库是"按这个结构填好的内容"。在企业里，实例往往不必复制到本体系统中，而是留在业务系统里，由本体负责解释和连接（第 05 篇详述）。
问：本体是不是只有大公司才用得上？
不是规模问题，而是复杂度问题。如果你的业务跨多个系统、规则多、例外多，而且希望 AI 能在规矩内办事，那么即使公司不大，一个小而准的本体也有价值；反之，即使公司很大，如果需求只是看报表，也未必需要。第 02 篇末尾有一张自查表。
问：建一个本体要多久？
取决于范围。一个小闭环（比如退货退款）的第一版，重点在业务梳理和数据质量，而不在建模本身；全公司范围的本体则是长期工程。本系列建议从小闭环开始，具体方法见第 06、07 篇，完整演练见第 10 篇。
问：我们已经有数仓和指标平台了，还需要本体吗？
先看要解决的问题。如果只是让人或 AI 查数字，指标语义层通常就够了；如果要跨对象做判断（这个客户的这件商品能不能退），还要让 Agent 在规矩内办事，就需要本体补上关系、规则、动作和权限。即使需要，也应当从数仓已有的一致性维度和指标定义起步，而不是推倒重来（见 8.1 节和第 05 篇第 14、15 节）。
本篇要点
- 本体是对业务领域"有什么、什么关系、能怎么改变、必须守什么规矩"的明确、共享、机器可处理的描述。
- 它源自哲学中"什么存在"的研究；计算机领域最常被引用的定义是 Gruber 的"对概念化的明确规约"。
- 语义网时代的本体重在表达与推理（RDF、OWL、SHACL）；企业实践把它扩展为同时包含名词（名词层）和动词（动能层）的运营模型。
- 从一张表到一个业务世界：表变对象、外键变关系、散落逻辑变动作与规则。
- 企业数据模型是一条连续谱：业务数据库 → 维度模型 → 指标语义层 → 本体。你的数仓里已经有一部分本体；关键区别不在表还是图，而在事实背后的意义有没有被写下来。
- 本体不是表结构、不等于知识图谱、不是某个产品，也不是越大越好；它不必用 OWL，也不只属于大公司，关键看业务复杂度。
参考引用
- 《A Translation Approach to Portable Ontology Specifications》，Thomas R. Gruber，Knowledge Acquisition 5(2)，1993。原文
- 《Ontology Development 101: A Guide to Creating Your First Ontology》，Natalya F. Noy、Deborah L. McGuinness，Stanford University。原文
- 《OWL 2 Web Ontology Language Document Overview (Second Edition)》，W3C Recommendation，2012-12-11。原文
- 《Shapes Constraint Language (SHACL)》，W3C Recommendation，2017-07-20。原文
- 《Ontology building: Overview》，Palantir Foundry 官方文档。原文
- 《Why create an Ontology?》，Palantir Foundry 官方文档。原文
- 《What is ontology (preview)? — Microsoft Fabric IQ》，Microsoft Learn。原文
- 《深入浅出学习本体论（Ontology）：从哲学根基到实践应用概要》，Tom 汤姆的技术雷达。Cubox，原文
- 《从本体论到本体建模，从本体建模到 AI 原生—我这一年关于本体的系统性复盘》，何明璐 人月聊IT。Cubox，原文
- 《为什么Agent需要Ontology？》，飞翔海马 AI手抄笔记。Cubox，原文
- 《准备上知识图谱和本体（Ontology）？要什么团队、选什么场景、花多少成本 | 人人都是产品经理》，叶小钗。Cubox，原文
- 《别把RAG当架构：Ontology（本体）才是Agent的业务世界》，KK AI应用落地社。Cubox，原文
- 《企业AI真正缺的不是 SQL，而是Semantic Layer》，本体论应用 AbutionGraph（厂商文章：作者团队开发 OntoFlow 等本体产品，文中观点带有产品立场）。Cubox，原文