只有实体与关系？
这通常只是语义模型或知识图谱，还缺业务行动和闭环。
Executable Ontology Handbook · 中文开源教学手册
让企业的现实世界
成为可执行模型
Ontology 不是“更漂亮的知识图谱”，而是一套把企业中的数据、业务逻辑、操作能力与安全规则统一为实时决策系统的方法与软件架构。
12核心章节
4决策基本要素
1端到端业务案例
30+关键术语与检查项
01
Ontology 到底是什么
先区分经典知识工程定义与 Palantir 的企业工程定义。
经典定义Tom Gruber 在 1993 年将计算机科学中的本体定义为“对概念化的明确规范”。它关心一个领域里有哪些概念、关系和约束，以及机器如何共享这套表达。
Palantir 官方Palantir 将 Ontology 定义为组织的 operational layer（运营层）：它位于数据集、虚拟表和模型之上，把数字资产连接到工厂、设备、订单、交易等现实对象，并同时包含语义元素与可执行元素。
一句话理解Ontology = 企业现实的实时、受治理、可执行数字模型。 数据库告诉你“记录在哪里”，Ontology 还要回答“这是什么、彼此如何关联、能做什么、谁可以做、做完如何写回并留下证据”。
企业本体 = 业务对象与关系 + 计算与规则 + 受控行动 + 动态安全与审计
三个判断题
只能查、不能改？
这通常还是分析系统，没有跨越到运营系统。
能改但无权限与审计？
这不是企业级可执行本体，而是高风险自动化。
02
为什么企业需要它
企业缺少的通常不是数据，而是从事实到行动的共同语言。
数据源ERP、CRM、MES、WMS、IoT、文档
→传统分析清洗、聚合、报表、预测
→人工解释理解影响、协调权限、选择方案
→人工执行回到多个业务系统分别操作
传统架构经常在“洞察”处结束：模型发现缺货风险，但系统不知道受影响的订单、可替代物料、可调用的优化器、谁有权批准，也无法安全地把最终方案写回仓储与生产系统。Ontology 的目标是把这条断裂链路重新接起来。
连接规模化
不同系统的数据被映射为共享业务对象，团队不必各自重复建设订单、设备、客户等定义。
业务可解释
非技术用户直接使用“航班、患者、工单”等业务语言，而不是表名、字段名和 Join。
决策可沉淀
记录决策时看到的数据版本、评估过的选项、调用的逻辑、执行动作和后续影响。
运营 AI/ML
模型不再只输出分数，而是进入受权限约束的实际工作流，形成反馈与持续学习。
03
四位一体的决策模型
Palantir 官方将每个运营决策拆为 Data、Logic、Action、Security。
Data · 数据
做决策所需的信息，包括结构化数据、实时流、边缘数据、文档、图像，以及人和 Agent 在决策过程中产生的“决策数据”。
产物：对象、属性、关系、状态、血缘。
Logic · 逻辑
评价方案的计算过程，可以是确定性规则、SQL/代码函数、预测模型、优化器、仿真器，也可以包含 LLM 推理。
原则：让确定性逻辑与非确定性模型各司其职。
Action · 行动
把选择变成真实操作：修改对象、建立关系、提交审批、调用 API、通知人员，或写回 ERP、设备及边缘系统。
分水岭：闭合行动回路，分析系统才成为运营系统。
Security · 安全
确保读取、推理和执行都符合组织政策。权限不只保护数据，还保护函数、模型、动作、Agent 工具和日志。
要求：最小权限、运行时校验、全链路审计。
教学归纳可以把一个决策写成：谁，基于哪一版事实，调用什么逻辑，在何种权限下，选择并执行了哪个行动，最终产生什么结果。
04
语义元素与动力元素
名词描述世界，动词改变世界；两者结合才是可执行本体。
语义元素：世界里“有什么”
Object Type · 对象类型
现实概念的类型定义，例如供应商、物料、订单、设备。对象类型把底层数据映射成业务可理解的实例集合。
Property · 属性
对象的字段与状态，例如库存量、承诺日期、风险等级。属性应有类型、来源、业务解释与权限。
Link Type · 关系类型
对象间有意义的连接，例如“供应商供应物料”“订单消耗物料”。关系使影响分析和跨对象导航成为可能。
Interface · 接口类型
描述一类对象共同的形状与能力，提供类似多态的建模方式，使不同对象以一致方式被查询和操作。
Object Set · 对象集合
按条件形成的动态业务集合，例如“未来 7 天内高风险订单”，通常是分析、应用和动作的输入。
Metadata · 元数据
标签、描述、血缘、负责人、版本与治理信息，让本体可发现、可维护、可审计。
动力元素：世界“如何变化”
Action Type 是一次业务事务的定义：它可以同时修改一个或多个对象、属性和关系，并携带参数、提交条件、校验规则与副作用。相同动作逻辑可复用于不同应用，保证业务操作一致。
动作 = 参数 + 提交条件 + 变更规则 + 副作用 + 权限 + 审计
Function 承载可演化的业务逻辑，复杂度可以从简单计算到多步骤编排。它可以增强对象、评估行动条件，也可以连接传统算法、机器学习模型、优化器和 LLM。
函数应优先做到：输入明确 · 输出可验证 · 版本可追踪 · 失败可观测
Dynamic Security 在每次交互时综合数据行列权限、用户组属性、用途、标记、项目范围与动作授权。Agent 只能看到其身份或项目被授予的对象，也只能调用被显式授权的工具。
能看见 ≠ 能推理 ≠ 能提交 ≠ 能写回；四类权限必须分别治理
05
Ontology System 系统架构
官方强调它不是一层薄薄的语义封装，而是由 Language、Engine、Toolchain 组成的多模态系统。
应用与 Agent运营应用、分析工具、工作流、AI Agent、外部系统
Human + AIToolchainSDK、应用开发、测试、发布、DevOps 与生产治理工具
Build & GovernLanguage对象、属性、关系、接口、动作、自动化以及动作依赖的逻辑
ModelEngine高规模读取、状态订阅、物化、原子事务、批量变更、流和 CDC
Read & Write企业系统ERP、CRM、MES、WMS、数据库、文档、IoT、地理空间与边缘设备
Sources & Sinks关键认识Language 负责表达；Engine 负责让表达在实时读写、事务和同步中成立；Toolchain 负责让团队安全地开发、发布和治理。缺少任意一层，都容易退化为“模型画得很好，但无法稳定运行”。
一次读写闭环
同步事实连接器、流、CDC、文档解析
→形成对象映射、链接、权限、实时状态
→运行逻辑规则、模型、优化、Agent
→提交行动事务、审批、副作用、写回
→记录结果决策血缘、反馈、审计、学习
06
与相似概念的区别
Ontology 会复用这些技术，但不能简单等同于其中任何一个。
| 概念 | 主要回答 | 典型强项 | 相对 Ontology 的缺口 |
|---|---|---|---|
| 数据库 Schema | 数据怎样存 | 结构、约束、事务 | 通常不表达跨系统业务语义、行动与决策血缘 |
| 知识图谱 | 事实怎样关联 | 实体关系、语义检索、推理 | 常停留在“可查询”，缺少受治理写回与运营动作 |
| 语义层 | 指标与术语怎样统一 | 统一口径、分析复用 | 通常是读优化层，不承担完整事务、行动和工具权限 |
| 数字孪生 | 现实状态怎样镜像 | 实时状态、仿真、可视化 | 可能偏设备或场景，未必统一企业语义和跨系统行动 |
| BPM / 工作流 | 步骤怎样编排 | 审批、流程状态、任务分派 | 常缺全域对象模型、实时关系和统一逻辑资产 |
| Palantir Ontology | 企业如何理解、决策并行动 | 数据 + 逻辑 + 行动 + 安全闭环 | 建设成本高，需要领域专家、数据工程和治理共同参与 |
边界“可执行本体”是 Palantir 的企业工程范式，不是所有学术 Ontology 都必须包含 Action，也不是所有知识图谱项目都应升级成运营系统。
07
完整案例：关键物料突然断供
用一个供应链事件看懂 Ontology 如何从发现问题走到受控执行。
现实世界对象供应商、物料、库存、工厂、生产订单、客户订单、运输线路
双向
映射
映射
系统数据来源SRM、ERP、WMS、MES、TMS、预测模型、客户承诺数据
事件进入本体
供应商把某原料状态更新为“停供”。实时同步使对应 Supplier 与 Material 对象状态变化，并触发订阅。
沿关系计算影响
系统沿“供应—消耗—生产—履约”关系定位受影响工单和客户订单，规则计算缺口、时间窗口与客户优先级。
调用逻辑资产
库存分配器、替代料规则、生产优化器与运输模型产生多个候选方案；LLM 可以解释方案，但关键数量由确定性逻辑计算。
建立隔离场景
候选调整先进入 scenario：模拟挪用库存、切换替代料、调整排产后对其他产品与客户的连锁影响，不改生产数据。
权限与人工复核
供应链分析员可运行场景，财务可查看成本，质量负责人批准替代料，生产经理批准排产；各角色只见必要信息。
提交 Action
批准后由“物料重分配”动作统一编排：WMS 更新库存预留，ERP 更新订单，MES 调整计划，TMS 修改运输，并逐项验证响应。
沉淀决策血缘
系统记录当时的数据版本、评估方案、使用模型、批准人、动作结果与最终履约表现，为审计和下次类似事件提供上下文。
核心差异知识图谱可以告诉你“哪些订单受影响”；可执行本体还要让你安全地评估方案、提交动作、写回系统并从结果中学习。
08
AI Agent 如何接入 Ontology
Ontology 为 Agent 提供的不是一堆原始表，而是带语义、权限、工具和操作边界的现实上下文。
读取业务对象
Agent 查询的是“高风险订单”和关联供应商，而不是猜测数据库表与 Join。
调用确定性工具
预测、优化、仿真和业务函数可作为工具，避免让 LLM 凭语言生成关键数值。
提出或执行行动
Action 可以只允许 Agent 暂存方案，交由人批准；成熟后再逐步扩大自动执行范围。
继承安全边界
工具调用取决于底层对象、属性和关系的访问权，并可叠加动作提交条件。
保留完整审计
查询、建议、工具调用、批准与写回均进入日志和决策血缘。
建立可控记忆
历史决策及结果形成高质量上下文，比无边界地保存聊天记录更适合企业学习。
建议的授权阶梯
阶段 1只读检索与解释
→阶段 2调用只读计算工具
→阶段 3生成可审查方案
→阶段 4暂存 Action，人工批准
→阶段 5低风险动作自动闭环
安全原则不要把“能访问 LLM”误认为“能执行企业操作”。读权限、工具权限、提交权限、写回权限必须分层授予，并准备幂等、超时、回滚或补偿机制。
09
如何落地建设
不要从“全企业本体”开局，要从一个高价值决策闭环反推最小模型。
选择一个运营决策
例如“缺料时如何重排生产”，明确决策频率、参与角色、输入、输出、风险和成功指标。
定义领域边界与负责人
确认哪些对象属于本次范围、谁对定义负责、哪些系统是事实来源。没有所有权，本体会迅速失真。
建最小语义骨架
先定义必要对象、属性、链接和标识策略，接入少量真实数据验证语义，不追求一次覆盖全部字段。
绑定逻辑资产
把规则、指标、模型和优化器接到对象上，为输入输出、版本、测试和失效模式建立契约。
设计 Action 与安全
把动作参数、提交条件、变更范围、副作用、授权、幂等、审计和失败补偿一并设计，而不是最后补权限。
先场景、后生产
使用沙箱或 scenario 验证影响；从只读、建议、人工批准逐步推进到受控自动化。
闭环度量与演进
跟踪决策耗时、执行成功率、业务结果、权限异常和模型漂移；通过版本化发布持续演进对象与动作。
上线前检查
10
常见误区与反模式
大多数失败不是技术栈不够，而是本体没有成为运营契约。
误区一：把数据库表直接改名为对象
表结构反映某个系统的实现历史，不等于稳定业务语义。应先确定业务身份、生命周期和跨系统映射，再决定对象边界。
误区二：对象越多、关系越密越先进
无明确决策用途的模型只会增加维护成本。按用例构建最小闭环，并让复用从真实需求中自然产生。
误区三：只建“名词”，不建“动词”
只有对象和关系的系统仍然偏分析。企业价值通常来自规则、Action、写回、审批和反馈闭环。
误区四：让 LLM 直接承担业务规则
金额、库存、约束和合规判断优先使用确定性逻辑；LLM 适合理解意图、综合上下文、解释与编排工具。
误区五：最后再补安全
安全必须贯穿对象、属性、函数、动作和日志。尤其要区分“可查看数据”和“可调用动作”。
误区六：建立一个永不变化的全局本体
企业会持续变化。本体需要所有权、版本、分支、兼容性测试和发布治理，而不是一次性建模项目。
误区七：把所有自动化都交给 Agent
自治应由真实测试、失败成本和可逆性决定。高风险、跨系统或不可逆动作应保留明确的人类控制点。
11
成熟度与验收标准
下面是教学归纳模型，不是 Palantir 官方等级，用于判断项目到底走到了哪一步。
L0数据可见统一接入与报表，仍以表和字段为中心。
L1语义对象关键实体被映射为稳定业务对象。
L2关系与逻辑对象可导航，规则和模型可复用。
L3受控行动Action 可审计写回，形成运营闭环。
L4人机协同Agent 在权限内查询、计算、提出动作。
L5受控自治低风险闭环自动执行，并根据结果学习。
| 验收维度 | 不合格信号 | 合格证据 |
|---|---|---|
| 语义正确性 | 同名不同义、对象重复、依赖人工解释 | 领域负责人签署定义，真实数据可稳定映射 |
| 运行实时性 | 页面状态长期落后于源系统 | 关键状态同步 SLA、延迟与异常均可观测 |
| 行动可靠性 | 提交后不知是否写回成功 | 幂等、事务/补偿、回执、重试和审计证据完整 |
| 安全治理 | Agent 使用共享超管账号 | 最小权限、运行时校验、日志隔离和授权评审 |
| 业务价值 | 只展示漂亮关系图 | 决策耗时、异常响应、履约或成本指标改善 |
| 演进能力 | 改一个字段导致全链路停机 | 版本化、兼容性测试、灰度发布与回滚机制 |
12
术语、自测与延伸资料
完成这一章，你应该能准确判断一个系统是否真正具备“可执行本体”。
关键术语速查
| Ontology | 企业现实的受治理运营模型，统一数据、逻辑、行动和安全。 | Object | 现实业务对象的数字实例。 |
|---|---|---|---|
| Link | 对象之间具有业务意义的关系。 | Function | 计算、规则、模型或编排逻辑。 |
| Action | 一次受校验、可审计的业务事务。 | Writeback | 将行动结果同步回运营系统或本体状态。 |
| Decision lineage | 决策所依据的数据、逻辑、过程、动作与结果的完整血缘。 | Scenario | 与生产隔离的候选变更与仿真空间。 |
| OSDK | 让开发者以 Ontology 作为应用后端的开发工具体系。 | Dynamic security | 按用户、用途、数据、工具和运行上下文实时计算的权限。 |
三题自测
1. Palantir Ontology 与普通知识图谱最关键的差异是什么？
2. Agent 准备修改生产订单时，正确做法是什么？
3. 首次建设 Ontology 最合理的范围是什么？
一手资料
- Palantir 官方：The Ontology system——四位一体模型以及 Language、Engine、Toolchain 架构。
- Palantir 官方：Ontology overview——对象、关系、Action、Function、Interface 与数字孪生定义。
- Palantir 官方：Why create an Ontology?——决策中心架构、运营工作流、场景、Agent 与决策血缘。
- Palantir 官方：Action types——动作事务、参数、规则、副作用、权限和 writeback。
- Thomas R. Gruber：A Translation Approach to Portable Ontology Specifications（1993）——计算机科学 Ontology 经典定义。
- Palantir 早期动态本体专利：Creating data in a data store using a dynamic ontology。
资料说明本手册基于上述一手资料进行中文转述；“成熟度模型、授权阶梯、实施清单”为教学归纳，不代表 Palantir 官方产品承诺。官方文档会持续更新，实际实施应以当前版本和组织治理要求为准。本项目为独立社区教学项目，与 Palantir Technologies 无隶属、合作或官方授权关系。