EO02｜ 从 Palantir 带火 Ontology，到 GB/T 48000.3-2026：看懂企业 AI 的关键底座

2026年8月1日，GB/T 48000.3—2026《标准数字化 第3部分：本体建模要求》正式实施。该标准并非专门面向企业 AI，也不等同于 Palantir 所代表的运营型 Ontology，但它释放出一个明确信号：本体正在从知识工程中的专业概念，走向规范化、工程化应用。

在 2026 WAIC 的演讲中，李开复将企业 AI 所需的能力比作“大脑、地图、导航系统和操作系统”。基于他的观点，我的理解是，企业 AI 应用需要三类核心能力：聪明的大脑（LLM）、企业地图（Ontology）和运行框架（Harness）。这里将“导航系统”提供的实时上下文，以及“操作系统”承担的任务编排与受控执行，统一归入 Harness。

简单来说：LLM 让 AI 会思考，Ontology 让 AI 懂企业，Harness 让 AI 能够稳定地完成任务。

当前，Ontology 正同时沿着三个方向发展：

• • GB/T 48000.3—2026 的实施，说明本体建模开始走向规范化工程；

• • Palantir、Databricks及国内厂商推出相关产品，说明 Ontology 正从建模方法走向商业化平台；

• • Apache Ossie 等开放项目的出现，则开始推动企业语义在不同 AI、分析和 BI 工具之间复用，从封闭语义走向开放交换；

这些路线的范围和成熟度并不相同，但共同指向一个趋势：企业 AI 的竞争，正在从单纯选择模型，转向能否把企业自己的业务对象、关系、状态、运行逻辑和行动边界组织清楚。

本文重点关注的，正是以 Palantir 为代表的运营型 Ontology：它如何用业务对象描述现实，用逻辑表达如何判断，用 Action 连接真实系统，再通过治理限定人和 AI 能做什么。

---

01 从 Ontology 到运营型 Ontology

Ontology 原本是知识工程中的概念，主要用于定义一个领域中的概念、属性、关系和约束，使人和机器能够以相对统一的方式理解知识。GB/T 48000.3—2026 所规范的，也主要是本体建模中的这些基础要素。

进入企业场景后，本体还需要连接真实数据和业务对象，例如客户、订单、设备、场站、告警和工单，并明确对象之间的关系、当前状态及权威数据来源。它解决的是企业如何用统一的业务语言描述自己。

以Palantir 为代表的运营型 Ontology,它在对象和关系之外，进一步连接决策逻辑、业务动作和安全治理。下面所说的“四层”，是对运营型 Ontology 核心结构的归纳，并不是 Ontology 唯一的标准定义。

用一句话理解它的作用：

把分散在企业系统中的数据，组织成业务人员和 AI 都能理解的对象、关系与状态，再进一步接通判断、执行和治理。

如果模型主要停留在对象、属性、关系和约束的表达，就还没有体现运营型特征。它可能是一套领域本体，也可能进一步落地为知识图谱。只有进一步连接逻辑、Action 和治理，才具备“运营型”的核心特征。

将运营型 Ontology 归纳为四个部分：数据与语义层、逻辑层、动作层、安全治理层。

其中，安全治理并不是独立运行的最后一层，而是贯穿数据、逻辑和动作全过程，决定谁能查看数据、使用规则、发起 Action，以及哪些操作需要审批和审计。

---

02 运营型 Ontology 的四层结构

为了看清这四层如何工作，先用一个常见的设备运维场景贯穿说明：

某充电场站的一台设备突然离线。系统不仅要识别这一状态，还要判断是否构成故障、影响有多大、应该如何处置，以及哪些操作需要人工审批。

第一层：数据与语义层——企业中有什么

企业的数据通常分散在不同系统中：

设备管理系统：设备编号、型号、在线状态
充电运营平台：场站、订单、充电量和利用率
告警平台：故障类型、发生时间和告警级别
工单系统：维修人员、处理进度和历史记录
客户系统：客户、服务合同和保障等级

这些系统中的表名和字段，技术人员能够看懂，但业务人员和 AI 很难仅凭字段稳定理解其真实含义。

数据与语义层需要把它们重新组织成企业实际使用的业务对象：

• • 场站

• • 充电设备

• • 充电订单

• • 故障告警

• • 运维工单

• • 维修人员

• • 客户

• • 服务合同

同时建立对象之间的关系：

• • 设备属于场站

• • 告警来源于设备

• • 工单用于处理告警

• • 订单发生在设备上

• • 场站服务于客户

• • 客户受到服务合同约束

这样，AI 看到的就不再只是：

