Ontology 怎样构建企业数字天下：Palantir 技能原理

Palantir 技能原理先容

本文档基于 Palantir 官方《平台概览》、Foundry 文档（Object backend、Action types、AIP features）整理，探究 Ontology（本体）、数据构造、决定机制与团体技能框架。公司定位、贸易模式与案例见同目次下《业务先容.md》。ER/OOP 与 Ontology 在存储与活动模式上的对比见《数据存储与使用方式对比.md》。

一、什么是 Ontology（本体论），与一样寻常的对象关系有什么差异？

1.1 官方界说

Palantir《平台概览》中的界说要点如下（中文版 / 英文版）：

Ontology 旨在体现企业中的决定，而不光仅是数据。

在工程上，Ontology 是一个语义层，用于毗连数据与现实天下的业务对象、关系和决定流程。它包罗 数据 (Data)，逻辑 (Logic)，使用 (Action) 三大要素，同时 安全 (Security) 贯穿此中。

• 数据 (Data)：究竟与状态。哪个现有究竟或本相构成了这个决定的配景？
  
• 逻辑 (Logic)：规则、模子、外部回调（护栏与分析）。哪些业务规则或内在逻辑作为决定的护栏？差异假设下的结果概率怎样？
  
• 使用 (Action)：怎样落地、回写，受权限与审计束缚。决定在现实天下中怎样体现？动力学要求是什么？
  

安全 (Security) 是管理层，涵盖基于脚色、标志和目标的访问控制，以及端到端的数据血缘追踪。安全也是Palantir的光显特点之一。
Ontology 布局的构成紧张包罗对象（Objects）、链接（Links）、活动范例（Action Types）、函数（Functions）与束缚（含权限/审计）。Action 是通过 Action Type 独立界说并实行的，而不是实体类上的方法，这与 DDD（范畴驱动计划）中的“富血模子”有本质区别。详见《数据存储与使用方式对比.md》第七章。
1.2 哲学底子：两种本体观

哲学本体论概念在工程里常有两种体现：

• 实体本体论（对象为主、关系附属 → ER/OOP）
  
• 关系/过程本体论（关系与变革为主 → 图、分布式状态、Palantir）。
  

关系过程本体论更贴近 Palantir：除了“有哪些对象”，还要关心怎样关联、哪些动作能改状态、受何束缚。 因此 Ontology 不是静态数据存储，而是把究竟、规则、权限与举措连在一起的语义层。
Palantir 还贯穿了“本体—熟悉—实践”三层哲学。 “过程本体”只是 Palantir 的第一层。纵观整个平台，可以看到平台同时涉及三个传统哲学概念——天下由什么构成、我们怎样熟悉它、怎样把熟悉酿成举措。 Ontology（Ontology 只是其涵盖的一层）。
flowchart LR    ONTO["① 本体论：ObjectType / Link / Property"]    EPI["② 熟悉论：ActionType / Function · OAG"]    PRAX["③ 实践论：FDE · AIP 写回"]    ONTO -->|语义底座| EPI    EPI -->|规则与左券| PRAX    style ONTO fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#0f172a    style EPI fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#1e1b4b    style PRAX fill:#ffedd5,stroke:#d97706,stroke-width:2px,color:#431407哲学概念哲学标题Palantir 的对应实现本体论（Ontology，"有什么"）业务天下由哪些对象、关系、链接构成？ObjectType + LinkType + Property：声明业务实体、具名关系与属性，作为平台共享的究竟底座（详见 2.1）熟悉论（Epistemology，"怎样熟悉"）体系怎样对天下做推理、盘算与分析？ActionType + Function + Models / Analytics：ActionType 把"哪些变更合法、须要哪些参数与校验"声明为可读左券；Function/Webhook 接入规则与外部知识；Models、Contour、Quiver 做推测、优化与归因；OAG（Ontology Augmented Generation） 让 LLM 的检索发生在 Ontology 语义层而非裸文本上（详见 3.1）实践论（Praxis，"怎样酿成举措"）熟悉怎样在构造中真正落地、改变现实？FDE 驻场 + AIP 决定回路：FDE（Forward Deployed Engineer）作为人侧抓手深入客户的工厂、战场、医院，把现实工作流翻译成 Ontology 与 Action；AIP 作为呆板侧抓手，让 Agent 走 Proposal → 人审 → Action → Audit 把决定推到生产体系（详见 3.2、3.4）三层是嵌套束缚关系：熟悉论里的 Function 与 ActionType 必须挂在本体论给出的 ObjectType 上才有语义；实践论里的 AIP 决定又必须穿过本体论与熟悉论给出的对象、规则、权限才气写回。这也是 Palantir 与"只做一层"的厂商最大的差异——数仓/图数据库厂商紧张办理本体论标题（建模"有什么"），BI / AutoML 厂商紧张办理熟悉论标题（建模"怎么算"），传统咨询/集成商紧张办理实践论标题（把方案塞进客户业务）；Palantir 的焦点卖点是把三层合到同一个语义层、同一套权限体系、同一条审计链路里，使得对象、推理与举措之间不再有跨体系的"翻译消耗"。

