ONTAO· 元道
Palantir Lab · 研究总纲

为什么逆向 Palantir Ontology

研究总纲 — World→Ontology→Decision→Action→Feedback

发布于 2026-09-08主线 · 第 研究总纲 / 13 篇 · 📍 所属层：

研究总纲:为什么逆向 Palantir Ontology

一句话纲领:Palantir Ontology 的价值不在"把世界描述出来",而在"让企业、软件、人与 AI Agent 共享同一个现实世界模型,并基于它决策、行动、学习"。本文是 Lab 的宣言页与研究总纲——为什么把研究主线从泛泛的 Ontology 收窄为逆向 Palantir Ontology;用怎样的框架(五层结构)拆解它;用怎样的路线(六阶段)重建它;最终要形成什么(自己的 Enterprise Ontology 理论)。

一、为什么是 Palantir:从"研究 Ontology"到"逆向企业操作系统"

如果只研究"Ontology 是什么",很容易止步于概念科普,最后产出一个知识百科。真正有价值的研究问法是反过来:

Palantir Ontology 凭什么能成为企业操作系统?把它拆开,把它的架构规律提炼成一般理论。

选择 Palantir Ontology 作为主线的理由有三条:

  1. 它是企业本体落地的当前最高工业形态——Palantir 官方对 Ontology 的定义已非常明确:它不是单纯的数据语义层,而是企业的 operational layer(业务操作层),把企业的数据、逻辑、行动和安全统一到一个可操作的模型中(公开经营规模 2025 财年营收约 44.8 亿美元,是这套体系成熟度的侧面佐证)。
  2. 它是 Ontology 从"描述学科"走向"运行学科"的分水岭——研究它,等于研究"决策操作系统"的架构本身,而不是研究某一种知识表示格式。
  3. 它是 AI Agent 时代企业软件的新地基——当 Agent 不再只是聊天机器人,而要真正操作企业业务时,它必须在一个人和机器共享、且被治理的语义面上工作。Ontology 就是这个面。

需要强调:我们研究的不是 Palantir 这个公司或产品本身,而是它背后的 Enterprise Ontology 一般架构规律。逆向工程的含义是——把一家公司的具体实现,还原成可迁移的理论、工程原则与设计取舍。

1.1 一个核心转向:从"数据 → 知识"到"世界 → 行动"

传统理解是:

Data → Knowledge → AI

Palantir 的思路更接近一条完整的业务闭环:

World → Ontology → Decision → Action → Feedback

现实世界
   ↓
数据
   ↓
Ontology
   ├── Objects        现实世界中的"东西"
   ├── Properties     东西的属性
   ├── Links          东西之间的关系
   │
   ├── Logic          如何判断
   ├── Actions        如何改变世界
   └── Security       谁可以知道 / 做什么
          ↓
      Decision
          ↓
       Action
          ↓
 Real World Change
          ↓
      Feedback
          ↓
     Ontology

这个循环里,Ontology 既是起点也是终点:它从现实世界吸收数据,支撑决策与行动,行动改变现实之后,反馈又回流进 Ontology,让模型持续更新。Palantir 官方把这一整套概括为四个组成部分:Data + Logic + Action + Security。

二、Ontology 是操作层,不是知识图谱

研究中最容易犯的方向性错误,是从传统 Ontology / Knowledge Graph 入手,陷进 Class、Property、Relationship、Entity、Triple、RDF、OWL、SPARQL 这一套描述语言。这些当然有价值,但 Palantir Ontology 真正厉害的地方不是"把世界描述出来",而是:

把"描述世界"进一步变成"可以对世界采取行动"。

它的核心概念清单已经暗示了这一点:

Object Type / Object / Property / Link Type
Action Type / Function / Interface / Object View
Roles / Security

其中 Action Type 直接定义如何修改对象,Function 则可以把代码逻辑直接接到 Ontology 上——这两个概念在传统知识图谱里根本不存在。因此研究时要把 Ontology 分成两个世界:

2.1 Semantic Layer(语义层):世界是什么?

Object / Property / Link / Interface

2.2 Kinetic Layer(动力层):世界怎么变化?

Function / Action / Workflow / Automation / Security

这两个层合起来,才接近 Palantir 的 Ontology。业界对此有一个广为流传的精炼表述:

"A semantic layer lets you read your business. An operational ontology lets you run it."
(语义层让你"读"业务;操作本体让你"运行"业务。)

这也是整个研究的第一条分水岭:我们研究的是 operational ontology,不是 semantic layer。

三、五层研究框架:从"定义"到"行动"

Palantir 官方把 Ontology 体系分为 Ontology Language + Ontology Engine + Ontology Toolchain,这是一个重要的架构思想。在此基础上,我们的研究框架进一步展开为五层——前两层回答"本体自身如何定义与运行",后三层回答"本体为什么对企业有价值":

Level 1  Ontology Language —— 如何定义世界
Level 2  Ontology Engine   —— 本体如何在海量数据上运行
Level 3  Decision          —— 本体围绕决策而非围绕数据组织
Level 4  Action            —— 决策如何变成对世界的改变
Level 5  AI Agent          —— 人与 Agent 如何在同一本体上协作

