AIP、Foundry 与 Apollo：一套底座上的三个产品面

很多工程师第一次接触 Palantir 会有一个困惑。对外宣传里它有三个响当当的产品名：AIP、Foundry、Apollo。看材料时又像在讲三家公司，各写各的博客、各发各的白皮书。我的看法是，这种"三件套"的讲法恰恰掩盖了最关键的事实：它们根本不是三个互不相干的独立产品，而是同一套底层之上的三个产品面（product surface）。一套 Ontology，一套安全模型，一套部署底座 Rubix，上面长出 Foundry、AIP、Apollo 三个能力面。

说得再直白一点。Foundry 负责把一家组织散落各处的数据，建模成可操作的语义层（Ontology）。AIP 负责在这个语义层之上跑 AI 推理，让大模型能读懂对象、调用工具、执行动作。Apollo 负责把这一切，以及它们背后的配置与软件，持续交付到任何环境，包括潜艇、战机、断网的医院机房。三者共享同一个 Ontology、同一个安全模型、同一个 Rubix 底座。

本篇我要做的，不是逐个产品念参数，而是把"它们为什么能共用底座"这件事讲透。读完你应该能回答三个问题：Ontology 到底是个什么东西；Foundry 和 AIP 的能力边界到底划在哪；Apollo 凭什么能把软件塞进最刁钻的环境。

一、先说 Ontology：三个产品共享的语义内核

要理解三个产品面，得先理解 Ontology。因为它既是 Foundry 的产出，又是 AIP 的输入，是横跨两个产品的真正内核。

Ontology 不是数据库，不是图数据库，也不是一份知识图谱。Palantir 自己的定义是"组织之上的操作层（an operational layer for the organization）"。它的工作是把底层的源数据资产，映射成对象（objects）、属性（properties）和链接（links），从而构建出这个组织的数字孪生（digital twin）。

这里有个要害。传统数据仓库关心的是"表、字段、行"，Ontology 关心的是"人、订单、设备、合同"这些真实世界里的事物，以及它们之间的业务关系。一个 shipment 对象会同时带着它的状态、关联的承运商、货物的温度读数、所在的位置，这些属性可能来自十几个互不相同的源系统。Ontology 把这种跨源关联做成了第一等公民，而不是每次查询都要临时 join。

更关键的是"kinetic logic"（动态逻辑）这个词。Ontology 不止于描述现状，它上面可以挂载 Actions（动作）。一个 Action 是对某个对象的合规的状态变更操作，比如"批准这张报销单""把这批货物改派给另一辆车"。Action 自带参数校验、权限检查和业务不变量约束。这就把"数据"变成了"可以做事的对象"。后面你会看到，这恰恰是 AIP 能"让模型真正动手"的支点。

还有一点容易被忽略，Ontology 不是一张只读的快照。它有读路径和写路径两条。读路径上，Object 的属性由 Foundry 的 transforms 持续编译产出，数据始终新鲜。写路径上，一个 Action 对 Object 做的变更，会经过校验后持久化回写，成为下游又能读到的状态。这种读写双向性，让 Ontology 真正像一个活的、可操作的世界模型，而不只是一层缓存视图。

二、Foundry：把数据落成 Ontology 的建模引擎

Foundry 定位是数据集成、治理与建模平台。外面常把它类比成"加强版的数据中台"，这个类比勉强能用，但漏掉了一点本质：Foundry 的终点不是生成报表，而是生成 Ontology。

接入这一层，Foundry 提供数百种连接器，把数据库、文件系统、消息流、SaaS API 里的原始数据拉进来。接下来是核心环节 transforms（变换）。Foundry 的变换是代码驱动的，支持 Python、SQL、以及跑在 Spark 上的 Java/Scala。你写一段代码，声明输入哪些源数据集、产出哪个数据集，Foundry 负责编排执行并完整记录血缘（lineage）。任何一份数据的来龙去脉，都能从下游一路回溯到最原始的源。