参考：Palantir 官方 AI FDE 概览、AIP Logic Overview、Palantir Blog Building with Palantir AIP: Logic Tools for RAG/OAG（OAG = Ontology Augmented Generation 概念出处）。

1.3 工程建模的三层演进

层级本体观技能代表紧张本领L1对象中心ER / OOP形貌实体、字段、属性L2对象 + 关系Graph / Knowledge Graph表达复杂关系和路径L3关系 + 活动 + 束缚Palantir Ontology对象、关系、动作、权限、审计1.4 与"一样寻常对象关系（ER / OOP）"模子的紧张差异

ER 紧张形貌表布局和外键；OOP 常把活动写在应用层类方法里。Palantir Ontology 用 ObjectType / LinkType / ActionType 在平台层声明对象、关系和可实行变更，权限与审计按界说同一收效。应用、Workshop、AIP Agent 只是调用这套界说，不须要各写一遍“谁能改什么”。

维度一样寻常的对象/关系模子Palantir 的 Ontology建模目标数据布局、字段束缚数据布局 + 业务运行语义 + 可实行变更的左券（回复"有什么、谁能动它、怎么动、留什么痕"）根本元素实体、属性、外键关系对象 + 链接 + 属性 + ActionType 对象（ObjectType 实例）映射业务实体； 链接（LinkType 实例）具名关系； ActionType 形貌可实行变更左券，运行时一次调用常称 Action，不是实体类上的方法与权限通常外挂在应用层权限 / 分类 / 目标访问控制内置于本体，随每一次数据调用自动收效与逻辑业务规则散落在应用或 ETL逻辑以模子、Function、Webhook、规则挂到 Ontology 上，供应用、管道与 Agent 在运行时调用与动作读写由应用各自实现ActionType 为独立一等范例，带细粒度权限与审计，可经 OSDK / 平台 API 对外袒露为可调用的 Action与 AI后接 LLM 对表问 SQL/自然语言在 Ontology 语义与权限下让 LLM/Agent 明白对象、链接、可调用的 Action，通常经 Proposal 与人审，而非默认直连写回与外部天下通过定制集成写回通过 Action、外部函数与 Webhook 在权限和审计下同步流程上，传统做法多是「库 → 应用 → 逻辑 → 使用」闭环；Ontology 把对象、关系、逻辑与 Action 串成可审计、可回写的闭环（上表已概括差异，此处不另画图）。
1.5 为什么 Ontology 对企业 AI 紧张

常见断层是：只把 LLM 接到湖表，缺业务语义与可调用的动作左券。Ontology 用对象/链接表达”是谁、与谁干系“，用 Action 与权限束缚”能改什么“；Agent 侧多经 Proposal 与人审再写回，变更可审计。AIP（Logic、Agent Studio、Threads 等，视租户开通情况）叠在这层之上，详见官方 AIP 功能总览。更细的决定链见第三节。
二、数据是怎样构造的？

2.1 对象 + 链接：形貌真实天下的图谱

Ontology 将数据构造为对象（Object）与链接（Link）：

• 对象对应真实天下中的实体：飞机、病人、订单、油井、任务、传感器等；
  
• 链接是对象之间的具名关系：installed_on、assigned_to、part_of、supervised_by……
  

这套模子让运营复杂性对人与 AI 都可明白——读到一个对象，就能沿着链接走到与之干系的全部上卑鄙，而不必像传统数仓那样靠 JOIN 一步步推导。

注意：Ontology 不是图数据库（Neo4j / JanusGraph）。

2.2 平台支持的数据范例与扩展

Foundry / Ontology 能纳管的数据范例比力杂：布局化、非布局化、地理空间、时间序列、模仿数据都在范围内；别的还提供了几个特别为"决定场景"准备的扩展基元：

• 语义搜刮（Semantic Search）：用向量化方式解锁非布局化数据（文档、通联记载、工单形貌）的检索；
  
• 媒体引用（Media Reference）：把图像、视频纳入对象属性，供视觉模子或人审使用；
  
• 值范例（Value Type）：为数据嵌入额外束缚与上下文（单位、合法取值、密级等），制止"一个字段寄义各说各话"。
  

2.3 数据接入：多模式、零拷贝

数据很少以"干净形状"到达。Palantir 提供一套可扩展、多模式的接入框架：

• 当场 / 零拷贝访问：对接现有数据湖与平台，只管制止"二次存储"；
  