device_id = 10086
status = 0
alarm_code = E203

而是：

A场站 3号充电设备通信中断，当前处于离线状态；该设备正在服务某客户，最近两小时已有多笔订单失败，目前尚未生成维修工单。

这一层回答的是：

企业中有什么，这些对象之间是什么关系，现在处于什么状态。

需要注意，建立 Ontology 并不意味着必须把所有数据复制到同一个数据库。数据仍然可以保留在原有系统中，Ontology 通过数据映射、接口和事件同步，将它们组织成统一的业务表达。

如果只做到对象、属性和关系，这套模型更接近企业知识图谱。运营型 Ontology 还要继续接入判断逻辑、业务动作和安全治理。

第二层：逻辑层——企业如何判断

知道设备离线，只能说明“发生了什么”，还不能回答“问题有多严重、应该如何处理”。

企业通常已经存在大量判断规则，例如：

• • 设备离线超过5分钟，生成故障告警

• • 场站可用设备低于一定比例，提升告警等级

• • 高峰期发生故障，优先安排处理

• • 同类故障连续发生，判断为重复故障

• • 重点客户场站故障，缩短响应时限

除了明确的业务规则，逻辑层还可以连接：

• • 设备健康评分；

• • 故障预测模型；

• • 告警合并算法；

• • 维修人员匹配模型；

• • 备件需求预测；

• • 场站运营影响评估。

例如，同样是一台设备离线：

在一个拥有20台设备的低利用率场站，可能只是普通故障；在一个仅有4台设备、正处于充电高峰的场站，则可能直接影响客户服务；如果该设备最近一个月已发生三次同类故障，还需要进一步判断是否应当更换部件，而不是再次进行简单重启。

逻辑层把这些分散在制度文件、算法模型、系统代码和员工经验中的判断依据，与设备、场站、客户和工单等业务对象连接起来。

它回答的是：

面对当前状态，企业依据什么作出判断。

这里并不是说所有逻辑都由 Ontology 自己计算。Ontology 负责说明哪些规则和模型适用于哪些对象；具体计算仍可由规则引擎、算法模型、优化系统或 LLM 完成。

经过逻辑层判断后，系统得到的不再只是“设备离线”，而可能是：

该设备故障已导致场站可用能力下降25%，当前正处于运营高峰，并影响重点客户，建议提升为高优先级工单，在30分钟内安排处理。

第三层：动作层——企业能够做什么

如果系统只能分析问题、给出建议，它仍然只是一套辅助分析工具。

动作层进一步把判断连接到真实业务系统，使系统能够推动业务状态发生变化。

在设备故障场景中，可以定义以下 Action：

• • 创建维修工单

• • 指派维修人员

• • 发送故障通知

• • 执行远程重启

• • 调整设备功率

• • 推荐或申请备件

• • 升级告警级别

• • 更新工单状态

• • 回写处理结果

每个 Action 都不能只是一个模糊的“操作按钮”，而需要明确：

• • 输入哪些参数；

• • 在什么条件下可以触发；

• • 调用哪个业务系统；

• • 执行后会改变哪些对象状态；

• • 如何确认执行成功；

• • 失败后如何处理。

例如，“创建高优先级维修工单”可以被定义为：

• • 输入：设备、故障类型、场站、优先级、建议处理时间

• • 前置条件：故障已经确认、当前不存在重复工单

• • 调用系统：企业运维工单系统

• • 执行结果：生成工单、关联设备和告警、更新告警处置状态、返回工单编号

当逻辑层判断该故障需要紧急处理后，AI 可以生成处置建议；在满足权限要求后，调用工单系统创建任务、匹配维修人员，并将执行结果重新写回设备和告警状态。

这一层回答的是：

已经形成判断后，如何推动真实业务执行。

动作层也是运营型 Ontology 与普通知识图谱的重要区别。知识图谱主要帮助系统认识对象和关系；Action 则让系统能够基于这些对象和关系，调用真实能力完成任务。

第四层：安全治理层——谁能看、谁能做、谁来审批

能够执行 Action，并不意味着 AI 可以不受限制地操作业务系统。

同一个设备故障场景中，企业可能规定：

• • 普通故障可以自动创建工单

• • 高优先级工单需要通知值班负责人

• • 远程重启可以由系统自动执行

• • 批量调整设备功率需要运营人员确认

• • 更换重要部件需要技术负责人审批

• • 采购超过一定金额的备件需要采购审批

• • 所有操作必须记录发起人、审批人和执行结果

这里需要区分两个概念：

Action 定义“可以做什么”，治理决定“谁能在什么条件下做”。

