深度剖析 Palantir Ontology 的工程化定义、数据结构、后端架构与建模哲学
Palantir Ontology 是一种声明式、平台化、可执行的业务运行模型，用于统一表达四个维度：
一句话概括：Ontology 是一个可执行的现实模型——让人和 AI 在同一个语义层里读、想、做。
不少从业者一听到"本体"就把它等同于自己熟悉的技术。这些误读会严重阻碍对 Ontology 真正价值的理解。
| 维度 | Ontology | 图数据库（Neo4j 等） |
|---|---|---|
| 底层存储 | 数据湖（Iceberg/Parquet 列存） | 原生图存储 |
| 关系表达 | 逻辑层语义结构 | 物理节点和边 |
| 可扩展性 | 关系库+列存+数据湖+图库组合 | 限于图模型 |
| DDD 概念 | Ontology 概念 | 关键差异 |
|---|---|---|
| 实体/聚合根 | ObjectType | Ontology 的对象不含方法，Action 独立声明 |
| 实体间关系 | LinkType | 关系是一等公民，自带属性和权限 |
| 应用服务/命令入口 | ActionType | 带参数、规则、权限、审计的结构化契约 |
| 领域服务 | Function | 平台级可复用函数，非某应用进程私有 |
| 维度 | 知识图谱 | Palantir Ontology |
|---|---|---|
| 核心范式 | 三元组 + 推理（RDF/OWL/SPARQL） | 对象 + 链接 + 行为 + 权限 + 运行时 |
| 核心目标 | 回答问题 | 把数据与行为写回现实 |
| 操作能力 | 查询与推理 | 读写操作 + 审计 + 权限 |
知识图谱让你"知道得更多"，Ontology 让你"做得更对"。
工程界对"如何组织企业数据"的认知，经历了三层叠加演进：
| 层级 | 本体观 | 技术代表 | 核心能力 | 典型短板 |
|---|---|---|---|---|
| L1 | 对象中心 | ER模型/关系库/OOP | 描述实体、字段、属性 | 关系语义弱，行为散落应用层 |
| L2 | 对象+关系 | Graph/Knowledge Graph | 表达复杂关系和路径 | 偏静态，缺动作与权限运行时 |
| L3 | 关系+行为+约束 | Palantir Ontology | 对象、关系、动作、权限、审计 | 平台依赖度高、迁移成本高 |
三层是叠加关系而非替代关系：L3 仍依赖 L1 的关系数据底座和 L2 的图查询能力。关键差异在于多了一个维度——把"业务该如何运行"也作为一等公民写进数据结构。
ObjectType: Vehicle（车辆） ├── id: string (主键, searchable) ├── model: string ├── status: enum[PLANNED, IN_PRODUCTION, DONE] ├── plant: PlantCode (值类型, 约束为已注册工厂代码) ├── vin: string (格式约束: vin-17) ├── scheduledStartAt: timestamp └── exteriorPhoto: mediaReference (图像/视频)
与传统建表语句的关键差异：语义注释成为一等公民，枚举驱动 UI 自动生成下拉框和 API 校验，值类型自带验证规则，媒资原生支持，索引通过 searchable 标记自动维护。
LinkType: REQUIRES_PART
├── from: Vehicle → to: Part
├── cardinality: many-to-many
└── properties:
├── mandatory: boolean (是否必装)
├── quantity: integer (数量)
├── substitute: Part[] (可替代零件)
├── validFrom: timestamp
└── validUntil: timestamp三个根本变化：关系本身是命名的（Named Relation），有业务含义；关系自带属性，UI/API/Agent 读到的不是裸 ID；关系参与权限和审计，可为每条 LinkType 单独配置权限。
ActionType: startProduction
├── parameters: { vehicle: Vehicle }
├── validation:
│ ├── allPartsInStock(vehicle) → "Missing parts"
│ └── hasAvailableLine(vehicle.plant) → "No available line"
├── rules:
│ ├── modifyObject: vehicle.status = "IN_PRODUCTION"
│ ├── createLink: ASSIGNED_TO(vehicle → line)
│ └── emitEvent: PRODUCTION_STARTED
├── permissions: { roles: [PlantManager, LineSupervisor] }
└── audit: trueActionType 将传统 Service 层代码中混杂的权限校验、前置条件、副作用编排、审计日志、通知——六大职责——拆分为声明式契约，让所有消费方（Workshop/OSDK/API/AIP Agent）共用同一份行为定义。
声明式表达不了所有逻辑——库存校验、产线调度、风险评分——这些天然适合用代码写。Function 挂在 Ontology 平台里运行，可被多个 Action、UI、Agent 调用，也可接入外部系统。一句话：ActionType 管"契约和合法性"，Function 管"怎么算出来"。
ValueType 不是基础数据类型，而是一种语义类型。例如 PlantCode 声明基础类型为 string，并附带正则约束和注册表验证。任何字段标注该 ValueType 后自动获得输入校验、跨对象一致性和 UI 自动标签，无需在每个使用点重复编写验证逻辑。
| 服务 | 角色 | 主要职责 |
|---|---|---|
| OMS | 元数据中枢 | 存储类型定义，版本化，提供类型契约查询 |
| OSv2 | 对象存储 | 存储对象与链接数据，强制写路径走 Action Service |
| Funnel | 索引同步 | 数据湖批量数据物化到 OSv2，维护检索索引 |
| OSS | 集合查询 | ObjectSet 抽象：过滤、排序、翻页、跨类型遍历 |
| Action Service | 写回中枢 | 解析 ActionType，校验权限/参数，原子执行 rules |
| Functions | 逻辑容器 | 复杂业务逻辑，外部 API/Webhook 调用 |
| Audit Log | 审计 | 不可篡改的写入记录，与 Action 同事务发生 |
一个 Action 调用经过四个阶段，确保一致性、安全性和可追溯性：
客户端提交（ActionType, params, identity）→ Action Service 从 OMS 取对应契约。
参数类型校验 × 权限校验（Role × Classification × Purpose 三维）× 业务前置条件。全部通过才进入写阶段，任何失败直接中止，不产生脏状态。
按 rules 声明顺序原子提交到 OSv2 → Funnel 异步同步索引到 OSS（最终一致）。
审计日志（与 OSv2 写入同事务）→ Webhook/外部函数调用 → 返回客户端。
关键工程结论：所有写都经 Action 路径，OSv2 不接受绕过 Action 直改对象。校验一次性发生在写之前。审计同事务——"改成功但审计漏了"不存在。对外回写在审计之后——内部先稳定留痕，再触碰外部世界。