• 批流同一的构建体系：同一套底子办法跑批处理处罚和流处理处罚（官方文档表述为"批流同一"，底层实现细节以 Palantir 为准）；
  
• Pipeline Builder + Code Repositories：前者是低代码点选式管道，后者是工程化的代码管道；
  
• LLM 数据变更：在 Pipeline Builder 里直接调用 LLM 做分类、感情分析、择要、实体抽取、翻译等；
  
• AIP Assist：在 Pipeline Builder 和代码堆栈里提供 AI 编程助手，相识 Palantir 文档与内部 API。
  

2.4 把数据模子酿成同一接口

在 Ontology 中建模数据会自动衍生出两件事：

• Ontology SDK（OSDK）：企业表里的应用都能以对象/链接/动作为语义调用业务；
  
• 平台 API：第三方工具可安全地读写 Ontology。
  

更精确地说，Ontology 提供的是一层同一语义接口。条件是相应对象、Action、权限和 API 已在租户内设置并袒暴露来；并不是任何底层数据一接进来，就自然自动酿成可供外部体系调用的业务接口。
2.5 Ontology 在工程上“存在那里”（不是图数据库）

紧张：业务视角上的“图”不便是摆设一套 Neo4j。Foundry Ontology 后端由多服务构成：Ontology Metadata Service (OMS)、Object databases（Object Storage）、Object Set Service (OSS)、Object Data Funnel、Actions、Functions 等协同完成索引、查询、写回与权限。对象数据可来自数据湖中的 Iceberg/Parquet 等，经索引进入面向应用的查询面。

• Object Storage V1（Phonograph）：旧版对象存储，官方已规划弃用（如文档所述目标日期前需迁移到 OSv2）。
  
• Object Storage V2 (OSv2)：新一代 Ontology 数据面；OSv2 在写回上夸大 Action 路径，并与 Funnel 等组件分工（详见官方 Object backend 概览、OSv1/OSv2 分析）。下面是官方给出的总体架构图。
  

根据官方架构图和文档把后端几个焦点折务天生了下面这张图，以便分析各模块的职责，以及流程内里怎么共同。详细调用细节以 Palantir 文档为准；图本身只是方便明白服务边界。
flowchart TB    subgraph SRC[数据源]        LAKE[(数据湖
Iceberg / Parquet / Delta)]        EXT[外部体系
ERP / MES / IoT / 文档]    end    subgraph PIPE[接入与构建]        PB[Pipeline Builder
Code Repositories]    end    subgraph META[元数据面]        OMS[Ontology Metadata Service
OMS
范例/链接/Action 界说]    end    subgraph DATA_PLANE[数据与查询面]        OSv2[(Object Storage V2
对象 + 属性)]        OSS[Object Set Service
聚集 / 过滤 / 翻页]        FUNNEL[Object Data Funnel
索引 / 物化 / 同步]    end    subgraph EXEC[实行面]        ACT[Action Service
校验 / 规则 / 写回]        FN[Functions
外部函数 / Webhook]        AUD[Audit Log
不可篡改记载]    end    subgraph CLIENT[消耗方]        WS[Workshop / Dashboards]        OSDK[OSDK / 平台 API]        AIP[AIP Agent / Logic]    end    LAKE --> PB    EXT  --> PB    PB   --> FUNNEL    FUNNEL --> OSv2    OSv2 -.写后索引同步.-> FUNNEL    OMS  -.范例左券.-> OSv2    OMS  -.范例左券.-> ACT    OSv2 --> OSS    OSS  --> WS    OSS  --> OSDK    OSS  --> AIP    WS   --> ACT    OSDK --> ACT    AIP  --> ACT    ACT  --> FN    ACT  --> OSv2    ACT  --> AUD    ACT  -. Webhook .-> EXT    style SRC fill:#fff7ed,stroke:#c2410c,stroke-width:2px,color:#000    style PIPE fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,color:#000    style META fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000    style DATA_PLANE fill:#dbeafe,stroke:#1d4ed8,stroke-width:2px,color:#000    style EXEC fill:#ede9fe,stroke:#6d28d9,stroke-width:2px,color:#000    style CLIENT fill:#dcfce7,stroke:#15803d,stroke-width:2px,color:#000简化影象：OMS 管"是什么"，OSv2 + OSS + Funnel 管"在哪、怎么读"，Action Service + Functions 管"怎么改、改完留什么痕"。读路径紧张走 OSS → OSv2，写路径紧张走 Action → OSv2 + 审计 + 可选 Webhook 写回外部。

关于 Funnel 的双机会：Funnel 既到场接入侧（Pipeline Builder 产出 → 物化为对象进入 OSv2，图中实线 PB → FUNNEL → OSv2），也到场写后索引同步（Action 写入 OSv2 后，Funnel 把变更同步到查询聚集，图中虚线 OSv2 -.写后索引同步.-> FUNNEL）。下文 3.2 的时序图只展示第二种机会。

