EO03｜Palantir 的企业操作系统

Posted on 2026-08-14 19:21 天戈朱阅读(17) 评论(0) 收藏举报

上一篇《E002｜看懂企业 AI 的关键底座》中，我用一套开源组件做了一个 Ontology MVP，验证它能否真正进入业务运行过程。

实验选择了一个很简单的设备异常处置场景：设备异常 → 产生告警 → 根据规则创建工单 → 工单处理完成 → 告警关闭 → 设备状态恢复。

整个 MVP 由几部分组成：

【图 1｜基于开源组件完成的 Ontology MVP 后台界面】

MVP 闭环跑通后的思考：如果把这个 MVP 放回 Palantir 的完整体系，它到底只覆盖了哪一部分？带着问题，重新理解 Palantir 整体架构。

一、Palantir 的企业操作系统

Palantir 官方将标准架构定义为三个相互集成的平台：Foundry、AIP 和 Apollo，并将整套集成架构定位为 Enterprise Operating System。

仅看三个平台，还不容易理解这套“企业操作系统”到底如何工作。结合 Palantir 的 Capability Sets、Ontology System 和 AIP Architecture，可以从两个视角理解：

• 架构视角：系统由哪些平台和能力组成；
• 运行视角：企业数据、业务应用和 AI 如何围绕同一套业务模型运行。

【图 2｜Palantir Enterprise Operating System：架构与任务运行视角】

说明：上图基于 Palantir Architecture Center 官方资料归纳，非 Palantir 官方架构图。

1.1 架构视角：三个平台，一套联合能力体系

Foundry、AIP、Apollo 是 Palantir 标准架构中的三个 Platform。

Foundry： Data Operations Platform，是基础的数据运营平台，提供数据管理、Logic 开发、Ontology 建设、分析和 Workflow 开发等能力。

AIP： Generative AI Platform，将生成式 AI 接入企业实际运行的业务环境，包括 LLM 接入、Context Engineering、Agent、Automation、Evals（评估）等能力。

Apollo： Continuous Delivery Platform，管理 Foundry、AIP 等服务的部署、升级和持续运行。

AIP + Foundry 可以概念化为九组 Capability Sets，其中 Ontology Language、Ontology Engine 和 Ontology Toolchain 共同构成 Ontology System。其余能力分别承担数据、逻辑、工作流、应用、自动化和产品交付等职责。这是一种能力视图，不是严格的软件分层。

AIP + Foundry 的各项能力共同依赖底层基础运行组件，并由 Apollo 负责持续交付与运行支撑。

1.2 运行视角：业务如何形成闭环

从运行视角看，企业原有的 ERP、CRM、数据库、IoT、External Systems 等仍然是业务事实来源，Foundry 负责将这些数据、模型、Logic 和 Workflow 接入平台。

Ontology 建立在这些数字资产之上，将其组织成统一的 Object、Relationship、State、Logic、Action 和 Security。

底层数据既可以来自 Dataset，也可以通过 Virtual Table 等方式映射，并不要求全部复制到 Ontology 中。

在此基础上，业务能力通过两类入口被使用：

• 业务应用：通过 OSDK、Workshop 等访问 Ontology；
• AI Agent：可通过 Ontology MCP 等受控工具接口访问 Ontology、获取 Context 并调用 Action。

两类入口可以共享同一套业务对象、逻辑、动作和权限模型，并通过 Action 改变真实业务状态，新的状态再回到数据体系，形成业务闭环。

1.3 Action 让系统从“分析”进入“运行”

如果一套系统只能查询、分析和回答问题，它仍然主要是一套信息系统。

Palantir Ontology 中的 Action，使应用和 AI 可以在权限、规则和审计约束下改变真实业务状态。

因此运行链路不止是：Data -> Analysis ;而是：

Data
  ↓
Ontology
  ↓
Application / Agent
  ↓
Decision
  ↓
Action
  ↓
真实业务状态改变
  ↓
新的状态重新进入数据体系

这就形成了真正的闭环。

从这个角度看，Palantir 的 Enterprise Operating System 可以先形成这样一个整体理解：

• Foundry 将企业已有的数据、模型、Logic 和 Workflow 接入并运行在平台中；
• Ontology 将这些数字资产组织成统一的业务对象、关系、状态、Logic、Action 和 Security；
• 传统业务应用可以通过 Workshop、OSDK 等使用这套业务模型；
• AIP 则让 LLM 和 Agent 基于同一套业务模型获得 Context 并参与判断与 Action；
• Apollo 负责整套系统持续交付和运行。

