Beyond Data · 决策的底层操作系统
Ontology：让人和 AI 在同一个世界里"读、想、做"
这是 Palantir 整个产品体系的"灵魂层"——它既不是数据库，也不是知识图谱，而是把企业的数据、逻辑、行动、安全编码成一个可执行的"业务世界模型"。本页用 9 个小节、边玩边学，让你从"听不懂"到"讲得清"。
一句话结论
Ontology（本体）是 Palantir 平台的核心层：它把企业的数据、逻辑、行动、安全编码成一个可执行的业务世界模型，让数据结构自带业务语义、行为要求与权限，从而让人和 AI 能在同一个语义层里「读、想、做」。它既不是数据库，也不是知识图谱。
- 四个维度：数据（把碎片化数据源统一成对象、属性、链接）、逻辑（把推理与业务规则固化下来）、行动（把真实世界的动作建模成一等公民）、安全（在人与 Agent 的混合劳动力上统一治理）。
- 语言层：名词是对象类型 / 对象 / 属性 / 链接类型；动词是动作类型（含输入参数、前置条件、副作用与权限）、函数（Function）与接口（Interface）。
- 引擎层：可扩展架构支撑百万级读写，跨异构基础设施协调读（查询、订阅状态变化）与写（事务更新、大规模批量变更），并与运营系统保持低延迟同步。
- 工具链：Ontology SDK（OSDK）把本体自动变成 API / SDK，官方称之为企业的「运营总线」；工具工厂（Tool Factory）为任何人和任何 Agent 定义工具；Ontology MCP 把本体原语暴露给外部 Agent。
- 定位澄清：Palantir 明确强调「The Ontology is not a semantic layer」——它管的是「世界如何运行」，而不只是「世界有什么」。
- 与其他平台的关系：Foundry 把本体建出来，AIP 让 AI 在本体上安全行动，Apollo 让它稳定运行——本体是贯穿三者的那条线。
0序章 · 为什么 AI 看不懂你的业务
先从一个所有上过"企业 AI"项目的人都踩过的坑说起。
大模型很聪明：能写邮件、能读文档、能调工具。可一旦接上真实业务系统，它就开始"犯傻"——用错系统、改错数据、写错单据。RAG、Function Calling、MCP 一项不少，却总差"最后一公里"。
拆开失败案例看，根因往往不是模型不行，而是模型与底层数据之间隔着一道"语义鸿沟"：数据库里有一张
vehicle_part 表，模型只看到字段名，看不出"这条零件是必装还是可选"；权限规则散落在网关、注解、中间件里，模型即便能改，也不知道"它现在到底有没有权改"。
鸿沟的本质是：数据结构本身没有表达出业务语义、行为要求与权限。Palantir 用 Ontology（本体） 填平了它——让数据结构自己"带语义、带行为、带权限、带审计"，于是人和 AI 能在同一个语义层里读、想、做。
提示：Ontology 是 Foundry（数据运营）与 AIP（AI 智能体）共同依赖的基础层。
1一句话看懂 Ontology
官方定义 + 一个能立刻做对的小测。
“The Ontology System encodes the data, logic, action, and security of the enterprise to automate decisions across your operations.”
—— Ontology 把企业的「数据、逻辑、行动、安全」编码成一个系统，用来在运营中自动化决策。
换个更直白的说法：如果 ERP 是"记账本"、数据仓库是"报表库"，那 Ontology 是企业的数字孪生（Digital Twin）——它把现实世界的人、机、料、订单、事件，连同"它们怎么关联、能做什么动作、谁能做"一起，建模成一个活的、可执行的业务世界模型。
小测：下列说法，哪一个最接近 Ontology 的本质？
记住一句话：它不替代人、规则引擎或 LLM 做最终决策，但它提供决策发生的"语义环境"和"执行载体"。
2四个维度：数据 · 逻辑 · 行动 · 安全
页面反复强调的"四元整合"。点开下面四块，看看每一维在解决什么问题。
📦
数据 Data
把碎片化的真实世界统一成对象
把 ERP、CRM、系统记录、地理空间库、实时传感器、文档库等分散且碎片化的数据源，统一编码成对象（Objects）、属性（Properties）、链接（Links），形成决策空间的实时图景。关键词是统一（Unify），而不是搬家。
🧠
逻辑 Logic
把企业的"怎么算、怎么判"固化下来
持续把用于计算和判定行动的推理与业务规则编码进来——既涵盖完整的业务规则与决策框架谱系，也被设计成会随业务推理的变化而演进。逻辑让系统知道"什么情况下该做什么"。
⚡
行动 Action
把真实世界的动作变成一等公民
把真实世界的行动（Actions）建模成一等公民（first-class primitives），并定义它们如何被执行——从简单的事务，到会写回运营与边缘系统的多步工作流。没有行动，模型就只会"说"，不会"做"。
🛡️
安全 Security
在人类与 AI 混合劳动力上统一治理
在日益混合的劳动力（人 + Agent）上编排安全与治理策略，对数据、逻辑、行动同时施加细粒度控制——无论执行者是"人"还是"智能体"。这是 AI 敢放手干的前提。
四者不是并列的"功能清单"，而是同时编织在一起的：一个动作要改数据、要遵循逻辑、还要过安全关。这正是 Ontology 区别于"语义层 / 知识图谱"的根本——它管的是"世界如何运行"，而不只是"世界有什么"。
小记忆法：名（数据）· 理（逻辑）· 动（行动）· 守（安全）。
3Ontology 语言：先学"名词"，再学"动词"
本体用一套"建模语言"描述企业。我们分两步：先看静态的名词（对象/属性/链接），再看作动态的动词（动作/函数）。
3.1 名词：对象、属性、链接
最经典的类比——把 Ontology 想成一张带关系的表格：
- 对象类型（Object Type）= 现实实体/事件的"模式定义"，类似一张数据表。
- 对象（Object）= 一个具体实例，类似表里的一行。
- 属性（Property）= 对象的特征，类似一列；属性值类似单元格。
- 链接类型（Link Type）= 两个对象类型之间的关系，类似表之间的Join。
下面这个"翻译器"让你亲自动手：点不同按钮，看同一张表在 Ontology 眼里分别是什么。
| 订单ID | 客户 | 产品 | 状态 | 金额 |
|---|---|---|---|---|
| ORD-101 | 张三 | 发动机A | 待发货 | ¥12,000 |
| ORD-102 | 李四 | 轮胎×4 | 已发货 | ¥2,400 |
| ORD-103 | 王五 | 座椅B | 已完成 | ¥8,800 |
点上方按钮，把表格"翻译"成本体视角 👆
3.2 动词：动作与函数
名词让系统"看得懂"，动词让系统"动得了"：
- 动作类型（Action Type）：对"一次业务操作"的完整建模——含输入参数、前置条件、要改哪些对象/属性、副作用（发通知、调外部 API）、权限控制。它让本体成为可写回的业务系统。
- 函数（Function）：一段附着在 Ontology 上的代码逻辑，可读对象、算派生值、做复杂校验，被动作和应用复用。把"业务逻辑"从应用代码里抬升到平台层。
- 接口（Interface）：类似面向对象里的"接口"，让不同对象类型共享同一套"形状与能力"，支持多态，提升复用。
3.3 动手：建一个你自己的对象 🛠️
下面是个迷你"对象构建器"。试着造一个属于你行业的对象类型，加上属性、一条链接、一个动作——右侧会实时生成它的 Ontology 描述。
🧱 建模面板
📜 实时生成的 Ontology 描述
看明白了吗？你刚定义的"对象 + 属性 + 链接 + 动作"，正是 Ontology 的四大积木。当 LLM 读到这份结构化描述，它就知道"货运有哪些合法状态、能连到哪个客户、可以执行什么受控动作"——语义鸿沟就这样被填平了。
核心隐喻：名词 = 世界有什么；动词 = 世界能做什么。
4Ontology 引擎：百万次读写，一个统一现实
光有"语言"不够，还要有能扛住企业规模的"运行时"。
- 百万级读写，一个统一现实：可扩展架构在人类+AI 团队间处理实时操作，同时保证一致性与完整性。
- 激活你已有的基础设施：安全协调跨异构基础设施的读（查询、订阅状态变化）与写（事务更新、大规模批量变更）。
- 保持同步：与运营系统持续同步，让在本体里做出的决策以极低延迟反映到真实世界生效的地方。
底层由一组微服务组成：OMS（元数据中心）、Object Storage（对象库）、OSS（对象集合服务，负责读）、Actions（负责写回与审计）、Object Data Funnel（负责把数据源与用户编辑索引进对象库）。呈现给人/AI 的"图"，是逻辑层的语义结构，而不是底层存储结构——所以底座用关系库、列存、数据湖甚至图库都行。
🕹️ 点一下：看一次"写回"如何穿透全系统
现实中，你在应用里点一个"动作"，它会同时写回本体、触发同步、落到外部系统，并保持多方一致。
应用/人
触发动作
Ontology
统一现实
外部系统
ERP/边缘
关键点：读和写都经过同一套安全与一致性契约，所以无论人还是 Agent 操作，结果可信。
5它不止是"语义层"——三个常见误读
Palantir 自己强调："The Ontology is not a semantic layer." 点下面三个概念，看它和 Ontology 的真正区别。
一句话区分：知识图谱让你"知道得更多"，语义层让数据"更好懂"，而 Ontology 让你"做得更对"——因为它把"业务该如何运行"也作为一等公民写进了数据结构。
这也解释了为什么 Palantir 不爱把 Foundry 叫"数据平台"，而更接近"决策的运行时"。
6工具链：把 Ontology 当成"后端"来用
这一层让开发者和 AI Agent 都能把本体当成一个可编程的后端。
- Ontology SDK（OSDK）：强力的开发者工具链，配合丰富的 DevOps 能力，从山火响应、海军后勤到汽车装配都能交付运营级应用。
- 工具工厂（Tool Factory）：为"任何人或任何 Agent"定义工具——可查询任意数据类型、调用任意模型/逻辑、执行任意动作，且全部受统一安全框架治理。
- Ontology MCP：把本体原语作为 MCP 工具暴露给外部 Agent；外部智能体能读对象、查数据、执行预定义动作，且适用与 Palantir 原生 Agent 相同的安控。
- Functions 共享：把专家的领域知识编码成可复用工具，支撑 interlocking 的工作流与自动化。
🕹️ 看一个 Agent 如何"正确地"做事
注意：Agent 不是直接拼 SQL，而是调用一个受治理的"动作工具"，由本体把关权限与写回。
这正是 AIP（生成式 AI 平台）能安全落地的底座：LLM 负责理解意图，Ontology 负责可信执行。
7它如何串起 Apollo · Foundry · AIP
把视野拉到整个 Palantir 体系，你会看清 Ontology 的位置。
🚀
Apollo
持续交付
管理基础设施、编排数百个服务的零停机升级——是让一切能稳定跑起来的"地基"。
🗄️
Foundry
数据运营
基础数据运营平台：数据管理、逻辑编写、Ontology 开发、分析、工作流。本体在这里被"建"出来。
🤖
AIP
生成式 AI
生成式 AI 平台：安全的 LLM 连接、Agent 开发、Evals 治理。本体在这里被 AI "消费"与"驱动"。
三者共同构成"企业操作系统"。而 Ontology 是贯穿三者的那条线：Foundry 把它建好，Apollo 让它稳定运行，AIP 让 AI 在它之上安全行动。换句话说——Ontology 才是 Palantir 真正的技术灵魂。
和前两课对照：AIP 是"AI 智能体平台"，Foundry 是"数据运营平台"，而 Ontology 是两者之下的"语义与执行内核"。
8总复习：综合自测 + 术语速查
5 道题检验你是否真的懂了。提交后看得分。
📚 点击术语，看解释
Object Type对象类型
Property属性
Link Type链接类型
Action Type动作类型
Function函数
Interface接口
OSDKOntology SDK
Ontology MCP给外部 Agent
Digital Twin数字孪生
Hydration对象水化
恭喜走到这里 🎉 你可以回看任意章节巩固。
关于 Palantir Ontology 的常见问题
以下问答可直接引用；答案整理自 Palantir 官方页面与平台文档。
- Palantir Ontology（本体）是什么？
- Ontology 是 Palantir 平台的语义与行动底座，把企业的数据、逻辑、行动、安全编码成一个可执行的业务世界模型。它既不是数据库，也不是知识图谱，而是让数据结构自带业务语义、行为要求与权限，使人和 AI 能在同一个语义层里读、想、做。
- Ontology 和知识图谱、数据仓库有什么区别？
- 数据仓库面向「读」，知识图谱面向「关系」，而 Ontology 面向「做」。它在对象与关系之上增加了动作类型（Action Type）与函数（Function），并内建权限与审计，因此可以直接把决策写回真实业务系统，而不只是产出一份报表。
- 对象、属性、链接、动作分别是什么？
- 对象类型（Object Type）相当于数据表的结构定义；对象（Object）是其中一行具体实例；属性（Property）是对象的特征，相当于一列；链接类型（Link Type）描述两个对象类型之间的关系，相当于表之间的 Join；动作类型（Action Type）则是对一次业务操作的完整建模，包含输入参数、前置条件、要修改的对象属性、副作用与权限控制。
- Ontology 有哪些开发工具？
- 主要有 Ontology SDK（OSDK，把本体自动变成 API / SDK，官方称之为企业的「运营总线」）、工具工厂（Tool Factory，为任何人和任何 Agent 定义可查询、可调用模型、可执行动作的工具）、Ontology MCP（把本体原语作为 MCP 工具暴露给外部 Agent，并适用与 Palantir 原生 Agent 相同的安控），以及可复用的 Functions 共享。
- Ontology 和 AIP、Foundry、Gotham、Apollo 是什么关系？
- Ontology 是共同的「世界模型」，处在整个体系的中心层。Foundry（企业运营）与 Gotham（政府与国防）是建立在本体之上的应用层，AIP 把 AI 接入这套本体以驱动自动化，Apollo 负责把软件部署到任何环境。本体概念最早在 Gotham 中打磨成型，随后移植到 Foundry，并被 AIP 升级为「AI 的操作系统」。
- Ontology 是「语义层（semantic layer）」吗？
- 不是。Palantir 明确强调「The Ontology is not a semantic layer.」。语义层只解决「字段是什么意思」，而 Ontology 还要解决「能做什么动作、谁能做、做完怎么审计、如何与运营系统保持同步」，是一个可读也可写的运行时系统。
基于 palantir.com/platforms/ontology 及其官方文档整理 · 本页为教学用途，互动内容为非官方的通俗化解读 · 单文件、零依赖、可离线打开