同一范畴标题的更细存储与 Action 对比见《数据存储与使用方式对比.md》。
2.6 一条最小运行链路

假如从架构实现角度看，一条典范调用链大抵是如许：

• 数据从 ERP、MES、日志体系、文档体系、传感器平台等接入 Foundry；
  
• 专门管道把原始数据整理成对象、链接和属性，进入 Ontology；
  
• Function、规则或外部函数补上盘算逻辑；
  
• ActionType 界说哪些变更可以被实行，以及实行时要颠末哪些校验、权限和审计；
  
• Workshop、OSDK、平台 API 或 AIP Agent 调用这些对象与 Action；
  
• 动作实行后，结果再写回 Ontology，须要时再同步到外部体系。
  

这条链路对架构师的意义在于：数据层、语义层、动作层、权限层和应用层不是各自零星实现，而是被放进了同一条运行路径里。
三、数据是怎样决定的？

官方把决定过程分解为"数据—逻辑—使用"三段，三者在 Ontology 中同层、同语义、同权限。
3.1 逻辑层：为决定提供"推理与分析"

逻辑层贯穿整个平台，大抵分为三类：
(a) 模子（Models）

• 覆盖 LLM、推测、优化器等；
  
• 支持平台内训练、自带容器（BYOC）、上传预训练模子三种接入方式；
  
• 以"建模目标（Modeling Objective）"承载模子的完备生命周期，以"模子适配器（Model Adapter）"抽象差异模子的调用；
  
• 通过 Function 把模子绑定进 Ontology，运营应用可实时调用；
  
• 通过批量摆设（Batch Deployment） 在数据管道中操持实行；
  
• 对天生式 AI 提供同一的语言模子服务，抽象差异 LLM 提供商的差异；
  
• 评估（Evaluations）工具用于跨模子、跨时间基准测试，监控漂移。
  

(b) 业务逻辑（Business Logic）

• 外部体系里的既有规则：通过外部函数 / Webhooks（实时）或外部变更（管道）接入；
  
• 平台内原生表达：Rules、Pipeline Builder、Automate、Functions。
  

(c) 模板化分析与陈诉

• Contour / Quiver：点选式分析工具；
  
• Code Workspaces：Jupyter / RStudio 风格的代码分析；
  
• Object View / Workshop 应用 / Dashboards：分析产物可复用、可嵌入运营应用；
  
• 支持 Tableau、Power BI 的专用毗连器。
  

这三类逻辑可以组合使用，在决定时补齐上下文。
3.2 使用层：让决定产生现实影响

在 Ontology 中，ActionType 形貌一类可实行变更的左券（参数、规则、权限、审计）；运行时发起的一次调用常称为 Action。二者在文档里偶然混用，这里按“范例 vs 调用”区分。创建/更改对象、在外部体系中触发变更，都经这条路径表达。关键计划：

• 细粒度权限：每个 ActionType 的权限独立设置，决定哪个用户或署理能在什么条件下实行对应 Action；
  
• 简单到复杂的界说路径：底子 Action 可点选设置，复杂 Action 可用函数支持的 Action 和 Ontology Edit TypeScript API 写恣意逻辑；
  
• 对外打包：Action 打进 OSDK / 平台 API，第三方应用可安全回写；
  
• 结果可回传：Action 的结果会回到 Ontology，便于后续再训练、微调和复盘。
  

这里有一个对架构师很紧张的边界：

• 声明式层 得当放对象范例、关系范例、权限、校验条件、可执举措作的根本左券；
  
• 代码层 得当放复杂盘算、外部体系编排、算法、批量处理处罚和难以通过设置表达的业务规则。
  

Palantir 的重点不是“完全不要代码”，而是把得当声明的部分平台化，把必须写代码的部分收敛到更清晰的边界里。
一次 Action 调用的时序