二、Ontology System：Palantir 架构的核心

Palantir 对 Ontology 的定位非常直接：

“The Ontology is the system at the heart of Palantir’s architecture.”

即：Ontology 是 Palantir 架构的核心系统。

从官方架构图看，Ontology System 可以从两个方向理解：

• 横向是 Data、Logic、Action、Security，描述企业运行所需要的业务能力；
• 纵向是 Language、Engine、Toolchain，描述这些能力如何被定义、运行和使用。

【图 3｜Palantir Ontology System 官方架构图】

### 2.1 Language：定义企业业务世界

Ontology Language 负责对企业决策过程进行建模，可以理解为 Ontology 的设计与定义能力。它覆盖 Data、Logic、Action 和 Security，而不只是对象和关系。

Data主要包括：

• Semantic Objects（语义对象）：将底层数据映射为设备、告警、工单、客户等具有明确业务含义的对象；
• Dynamic Links（动态关系）：描述对象之间可以随业务状态变化而变化的关联关系；
• Interfaces（对象接口）：抽象不同对象共有的属性和能力，使不同 Object Type 可以按照统一方式被使用。

Logic主要包括：

• Business Rules（业务规则）：定义业务判断、计算和约束逻辑；
• AI-Driven Functions（AI 驱动函数）：将 LLM 等 AI 能力封装为可以被业务调用的 Function；
• Machine Learning Models（机器学习模型）：将预测、分类等模型纳入业务逻辑；
• Optimization Models（优化模型）：用于资源分配、路径规划等优化决策。

Action主要包括：

• User-Authored Actions（用户定义动作）：由开发者定义的业务操作，例如创建工单、关闭告警；
• Agentic Actions（Agent 动作）：允许 AI Agent 在约束条件下执行的业务动作；
• Sandboxed Simulations（沙箱仿真）：在不直接改变真实业务状态的情况下模拟 Action 的影响；
• Writeback Orchestrations（回写编排）：将 Action 产生的结果按业务流程写回一个或多个业务系统。

Security主要包括：

• Role-based Controls（基于角色的控制）：根据用户角色决定访问和操作权限；
• Marking-based Controls（基于标记的控制）：根据数据或对象的安全标记实施访问控制；
• Purpose-based Controls（基于用途的控制）：根据访问数据的业务目的限制使用范围。

因此，Ontology Language 定义的不只是“企业有哪些对象”，而是进一步定义：

企业中有什么对象、对象如何关联、有哪些业务逻辑和动作，以及这些能力受到什么权限约束。

2.2 Engine：让业务世界持续运行

如果说 Ontology Language 负责“定义业务世界”，那么 Ontology Engine 负责让这些定义真正运行起来。

它同样覆盖 Data、Logic、Action 和 Security，但关注的是查询、计算、状态变化、动作执行和权限控制等运行时能力。

Data主要包括：

• Ontology Metadata Service（本体元数据服务）：管理 Object Type、Property、Link 等 Ontology 定义及相关元数据；
• Object Set Service（对象集合服务）：对满足条件的一组业务对象进行查询、筛选和处理；
• Subscription Service（订阅服务）：持续订阅对象或状态变化，使应用能够及时感知业务变化；
• Time Series（时序数据）、Geospatial（地理空间）、Media（媒体）等数据运行能力。

这部分解决的是： Ontology 中定义的业务对象，如何被查询、订阅，并持续反映真实业务状态。

Logicy主要包括：

• Python Functions：使用 Python 实现业务计算和规则；
• TypeScript Functions：使用 TypeScript 实现业务逻辑；
• Compute Modules（计算模块）：承载更复杂或独立的计算任务；
• AIP Logic：将 AIP 中的 AI 能力接入业务逻辑执行过程；
• Model Adapter Framework（模型适配与调用）

也就是说，Ontology 中的 Logic 不只是简单规则，还可以连接代码、模型、优化计算和 AI。

Action主要包括：

• Actions Service：负责执行 Ontology 中定义的 Action；
• Validations：在 Action 执行前检查业务条件和约束；
• Side Effects（关联影响处理）：处理 Action 对其他对象或外部系统产生的连带影响；
• Scenarios（场景模拟）：支持在特定场景下验证业务动作及其影响；
• Automate：根据条件自动触发业务流程或 Action；
• Webhooks：通过事件通知外部系统；
• CDC：感知底层数据变化并驱动状态同步；
• Event Listeners：监听业务事件并触发后续处理；

