Palantir Study 02｜Palantir 产品全景：Gotham、Foundry 等名词归位

上午 9:10，恒川工业的计划员打开缺料处置页面：物料M-1042只剩 760 EA 可用，订单HC-SO-260801可能延期。页面给出受影响订单、调拨方案和供应商邮件摘要，主管可以批准处置。

新 BA 看完演示，却在会议纪要里写下六个“系统”：Foundry、AIP、Ontology、MMDP、Rubix、Apollo。架构师追问：“它们真是六套平级产品吗？Gotham 又去哪了？”

这个问题不澄清，后面每学一个新词，地图就会更乱：Ontology 会被当成 Foundry 的别名，MMDP 会被当成数据接入产品，Apollo 还会被误写成业务自动化工具。

先给结论：这里没有一棵能解释一切的“唯一产品树”

Palantir 产品全景，是从产品披露、标准技术架构和运行基础三个视角，理解 Gotham、Foundry、AIP、Apollo、Ontology、MMDP 与 Rubix 各自职责及协作关系的地图。

Palantir 官方材料同时使用两种看似不同的口径：公司披露回答“Palantir 有哪些主要软件平台”，Architecture Center 回答“今天的标准集成架构怎样组成”。两个问题不同，答案自然不能被硬塞进同一层。

口径一：公司产品披露——四个主要软件平台

Palantir 在 FY2025 年报中把Gotham、Foundry、Apollo、AIP称为四个 principal software platforms（主要软件平台）。这组口径适合产品清单或高层产品介绍。

Palantir（公司与软件体系） ├─ Gotham ├─ Foundry ├─ AIP └─ Apollo

这张图只表达“产品披露中的成员”，不表达谁运行在谁之上，也不表示四者在技术上对称。

口径二：标准技术架构——三个集成平台

Palantir Architecture Center 采用另一种口径：标准架构由AIP、Foundry、Apollo三个集成平台组成。

• Foundry是基础数据运营平台；

• AIP是生成式 AI 平台；

• Apollo是持续交付平台（continuous delivery platform）。

在这套标准架构中，Gotham 的核心多模态应用和工具已经与标准架构集成，并由 Foundry 管理的 Ontology 驱动。也就是说，Gotham 既是公司披露中的主要平台，又可从技术架构视角理解为面向国防、情报与任务场景的领域化应用与工具体系。

所以，“Gotham 与 Foundry 平级”在产品披露口径成立；“标准集成架构是 AIP、Foundry、Apollo”也成立。真正错误的是不说明口径，直接把两张图拼成一个所谓严格层级。

一张可工作的架构地图

指导恒川工业项目时，可以使用下面这张职责图：

领域化产品与运营体验 Gotham 等领域产品｜行业应用｜业务应用｜Agent｜Automation ▲ │ 使用对象、逻辑和受控操作 ┌────────────────────────┴────────────────────────┐ │ Foundry：数据运营平台 AIP：生成式 AI 平台 │ │ 数据、逻辑、分析、工作流 模型、AI 工作流、Agent│ └────────────────────────┬────────────────────────┘ │ Ontology system：共同的运营语义与操作系统 （Language｜Engine｜Toolchain） │ MMDP：开放数据与计算架构——连接不同数据、计算与模型 │ Rubix：加固、弹性伸缩、高可用的 Kubernetes 计算基底 Apollo：横跨上述服务的持续交付、升级与基础设施管理平台

这是一张 BA 职责图，不是官方网络拓扑或计费清单。它表达五个判断：

1. Foundry、AIP、Apollo 是标准架构中的平台级概念；

2. Ontology 是架构核心系统，不是“第五个平台”；

3. MMDP 是开放数据与计算架构，不是“第六个平台”；

4. Rubix 是计算基底，不是业务用户进入的应用；

5. Gotham 是公司主要平台，同时以领域化应用和工具扩展并使用标准架构，不能粗暴塞成 Foundry 的普通菜单。

七个核心名词，分别是什么

Gotham：面向任务领域的产品与应用体系

一句话定义：Gotham 是 Palantir 面向国防、情报和任务运营等场景的主要软件平台，其核心多模态应用和工具已经与 AIP、Foundry、Apollo 标准架构集成。

