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 职责图，不是官方网络拓扑或计费清单。它表达五个判断：

Foundry、AIP、Apollo 是标准架构中的平台级概念；
Ontology 是架构核心系统，不是“第五个平台”；
MMDP 是开放数据与计算架构，不是“第六个平台”；
Rubix 是计算基底，不是业务用户进入的应用；
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 不应只收藏产品定义，而应把每个名词放进项目语境。下面这张卡可直接复制到术语澄清会、范围说明书或架构评审材料中。

名词	类型	哪些概念与它同口径平级	上一级/所属语境	它由什么支撑或包含什么	恒川中的介入点	本项目是否直接建设	关键限制
Gotham	公司主要平台；领域产品体系	公司披露：Foundry、AIP、Apollo	Palantir 产品体系	与标准架构集成；核心工具由 Foundry-managed Ontology 驱动	本用例不介入	否	不能当 Foundry 菜单，也不能强塞成标准架构第四层
Foundry	数据运营平台	标准架构：AIP、Apollo	Palantir 标准架构	数据、逻辑、Ontology、分析与工作流能力	接入数据并交付缺料应用	是	不是单一数仓、BI 或 Ontology 别名
AIP	生成式 AI 平台	标准架构：Foundry、Apollo	Palantir 标准架构	模型连接、AI 工具链、Agent、Evals 等	读邮件、解释方案、受控调用工具	选配	不越权；模型输出不自动成为业务事实
Apollo	持续交付平台	标准架构：Foundry、AIP	Palantir 标准架构	部署、升级、基础设施管理	支撑平台持续运行	通常由平台团队负责	不等于业务 Automation
Ontology	核心系统/运营层	与 MMDP 为相邻但不同类别	Palantir 架构中心	Language、Engine、Toolchain；整合 Data/Logic/Action/Security	组织 Material、Order、规则和 Action	是	不是静态数据模型，也不是第五平台
MMDP	开放数据与计算架构	无严格平台平级项	Palantir 整体架构	开放数据、计算、模型接入与互操作	决定 ERP/WMS 如何接入和计算	作为架构原则采用	不承诺所有场景零复制
Rubix	计算基底	存储、网络、安全等基础能力是相邻项	Palantir 基础设施	加固、弹性、高可用 Kubernetes compute mesh	承载计算与服务	否，通常不由 BA 设计	不是业务应用或 Ontology 构件

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

口径验收：写“平级”时，是否说明是公司产品披露还是标准技术架构？
责任验收：每个名词是否对应恒川的一段实际责任，而不是用同义词互相解释？
边界验收：是否写清本项目直接建设、平台团队负责，还是只作为架构原则采用？

在恒川项目中，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 到底是什么”。