Palantir 的 Ontology 不是传统语义层，也不是给数据表换一组业务名词。它把对象、关系、动作、逻辑和权限放进同一个可执行模型，让企业现实世界可以被人和 AI Agent 共同操作。
系列：Palantir 系列 3 / 8
如果说 Foundry 是 Palantir 的数据运营底座，那么 Ontology 就是这套底座上的核心业务模型。
很多人第一次看到 Ontology，会把它理解成“本体”“知识图谱”“语义层”或“业务对象模型”。这些理解都有一部分对，但都不完整。
从工程视角看，Palantir 的 Ontology 更接近这样一层东西：
它把企业里的对象、关系、逻辑、动作和权限放进同一个可执行模型里，让人、应用和 AI Agent 可以围绕同一个业务世界协作。
这句话是理解 Palantir 的关键。
为什么企业需要 Ontology
企业系统最大的问题，不是没有数据。
恰恰相反，大型组织通常有太多数据：
- ERP 里有订单、库存、采购。
- CRM 里有客户、合同、销售机会。
- MES 里有工单、产线、设备状态。
- WMS 里有仓库、库位、出入库。
- 财务系统里有成本、回款、预算。
- 文档和邮件里有大量非结构化业务判断。
每个系统都对一部分现实负责，但没有一个系统等于企业现实本身。
所以业务人员真正关心的问题，经常跨越多个系统：
- 一个供应商延迟，会影响哪些客户订单？
- 某条产线故障，会影响哪些交付承诺？
- 某个病房资源紧张，应该优先调整哪些患者路径？
- 某个能源设备异常，是维修、降载，还是继续观察？
这些问题不是单表查询。
它们是对象关系、业务规则、权限边界和行动方案共同构成的决策问题。
Ontology 存在的原因，就是把这些决策问题显式建模出来。
Ontology 不是传统语义层
很多数据平台也会讲语义层。
语义层通常解决的问题是：指标和字段怎么解释。
例如：
- “收入”到底按下单时间还是确认收入时间计算？
- “活跃用户”口径是什么？
- “库存可用量”是否扣除了已分配库存？
- 不同部门能不能用同一个指标名称？
这些都很重要。
但 Palantir 的 Ontology 要解决的问题更靠近操作层：
传统语义层主要回答：
这个指标是什么意思？
Ontology 进一步回答：
这个业务世界现在是什么状态？哪些对象相互影响？有哪些动作可以执行？谁有权限执行？执行后如何反馈？
所以，不要把 Ontology 只看成指标字典或数据模型。
它是操作模型。
Ontology 的两个部分：语义元素和动能元素
Palantir 官方文档把 Ontology 的组成分成两类：
- Semantic elements：objects、properties、links，也就是对象、属性和关系。
- Kinetic elements：actions、functions、dynamic security，也就是动作、函数和动态安全。
这个划分非常重要。
很多系统只做到前半部分：把现实世界建模成对象和关系。
Palantir 强调后半部分：这个模型还要能被调用、能执行动作、能处理权限。
可以把它理解成四个核心维度：
数据：对象、属性、关系、状态
Ontology 的第一层是业务对象。
对象不是数据库表，而是业务世界里的实体。例如：
- 订单。
- 客户。
- 供应商。
- 设备。
- 工单。
- 航班。
- 病床。
- 车辆。
- 任务。
每个对象有属性，也有状态。
例如一个订单有金额、交期、客户、优先级、履约状态。
对象之间通过 links 连接起来：订单依赖物料，物料来自供应商，工单占用产线，设备属于工厂。
这一步的目标，是让系统不再只面对表和字段，而是面对业务人员真正理解的实体。
逻辑：规则、函数、模型、优化器
只有对象还不够。
企业运营里还有大量逻辑：
- 哪些客户应该优先保护？
- 哪些物料可以替代？
- 哪些规则不能违反？
- 哪个方案成本最低？
- 哪个方案风险最小？
- 什么情况下必须人工审批？
这些逻辑可以来自代码、函数、模型、规则引擎或优化器。
Ontology 的价值在于，它把这些逻辑和业务对象连接起来。
例如，不是写一个孤立的“库存预测模型”，而是让这个模型能围绕物料、工单、订单、客户这些对象运行，并把结果回到同一个对象世界里。
动作：从建议走向执行
这是 Ontology 和普通数据模型最根本的分界线。
传统数据模型通常是只读的。
它告诉你业务发生了什么。
Ontology 还要表达可以做什么：
- 调整排产。
- 创建采购单。
- 修改配送路线。
- 升级告警。
- 触发审批。
- 分派任务。
- 写回外部系统。
动作不等于自动乱改系统。
成熟的动作设计一定要有边界：谁可以发起、什么条件下可以执行、是否需要审批、执行后如何记录、失败后如何处理。
但只要动作被纳入模型，系统就从“解释业务”进入了“参与业务”。
安全：权限不是外置过滤器
在企业系统里，权限经常被当成 UI 或 API 外层的过滤器。
但在 Palantir 的 Ontology 语境里，安全是模型的一部分。
因为同一个对象、同一个动作、同一个字段，在不同角色、不同任务目的、不同数据标记下，访问和执行规则可能完全不同。
例如：
- 销售能看客户订单，但未必能看成本。
- 生产能看工单，但未必能改客户优先级。
- AI Agent 可以读取汇总结果，但不能读取敏感明细。
- 某些动作必须经过人工确认。
如果安全不进入 Ontology，AI Agent 就很难安全地工作。
它可能知道该做什么，却不知道自己被允许做什么。
一个工程例子：不是“订单表”，而是“订单对象”
假设系统里有一张订单表。
传统数据平台会关心：
- 表结构。
- 字段类型。
- 指标口径。
- 数据质量。
- 查询性能。
这些当然重要。
但 Ontology 会进一步问：
- 订单对象有哪些属性？
- 它和客户、产品、物料、工单、运输路线是什么关系？
- 哪些规则决定它的优先级？
- 哪些模型会预测它的延期风险？
- 哪些动作可以改变它的状态？
- 谁可以批准这些动作？
- 执行结果如何反馈到订单对象？
这时“订单”已经不是报表中的一行数据，而是一个可被系统理解和操作的业务对象。
这就是本体论的工程意义。
为什么 Ontology 是 AI Agent 的前提
现在很多企业想做 AI Agent。
但如果没有 Ontology，Agent 通常只能停在三个浅层能力：
- 问答。
- 摘要。
- 生成建议。
这些能力有价值，但离真实运营还很远。
真正的企业 Agent 需要知道：
- 当前有哪些业务对象？
- 对象之间有什么关系？
- 哪些状态是最新的？
- 哪些规则必须遵守？
- 它能调用哪些函数？
- 它能发起哪些动作？
- 哪些动作必须交给人确认？
- 执行后如何记录和追踪？
Ontology 给 Agent 提供的不是一堆文档，而是一个可操作的业务世界。
这也是为什么 Palantir 会把 AIP 和 Ontology 绑得很紧。
AIP 让大模型进入企业流程；Ontology 告诉模型这个企业世界长什么样、有哪些边界、能做什么。
没有 Ontology，AIP 很容易变成一个会聊天的搜索框。
有了 Ontology，AIP 才可能成为受控的运营助手。
为什么 Ontology 难做
Ontology 听起来很漂亮，但它不是画一张实体关系图就结束。
真正难点在几个地方。
第一，业务对象不是稳定不变的。
企业流程会变，组织结构会变，权限会变，系统也会变。Ontology 必须能跟着业务演化，否则很快就会变成没人敢改的中心化模型。
第二，不同部门对同一个对象的理解不同。
销售眼里的客户、财务眼里的客户、交付团队眼里的客户，并不总是同一个对象视角。Ontology 要处理这些差异，而不是假装全公司天然共享同一套语言。
第三，动作比数据更敏感。
查询错了，最多是分析错误。
动作错了，可能影响订单、产线、患者、设备、安全和资金。
所以 Ontology 里的 action 设计必须谨慎：边界、审批、审计和回滚都要先想清楚。
第四，AI 会放大模型质量问题。
当 Ontology 只是给人用时，人会自动补充常识。
当 Ontology 给 Agent 用时，模型缺失、关系错误、权限边界模糊，都会直接影响 Agent 行为。
这也是为什么我认为 Ontology 不是“低代码配置工作”，而是严肃的软件工程。
怎么判断一个 Ontology 做得好不好
不要只看对象数量。
对象很多，不代表 Ontology 好。
更应该看这些问题：
- 业务人员是否能用对象语言描述问题？
- 对象关系是否能支撑真实影响分析？
- 权限是否能跟对象、字段和动作联动？
- 业务逻辑是否能围绕对象复用？
- 应用是否直接建立在 Ontology 之上？
- 动作是否可审批、可审计、可追踪？
- Agent 是否能基于 Ontology 安全地完成任务？
一个好的 Ontology，最终会让业务和工程团队使用同一套对象语言讨论问题。
这件事很难，但价值也在这里。
因为企业软件最大的隐性成本之一，就是不同系统、不同团队、不同流程之间没有共享的业务现实。
结尾：Ontology 是 Palantir 的核心，不是因为它抽象
Ontology 不是 Palantir 的核心，因为它听起来高级。
它之所以核心，是因为 Palantir 想做的不是报表系统，也不是单纯的数据仓库，而是企业操作系统。
企业操作系统必须有一个对现实世界的模型。
这个模型要能表达对象、关系、状态、逻辑、动作、权限和反馈。
这就是 Ontology。
用一句话概括：
Ontology 是 Palantir 把企业现实世界变成可执行软件系统的核心抽象。
理解了 Ontology，才能真正理解为什么 Foundry 不只是数据平台，为什么 AIP 不只是聊天机器人，以及为什么 Palantir 的产品看起来总是同时谈数据、应用、权限、动作和 AI。
