上午 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 等领域产品行业应用业务应用AgentAutomation ▲ │ 使用对象、逻辑和受控操作 ┌────────────────────────┴────────────────────────┐ │ Foundry数据运营平台 AIP生成式 AI 平台 │ │ 数据、逻辑、分析、工作流 模型、AI 工作流、Agent│ └────────────────────────┬────────────────────────┘ │ Ontology system共同的运营语义与操作系统 LanguageEngineToolchain │ 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-20WMS 给出两个仓库的库存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并在需要时发起受控 Action500 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、ApolloPalantir 产品体系与标准架构集成核心工具由 Foundry-managed Ontology 驱动本用例不介入否不能当 Foundry 菜单也不能强塞成标准架构第四层Foundry数据运营平台标准架构AIP、ApolloPalantir 标准架构数据、逻辑、Ontology、分析与工作流能力接入数据并交付缺料应用是不是单一数仓、BI 或 Ontology 别名AIP生成式 AI 平台标准架构Foundry、ApolloPalantir 标准架构模型连接、AI 工具链、Agent、Evals 等读邮件、解释方案、受控调用工具选配不越权模型输出不自动成为业务事实Apollo持续交付平台标准架构Foundry、AIPPalantir 标准架构部署、升级、基础设施管理支撑平台持续运行通常由平台团队负责不等于业务 AutomationOntology核心系统/运营层与 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 到底是什么”。本文依据 Palantir 公开资料与实施研究整理与 Palantir Technologies 无官方关联。恒川工业及其编号和数据均为虚构教学案例“名词归位卡”是本专栏的实施性模板不是 Palantir 官方固定产品模型。产品命名、能力和可用范围可能变化请以官方文档及具体环境为准。