下面这张时序图把 2.5 提到的几个后端服务串起来，明细"谁先谁后、错误从哪抛出"。下文把"应用 / OSDK / Agent"同一称作客户端。
sequenceDiagram    autonumber    participant CLI as 客户端
(Workshop / OSDK / Agent)    participant ACT as Action Service    participant OMS as OMS
(范例左券)    participant FN  as Function
/ Webhook    participant OS2 as OSv2
(对象数据)    participant FUN as Object Data Funnel    participant OSS as Object Set Service    participant AUD as Audit Log    participant EXT as 外部体系    Note over CLI,EXT: ① 左券获取    CLI->>ACT: invoke(ActionType, params, identity)    ACT->>OMS: 查 ActionType 界说 / 关联范例    OMS-->>ACT: 参数、rules、权限、审计设置    Note over CLI,EXT: ② 校验（决定是否进入写阶段）    ACT->>ACT: 校验参数 + 权限 (Role / Classification / Purpose)    alt 含 Function 校验        ACT->>FN: submission criteria(params, world)        FN-->>ACT: 通过 / 拒绝(缘故原由)    end    Note over CLI,EXT: ③ 数据写入与索引同步    ACT->>OS2: apply edits (modifyObject / createObject / link)    OS2-->>FUN: 同步索引（异步）    FUN-->>OSS: 更新可查询聚集（终极划一）    Note over CLI,EXT: ④ 审计与外部回写（同事件）    ACT->>AUD: 写审计 (who/what/when/why)    opt 设置了对外回写        ACT-->>EXT: Webhook / 外部函数调用    end    Note over CLI,EXT: ⑤ 返回与后续读    ACT-->>CLI: result + (validationError | success)    CLI->>OSS: 后续读 (objects, links, sets)    OSS-->>CLI: 视图数据 (按权限裁剪)关键点：

• 校验在 Action Service 内一次性发生：参数范例、权限、Function 情势的 submission criteria 全部通过，才会进入数据面修改阶段；
  
• 全部写都经 Action 路径，OSv2 不担当"绕过 Action 直改对象"的哀求（OSv2 的官方表述）；
  
• 审计是同事件发生的副作用，不是事后补记；
  
• 索引同步是终极划一：OSv2 → Funnel → OSS 通常异步发生，Action 返回乐成的刹时 OSS 上的查询结果大概尚未革新；"写完立即查"要走 OSDK 的强划一读路径或显式期待索引停当；
  
• 对外回写（Webhook / 外部函数）发生在审计之后，制止"外部体系改乐成，但内部状态没留痕"。
  

3.3 场景（Scenario）：安全地"假想推演……"

在精密耦合的体系（供应链、制造车间、战场态势）里，一个小改动会引发级联效应。Ontology 提供 Scenario 原语：

• 在 Ontology 的一个分支上做修改，如同在"沙盒宇宙"里预演；
  
• Vertex 应用专门用于过程可视化与情况测试；
  
• Workshop 构建器原生支持"假如……"工作流。
  

Scenario 在底层做了什么（按官方的形貌推断，不肯定完全精确）

Scenario 不是把整套数据完备复制一份，那样代价太高。官方文档的形貌是：分支只存"相对主线 Ontology 的增量"——修改过的对象属性、新建对象、删除对象、新建/删除链接范例——别的仍共享主线。这就是写时复制（copy-on-write）的逻辑分支。读路径先看分支增量、再回落主线；分支被抛弃时增量直接抛掉。
工程上这意味着：

• 隔离写、共享读：分支只负担"差异部分"，多数对象仍指向主线。
  
• 权限同样收效：分支里跑的 Action 也走 Role / Classification / Purpose 校验，不会由于是"沙盒"就放宽。
  
• Scenario 创建后不可变（immutable），且不会自动归并回主线：官方原文是 "A Scenario is immutable once created"。要"修改"一个 Scenario，须要新建一个带差异 Action 聚集的 Scenario。
  
• 想让推演结果落到主线，得另走一条路：要么在主线上重新发起对应 Action（Scenario 充当人审/对比用的"草稿"），要么走 Foundry Branching / Ontology Proposals——它才是带 Pull Request 风格审阅与归并的机制。Scenario 与 Foundry Branch 是两个差异概念，常被等量齐观。
  
• 不可作为事件保障：Scenario 是用于推演，不更换数据库事件；高划一性要求的写仍走 Action 主路径。
  

以上联合官方 Workshop Scenarios 与 Foundry Branching 文档归纳；详细实现细节与租户现实本领以 Palantir 文档为准。

3.4 人机协作：Proposal 模式

AIP 的常见落地方式不是“让 AI 直接改体系”，而是：

• AI 署理天赋生提案（Proposal）（可通过 Workshop 中的 AIP Logic 同步天生，或通过 Automate / Pipeline Builder 的 Use LLM 节点异步天生）；
  
• 提案出现给人类使用员；
  
• 使用员审阅、改进、终极决定；
  
• 每个提案都天生元数据，反过来帮署理学习与演进。
  

这套“署理—沙盒—提案—审阅”流程，焦点就是把人放在终极决定位。
四、技能框架是什么？

4.1 Palantir 平台的总体布局

官方《平台概览》里平台本领先容较多，通过整理，总体上可以自上而下拆成 8 层。

• Ontology 是平台焦点；
  
• AIP 创建在 Ontology 之上；
  
• Action 本质属于 Ontology 的运行本领；
  
• Apollo 更偏平台运维与交付，而不是业务本领层。
  