真正让 Foundry 区别于普通 ETL 工具的，是它把"建模语义层"作为一等目标。数据经过清洗、对齐、标准化之后，会被编译进 Ontology：每一条业务记录映射为一个 Object，字段映射为 Property，关联映射为 Link。这个过程叫 build，build 是确定性的、可重放的、带版本标识的。你今天 build 出来的 Ontology，明天换个参数能 reproducible 地再 build 一遍，结果可预期、可审计。

再补一句 Foundry 的工程实现。transforms 跑在一套托管的分布式计算引擎上（Spark 系为主），而整个 build 关系图是内容寻址的：上游数据没变，下游就不会被重复计算，重建是增量的。这意味着一家企业哪怕有上万个互相依赖的数据集，也能高效、确定地重算。也正是从这一层开始，安全模型第一次被 enforce，不是应用代码里手写 if 判断，而是平台在读取源数据时就把权限算进去，下游的 Ontology 对象天然继承上游的授权边界。

治理也是 Foundry 的一块重头。数据质量规则、血缘、版本、谱系，在线上的每一个 Object 上都是可见的。到了应用层，Object Explorer 让你像翻通讯录一样翻业务对象，Workshop 让你低代码拼出操作界面，Quiver 做时序分析。注意，这些应用消费的不是一个数据库，而是 Ontology。这就是关键：Foundry 把"脏乱差的数据"变成了"有结构、有权限、可操作的对象"。这一步做完，后面 AIP 才能直接站在语义层上推理，而不是从零开始和原始表搏斗。

三、AIP：在 Ontology 之上跑 AI 推理

如果 Foundry 把世界建模成对象，AIP 就是让 AI 在这些对象上"思考并行动"的那一层。

先澄清一个常见误解。很多人以为 AIP 就是"给 Foundry 接个大模型"。不是这样。接模型是最不重要的部分。AIP 最本质的设计是：让大模型的推理 grounding（锚定）在 Ontology 之上，而不是直接喂原始数据。模型看到的不是一张张裸表，而是已经被语义化、已经过了权限裁剪的业务对象。

AIP 这套能力由几个构件组成。AIP Logic 是一个可视化编排 LLM 工作流的画布，你在上面串起 prompt、检索、工具调用和函数。Ontology SDK（TypeScript / Python）给开发者用来写 AI 应用，这些应用能读写 Ontology 对象、调用 Functions 和 Actions。AIP Assist 是给 Foundry 开发者用的 copilot。AIP Agents / Agent 工具箱支持构建能自主循环的 agent。AIP Connect 解决"自带模型"的问题，允许接入企业自己的模型或外部模型供应商，同时数据始终留在私有网络里。

值得强调的是，AIP 里的"工具"不是随意的脚本，而是有契约的 Functions。一个 Function 就是一段带类型的代码（Python 或 TypeScript），输入输出都绑定到 Ontology 的类型上。模型要调用它，必须按契约传参，AIP 会在边界上做类型和权限校验。这把"模型乱调 API"变成了一个被约束、可验证的操作。也正因为底层是 Ontology 的类型系统，AIP 支持的不只是大模型，线性回归、优化求解器这类传统模型同样可以作为"推理算子"挂上来，和 LLM 混在同一个闭环里。

推理闭环拆开看，是这样一个循环。任务进来，可能是一句自然语言，也可能是一个结构化指令。大模型先做规划（reasoning），把任务拆成几步，决定要调哪些工具。接着它从 Ontology 里检索（retrieve）相关的对象、属性和链接，作为推理上下文塞进 prompt。这一步是 RAG，但检索的目标不是文档库，而是 Ontology 里那些结构化的、实时的业务对象。然后模型发起工具调用，去执行一个 Ontology Function（纯查询或计算），或者触发一个 Action（真正的状态变更）。Action 不是模型自己偷偷改了数据库，AIP 会让 Action 走 Ontology 的校验和权限链，和人工操作走完全相同的路径。执行结果回写到 Ontology，agent 观测到新状态，继续下一轮推理，直到任务完成。

这套闭环的价值，我觉得被很多演示视频低估了。它最厉害的地方不在于"模型能聊天"，而在于模型是在一个语义层上推理，每一步都可解释、可审计、可行动。模型说"我建议把这批货改派"，背后是它真的读到了承运商负载、真的调了计算函数、真的走了一条带审批的 Action 通道。这和"让 ChatGPT 写一段 SQL"是完全不同的范式。前者落到一个受控的对象操作上，后者只是一段文本。