• 类型：公司主要平台；从技术架构看又是领域化产品与应用体系。

• 上级：Palantir 的产品体系。

• 产品披露中的平级：Foundry、AIP、Apollo。

• 运行基础：当前核心应用可使用由 Foundry 管理的 Ontology，并接入标准架构。

• 产品形态：任务分析、协同和行动相关的领域应用与工具，而非制造企业通用资源目录中的一个按钮。

• 核心作用：把 Palantir 的通用平台能力组织为国防、情报等高风险任务工作流。

• 限制：不能因为 Gotham 使用 Foundry-managed Ontology，就把它降格成 Foundry 的普通组件；也不能因为产品披露把它与 Foundry 并列，就推断它与标准三平台拥有完全相同的技术职责。

恒川工业的缺料用例并不需要 Gotham。它在此只用于解释“四个平台”和“三个平台”两种口径为何并存。

Foundry：把企业数据和逻辑交付到运营工作的基础平台

一句话定义：Foundry 是 Palantir 的基础数据运营平台，提供数据管理、逻辑编著、Ontology 开发、分析和工作流开发的核心能力。

• 类型：平台。

• 上级：Palantir 标准架构。

• 标准架构平级：AIP、Apollo。

• 主要基础和能力：数据、逻辑、Ontology、分析、应用与工作流相关服务。

• 产品形态：建设者会在 Foundry 工作空间中看到数据连接、资源、开发与分析工具、Ontology 建设工具和运营应用。

• 核心作用：把来自 ERP、WMS、MES、文件和 API 的事实，变成可治理、可计算、可供运营工作使用的资产和能力。

• 限制：它不是单一数据库、BI 工具或低代码平台；也不是 Ontology 的同义词。

AIP：让生成式 AI 进入受治理运营流程的平台

一句话定义：AIP 是 Palantir 的生成式 AI 平台，用来安全连接大模型，并构建、评估和运行 AI 工作流、Agent 与 AI 应用。

• 类型：平台。

• 上级：Palantir 标准架构。

• 标准架构平级：Foundry、Apollo。

• 主要基础：企业已有的数据与权限、Ontology、模型连接、AIP 开发工具链和评测治理能力。

• 产品形态：建设者可使用 AIP Logic、AIP Chatbot Studio、AIP Evals 等工具；业务用户看到的是被嵌入工作流的 AI 能力，而不必总面对一个聊天窗口。

• 核心作用：让模型在受控的企业上下文中查询信息、调用既有逻辑、生成建议，并通过允许的工具参与运营。

• 限制：AIP 不是一个大模型，也不是 Foundry 的新名字。Agent 不会因“用了 AI”便自动拥有全量数据或写入权；它仍受身份、对象、属性、工具和 Action 权限约束。

Apollo：让整套软件持续交付和运行的平台

一句话定义：Apollo 是 Palantir 的持续交付平台，负责管理承载 Foundry 和 AIP 服务的基础设施，并编排服务和资产的持续部署、升级与运行。

• 类型：平台。

• 上级：Palantir 标准架构。

• 标准架构平级：Foundry、AIP，但职责偏平台运行。

• 基础：跨云、数据中心和边缘环境的基础设施，以及自动部署和运行管理机制。

• 产品形态：主要体现为交付控制面、升级编排和环境运行管理，不是计划员的缺料处置页面。

• 核心作用：使 Foundry/AIP 的大量服务能够在不同环境中持续更新并保持运行。

• 限制：Apollo 的“自动化”是软件交付与运行层面的自动化，不等同于“库存低于阈值就创建催交任务”这种业务 Automation。

Ontology：人、应用与 Agent 共享的运营系统

一句话定义：Ontology system 把企业的数据、逻辑、Action 和安全策略整合成一套人和 AI Agent 都能使用的业务世界与操作接口。

• 类型：核心系统与运营层。

• 架构位置：处在 Palantir 架构中心，由 Foundry 建设和管理，并被 Foundry 应用与 AIP 能力共同使用。

• 组成：官方架构将其概括为 Ontology Language、Ontology Engine 和 Ontology Toolchain；本篇只做定位，不展开三层内部机制。

