Palantir 到底做什么？从一次临时闭馆说起

一句闭馆通知，为什么要翻好几套系统？

负责人的第一站是订票系统。那里有明天的预约，但他很快发现，“预约了博物馆”不等于“一定要进青铜器展厅”。有的票只含常设展，有的票包含专门讲解。于是他又去查票种说明，找客服确认以前遇到这种情况怎样处理。

接着是人员安排。讲解员的排班在另一套系统里，有人只负责青铜器展厅，有人还带其他路线。即使决定取消一场讲解，也不能直接把这个人一整天的工作全部取消。财务还要核对哪些票已经付款，以及退款应该回到哪个订单。

这些系统未必有哪一个做错了。订票系统认真记订单，排班系统认真记人员，维修系统认真记故障。困难在于，现在要解决的是一件横跨它们的事：展厅关闭之后，整套安排应怎样改变？信息分别存在，彼此的关系和处理规则却可能只在老员工脑子里。

Vanyar 原文关注的正是这种跨系统协作困境，并由此引出企业 AI 的问题。我们可以顺着它继续问：既然现在有 AI，给每套系统各装一个助手，会不会就解决了？

每套系统都有 AI，为什么还不够？

订票助手可以告诉你明天有多少预约，排班助手可以列出哪些讲解员上班，维修助手也可以解释设备故障。但负责人真正问的是：“这次闭馆应该影响谁，应该怎样安排？”回答这个问题，需要把三套信息对上，还要知道业务上的约定。

比如订票助手看到 80 条记录，排班助手看到两场讲解。它不能只凭数字就认定每场正好 40 人。那 80 条记录里可能有改期前的旧记录，也可能有已经取消的订单；某位讲解员还可能同时负责别的展厅。每个助手都把自己那一部分说得很清楚，合起来仍可能是一套错误安排。

这里并不是说某家厂商的 AI 永远只能读自家的数据。许多产品已经可以连接外部系统。更根本的问题是：连进来的信息是否使用了同一套业务定义？当“一个观众”“一张预约”“一个订单”不是同一回事时，AI 需要知道应该按谁来计算和处理，而不能每次临时猜测。

这就把我们带到下一步：先把数据连接起来。但连接好了，是否就意味着 AI 已经理解这家博物馆？

本节事实核查：官方资料 [1]

把表放到一起，仍然有一些意思需要说明

假设工程师已经接通订票、门禁和排班数据。接口可以理解为系统约定好的信息交换入口；连接器则是按照这些约定读取数据的工具。Foundry 是 Palantir 用于整理数据和建设业务应用的平台。有些数据会复制到 Foundry，有些可通过虚拟表查询原系统。数据用哪种方式取得，会影响速度、更新时点和成本，但不改变接下来这个问题。

订票表里有一列“已完成”，门禁表里也有一列“已完成”。前者是票款付好了，后者是已经入场了。人一旦听过解释，通常不会混淆；可是把这两张表交给一个不熟悉业务的人，光看列名就可能误解。AI 也一样：它能读取表格，却没有理由天然知道这两个词在这家机构里的确切意思。

还有编号的问题。排班表把明晚的讲解写成“青铜器 A 场”，订票表把它写成“场次 709”。它们是否是同一场，必须有人确认并建立对应关系。如果只是把所有表放在同一个地方，这个对应关系不会因此自动出现。

所以我们需要的不仅是取到数据，还要把“哪些记录指同一件事、每个状态是什么意思、哪些事情互相影响”写成系统可以反复使用的定义。这就是理解 Ontology 的入口。

本节事实核查：官方资料 [3]官方资料 [10]

Ontology：给分散的信息补上一张业务地图

Ontology 通常译为“本体”。在 Palantir 里，可以先把它理解为一套能被程序使用的业务模型。这里的“模型”不是某个聊天 AI，而是对业务的描述：有什么事物，它们有哪些特点，彼此怎样关联，以及允许怎样改变。

在博物馆的例子里，“青铜器展厅”是一个对象，也就是有独立身份的具体事物。“明晚 19 点的讲解场次”是另一个对象。“王女士的预约”又是一个对象。展厅是否开放、场次何时开始、预约是否付款，是各自的属性；预约属于哪个场次、场次需要进入哪个展厅，则是它们之间的关系。

这些关系明确之后，负责人就可以从“青铜器展厅”出发，找到使用它的场次，再找到相应预约和讲解员。页面和 AI 调用配置好的查询时，也可以使用这条已经定义的路径。它们不必每次根据表名重新猜测哪些资料应该关联。

但地图还要说明哪些路可以走。某种票允许免费改期，某种活动只能原路退款；已入场观众和未到场观众可能适用不同规则。Palantir 的本体还可以连接这些计算逻辑与业务动作，因此它描述的不只是“现在是什么情况”，也包括“系统允许怎样处理”。规则需要团队建立，错误的数据也仍需修正。

现在，数据已经取得，业务含义也更明确了。AI 终于有条件围绕整件事提出一个可检查的建议。

本节事实核查：官方资料 [4]官方资料 [9]

AI 从“分别回答问题”，走向“帮忙处理这件事”

负责人再次问：“明天青铜器展厅关闭，已经预约的人怎么办？”在一个按上述方式配置的流程中，AI 可以先定位展厅和受影响场次，再取得对应预约及改退规则。假设有 60 张有效票，本例每张票对应一位观众，其中 20 张票允许调整路线，其余 40 张需要给观众提供改期或退款选择。它生成的建议就应围绕这些具体事实，而不是对所有预约发一条笼统通知。