顺带说一句安全，这点后面还会展开。AIP 的安全框架核心就一条：模型上下文是被 Ontology 安全层裁剪过的。你给模型的 prompt 里，只会注入当前用户有权看到的对象。模型想执行一个 Action，也会被同样的权限和审批规则拦一遍。换句话说，AI 没有绕过任何一条既有的安全规则，它只是多了一个走同一条规则的操作者。

四、Apollo：把软件持续交付到任何环境

Apollo 是三者里最低调、也最被外界误解的一个。一个常被忽略的事实是：Foundry 和 AIP 自己，就是用 Apollo 部署和运维的。Palantir 的说法是 Apollo 负责"把软件持续交付到所有环境，从车辆到潜艇"。

Apollo 的职责是持续交付与部署编排。它把配置和软件，持续地、可靠地推送到任意环境：公有云、私有云、本地裸金属、边缘节点，乃至完全断网的气隙（air-gapped）环境。后面这种环境才是 Apollo 的真功夫。潜艇、战机、偏远医院的机房，没有外网，没有稳定的运维人员，软件怎么活下去？这就是 Apollo 要解决的那类问题。

它用声明式配置工作。你描述"目标状态"，Apollo 负责计算出执行计划，然后滚动落地。它做健康监控，发现异常会自动回滚或重调度，也就是带自我修复能力。它还做"trustless deployment"，部署包经过加密校验，不依赖某个人的手工人肉操作。在舰队（fleet）层面，一个控制台能管理成百上千个异构环境的部署版本，统一看健康、统一推变更。

Apollo 的工作方式其实和 Kubernetes 的 reconcile 循环同构，但作用对象是整个软件栈而不是单个容器：它持续观察环境的实际状态，和声明目标比对，发现漂移就收敛回去。对于带状态的服务，它还负责安全地做 schema 迁移，把数据结构变更编排进发布流程，而不是让人停工半夜手动改表。这套机制让"在 1000 个隔离站点上升级同一版 Foundry"从一个不可能的人力工程，变成一条可审计、可回滚的自动化流水线。

回到和前两者的关系。Apollo 的存在，解释了为什么 Palantir 能跟国防、情报、强监管医疗客户合作：这些客户的环境往往是隔离的、苛刻的。Apollo 负责把同一套 Foundry 和 AIP，原封不动地搬进那些环境里跑起来。没有 Apollo，"一套 Ontology 三个产品面"就只停留在云上，进不了前线，也过不了那些客户的合规门槛。

五、它们怎么共用底层：同一 Ontology、同一安全模型、同一 Rubix

讲到这，三个产品面各自的定位都清楚了。现在回答最本质的那个问题：它们凭什么能共用底座。我认为答案落在三层共享上。

第一层共享，是同一个 Ontology。Foundry 建出来的对象、属性、链接，就是 AIP 推理所消费的对象、属性、链接。它不是一个要给两个系统各建一份的副本，而是单一事实来源（single source of truth）。AIP 不需要重新定义"什么是订单"，它直接读 Foundry 定义好的订单对象。少了这层共享，AIP 每接一个场景都得重新对齐一次数据 schema，成本会高到没法用。

第二层共享，是同一个全局安全模型（global security model）。这个模型从最原始的源数据，一路贯穿到 Ontology 对象，再到 Actions，再到喂给大模型的上下文。它用的是一种 mark（标记）/ grantee（被授予者） 的思路：数据被打上标记，用户和服务被授予权限，权限在每一层自动继承、向下传播。在 Foundry 里，源数据的权限决定了一个变换能不能读它，变换的权限又决定了产出的 Ontology 对象谁能看。在 AIP 里，模型拿到的上下文被这个安全层裁剪过，只能含授权对象；它想执行的 Action 和人工走同一条权限链。在 Apollo 里，连"谁能往哪个环境推哪个版本"这件事本身也是被审计、受控的。

