逆向工程:Palantir Ontology 总览
摘要:本文以逆向工程的方式研究 Palantir Ontology——从 Palantir 官方公开架构出发,推断其内部系统边界,进而建立一套可运行的架构模型。文章基于官方资料梳理 Ontology 的三层切分(Ontology Language / Ontology Engine / Ontology Toolchain),覆盖 Data、Logic、Action、Security 四个核心统一对象,讨论 Object / Link / Action / Function 等核心概念及其运行时机制,并在结尾给出从拆解到自建的六阶段研究路线,以移动广告变现场景作为教学模型验证。
方法主线:官方公开架构 → 推断内部系统边界 → 建立可运行的架构模型 → 以自建业务系统验证。
总览:一张逆向工程总图
Palantir 官方明确把 Ontology 分成 Ontology Language、Ontology Engine、Ontology Toolchain 三大部分,并把 Data、Logic、Action、Security 四者作为核心统一对象。(Palantir 官方文档:Ontology System)
根据 Palantir 当前公开的 Architecture Center 与 Ontology 文档,可以把其公开架构拼成一张完整的图——Palantir Ontology Architecture v0.1:
┌──────────────────────────────────┐
│ HUMAN USERS │
│ Analysts / Operators / Developers │
└────────────────┬─────────────────┘
│
┌────────────────▼─────────────────┐
│ AI AGENTS / AIP │
│ LLM / Agent / Workflow / Copilot │
└────────────────┬─────────────────┘
│
Query / Reason / Act
│
══════════════════════════════════════════╪══════════════════════════════════
│
APPLICATION / EXPERIENCE LAYER
│
┌─────────────────┬───────────────┼────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
Operational Apps Analytics Workflows Automations
│ │ │ │
└─────────────────┴───────────────┼────────────────┘
│
Ontology SDK / API / MCP
│
══════════════════════════════════════════╪══════════════════════════════════
│
┌─────────────────────▼────────────────────┐
│ ONTOLOGY TOOLCHAIN │
│ │
│ OSDK / REST API / MCP / Dev Console │
│ App Building / Workflow / DevOps │
└─────────────────────┬────────────────────┘
│
══════════════════════════════════════════╪══════════════════════════════════
│
┌─────────────────────▼────────────────────┐
│ ONTOLOGY SYSTEM │
│ │
│ ┌────────────────────────────────────┐ │
│ │ ONTOLOGY LANGUAGE │ │
│ │ │ │
│ │ Object Types Link Types │ │
│ │ Properties Interfaces │ │
│ │ Object Views Action Types │ │
│ │ Functions Rules │ │
│ └──────────────────┬─────────────────┘ │
│ │ │
│ ┌──────────────────▼─────────────────┐ │
│ │ ONTOLOGY ENGINE │ │
│ │ │ │
│ │ Object Query / Search │ │
│ │ Object Set │ │
│ │ Object Storage / Index │ │
│ │ Actions / Transactions │ │
│ │ Functions │ │
│ │ Change Data Capture │ │
│ │ Real-time State │ │
│ └──────────────────┬─────────────────┘ │
└─────────────────────┼────────────────────┘
│
══════════════════════════════════════════╪══════════════════════════════════
│
┌────────────────────────────▼──────────────────────────┐
│ DATA / LOGIC / WORKFLOW SERVICES │
│ │
│ Data Services Logic Services Workflow │
│ │
│ Connectors ML Models Pipelines │
│ ETL / ELT LLM Automations │
│ Streaming Optimizers Orchestration │
│ CDC Functions │
└──────────────┬──────────────────┬─────────────────────┘
│ │
════════════════════════════╪══════════════════╪══════════════════════
│ │
┌───────────────────▼──────┐ ┌──────▼─────────────────────┐
│ ENTERPRISE DATA │ │ EXTERNAL SYSTEMS │
│ │ │ │
│ ERP / CRM / MES / WMS │ │ APIs / SaaS / Edge │
│ DB / Data Lake / Files │ │ IoT / Sensors / Devices │
│ Streaming / Documents │ │ External AI / Services │
└──────────────────────────┘ └─────────────────────────────┘
══════════════════════════════════════════════════════════════════════════
SECURITY / GOVERNANCE / AUDIT
─────────────────────────────
Identity
RBAC
Markings
Purpose
Row / Column security
Lineage
Authorization
Audit
Change management
↓ 横向贯穿整个系统 ↓
图中首先值得确立的判断是:
Ontology 不是这张图中间的一个数据库。
它是:
Language + Engine + Toolchain
再由下面的 Data / Logic / Workflow Services 提供能力,上面承载 Applications / Automations / AI Agents。这正是 Palantir 当前官方架构描述的方向。(Palantir 官方文档:Ontology System)
纠正一个常见误解:Ontology 不是夹在中间的一层
一种常见的错误画法是把 Ontology 放在数据库与 AI 之间:
Database
↓
Ontology
↓
AI
这是错的。
更准确的画法如下:
┌───────────────┐
│ Humans │
└───────┬───────┘
│
┌───────▼───────┐
│ AI / Agents │
└───────┬───────┘
│
Query / Reason
Decision / Act
│
┌──────────▼──────────┐
│ Ontology │
│ │
│ World Model │
│ Decision Model │
│ Action Model │
│ Security Model │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Enterprise Systems │
└─────────────────────┘
也就是说:
Ontology 是企业“可计算现实”的中间操作层。
Palantir 官方将其称为组织的 digital twin 和 operational layer。(Palantir 官方文档:Object Backend 概览)
Ontology Language:语言层与核心概念
逆向工程的第一个研究对象是 Ontology Language——描述世界的“语言”层。Palantir Ontology 的语言可以拆成:
Ontology Language
│
├── Object Type
├── Object
├── Property
├── Link Type
├── Interface
│
├── Action Type
├── Function
│
└── Object View
官方核心概念文档明确列出了 Object Type、Property、Link Type、Action Type、Roles、Functions、Interfaces、Object Views。(Palantir 官方文档:Core concepts)
Object:现实世界中的实体
假设我们经营一个航空公司。
传统数据库:
aircraft
flight
crew
passenger
airport
Ontology:
Aircraft
Flight
Crew
Passenger
Airport
但区别非常大。
数据库关注:
表是什么?
Ontology 关注:
现实世界里有什么东西?
所以:
Aircraft
│
├── registrationNumber
├── model
├── status
├── location
└── fuelLevel
它代表的是现实世界中的一个:
Aircraft
Link:现实世界的语义关系
接下来是关系:
Flight
│
├── operatedBy → Aircraft
├── departsFrom → Airport
├── arrivesAt → Airport
└── assignedTo → Crew
这就不是简单的 Foreign Key 了。
它实际上是在定义:
现实世界之间的语义关系。
所以:
Object + Link
构成了:
World Model
Action:名词之外的“动词”
到这一步,模型仍然只是普通 Ontology。真正的分水岭是 Action。
例如:
Flight
│
├── delay()
├── cancel()
├── changeAircraft()
└── reassignCrew()
这时候模型从:
“世界是什么”
变成:
“世界可以发生什么变化”。
Palantir 官方对此的表述非常直接:
nouns + verbs
Object 是 nouns。
Action 是 verbs。
而且 Action 不只是 API,它是受到权限、条件和事务机制约束的业务动作。(Palantir 官方文档:Ontology System)
核心公式:Nouns + Verbs
研究 Ontology 时,可以把下面这条公式作为始终携带的参考:
Ontology
┌──────────────┐
│ Nouns │
│ │
│ Object │
│ Property │
│ Link │
└──────┬───────┘
│
+
┌──────▼───────┐
│ Verbs │
│ │
│ Action │
│ Function │
│ Workflow │
└──────┬───────┘
│
↓
Decision
│
↓
Action
│
↓
World Changes
这就是 Palantir 和传统 Knowledge Graph 最大的分水岭之一。
Ontology Engine:Schema + Runtime
这一层非常关键:如果 Ontology 只有:
Object
Link
Action
它实际上只是一个 Schema。
真正的 Palantir 是:
Schema + Runtime
也就是 Ontology Engine。
Palantir 公开的 Object Backend 文档列出了 OMS、Object Databases、Object Set Service、Actions、Object Data Funnel、Functions on Objects 等重要组件。(Palantir 官方文档:Object Backend 概览)
可以将其逆向抽象成:
ONTOLOGY ENGINE
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
READ PATH WRITE PATH LOGIC PATH
│ │ │
▼ ▼ ▼
Object Query Actions Functions
Object Search Transactions Compute
Object Set Batch Mutations Business Logic
Aggregation CDC ML
Subscription Event Stream Optimization
Read Path
例如,AI Agent 发出查询:
“美国市场过去7天收入下降超过20%的游戏有哪些?”
它不是简单的:
SELECT ...
而可能是:
Agent
↓
Ontology Query
↓
Game Objects
↓
Country Links
↓
Revenue Objects
↓
Time Filter
↓
Permission Filter
↓
Aggregation
↓
Result
所以:
Object Set Service
非常重要——它让 Ontology 从“单个对象查询”进入:
Object Graph / Object Set computation
Write Path
Write Path 更为关键。例如:
Agent
↓
发现 Game A US eCPM 下降
↓
提出调整 AdNetwork allocation
↓
Action
↓
Permission Check
↓
Validation
↓
Transaction
↓
Ontology Object Update
↓
External System
Palantir 的 Actions 服务负责应用用户编辑,并支持复杂权限、条件以及历史 action log。(Palantir 官方文档:Object Backend 概览)
所以:
Action ≠ API call
而更接近:
Action
=
Intent
+ Input
+ Validation
+ Authorization
+ Transaction
+ Side Effect
+ Audit
这一执行机制值得作为独立专题深入逆向。
Object Data Funnel:数据进入 Ontology 的通道
可以把 Object Data Funnel 理解成:
现实世界 → Ontology 的血液循环系统。
例如:
ERP
│
MES
│
CRM
│
Streaming
│
Dataset
│
IoT
│
└──────────┐
↓
Object Data Funnel
↓
Object Database
↓
Ontology
Palantir 公开资料明确,Funnel 负责把 Foundry 数据源和用户 Action 产生的编辑写入并索引到 Object Database,并保持数据源更新后的对象状态同步。(Palantir 官方文档:Object Backend 概览)
所以:
Ontology 不是一个静态知识库。
它是:
动态世界模型。
Data Services:连接、转换与虚拟化
关于 Ontology 上层有一个常见误区:
“Ontology 自己存所有数据。”
当前的架构并非如此。Palantir 现在的架构明显是:
Data Services
│
┌─────────┼──────────┐
↓ ↓ ↓
Connectors ETL/ELT Streaming
│ │ │
└─────────┼──────────┘
↓
Ontology
Data Services 负责:
- 数据连接
- 数据转换
- 数据虚拟化
- 数据存储
- 数据质量
- 数据管理
官方 Architecture Center 对此有明确划分。(Palantir 官方文档:Architecture Center 概览)
由此得到第二个重要判断:
Ontology 不是 Data Lake 的替代品。
Logic Services:规则、模型与决策
Logic Services 的结构如下:
Logic Services
│
├── Business Rules
├── ML Models
├── Optimization
├── LLM
├── Generative AI
├── Model Ops
└── Agent Ops
这些逻辑并不一定全部塞进 Ontology,而是:
Ontology
↑
│
Logic Services
Ontology 负责:
把 Logic 接到真实世界对象和 Action 上。
所以:
ML Model
↓
预测 demand
↓
Ontology
↓
Order Object
↓
Decision
↓
Action
这就开始形成:
Decision Graph
Palantir 官方明确把 business rules、ML、optimizers、LLM 等逻辑连接到 Ontology 的决策过程中。(Palantir 官方文档:Architecture Center 概览)
Workflow:触发、审批与行动闭环
Workflow 部分经常被忽略。真正企业业务不是:
Input → Output
而是:
Trigger
↓
Analyze
↓
Decision
↓
Approval
↓
Action
↓
External System
↓
Monitor
↓
Escalate
↓
Feedback
所以:
Ontology
↓
Workflow
↓
Action
↓
External World
这也是为什么 Palantir 越来越像:
Enterprise Operating System
而不是数据库。
Palantir 官方目前直接把 AIP + Foundry + Apollo 描述为 Enterprise Operating System,并把 Ontology、Data Services、Logic Services、Workflow Services、Analytics & Applications、Automations、Product Delivery 等组成九大能力集合。(Palantir 官方文档:AIP, Foundry, and Apollo)
AI Agent 与 Ontology MCP
把 AI 放进来后,整个架构发生变化:
Human
│
▼
Application
│
▼
┌───────────┐
│ Ontology │
└─────┬─────┘
│
┌───────────┼────────────┐
│ │ │
Query Logic Action
│ │ │
└───────────┼────────────┘
│
AI Agent
│
┌──────────┼───────────┐
▼ ▼ ▼
Object Function Action
│ │ │
└──────────┼───────────┘
▼
Real World
Palantir 又增加了:
Ontology MCP
官方文档显示,Ontology MCP 可以把 Object Types、Action Types、Query Functions 暴露成 MCP tools,让外部 AI agents 安全地读取和写入生产 Ontology。(Palantir 官方文档:Dev toolchain 概览)
这个变化非常重要:
以前：
AI → API → System
现在：
AI
↓
MCP
↓
Ontology
↓
Object / Function / Action
↓
Enterprise
也就是说:
Ontology 开始变成 Agent 的“世界接口”。
Security / Governance:横切整个系统的安全层
Security 不是架构底部的“一个模块”,而应该画成一条横切带:
════════════════════════════════════════════
SECURITY / GOVERNANCE
════════════════════════════════════════════
↓ ↓ ↓
Data Logic Action
↓ ↓ ↓
└────────────┼─────────────┘
↓
Agent
↓
Workflow
Palantir 现在强调:
RBAC
+
Marking
+
Purpose
+
Lineage
+
Dynamic Authorization
+
Audit
并且安全控制会贯穿:
Object
Property
Link
Action
Function
Application
Agent
Memory
Telemetry
官方文档明确强调,Agent 调用工具时,也必须受与底层 Ontology 对象、属性、Links 相同的安全机制约束。(Palantir 官方文档:Why create an Ontology?)
这其实是 Palantir Ontology 非常深的一层护城河。
逆向工程最终架构图:v0.1
综合以上分层,可以得到最终架构总图——Palantir Ontology Reverse Engineering Architecture v0.1:
┌─────────────────────┐
│ HUMAN │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ AI / AGENTS │
└──────────┬──────────┘
│
Query / Reason / Act
│
════════════════════════════════════╪════════════════════════════════════
│
EXPERIENCE / APPLICATION
│
┌────────────┬─────────┼──────────┬────────────┐
▼ ▼ ▼ ▼ ▼
Apps Analytics Workflow Automation Agents
│ │ │ │ │
└────────────┴─────────┼──────────┴────────────┘
│
SDK / API / MCP
│
════════════════════════════════════╪════════════════════════════════════
│
┌──────────▼──────────┐
│ ONTOLOGY SYSTEM │
│ │
│ ┌─────────────────┐ │
│ │ ONTOLOGY LANGUAGE│ │
│ │ │ │
│ │ Objects │ │
│ │ Properties │ │
│ │ Links │ │
│ │ Interfaces │ │
│ │ Actions │ │
│ │ Functions │ │
│ │ Views │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ ONTOLOGY ENGINE │ │
│ │ │ │
│ │ Query │ │
│ │ Search │ │
│ │ Object Sets │ │
│ │ Object Storage │ │
│ │ Transactions │ │
│ │ Actions │ │
│ │ CDC │ │
│ │ Functions │ │
│ └────────┬────────┘ │
└──────────┼──────────┘
│
════════════════════════════════════╪════════════════════════════════════
│
┌─────────────────▼──────────────────┐
│ DATA / LOGIC / WORKFLOW │
│ │
│ Data Services │
│ Logic Services │
│ Workflow Services │
└─────────────────┬──────────────────┘
│
┌─────────────────┼──────────────────┐
▼ ▼ ▼
Enterprise Models External
Data / AI Systems
│ │ │
└─────────────────┼──────────────────┘
│
════════════════════════════════════╪════════════════════════════════════
│
SECURITY / GOVERNANCE / AUDIT
│
Identity / RBAC / Marking / Purpose
Lineage / Authorization / Audit
Change Management / Policy
闭环:World → Ontology → World
但以上架构还缺一个最重要的箭头——理解 Palantir Ontology,要把它改成一个闭环:
┌───────────────┐
│ WORLD │
└───────┬───────┘
│
Data
↓
┌───────────────┐
│ ONTOLOGY │
│ │
│ World Model │
│ Decision Model│
│ Action Model │
└───────┬───────┘
│
┌────────┼─────────┐
↓ ↓ ↓
Human AI Logic
└────────┼─────────┘
↓
Decision
↓
Action
↓
┌───────────────┐
│ WORLD │
└───────┬───────┘
│
Feedback
│
└───────────→ Ontology
这是对 Palantir Ontology 的核心理解:
Ontology = Enterprise World Model + Decision Runtime + Action Runtime + Governance + Feedback Loop
而不是:
Ontology = Knowledge Graph。
六阶段研究路线:从拆解到自建
完整的“逆向工程”可按以下六个阶段推进,每个阶段都落到数据结构与运行时行为层面,而非止于概念。
第一阶段:拆解 Ontology Language
Object
Property
Link
Interface
Action
Function
Object Set
Object View
目标:把每一个概念拆到数据结构级别,明确其 Schema 定义、API 形态与运行时行为。
第二阶段:拆解 Ontology Engine
重点研究对象:
OMS
Object Database
Object Set Service
Action Service
Object Data Funnel
Function Runtime
然后回答:
一个 Object 到底存在哪里?
Link 到底怎么实现?
Query 怎么执行?
Action 怎么保证事务?
数据变化怎么进入 Ontology?
第三阶段:拆解 Decision Runtime
建立:
Data
↓
Logic
↓
Decision
↓
Action
↓
Workflow
这是 Palantir 最有价值的部分。
第四阶段:拆解 Security Runtime
研究:
User
Agent
Object
Property
Link
Action
Function
Tool
Memory
Audit
之间到底怎么做动态授权。
第五阶段:拆解 Agent Runtime
重点研究对象:
AIP
Agent
Ontology MCP
Palantir MCP
Function
Action
Tool
Memory
Evaluation
Observability
这一层直接通向 AI Agent / Digital Persona / 企业数字分身 等研究方向。
第六阶段:自建 Mini Ontology
阶段产出不是概念图,而是一个可运行的最小实现:
Mini Ontology
┌─────────────────────────────────────────────┐
│ Ontology API │
├─────────────────────────────────────────────┤
│ Object Engine │
│ Link Engine │
│ Query Engine │
│ Action Engine │
│ Function Engine │
│ Permission Engine │
│ Event / CDC Engine │
├─────────────────────────────────────────────┤
│ PostgreSQL + Redis + Event Bus │
└─────────────────────────────────────────────┘
随后以自建的移动广告变现系统 Ad Monetization OS 作为第一套真实业务 Ontology 进行验证。
例如,广告变现领域的业务对象模型可以这样建立:
Game
Publisher
User
Country
AdNetwork
AdPlacement
AdRequest
Impression
Revenue
Experiment
OptimizationStrategy
TrafficAllocation
然后让它在真实数据上跑通完整闭环:
Data
↓
Ontology
↓
Diagnosis
↓
AI
↓
Decision
↓
Action
↓
Experiment
↓
Revenue
↓
Feedback
↓
Ontology
移动广告变现领域现有的数据链路(user_metrics → user_segment → optimization_experiment → A/B 实验 → 效果 → 知识回流)已经天然具备这个闭环的一部分,可以直接重新建模为 Ontology,而不是另造一个演示项目。完成上述闭环,即完成对 Palantir Ontology 的一次完整逆向验证。