• 下游使用者：分析应用、运营应用、Automation、Agent、外部应用，以及获得授权的人。

• 产品形态：建设者配置 Object Type、Link、Action 等定义；业务用户通常通过对象页面、Workshop 应用或 Agent 间接使用它。

• 核心作用：让Material、Customer Order、风险判断和“批准调拨”不再散落于表、脚本和界面里，而成为可共同查询和操作的业务语言。

• 限制：Ontology 不是 Foundry 的别名，不是一张 ER 图，也不是单纯的知识图谱。它必须依赖数据、逻辑、运行引擎、工具链和权限才能工作。

MMDP：开放数据与计算架构

一句话定义：Multimodal Data Plane（多模态数据平面，MMDP）是 Palantir 的开放数据与计算架构，用于在不同数据形态、计算引擎、模型与基础设施之间保持互操作。

• 类型：开放架构，不是独立业务平台。

• 上级：Palantir 整体技术架构。

• 相邻：Ontology 负责运营语义与操作；MMDP 负责数据、计算和模型的开放连接，两者职责不同。

• 基础：开放表格式、虚拟目录与虚拟表、批流与交互计算、外部计算和模型接入等机制。

• 产品形态：它更像一组贯穿平台的架构选择。实施人员会在数据连接、虚拟表、计算运行时、API/SDK 和模型接入中看到具体能力，而不会找到一个包办所有事情的“MMDP 页面”。

• 核心作用：让企业不必为了使用 Ontology、应用或 AI，就把所有数据和计算统一迁入一种封闭存储与运行时。

• 限制：“不要求复制所有数据”不等于“任何情况下都不移动数据”。是否同步、虚拟访问、推送计算或保留源端，仍需按延迟、驻留、权限、性能和成本逐项设计。

Rubix：承载运行时的计算基底

一句话定义：Rubix 是 Palantir 加固、弹性伸缩且高可用的 Kubernetes 计算基底，承载 AIP、Foundry 和 Apollo 所依赖的多种运行时与服务。

• 类型：基础设施计算基底（substrate / compute mesh）。

• 上级：Palantir 的基础设施与 MMDP 开放计算体系。

• 相邻基础：存储、网络、安全、治理等平台级能力。

• 产品形态：通常对 BA 和一线业务用户不可见，更多体现为平台服务的运行环境和工程保障。

• 核心作用：为批处理、流处理、交互计算以及平台服务提供统一、受治理的运行基础。

• 限制：Rubix 不是业务应用，不负责定义Material，也不是项目团队为某个缺料页面单独购买或配置的“计算按钮”。

最容易混淆的，不只是七个英文词

Palantir 周边还有两组常见表达，最好在此一并归位。

Data、Logic、Action、Security是理解 Ontology 如何整合运营决策的四个观察面：事实、判断、操作和约束。本文可简称为 DLAS，但它不是官方独立产品，也不是与 Foundry 并列的四个模块。

“Enterprise Operating System”则是官方对 AIP、Foundry、Apollo 集成架构的定位。它强调这套架构连接数据、分析、AI 与关键运营，并不意味着它是取代 Windows、Linux 的主机操作系统。

以后看到新词，先问它是产品、平台、系统、架构、基础设施，还是实施方法。先判类型，再谈上下级。

恒川工业：一次缺料处置，各部分何时介入

回到M-1042。

计划员需要在调拨、催交、替代料和生产改序之间做选择。她真正关心的不是“今天用了几个 Palantir 产品”，而是谁在每个环节承担责任。

环节一：Foundry 建立可运营的事实和工作流

ERP 提供销售订单HC-SO-260801、生产订单HC-PO-260815和采购订单行HC-PO-88210-20；WMS 给出两个仓库的库存；MES 提供排产；供应商门户给出承诺日期。

Foundry 负责连接和治理这些事实，让缺料计算、对象映射、分析及运营应用可以在同一平台协作。计划员看到的不是四套源系统截图，而是一条围绕短缺事件SD-260808-01组织起来的处置工作流。

环节二：Ontology 让事实成为同一个业务世界

