本文是《拆解 Palantir：企业 AI 与 FDE 架构指南》第 1 篇，也是整个系列的阅读地图。

很多人第一次接触 Palantir，会把它理解成数据平台、BI 工具或者企业版 Agent 平台。这些说法都只碰到了局部。Palantir 真正试图构建的，是一套能够把企业数据、业务逻辑、决策动作和权限治理连起来的“企业操作系统”。

它关注的不是模型能不能生成一段文字，而是模型能否理解企业正在发生什么、调用哪些受控能力、做出什么业务动作，以及整个过程是否能够追踪和审计。

整体架构

可以把 Palantir 的体系理解为六层：

业务应用 / 自动化 / AI Agents
              ↓
Ontology：数据 + 逻辑 + 动作 + 安全
              ↓
Foundry（数据运营） + AIP（生成式 AI）
              ↓
MMDP（开放数据、计算与模型接入）
              ↓
Apollo（持续交付与部署编排）
              ↓
Rubix（强化 Kubernetes 运行底座）

这几层不是相互独立的产品拼盘，而是围绕业务决策形成的一套闭环。

Foundry：整理企业的数据与运营逻辑

Foundry 是数据运营平台。它负责连接数据源、构建数据管道、编写业务逻辑、开发 Ontology、制作分析应用和承载工作流。

传统数据平台常常停留在“把数据汇总起来供人查询”。Foundry 更进一步：数据不仅用于分析，还会成为业务应用和自动化流程能够直接使用的运营资产。

AIP：让生成式 AI 进入真实业务

AIP 负责安全连接商业模型、开源模型和企业自有模型，并提供智能体构建、评估、调试、观测和治理能力。

它的重点不是封装一次模型调用，而是让模型在企业上下文里工作。AI 能看到哪些对象、能调用哪些工具、能执行哪些动作，都受到统一权限约束。

Apollo：让软件持续抵达各种环境

Apollo 是持续交付和部署编排平台，负责管理 Foundry 与 AIP 所依赖的服务和基础设施。

企业软件通常需要运行在公有云、本地机房、边缘节点甚至网络条件受限的高安全环境中。Apollo 的价值，是让大量服务可以在这些环境里持续安装、升级、监控和回滚。

Ontology：整套系统的核心

Ontology 把企业里的真实事物表达为对象、属性和关系，例如工厂、设备、工单、客户、航班和病床；同时把业务动作表达为可以执行的“动词”，例如调整排班、更新订单、重新分配库存或触发审批。

在这套模型中，数据、业务逻辑、动作和权限不是四套割裂系统，而是共同组成一个可读、可写、可执行的业务世界。人和 AI Agent 都在这个世界中协同。

这也是 Palantir 与普通 RAG 或 Agent 平台最大的区别：RAG 主要解决“找到相关信息”，Ontology 则进一步解决“信息在业务里代表什么、能够做什么、谁有权做”。

MMDP：不推倒重来的开放接入层

多模态数据平面 MMDP 负责连接各种数据、计算、模型和运行环境。

它支持结构化数据、文档、媒体、流式数据、时序和地理空间数据；支持 Spark、Flink、DuckDB、Polars 等计算引擎；也允许引入企业已有容器、模型和计算集群。

它传达了一个重要的落地原则：企业不需要为了采用 AI 先迁移所有系统，而可以在保留现有资产的前提下逐步纳管。

Rubix：安全且可持续演进的运行底座

Rubix 是经过强化、可自动扩缩、高可用的 Kubernetes 实现。它通过工作负载隔离、默认加密、节点轮换、故障恢复和蓝绿发布，把安全与高可用变成基础设施的默认能力。

Rubix 解决的是“系统如何稳定运行”，Apollo 解决的是“软件如何持续交付”。二者配合，让上层平台可以在云、本地和边缘环境中保持一致演进。

FDE 为什么重要

Forward Deployed Engineering 的关键不是派工程师去客户现场写定制代码，而是让工程师尽量靠近真实问题，将现场反馈带回产品和平台。

好的 FDE 项目应该形成这样的循环：

  1. 进入真实业务流程；
  2. 连接现有数据和系统；
  3. 建立业务 Ontology；
  4. 构建应用、自动化或 Agent；
  5. 从运行结果中收集反馈；
  6. 持续改进逻辑、产品和平台能力。

因此，AI FDE 的核心也不是“帮客户做一个聊天机器人”，而是把 AI 安全地纳入一个持续运行的业务系统。

最简记忆法

  • Foundry 管数据与运营逻辑；
  • AIP 管模型、Agent 与 AI 工作流；
  • Ontology 管业务世界的共同语言和动作；
  • MMDP 管开放的数据、计算和模型接入；
  • Apollo 管持续交付；
  • Rubix 管跨环境运行；
  • FDE 管现场反馈与持续演进。

系列文章

  1. 当前篇：一文看懂 Palantir 技术架构
  2. Palantir 的三大平台如何协作：AIP、Foundry 与 Apollo
  3. Ontology：Palantir 把企业数据变成业务行动的核心
  4. MMDP：Palantir 如何接入任意数据、计算与 AI 模型
  5. Palantir 的互操作性：如何连接企业已有数据与系统
  6. Rubix：支撑企业 AI 落地的 Kubernetes 基础设施
  7. AIP 架构全景：一个企业 AI 中台需要哪些能力

后续文章会逐层展开这些组件，并说明它们对企业 AI 和 FDE 项目的实际意义。

参考资料

中文内容来源：https://x.com/oops073111/status/2095341660385509463
官方资料：https://www.palantir.com/docs/foundry/architecture-center/overview

下一篇：Palantir 的三大平台如何协作：AIP、Foundry 与 Apollo