模型越来越聪明，Agent 还是做不好一件简单的事——搞清楚公司里"客户"到底指的是什么。
先说一个场景。
一家公司有两个系统：CRM 里管客户叫 Account，ERP 里管客户叫 Customer。Salesforce 里的 Account 可以是一家公司下面的多个部门，SAP 里的 Customer 只能是一个法人实体。两个系统都对，但含义不一样。
你给 Agent 下指令："查一下这个客户上个月的订单情况。"
Agent 去了 CRM，找到了三个 Account，去了 ERP，找到了一个 Customer。它不知道该信哪一个，于是随便拼了一个答案出来。你没法追究它为什么错，因为它连"客户"指的是什么都没搞对。
问题不在模型。在意义。
Ontology 就是解决这个问题的东西。
Ontology 到底是什么
这个词的正式定义来自 Tom Gruber（1993）——对，就是 Siri 那个 Gruber——他说 ontology 是"a formal, explicit specification of a shared conceptualization"。翻译成人话：
它不存具体数据。它不记录"张三在腾讯工作"这种事实。它记录的是：
- 有什么东西——客户、订单、商品、员工，这些是"类"（Classes）
- 它们有什么属性——客户有行业、规模，订单有金额、日期，这些是"属性"（Properties）
- 它们之间什么关系——客户"下"订单，订单"包含"商品，这些是"关系"（Relationships）
- 什么规则不能破——订单金额不能是负数，库存不够不能发货，这些是"公理"（Axioms）
打个比方。
你去一个陌生城市，手里有一张地图。地图上不标"张三住在XX路XX号"——那是具体的数据。地图标的是：这里有一条河，河上有几座桥，桥连着两条路，路的尽头是市中心。
Ontology 就是那张地图的图例。它告诉你蓝色代表水、棕色代表山、虚线代表省界。有了这个图例，你才能看懂任何一张具体的地图。
Ontology 和知识图谱不是一回事
很多人混着说，但它们是两层东西。
知识图谱
存具体事实。"张三在腾讯工作""订单 1001 包含商品 A"。回答的是发生了什么。
Ontology
定义概念和规则。"员工属于公司""订单包含商品"。回答的是这意味着什么。
知识图谱是 Ontology 的实例化。先有 Ontology 定义"员工"和"公司"之间可以有"就职"关系，然后知识图谱里才存得下"张三—就职→腾讯"这条具体数据。
在知识表示理论里，这叫 TBox/ABox 的区分，1980 年代就有了。Ontology 是 TBox（概念层），知识图谱是 ABox（实例层）。实际产品中这两层经常打包在一起卖，但概念上的区别没变。
为什么企业做 Agent 需要它
EY 写过一句话："AI 项目失败，更多是因为缺少对业务意义的共识，而不是模型能力不够。"
CIO Magazine 2026 年的报道说得更直白："AI Agent 在规模化部署时失败，不是因为模型不好，是因为它们在含糊不清的业务定义上做推理。"
这不是夸张。想想看：
LLM 读的是自然语言。它看到"客户"两个字，会从训练数据里推断出一个大致含义。但它不知道你公司里"客户"的精确定义——是签约方？是使用方？是付费方？这三个在很多公司不是同一个人。
没有 Ontology 的 Agent，就像一个被扔进你公司的新员工。聪明，读过很多书，但不知道你公司里的"Q1 营收"算不算含退款，不知道"A 类产品"和"B 类产品"的分界线在哪里。它猜。猜对了看起来厉害，猜错了你也不知道它怎么想的。
有了 Ontology 之后，Agent 的工作方式变了。它不再"猜"业务含义，而是查定义。"客户"是什么？Ontology 写着：签约法人实体，关联到 CRM 的 Account 表和 ERP 的 Customer 表，排除了个人消费者。Agent 按这个定义去取数据，结果是一致的、可追溯的。
实际案例
Palantir AIP + Tampa General Hospital
2024 年 6 月，佛罗里达的 Tampa General Hospital 部署了 Palantir 的 AIP 平台做 AI 驱动的病人协调。这个案例被多家独立媒体报道，2025 年底还拿了"年度合作伙伴"Inno Award。
Palantir 的核心就是它的 Ontology 层——把医院里分散的系统（电子病历、排班、设备管理、床位管理）中的概念统一成一套机器可读的模型：什么是"病人"、什么是"床位"、"入院"和"出院"之间有什么规则约束。Agent 在这个 Ontology 上做推理，而不是各自去猜每个系统里的字段含义。
具体效果的数字在各个报道里有出入，没被独立验证过，就不引用了。但这件事本身——一家三甲医院在生产环境里用 Ontology 驱动的 AI——说明这个方向已经从论文走到了病房。
TopBraid EDG
TopQuadrant 的 TopBraid EDG 在 2025 年连续发了 8.3、8.4、8.5 三个版本，重点就是让 AI Agent 能用 Ontology 做自动化内容分类、数据治理和跨系统一致性检查。它支持 RDF Schema 和 OWL 标准，2025 年版本还加上了 Git 集成，让多人协作编辑 Ontology 像写代码一样有版本控制。
独立评测说这个工具学习曲线比较陡。 Ontology 工程目前确实还是一个需要专门技能的领域。
怎么做：企业 Ontology 的四个维度
一个实用的企业 Ontology，不管用什么工具建，基本都绕不开这四块：
| 维度 | 回答的问题 | 例子 |
|---|---|---|
| 实体（Entities） | 我们业务里有什么东西？ | 客户、订单、SKU、员工 |
| 属性（Properties） | 这些东西有什么特征？ | 客户有行业、地区；订单有金额、状态 |
| 关系（Relationships） | 它们之间怎么连接？ | 客户→下→订单；订单→包含→SKU |
| 公理（Axioms） | 什么规则永远不能破？ | 库存不足→不能发货；负金额→不是有效订单 |
建好之后还要管。Ontology 不是一次性写完就放着的东西。业务变了，Ontology 也要变。TopBraid EDG 8.3 加 Git 集成就是这个思路——把 Ontology 当代码管，有版本、有 review、有 CI/CD。有人管这个叫 "OntologyOps"，概念还在早期，具体工具链还不成熟，但方向是对的。
主流工具一览
| 工具 | 类型 | 特点 |
|---|---|---|
| TopBraid EDG | 商业 | RDF/OWL 标准支持，Git 集成，Gartner 评测成熟产品。学习曲线陡。 |
| Palantir AIP | 商业平台 | Ontology 驱动的数据整合层，已有医疗等行业的生产部署案例。 |
| Stardog | 商业 | 知识图谱数据库，内置 Ontology 管理和推理能力，支持 Agent AI 场景。 |
| Protégé | 开源 | 斯坦福开发的老牌 Ontology 编辑器，OWL 标准支持，免费但界面老旧。 |
| TypeDB | 开源 | 类型化的数据库，自带语义建模能力，适合 Agent 推理场景。 |
但 Ontology 不是每个公司都需要
有个叫 Kevin DeWalt 的从业者说过一句话："Don't build ontologies unless you absolutely need them."
如果你公司就一个系统，两个表，Agent 只需要查客户名和订单金额——不需要 Ontology。一个 prompt 加 function calling 就够了。
Ontology 的门槛在规模。三个以上系统、五六个部门、同一个词在不同地方含义不同——到了这个点，不建 Ontology 的代价开始超过建它的代价。
还有一个现实问题：Ontology 会衰变。建的时候是准的，三个月后业务改了，Ontology 没跟上，它就开始引入自己的错误。所以需要人管，需要流程，需要像管代码一样管它。
这些事做不做，取决于你的 Agent 要干什么。让它写邮件，不需要。让它做跨系统的数据决策——那就得想想，它到底该信谁的"客户"定义。