3.1 Level 1 · Ontology Language:定义世界的语言

研究要素:Object Types、Properties、Links、Actions、Functions、Interfaces——即 Ontology 的"语言"本身。三个值得深挖的机制:

学术上,这套设计有 30 年理论根基:描述逻辑的 TBox(术语层)/ ABox(断言层) 分离对应 schema 与实例;上层本体 BFO 的 Continuant(持续者)/ Occurrent(发生者) 区分,正是"属性表达现在、事件留下历史"的学术版。

3.2 Level 2 · Ontology Engine:本体是一套运行时,不是一张图

很多研究止步于"Object 怎么定义",忽略更关键的问题:Object 在海量数据中到底怎么运行? 官方公开的底层组件包括 Ontology Metadata Service、Object Databases、Object Set Service、Actions、Object Data Funnel、Functions on Objects 等。由此得到一个核心认知:

Ontology
    ↓
不是一张 Graph
    ↓
而是一套 Runtime

与之相关的两个工程真相:

3.3 Level 3 · Decision:围绕决策,而不是围绕数据组织

Palantir Ontology 最值得研究的一点是:

Ontology 不是围绕"数据"组织,而是围绕"决策"组织。

传统企业里,每个系统都有自己的数据孤岛:

CRM / ERP / MES / WMS / BI / Data Warehouse / AI Model

Palantir 想做的是让这些系统共享一个"共同现实":

              Customer
                  │
             Customer Order
             /            \
         Product          Plant
           │                │
        Inventory       Production
           │                │
           └──────┬─────────┘
                  ↓
             Decision
                  ↓
             Action
                  ↓
          ERP / MES / WMS

官方明确强调:Ontology 建模的是企业的 decisions,而不仅仅是 data。我们可以把这提炼为一个核心概念:Decision-Centric Ontology。

更精确地说,何谓决策?业界有一个非常干净的定义:

"Any write that picks a business outcome is a decision, whatever the endpoint is named, and decisions go through actions."
(任何"选择业务结果"的写入都是决策——无论端点叫什么名字——而决策都走 action。)

3.4 Level 4 · Action:从"给出建议"到"改变世界"

这是 Palantir 与众多"AI + 知识图谱"产品拉开差距的关键。传统链路里 AI 止步于建议,改变要由人手工完成:

AI → 推荐 → 人 → 自己去 ERP 修改

Palantir 的链路是:

Ontology → AI 分析 → Decision → Action → ERP/CRM/MES/WMS → 现实世界发生变化

例如一个补货场景:Plant → Inventory 下降 → Demand 预测上升 → AI 判断 → Create Purchase Order → 供应商系统。这里的 Create Purchase Order 不是简单的 API,而是 Ontology 中的一个 Action。关于 Action,有三条需要刻进脑子里的机制:

3.5 Level 5 · AI Agent:Human + AI Agent → Ontology

这是当前阶段研究它最值得的原因。Ontology 已经不只是 Human → Ontology,而是:

Human + AI Agent → Ontology

Palantir 把 Ontology 定位成让人类与 AI Agent 共同工作的 operational foundation:

                  Ontology
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
     Human         AI Agent      Software
       │             │             │
       └─────────────┼─────────────┘
                     ↓
                  Decision
                     ↓
                   Action
                     ↓
              Real World
                     ↓
                  Feedback
                     ↓
                 Ontology

在这个模型里,Agent 只是三种操作者之一——人与软件早就以各自方式操作本体,Agent 的出现只是让第三种操作者以自然语言接入同一个被治理的层。由此理解 Agent 场景下的"本体增强生成"(OAG),它比 RAG 精确得多:

这正是官方将其整体架构(AIP + Foundry + Apollo)表述为 Enterprise Operating System(企业操作系统) 的原因。

四、安全与治理:横切一切层的第四维

Data + Logic + Action + Security 四件套里, Security 最容易被当成"附加功能",实际上它是操作本体的地基——因为一旦 Agent 能直接改数据,安全就从"事后审计"变成"事前的运行前提"。核心机制可归纳为五组:

还有一个容易被忽略的所有权问题:每个状态必须声明所有者。写回所有权分三态——source-backed(状态归源系统,如订单状态以 ERP 为准)、local-backed(状态归本体,如本地决策状态)、decision(决策写入);无所有者的状态是禁止的,因为"本地副本改了却不写回"会产生幽灵状态。业界对此有一句狠话:

一个完全没有源写回(系统间真实同步)的实现,并不是这个模式的缩小版——它只是一个带自己数据库的普通应用。

五、研究路线:六阶段逆向工程

不按传统"Ontology 课程"从概念学起,而是直接做一轮 《Palantir Ontology Reverse Engineering》,分六个阶段,边逆向边重建。

Phase 1 · Understand——概念还原

把 Object、Property、Link、Action、Function、Interface、Object Set、Object View 这八个核心概念逐一搞懂。

完成标志:能够完全不用 Palantir 的术语,用自己的话解释每一个概念到底解决什么问题。