这时的 AI 不只是回答一段文字。它可以在获授权的工具范围内查询资料、调用计算、整理候选安排，并把准备执行的操作交给人确认。这类能按步骤调用工具完成任务的 AI，通常被称为 agent，也就是智能体。它究竟能查看什么、能执行什么，取决于身份、权限和流程配置。

Palantir 把连接这类 AI 能力的产品称为 AIP，全称 Artificial Intelligence Platform，即人工智能平台。本体给它提供业务信息和可用工具，语言模型负责理解问题、组织步骤或生成说明，两者分工配合。并不是购买 AIP 后，模型就会自动读遍企业全部系统、学会所有规则。

对负责人而言，最有帮助的回答会说明：这些预约为什么受影响，推荐方案用了哪些条件，哪些信息还不确定。这样他才能检查“这 40 张有效票对应的观众是否真的都需要改期或退款”，而不只是觉得文案写得很好。接下来还有最后一关：建议怎样变成真实的处理结果？

本节事实核查：官方资料 [5]官方资料 [1]

决定做了，还要让原来的系统真正执行

假设负责人批准给部分观众退款。此时，系统可以发起一个预先定义好的退款操作，按配置向票务服务提交请求。这种通过网络调用外部接口的方式，可以用 webhook 实现。票务系统仍负责受理退款，支付服务仍负责实际退钱，新的业务应用负责把这件事组织起来并跟踪结果。

因此，原有系统未必需要被替换。ERP 是企业资源计划系统，通常负责财务、采购、库存等事务；CRM 是客户关系管理系统，用来管理客户资料及销售服务互动。这些系统可以继续各司其职。Palantir 所增加的是跨系统看待问题、作出决定并组织操作的一层能力。

不过，“负责人已批准”“票务系统已受理”和“钱已退回”是三个不同状态。如果退款请求失败，那些预约仍需要处理；如果退款完成但通知未发出，则应继续补发通知。一次成功的页面点击不能替代这些业务结果，也不能因为 AI 参与了流程就省略它们。

前面讲了很多动作，原理其实是一条连贯的线：数据告诉我们发生了什么，业务模型说明这些信息意味着什么，规则和权限限定能做什么，执行结果再回到系统中，供人继续判断。

本节事实核查：官方资料 [3]官方资料 [11]官方资料 [7]官方资料 [8]

现在再看产品名称，就容易记住了

到这里再回头看 Palantir 的产品名称，它们就不再是一串需要硬记的缩写。Palantir 是公司；Foundry 提供数据整理与业务应用的基础；Ontology 是其中把业务对象、关系和操作组织起来的关键部分；AIP 让 AI 能力参与这些流程。

软件还需要部署和更新，Apollo 负责这方面的软件交付与运行管理。另一个产品 Gotham 主要面向情报分析和行动协作，本系列重点讲 Foundry 与 AIP。下面这张简表只是帮助回顾分工；实际采用哪些功能、怎样组合，仍取决于使用方案。

本节事实核查：官方资料 [1]官方资料 [5]官方资料 [6]

它真正可能改变的，是下一次遇到变化时怎么协作

几个月后，博物馆把改期政策从“开场前 24 小时可改”调整为“开场前 12 小时可改”。如果相关判断散落在客服说明、预约页面和多个脚本里，团队就要逐处寻找、修改和核对。若多个入口使用同一套已管理的业务定义和操作规则，调整之后，它们更容易保持一致。

这也是原文看重的变化速度。但“规则可以集中维护”并不等于“任何政策都能几小时上线”。这次变更可能还牵涉已售票的权益、外部接口或财务处理，依然需要相关人员配合。共用一层业务模型也会产生维护工作和平台依赖，不能把它理解成摆脱一切厂商约束。

因此，Palantir 更值得理解的地方，是它把一件跨系统的工作放到同一套业务模型中处理的思路。对于只需偶尔汇总一张表的场景，这份投入未必必要；对于员工、应用和 AI 反复围绕订单、设备、场次等对象共同工作的场景，定义一次、反复使用的价值更容易体现。

下一篇先回到最朴素的一步：数据到底怎样进入 Foundry？因为再清楚的业务地图，也必须建立在能取得、能更新、能解释的数据之上。

本节事实核查：官方资料 [4]官方资料 [11]

适用边界与容易误解的地方

术语速查

ERP

管理财务、采购等企业事务的软件类别。

CRM

管理客户与销售关系的软件类别。

Ontology

本文指承载业务对象、关系和操作规则的模型。

回写

把一个系统中的决定或数据送回另一个业务系统。

来源与核查

对应原文

Rahul Garg · 2026-05-07 · Vanyar

1. Palantir：平台概览核对 Foundry、AIP 与 Apollo 的基本分工。
2. Palantir 2024 年 Form 10-K公司向 SEC 提交的一手资料，用于确认 Gotham 等产品范围，不用于财务建议。
3. Palantir：Data Connection核对数据接入、导出及 webhook 连接能力。
4. Palantir：Ontology building仅用于业务本体的基本定义与组成。
5. Palantir：AIP核对人工智能平台定位。
6. Palantir：Gotham核对产品名称和范围。
7. SAP：什么是 ERP核对企业资源计划的通用含义。
8. Salesforce：什么是 CRM核对客户关系管理的通用含义。
9. Palantir：为什么建立本体核对本体组织业务数据、逻辑及操作的用途。
10. Palantir：虚拟表核对无需先同步整表即可使用支持的外部表。
11. Palantir：动作类型核对业务操作的定义与共享规则。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。