第三层共享，是同一个部署底座 Rubix。这一点最底层，也最不被讨论。Rubix 是 Foundry、AIP、甚至连 Gotham 都安装其上的那套运行时与部署底座。它提供分布式微服务运行时、编排、网络、存储原语和部署引擎。关键在于，无论最终部署在 AWS、Azure、GCP、本地裸金属，还是完全气隙的环境，Rubix 把底层差异都抽象掉了，使得三套产品面在任何环境下行为一致。Foundry 在客户的 AWS 账号里是那套语义层，在被搬到潜艇上的气隙环境里，仍然是同一套语义层。

把 Rubix 讲得更实一点。它不只是个装软件的底座，还内置了网络与服务网格、配置下发通道，以及"主权部署"能力，客户可以把控制权完全留在自己手里，连 Palantir 自己都无法远程触达。正是这些原语，让 Apollo 能跨上千个异构环境做统一编排，也让"在同一套 Rubix 上升级所有站点的 Foundry 和 AIP"成为可能。底座一旦统一，上面的产品面之间就不再有"对接"的摩擦力。

而 Rubix 之上的安全与治理层，才是"同一安全模型"真正落地的物理基础。它不是三个产品各自实现一套安全，而是在 Rubix 之上统一实现一次，三个产品面共同消费。这也是为什么安全模型能如此顺畅地从数据一路贯穿到 AI 推理，而不是在各层之间出现裂缝。

把这三层共享放在一起看，会得到一个单独做任何一个产品都拿不到的性质：安全策略只在一处定义，全栈自动生效。你在 Rubix 上改一条授权规则，Foundry 里对应的数据集、AIP 里模型能看到的上下文、Apollo 里能推送的环境，会一起跟着变，不需要挨个系统去改配置。这正是"一套底座、三个产品面"相比"三套独立系统拼起来"的根本优势：拼起来的系统最难搞定的永远是接缝处，而底座统一后，接缝消失了。

六、客户实际怎么用这三件套

落到实践，客户并不是三件一起买。最常见的路径是先从 Foundry 起。一家大企业最痛的往往是数据孤岛，数据有但说不清、连不上、动不了。Foundry 先把数据集成、治理、建模成 Ontology，解决"让数据能说话、能操作"的问题。

等 Ontology 成型了，再叠加 AIP 就顺理成章。这一步比从零给大模型接数据省事太多，因为语义层已经把"业务对象长什么样"定义清楚了，模型要做的只是学会在这些对象上推理和发起动作。这比重新做一套 RAG、重新对齐 schema、重新搞权限，成本要低一个数量级。这也是为什么"客户常从 Foundry 起，再叠加 AIP"是行业里反复出现的真实路径，而不是销售话术。

Apollo 往往是个隐性刚需，而不是一开始的主角。当客户的环境开始变严苛，比如要部署到边缘、要断网运行、要满足强合规审计，Apollo 才显出价值：它把前面建好的 Foundry 和 AIP，可靠地交付进那些环境，并在成百上千个环境里持续运维。换句话说，Foundry 和 AIP 决定了"系统能做什么"，Apollo 决定了"系统能在哪跑、能跑多稳"。

举个具体的例子。某家制造企业先用 Foundry 把 ERP、MES、供应链系统的数据接进来，建出"生产线""工单""物料"这些对象。三个月后叠加 AIP，工程师用自然语言问"三号产线明天可能缺哪些料"，模型直接检索 Ontology 里的工单和库存对象、调用一个计算函数算出缺口，整个过程没有为接大模型重写一行数据管道的 glue 代码。再过半年，为应对海外工厂断网风险，他们用 Apollo 把同一套 Foundry 加 AIP 推到当地气隙环境，版本和总部保持同步。这条路径之所以顺畅，根子就在于三层始终共享。

我的看法是，Palantir 真正卖的不是三个软件，而是一套贯穿数据、语义、AI、部署的统一操作系统范式。AIP、Foundry、Apollo 只是这套范式面向不同问题暴露出来的三个产品面。理解了"一个 Ontology，三个产品面"，你再看它的任何架构文档，都会清楚得多，也不会再被三个产品名带进"这是三家公司的东西"的误区里。