例如，“调整设备功率”是一项 Action，但系统还要继续判断：

• • AI 是否有权直接执行；

• • 调整幅度是否超过自动执行范围；

• • 是否会影响正在进行的订单；

• • 是否需要场站负责人确认；

• • 执行失败后能否自动回滚。

安全治理虽然被列为第四层，实际上并不是最后才发挥作用，而是贯穿前三层：

治理层回答的是：

谁能够看到什么、使用什么，并在什么条件下采取行动。

这也是企业敢不敢让 AI 进入真实业务系统的关键。没有治理，AI即使判断正确，也可能越权执行；只有治理没有 Action，系统又只能停留在查看和建议阶段。

四层如何形成一个闭环

把四层连接起来，设备故障的处理过程就变成：

设备发生离线
        ↓
更新设备、场站和告警状态
        ↓
判断故障等级及业务影响
        ↓
生成处置方案和可执行 Action
        ↓
根据权限和审批规则执行
        ↓
创建工单、指派人员或远程处理
        ↓
执行结果重新更新设备与工单状态

因此，运营型 Ontology 不是四层彼此独立的模型，而是一套从理解现实、形成判断、推动执行到反馈更新的运营闭环：

数据与语义层让 AI 看懂企业，逻辑层让 AI 理解企业如何判断，动作层让 AI 能够推动业务执行，安全治理层则保证整个过程受控、可追溯。

---

03 与现有系统的区别

运营型 Ontology 并不是用来替代数据仓库、知识库或知识图谱，而是解决另一类问题。

• • 数据仓库：汇总、计算和分析数据

• • 知识库 / RAG：从文档中检索知识并生成答案

• • 知识图谱：表达业务对象及其关系

• • 运营型 Ontology：组织企业的业务对象、判断逻辑、可执行动作和治理边界

数据仓库更关心“数据是多少”，RAG 更关心“资料中怎么说”，知识图谱更关心“对象之间有什么关系”。运营型 Ontology 则进一步关注：企业当前处于什么状态，应依据什么逻辑判断，可以采取哪些行动，以及这些行动受到什么约束。

前三类系统同样可以通过工程集成接入规则、工作流和业务接口，但这些通常不是其最初的设计重点。运营型 Ontology 从一开始就围绕业务运行来组织模型。

因此，它更像连接数据、决策与执行的企业运营层，而不是另一套数据平台。

---

04 从本体论角度思考广西洪水

图特摩斯科技在《从 Palantir 本体论角度对广西洪水的一点思考》中，尝试从信息科学中的 Ontology 视角设想洪水应急协同。下面选取其中“快速建立统一态势”的场景，理解共享世界模型能够带来什么价值。需要说明的是，这是一种技术设想，并非已经部署的实际系统。

洪水发生后，气象、水利、交通、医疗、通信和应急等部门的信息都在不断变化：

• • 哪些道路已经中断

• • 哪些乡镇已经完成转移

• • 哪些医院仍有接诊能力

• • 哪些区域已经恢复通信

• • 哪些堤坝进入重点监测状态

传统方式下，这些信息分散在不同部门的系统中。决策者需要查看多套平台、听取逐级汇报，再通过人工汇总形成整体判断。

运营型 Ontology 则把各部门授权共享的信息，组织成河流、堤坝、道路、乡镇、医院、通信设施和救援力量等现实对象，并持续更新它们之间的关系和状态。

这样，决策者看到的不再是几十套相互割裂的系统，而是一张持续变化的城市运行“世界地图”：

哪里正在发生危险，哪些区域受到影响，人员转移进展如何，医疗、通信和救援资源还剩多少能力。

这张“世界地图”并不是简单的数据大屏。它不仅展示道路中断，还能进一步关联受影响的乡镇、医院和救援路线；不仅显示通信恢复情况，还能判断哪些区域已经具备救援协调条件。

它带来的核心价值是：

把分散在不同部门的局部信息，组织成相互关联、持续更新的统一态势，让决策者和各部门围绕同一个现实状态进行判断和协同。

各部门仍然维护自己的系统和原始数据，只需在授权范围内共享必要的对象状态、事件和业务能力。运营型 Ontology 统一的不是数据库，而是对现实世界的理解。

有了这张持续变化的“世界地图”，后续的影响分析、方案推演和资源调度，才有统一、可信的决策基础。

---

05 可参考的产品与模式

从公开产品看，Ontology 还没有形成统一形态。不同厂商分别从企业运营、数据平台、企业软件和开放语义等方向切入。

国外商业产品