flowchart BT    SRC[外部体系
ERP / MES / CRM / IoT / Documents]    DATA[1. 数据工程与存储层
Pipeline Builder / Stream / Batch / OSv2 / Data Lake]    LOGIC[2. 逻辑与模子层
Rules / Models / Functions / Webhooks]    ONT[3. Ontology 语义层
ObjectType / LinkType / ActionType / Function]    ACT[4. Action 实行与运营层
Workflow / Automation / Writeback / Operations]    AI[5. AIP 智能本领层
AIP Logic / Agent Studio / Threads]    APP[6. 应用与用例层
Workshop / Dashboards / OSDK App]    GOV[7. 安全与管理层
Identity / Purpose / Policy / Audit / Encryption]    OPS[8. 平台运维与交付层
Apollo / Control Panel / Marketplace / Upgrade]    U[用户 / 业务职员 / 开辟者 / Agent]    EXT[外部实行
工单 / 调治 / 关照 / 业务闭环]    %% 主链路（自底向上）    SRC --> DATA    DATA --> LOGIC    LOGIC --> ONT    ONT --> ACT    ONT --> AI    AI --> APP    APP --> U    ACT --> EXT    %% 横向管理    GOV -.管理束缚.-> DATA    GOV -.管理束缚.-> LOGIC    GOV -.管理束缚.-> ONT    GOV -.管理束缚.-> ACT    GOV -.管理束缚.-> AI    GOV -.管理束缚.-> APP    %% 运维与交付    OPS -.发布与运维.-> DATA    OPS -.发布与运维.-> ONT    OPS -.发布与运维.-> AI    OPS -.发布与运维.-> APP    %% 样式    style SRC fill:#f3f4f6,stroke:#4b5563,stroke-width:1px,color:#000    style DATA fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,color:#000    style LOGIC fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000    style ONT fill:#dcfce7,stroke:#15803d,stroke-width:2px,color:#000    style ACT fill:#ede9fe,stroke:#6d28d9,stroke-width:2px,color:#000    style AI fill:#fce7f3,stroke:#be185d,stroke-width:2px,color:#000    style APP fill:#dbeafe,stroke:#1d4ed8,stroke-width:2px,color:#000    style GOV fill:#fee2e2,stroke:#b91c1c,stroke-width:2px,color:#000    style OPS fill:#e5e7eb,stroke:#374151,stroke-width:2px,color:#000    style U fill:#fff7ed,stroke:#c2410c,stroke-width:2px,color:#000    style EXT fill:#ccfbf1,stroke:#0f766e,stroke-width:1px,color:#000

• 数据工程与存储层（Data Foundation）
  数据接入、批流处理处罚、Data Lake、OSv2、数据管道与数据服务。
  
• 逻辑与模子层（Logic & Compute）
  Rules、Functions、Webhook、Transform、模子推理与业务盘算。
  
• Ontology 语义层（Ontology）
  ObjectType、LinkType、ActionType、Function、语义对象与业务天下建模。
  
• Action 实行与运营层（Operational Actions）
  Workflow、Automation、Writeback、Operational Runtime、业务闭环实行。
  
• AIP 智能本领层（AIP）
  AIP Logic、Agent Studio、Threads、LLM Runtime、AI Agents。
  
• 应用与用例层（Applications）
  Workshop、Dashboards、OSDK App、业务应用与交互界面。
  
• 安全与管理层（Governance & Security）
  Identity、Policy、Purpose、Audit、Encryption、数据管理与权限体系。
  
• 平台运维与交付层（Platform Operations）
  Apollo、Control Panel、Marketplace、升级与平台级运维。
  

4.2 三大平台的关系

业务侧的产物矩阵（Gotham / Foundry / AIP）与技能侧的运行分工不是同一张图。下表从技能架构角度拆四件东西在栈里各占什么位置；产物定位 / 客户场景见《业务先容.md》1.2。
组件在技能栈里的位置紧张职责与 Ontology 的关系摆设形态Foundry数据 + 应用运行面数据接入、批流处理处罚、OSv2、Function、Workshop、Pipeline Builder——把数据"跑起来"的全套底子办法提供 Ontology 的存储与实行情况（OMS、OSv2、Action Service 等都跑在 Foundry 上）贸易云、专网、政府云Ontology语义层（Foundry 之内的焦点）ObjectType / LinkType / ActionType / Function / 权限 / 审计——把业务对象、关系、动作、束缚同一表达自身便是语义层随 Foundry 摆设，不独立交付AIP智能本领层（Ontology 之上）LLM 函数、Agent Studio、Threads、AIP Logic——让 LLM/Agent 在 Ontology 的语义和权限下工作强依靠：Agent 只能看到 Ontology 袒露的对象和 Action，写回必经 Action + 审计跟随 Foundry / Gotham 地点情况Gotham与 Foundry 并列的政府/国防产物线与 Foundry 共享对象、链、安全协作的底层理念，但交付情况、鉴权模子、网络隔离要求都差异同样以本体 + 安全协作为焦点，工程实现细节不公开政府云、隔离网、专网Apollo平台运维与交付层（跨全部产物）一连摆设、版本编排、灰度、回滚——把 Foundry / AIP / Gotham 的更新推到云、当地、边沿、隔离网自身不读 Ontology，但负责把承载 Ontology 的运行时稳固发布到各情况控制面会合、实行面分布在各目标情况几个常被肴杂的点：