这部分非常关键，因为它让 Ontology 从“描述业务”进入“执行和改变业务”。

Security主要包括：

• Roles（角色）：基于用户或系统角色分配权限；
• Markings（安全标记）：根据对象或数据的安全标记控制访问；
• Granular Permission Service（细粒度权限服务）：控制到具体对象、属性或操作级别的权限；
• Checkpoints：在关键业务环节增加权限或条件检查；
• Approvals（审批）：高风险 Action 可以要求人工审批后执行；
• Object Security Policies（对象安全策略）：针对不同 Object 设置访问和操作规则。

因此，Ontology Engine 可以概括为：让 Ontology 中定义的 Data、Logic、Action 和 Security 真正进入运行态，并持续处理查询、计算、事件、事务和业务状态变化。

2.3 Toolchain：开发和使用 Ontology

Ontology Toolchain 负责让开发者基于 Ontology 进行开发、集成和交付。

官方图中主要包括：

• OSDK（Ontology SDK）：基于 Object、Function、Action 开发应用；
• PSDK：平台相关的软件开发能力；
• Branching（分支管理）：支持 Ontology 的协作开发和变更管理；
• Marketplace（能力分发）：支持能力复用和分发；
• DevOps：支持开发、版本和交付流程。

其中，对本文最重要的是 OSDK：开发者面对的不再只是底层表结构和 API，而是已经定义好的 Object、Function 和 Action。

因此，可以把三部分概括为：

• Ontology Language：定义业务世界
• Ontology Engine：运行业务世界
• Ontology Toolchain：开发和使用业务能力

2.4 一个业务在 Ontology System 中如何落地

Data、Logic、Action、Security 与 Language、Engine、Toolchain 并不是两套独立结构，而是同一个 Ontology System 的两个观察维度。

以 CreateWorkOrder 为例：

Language：定义
├─ Data：Alarm / WorkOrder
├─ Logic：创建条件
├─ Action：CreateWorkOrder
└─ Security：执行权限
        ↓
Engine：运行
├─ 查询 Alarm 状态
├─ 校验 Logic / Permission
├─ 执行 Action
└─ 更新 WorkOrder 状态
        ↓
Toolchain：使用
└─ 提供给业务应用开发和调用

也就是说，一项业务能力首先通过 Language 被定义，再由 Engine 负责运行，最后通过 Toolchain 被应用开发和使用。

这也是 Palantir Ontology 与单纯知识图谱或 Semantic Layer 的关键差异：

Ontology 不只是描述业务对象和关系，而是把 Data、Logic、Action 和 Security 统一到一套可以定义、运行和使用的业务系统中。

三、从 Ontology 到业务应用和 AI Agent

Ontology System 的价值最终要通过业务应用和 AI Agent 体现。两类入口不同，但都可以基于同一套 Ontology 业务能力运行。

3.1 业务应用：基于 Ontology 开发

Palantir 提供 Workshop 和 OSDK 等方式使用 Ontology。

• Workshop: 面向业务应用构建，可以直接使用 Ontology 中的 Object、Function 和 Action。
• OSDK: 则面向自定义应用开发，使开发者能够在自己的开发环境中访问 Ontology，并围绕已经定义好的 Object、Relationship、Function 和 Action 开发应用。

这意味着应用面对的是一套已经具有业务语义、逻辑、动作和权限的业务模型。

3.2 AI Agent：通过受控能力进入业务系统

AI Agent 同样需要访问企业数据和执行业务动作，但不适合直接获得底层数据库的自由读写权限。

Ontology MCP: 将允许访问的 Object、Action、Query Function 等 Ontology 能力暴露为 MCP Tools，使 Agent 能够查询业务对象、获取 Context，并调用经过定义和权限控制的 Action。

因此，Agent 使用的不是底层数据接口本身，而是经过 Ontology 组织和治理后的业务能力。

四、MVP 对照 Palantir

MVP 对照 Palantir 完整体系，关键缺失：

下一阶段将优先围绕 Action 模型化、Ontology Engine Runtime 和 Toolchain 继续验证，Apollo 相关能力后置。

更佳阅读效果，请关注我的公众号

参考资料

引用链接

刷新页面返回顶部

天戈朱

公告