Ontology 把 ERP 的M-1042、WMS 的MAT1042-SH和供应商门户的P-8821归到规范对象MAT-0001042，再把它与客户订单、生产订单、采购订单、工厂PLANT-EAST和仓库连接起来。

系统据此表达：当前可用量 760 EA；哪些订单受影响；谁是负责人；哪些候选 Action 可以执行；超过 500 EA 的调拨为何必须由供应链经理复核。这不是“多画了一张关系图”，而是在给应用与 Agent 一个共同、受权限约束的运营语境。

环节三：AIP 辅助研判，但不替人获得权力

供应商发来一封措辞含糊的邮件。AIP 可以抽取延迟原因，把邮件与SUP-0088、采购订单行和短缺事件关联起来，再调用已批准的逻辑解释四个候选方案。

但 AIP 的建议不是 ERP 的新承诺日期，也不是主管批准。Agent 只能读取获准对象、调用获准 Function，并在需要时发起受控 Action；500 EA 以上的调拨仍停在人工确认点。

环节四：Apollo 与 Rubix 支撑平台运行，而非替业务做决定

计划员不会在页面上选择“让 Apollo 部署一下”，也不会决定这次缺口计算跑在哪个 Rubix 节点。Apollo 在平台层管理服务交付、升级和运行；Rubix 提供计算基底。它们让业务能力可靠可用，但不拥有缺料处置规则和批准权。

环节五：MMDP 约束集成方式，Gotham 不介入

恒川不必先把所有 ERP、WMS 和供应商数据复制成一种格式再开始。项目可依据 MMDP 的开放架构，在受支持范围内组合数据同步、虚拟访问、外部计算和模型接入；具体选择要考虑延迟、驻留、成本与权限。

Gotham 在这个商业制造案例中没有必要介入。把它放在地图上，是为了理解 Palantir 产品体系，而不是为了凑齐产品名称。

这条链路可以压缩成一句话：

Foundry 组织运营事实，Ontology赋予业务语义和受控动作，AIP 辅助理解与判断，Apollo 维持持续交付，MMDP 保持数据与计算开放，Rubix 承载运行；Gotham 服务另一类领域化任务。

BA 工作台：一张“名词归位卡”

BA 不应只收藏产品定义，而应把每个名词放进项目语境。下面这张卡可直接复制到术语澄清会、范围说明书或架构评审材料中。

使用这张卡时，至少完成三项验收：

1. 口径验收：写“平级”时，是否说明是公司产品披露还是标准技术架构？

2. 责任验收：每个名词是否对应恒川的一段实际责任，而不是用同义词互相解释？

3. 边界验收：是否写清本项目直接建设、平台团队负责，还是只作为架构原则采用？

在恒川项目中，BA 应直接设计的是缺料决策、Ontology 语义、权限、Action 与用户工作流；应与数据和平台团队共同确认 Foundry 数据能力、MMDP 接入选择及 AIP 工具边界；不应把 Rubix 节点编排或 Apollo 服务升级误列为业务需求。

回到开头：不是六套系统，而是不同种类的责任

会议纪要里的“六个平级系统”应该删掉。

正确说法是：在公司披露口径，Gotham、Foundry、AIP、Apollo 是四个主要软件平台；在当前标准架构口径，AIP、Foundry、Apollo 是三个集成平台。Ontology 是架构核心系统，MMDP 是开放数据与计算架构，Rubix 是计算基底。它们可以同时出现在一张图里，却不属于同一种类别。

名词归位以后，新的问题反而更具体了：既然 Foundry 是数据运营平台，它内部如何把 ERP/WMS/MES 数据、Ontology、分析工具和运营应用连成一条链？Dataset、Workshop、Action 等名词又分别站在哪一层？

下一篇，我们只把镜头推进 Foundry，回答“Foundry 到底是什么”。

本文依据 Palantir 公开资料与实施研究整理，与 Palantir Technologies 无官方关联。恒川工业及其编号和数据均为虚构教学案例；“名词归位卡”是本专栏的实施性模板，不是 Palantir 官方固定产品模型。产品命名、能力和可用范围可能变化，请以官方文档及具体环境为准。