• AIP 不是与 Foundry 并列的"另一套数据库"：它是本领剖面 / 产物集，叠在 Foundry 的 Ontology 与安全模子之上，没有本身独立的数据面。
  
• Ontology 不是单独可售的产物：它是 Foundry / Gotham 的焦点组件，对外袒露为 OSDK 与平台 API，但摆设上跟随 Foundry / Gotham。
  
• Apollo 不到场业务本领：它只办理"怎样把上面这些稳固升级到各种情况"，因此在业务架构图里通常被画成横切层，而不是某一层。
  
• 官方对外叙述里的"alantir 平台"通常指 Foundry + AIP + Apollo；业务侧产物线分别仍以 Gotham / Foundry / AIP 为主。
  

4.3 安全与管理：默认随数据活动

Palantir 的安全模子最焦点的一点：安全规则与信息偕行。详细本领：

• 传输中与静止时的全量加密；
  
• 身份验证与身份掩护；
  
• 基于脚色 / 分类 / 目标 三种方式可叠加的授权控制；
  
• 强审计日志；
  
• 信息管理、隐私控制可按字段、按目标风雅设置。
  

这套机制使 Ontology 即便跨部分共享，权限也不会因"数据离开了原有应用"而失效。
三种授权方式合在一起长什么样

光说"基于脚色 / 分类 / 目标"很容易停在抽象。把它落到一张矩阵上更直观：每条访问哀求都会被三个独立维度同时查抄，只要任何一维不通过就拒绝。
维度控制对象例子工程上挂在哪Role（脚色）"你是谁、属于哪个组"PlantManager、StrikeCellChief、J2_Analyst用户 / 组 / 服务账号 → 脚色映射Classification（分类 / 密级）"数据本身的敏感品级"UNCLASSIFIED / CONFIDENTIAL / SECRET / TOP_SECRET，加 NOFORN 等警示语ObjectType / 字段 / Action / 数据集级别声明Purpose（目标）"你来做什么用"production-scheduling、outage-investigation、audit-reviewAction / 查询哀求时显式声明，平台校验该目标是否被允许这三维独立、可叠加。一个详细例子：
哀求脚色查抄分类查抄目标查抄结果工厂司理读 Vehicle.statusPlantManager ✓SECRET ⊆ 用户 SECRET 允许 ✓production-monitoring ✓允许同一个工厂司理读 Vehicle.lotMargin（财政字段）PlantManager ✗（该字段脚色受限）——拒绝审计员读 Vehicle.statusAuditor ✓SECRET ⊆ 审计员允许 ✓audit-review ✓允许（只读）同一审计员调用 startProduction ActionAuditor ✗（脚色不在该 Action permissions.roles 内）——拒绝跨域共享：相助方访问 VehiclePartner ✓字段含 NOFORN ✗—字段被裁剪，别的可见要点：

• 维度独立意味着加一个脚色不会顺带放开密级，反过来也是。
  
• 字段级支持是关键：同一对象的 status 公开、margin 敏感，可以分开声明，而不必拆成两个对象。
  
• Purpose 是常被忽略的一维：它把"我有权限"和"我现在有合法来由用"分开，事后审计可以按目标查"谁在什么场景下访问了什么"。
  
• 这套规则进 Ontology 而不是进应用代码，因此 Workshop、OSDK、AIP Agent 拿到的视图都已经按规则裁剪好，不须要每个应用各自实现一遍。
  

4.4 开辟与交付工具链

• Pipeline Builder：低代码数据管道，支持 LLM 变更节点；
  
• Code Repositories：工程化代码管道；
  
• Code Workspaces：Jupyter / RStudio 等条记本情况；
  
• AIP Logic：无/低代码情况，构建、测试、摆设以 LLM 和 Ontology 为后盾的函数与工作流，可与 Automate 等集成；
  
• AIP Agent Studio / AIP Threads（官方文档）：构建可摆设的 Agent 与即席分析（Threads 为 Beta 等，视情况而定）；
  
• Workshop：低代码应用开辟，支持实时预览与 Scenario；
  
• Vertex：过程可视化与情况测试；
  
• Marketplace：平台内的"产物市场"，用于交付与安装数据产物；
  
• OSDK / 平台 API：让外部应用以语义方式读写 Ontology。
  