Phase 2 · Model——真实业务建模

选一个自己真正熟悉的业务领域(例如广告变现系统),建立对象清单与关系网络:

Game / App / User / Country / AdNetwork / AdPlacement
AdRequest / AdImpression / AdClick / Revenue
Campaign / Experiment / Publisher

Game       ├── has → AdPlacement   ├── has → User
           ├── generates → Impression   └── participates → Experiment
Impression ├── belongs_to → AdNetwork / Country
           └── generates → Revenue

这一步非常关键,因为会亲身体验到:Ontology 不是画图,而是在定义"业务现实"。

Phase 3 · Act——动作实验

让系统在本体上执行一个真实的业务动作,而不只是展示数据。例:系统发现某条流量链路的 eCPM 持续下降,AI 提出将部分流量在两家广告网络间切换——这不是一份建议报告,而是 Ontology 中的一个 Action(SwitchTrafficAllocation),输入是类型化的参数(Game / Country / AdNetwork / Percentage / Reason),执行后真实改变投放配置,结果(真实流量与收入变化)重新进入 Ontology。

这一阶段过后才会真正理解:Palantir Ontology ≠ Knowledge Graph,而是 Knowledge + Decision + Action + Feedback 的闭环。

Phase 4 · Systemize——全链路操作化

把整个业务的运行环搬上本体:

数据 → 分析 → 发现问题 → 策略 → 实验 → 执行 → 结果 → 知识沉淀

此时系统自然呈现出本体的运行骨架:

Object → State → Decision → Action → Experiment → Outcome → Learning

因此不需要单独造一个 ToDo / CRM 式的 Ontology Demo——直接用自己正在运营的业务系统做实验场,比任何教学示例都更早暴露真实问题(命名、所有权、写回、审计),价值也高得多。

Phase 5 · Reverse——逆向架构

回到 Palantir:先画出它的完整技术架构(语言层、引擎层、工具链、治理机制),再逐个模块对照自己的实验场,判断每个机制"解决什么问题、代价是什么、我们的场景需不需要"。以官方一手文档为教材,二手解读只作线索,不代替原文。

Phase 6 · Theorize——自建理论

研究到后期,不再停留在"Palantir Ontology 是怎么做的",而进入:

"我认为 Enterprise Ontology 应该怎么做?"

六阶段的终点不是一份逆向报告,而是一个自己的理论模型。

六、终点:形成自己的 Enterprise Ontology 理论

6.1 一个初始假设

研究前期可以先立一个待检验的假设模型——它不是结论,而是后续所有工作的靶子:

                 ENTERPRISE ONTOLOGY
                         │
        ┌────────────────┼────────────────┐
        ↓                ↓                ↓
     SEMANTICS        KINETICS         GOVERNANCE
        │                │                │
   Objects/Links     Actions/Logic     Security
        │                │                │
        └────────────────┼────────────────┘
                         ↓
                     DECISION
                         ↓
                    AI / HUMAN
                         ↓
                      ACTION
                         ↓
                   REAL WORLD
                         ↓
                     FEEDBACK
                         ↓
                   LEARNING

三个支柱缺一不可:SEMANTICS 回答"世界是什么",KINETICS 回答"世界怎么变",GOVERNANCE 回答"谁在什么条件下可以知道与行动";三者汇合于 DECISION,经人与 AI 执行 ACTION,改变 REAL WORLD,再经 FEEDBACK 回流成 LEARNING——学习又反过来修正三个支柱本身。这个闭环,就是操作本体与语义层的根本区别。

6.2 研究的本质

最终研究的其实不是"Ontology"这个词,而是:

如何建立一套让企业、软件、人与 AI Agent 共享同一个"现实世界模型"的计算系统。

这套系统需要回答三个层次的工程问题:模型层(如何定义现实)、运行层(如何让模型活在真实数据与系统之上)、治理层(如何让所有写操作都可验证、可审计、可逆)。Palantir Ontology 是当前对这三个问题最完整的一份公开答卷——这就是它值得被逆向的原因。

6.3 Lab 的定位与研究地图

Lab 的定位是 Ontology Engineering Lab——研究 Enterprise Ontology、Palantir Ontology 与 AI Agent Operating System 的理论、架构与工程实践。围绕这篇总纲,研究地图分为四块:

palantir 逆向
   ├── ontology-language / ontology-engine / ontology-toolchain
   ├── objects / links / actions / functions / interfaces / security
   └── decision-centric 本体

对照研究
   ├── ontology vs knowledge-graph / semantic-layer / data-warehouse
   └── ontology vs agent-memory

工程方法论
   ├── object-model / action-model / event-model
   └── feedback-loop

案例研究
   ├── ad-monetization / e-commerce / manufacturing
   └── AI-agent

教材纪律只有一条:以官方一手资料作为第一手教材。官方文档已经把 Ontology 的 Language、Engine、Toolchain、Data/Logic/Action/Security 与 Agent 场景逐步讲得很完整——先读原文,再谈解读。

参考资料

Palantir 官方文档

机制与深度解读

学术根基