Palantir Ontology 是运营型 Ontology 的代表，应用于 Foundry 和 AIP 产品体系。Palantir 将其定位为组织的“运营层”：既包含对象、属性和关系等语义要素，也包含 Action、Function 和动态安全等运行要素，用于连接企业数字资产与现实世界中的业务对象，并支撑决策逻辑、业务执行和安全治理。

Databricks Genie Ontology 更强调从企业已有资产中发现和维护业务上下文。官方资料显示，它从表、查询、仪表板、Notebook、文档和已连接应用中提取知识，自动构建并维护企业的数据与业务地图。目前仍处于 Public Preview。

两者代表了两种不同思路：

Palantir：先建立权威业务模型，再连接数据与 Action

Databricks：从已有数据资产和使用过程发现知识，再逐步形成可信的企业上下文

国内商业产品

国内厂商更多依托已有的数据平台、企业软件和 Agent 体系建设本体能力。

中国电子云将 Ontology Foundry 定位为“本体构建与运营平台”，并与 DataFoundry、AgentFoundry 等产品共同组成其 AI 平台体系，体现了从数据、本体到智能体应用的组合路线。

用友推出的 BIP 本体智能体，则从企业管理软件切入，通过业务实体、关系、流程和状态建模，连接财务、供应链和生产等系统，并进一步支持分析、决策与跨系统执行。

这类路线的特点，是把本体直接嵌入现有业务系统和 Agent 平台，而不是单独建设一套知识模型。

开源生态

开源领域目前更成熟的是语义建模、图谱、规则和模型交换等基础能力，尚未出现与 Palantir 产品形态完全对应的完整运营型 Ontology 平台。

例如 Apache Ossie，重点建立跨 AI、BI 和分析平台的开放语义模型规范，使指标、维度、数据集及其关系可以被不同工具和 Agent 复用。它解决的是语义一致性和可交换问题，并不直接覆盖完整的 Action 与运营治理。

按照产品的建设起点和能力重心，本文将当前路线归纳为四种模式：

• • 权威运营模型：以 Palantir 为代表，自上而下定义业务对象、逻辑、Action 和治理。

• • 动态上下文发现：以 Databricks 为代表，从已有数据资产和使用行为中持续提取企业知识。

• • 本体与业务系统融合：以中国电子云、用友等为代表，将本体嵌入数据平台、企业软件和 Agent 体系。

• • 开放语义与组件组合：以 Apache Ossie 及图谱、规则、工作流等开源组件为基础，由企业自行集成。

这些路线并非互相排斥。一个更现实的企业方案，可能同时采用：

自上而下确定核心业务对象和规则，自下而上发现长尾知识，再通过开放标准和 Agent 平台连接实际业务。

总体来看，Ontology 正形成两条逐渐靠近的主线：一条从业务运行出发，连接数据、判断和执行；另一条从数据与语义出发，为 AI 持续提供可信的企业上下文。

---

06 MVP 实践：基于开源组件验证可行性

目前还没有能够直接替代 Palantir 的完整开源运营型 Ontology 平台，但核心能力可以待尝试通过开源组件组合验证。

下面是待预研的一套 MVP 技术选型架构：

                    OpenWorker
               Agent Harness / 任务入口
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
  语义与上下文           判断与治理           业务执行
       │                 │                 │
Ontology Playground   Drools / DMN      MCP Action
Ossie                 Keycloak + OPA        │
OWL / SHACL                             Camel + Temporal
Jena / Fuseki
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
             现有数据平台与业务系统

支撑能力：
模型服务：vLLM
文档知识：Haystack / RAG
可观测：OpenTelemetry + Langfuse

这套架构不是“开源版 Palantir”，而是将运营型 Ontology 所需的语义、逻辑、Action、治理和运行能力拆开，分别选择成熟的开源组件进行组合。

• • OpenWorker：作为 Agent Harness 和任务入口

• • Apache Ossie：管理指标、维度和分析语义

• • Ontology Playground + Protégé / OWL / SHACL：通过可视化方式快速设计和评审业务对象、关系与属性，再补充正式语义约束并导出运行模型

• • Apache Jena / Fuseki：存储本体实例并提供语义查询

• • Drools / DMN：承载确定性的业务规则

• • MCP + Apache Camel：将现有系统接口封装为业务 Action

• • Keycloak + OPA：实现身份认证、权限与执行策略

• • OpenTelemetry + Langfuse：追踪 Agent、模型和工具调用过程

其中，Apache Ossie 更适合统一分析语义，不能独立承担完整的企业本体；OpenWorker 可以作为 Harness，但关键业务仍需补充权限、审批、审计和异常处理能力。

更佳阅读效果，请关注我的公众号

参考资料