五、扩展：怎样搭建同类平台

5.1 通用门路图（技能视角）

做同类平台须要覆盖 8 个本领层，少任何一层都会让"决定—举措—审计"闭环掉链。下表把每一层的必备子本领与工程要点列出来，便于按层做技能选型评审：
#本领层本领项工程要点 / 可参考的开源或贸易组件1多模式数据接入批 / 流 / 当场访问 / 零拷贝；布局化、非布局化、地理空间、时间序列、模仿数据兼容 Iceberg / Delta / Hudi / Parquet；流侧 Kafka + Flink CDC；RDBMS 通过 CDC 或 JDBC；只管"零二次存储"以制止数据漂移2语义层（Ontology 当地化实现）对象—链接—属性—Action 同一建模；值范例与束缚；语义搜刮、媒体引用扩展；SDK / API 自动天生元数据服务 + 索引服务 + 对象存储分层（参考 Palantir 的 OMS / OSv2 / OSS / Funnel 分工，详见 2.5）；可以鉴戒 SchemaRegistry / Iceberg Catalog 思绪3逻辑层模子托管（BYOC、上传预训练、平台内训练）；同一 LLM 服务；外部函数 / Webhook；模子评估与漂移监控模子服务化（KServe / BentoML / Triton）；LLM 网关层抽象差异供应商；评估管道独立于训练管道4使用层Action 作为一等公民（独立范例 + 细粒度权限 + 审计）；Scenario 分支与"假如…"仿真Action Service 会合校验，写回经审计同事件；Scenario 用 copy-on-write 逻辑分支实现（见 3.3）5人机协作Proposal 模式（AI 提发起、人审、再落地）；使用反馈回流；元数据用于微调UI 侧 Proposal 队列 + 审批工作流；变乱总线把审批结果回写训练集6安全与管理Role / Classification / Purpose 三维授权可叠加；全链路加密、审计；按字段、按目标风雅设置权限规则进语义层而非应用层（见 4.3）；审计日志只增不删；合规适配（国标 / GDPR / HIPAA 按场景）7一连摆设多情况（云、当地、边沿、隔离网）自动化升级；灰度、回滚、版本编排控制面 + 实行面分离，参考 Apollo 模式；离线/断网情况用包堆栈 + 离线升级通道8低代码 + 代码"双轨"开辟低代码应用与管道构建器；面向工程师的代码堆栈 + IDE 集成；AI 编程助手低代码产物可被代码层"担当"而非锁定；两条路产出同一可摆设单位依靠关系上，第 2 层（语义层）是别的各层的焦点左券：第 3 层的 Function 要挂在 ObjectType 上才气用，第 4 层的 Action 要符合 ActionType 左券，第 5 层的 Proposal 要表告竣 Action 候选，第 6 层的权限直接进语义层。先把第 2 层做踏实，其他层再往上叠，否则极易在后期把权限和审计当补丁打。
5.2 在中国搭建同类服务的技能考量

在国内搭建时，除了上述技能层，还要针对情况做适配：

• 当地化底座：优先选择信创合规的底子办法（国产数据库、国产云、信创 Linux），并对接现有数据湖/仓尺度（如开源 Iceberg / Delta）。
  
• 联邦式本体：把语义层与数据全部权解耦。各企业/部分保存自有数据与算力，平台提供本体构建方法、跨节点查询与联邦学习本领，制止把敏感数据会合到一处。
  
• 私有化 + 专有云摆设：给国防、能源、金融等焦点客户提供完全离线摆设方案；Apollo 式的一连升级需改造为"断网也能升级"的模式。
  
• 数据分类与合规：按《数据安全法》《个人信息掩护法》《网络安全法》以及行业合规要求，把数据分级分类内建到权限模子中。
  
• 大模子当地化：语言模子服务层对接国产大模子（如符合羁系要求的自研/开源模子），并保存切换本领。
  
• 与现有业务体系的深度买通：Action 层优先支持国产 ERP / MES / OA / GIS 等体系的写回接口。
  
• 文化与构造：技能平台再强，也须要在交付模式上引入 FDE 式驻场，或“客户内部骨干 + 外部产物团队”混编，否则复杂场景很难稳固沉淀下来。
  

技能本领可以渐渐补齐，但构造与贸易模式同样关键。这部分请见《业务先容.md》，可以两份文档一起对比看。
六、参考资料

• Palantir 官方平台概览
  
• Palantir 官方Ontology 后端架构（Object Storage V1/V2、OSS、Funnel 等）
  
• Palantir 官方Action types 概览、AIP 功能
  
• 知乎转译《我们不是一家数据公司》
  
• 《Palantir 的"本体论"骗局》（品评视角）
  
• 《在中国复制帕兰提尔，有多难？》，GeoHey
  

免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.