Foundry 篇：为什么 Palantir 把数据平台做成运营系统

上一篇讲 Palantir 的基本地图时，我把它概括成一句话：

Palantir 的核心，是把企业数据变成可操作的业务世界，再把 AI 放进这个世界里做受控行动。

这篇单独讲 Foundry。

如果只把 Foundry 理解成“数据平台”，会低估它。更准确的说法是：Foundry 是 Palantir 用来把企业数据变成运营系统的基础层。

它不只是负责把数据接进来，也不只是负责存储、清洗、建模和展示。它真正要打通的是这条链路：

这条链路一旦打通，数据就不再只是看板里的指标，而会变成业务流程里的对象、判断、动作和反馈。

为什么普通数据平台会卡在“看见”

大多数企业做数据平台，第一阶段通常都很合理：

1. 把各个系统的数据接进来。
2. 建数据仓库或湖仓。
3. 做指标口径。
4. 做报表和看板。
5. 给管理层、业务团队、分析师使用。

这套路径能解决一个重要问题：让企业看见自己发生了什么。

但真正进入运营现场后，会遇到另一个问题：

看见不等于能改变。

例如供应链团队在看板里发现某个物料库存不足，但下一步仍然要手动去查供应商、查工单、查客户订单、算替代方案、开会确认，再回到 ERP 或其他系统里执行。

这时数据平台只是“提示风险”的系统，不是“处理风险”的系统。

问题不在于报表不重要，而在于企业运营需要的不只是信息展示，而是一个可执行的业务模型：

• 哪些对象被影响？
• 对象之间有什么依赖？
• 谁有权限看、改、执行？
• 哪些规则和模型可以参与判断？
• 哪些动作可以写回业务系统？
• 执行之后结果如何反馈？

Foundry 的目标，就是让数据平台从“看见业务”走向“操作业务”。

Foundry 的定位：数据运营平台

Palantir 官方文档把 Foundry 定义为基础数据运营平台，提供数据管理、逻辑编写、Ontology 开发、分析和工作流开发等核心能力。

这句话要拆开看。

如果只看“数据管理”，Foundry 像数据平台。

如果看“逻辑编写”，它开始接近工程平台。

如果看“Ontology 开发”，它进入业务对象建模。

如果看“分析和工作流开发”，它已经不只是分析工具，而是在支撑业务操作。

所以 Foundry 更像一套分层的数据运营栈：

越往下，越接近数据接入和治理。

越往上，越接近业务对象、应用、工作流和动作。

这也是 Foundry 和普通数据平台最大的差异：普通数据平台的终点常常是数据资产和分析消费；Foundry 的终点更接近业务应用和运营动作。

第一层：把外部系统接进来，但不止于接入

企业数据从来不是干净地躺在一个地方。

它可能在 ERP、CRM、MES、WMS、数据库、文件系统、工业传感器、地理空间系统、文档系统、供应商平台和人工 Excel 里。

Foundry 的 Data Connection 用来把外部系统和其他 Foundry 实例的数据同步进平台，供数据集成、建模和 Ontology 使用。官方文档还提到，它也支持通过 webhooks 和数据导出设置 outbound connections，也就是把数据或动作写回外部系统。

这里有一个关键点：

Foundry 的数据连接不是单向搬运，而是为了后续的建模、治理、应用和写回服务。

传统 ETL 更像“把数据搬进仓库”。

Foundry 更关心“这些数据进入平台后，如何成为业务对象的一部分，并参与后续操作”。

如果没有这个目标，数据接入很容易变成无休止的数据管道建设：接了很多源，建了很多表，最后还是只有少数分析师知道怎么用。

第二层：治理不是合规装饰，而是操作前提

在真实企业里，数据治理不是文档工作。

它决定一个系统能不能进入生产运营。

例如：

• 一线操作员能不能看供应商价格？
• 区域经理能不能看其他区域的客户？
• 生产团队能不能修改排产建议？
• AI Agent 能不能读取敏感订单？
• 某个动作是谁批准的，什么时候执行的？

如果只是看报表，权限问题已经很复杂。

如果系统还要支持动作写回，权限、血缘、审计和变更管理就更重要。

Foundry 里有数据血缘、数据健康、数据目录、访问控制、资源状态等能力。它们不是为了让平台“看起来专业”，而是为了让数据和后续动作可以被信任。

一个没有血缘和审计的数据平台，只适合做参考。

一个要支撑运营动作的平台，必须回答：

• 这个字段从哪里来？
• 这个对象状态是否可信？
• 这个模型用了哪些输入？
• 这个动作为什么被触发？
• 谁能看到、修改、批准和回滚？

这就是 Foundry 为什么要把治理和操作放在一起。

第三层：把数据表变成业务对象

这是 Foundry 最重要的转折点。

传统数据平台里，核心对象通常是表、字段、指标、任务、报表。

业务现场关心的却不是这些东西。

业务现场关心的是：

• 订单。
• 客户。
• 供应商。
• 工厂。
• 设备。
• 航班。
• 病床。
• 运输路线。
• 作战任务。

这些才是现实世界里的“东西”。

Foundry 通过 Ontology 把底层数字资产连接到现实世界对象。官方文档描述过，Ontology 位于集成到平台的数字资产之上，将 datasets、virtual tables、models 等连接到现实世界中的工厂、设备、产品、客户订单、金融交易等对象。

这个转换非常关键。

因为 Agent、应用和操作员不能长期围绕表名工作。

一个供应链负责人不应该问：

inventory_snapshot_v4 里 SKU 123 的 available_qty 和 allocation_pending_qty 差多少？

他真正想问的是：

这个关键物料还能支撑哪些工单？如果优先保证 A 客户，B 客户会延迟几天？

要回答后一个问题，系统必须理解物料、工单、客户、库存、交期、替代供应商之间的关系。

这就是 Ontology 要在 Foundry 中承担的职责。

第四层：逻辑不能只存在于人的脑子里

很多企业运营依赖大量隐性规则。

例如：

• A 类客户优先级高于 B 类客户。
• 某些订单不能拆分交付。
• 某些替代物料只能用于特定产线。
• 某个供应商虽然价格低，但质量风险高。
• 某些调拨方案会影响区域库存安全线。

这些规则如果只存在于老员工经验、Excel 模板和会议讨论里，系统就很难稳定自动化。

Foundry 的逻辑层价值在这里：它允许团队把业务规则、函数、模型、流水线和优化逻辑沉淀到平台中，再通过 Ontology 和应用层被调用。

这不是为了追求“全自动决策”。

恰恰相反，成熟的运营系统往往先从“更好的辅助决策”开始：

• 自动找出受影响对象。
• 自动计算几个可行方案。
• 自动标注风险和约束。
• 自动展示每个方案的代价。
• 最后由人确认并执行。

AI Agent 要真正进入企业，也需要这层逻辑。

否则大模型只能根据文本猜测，而不是基于真实业务对象和可验证逻辑推理。

第五层：应用不是看板，而是操作界面

很多数据平台的用户界面是报表。

Foundry 的上层应用更接近业务工作台。

这两者不一样。

报表告诉你发生了什么。

操作界面要支持你完成一件事。

例如供应链场景里，一个 Foundry 应用不应该只是展示“库存下降曲线”。它更应该帮助用户完成一个闭环：

1. 识别短缺物料。
2. 展示受影响工单。
3. 展示受影响客户订单。
4. 生成调拨、替代采购、排产调整方案。
5. 标注每个方案的成本、交期和风险。
6. 让有权限的人确认。
7. 写回 ERP、工单系统或审批系统。
8. 跟踪执行结果。

这才是 Foundry 所说的数据运营平台的含义。

它不是把数据平台上面套一个漂亮 UI，而是让应用直接建立在 Ontology、权限、逻辑和数据血缘之上。

为什么写回很重要

判断一个数据平台有没有进入运营层，可以看它是否支持写回。

只读系统负责解释世界。

可写系统开始改变世界。

当然，写回也意味着风险变大。它要求：

• 动作边界清楚。
• 权限判断严格。
• 审批流程明确。
• 执行记录可审计。
• 出错可以追踪和回滚。

这也是为什么 Foundry 不能只被理解为“更强的数据仓库”。

一旦平台参与写回，它就成为企业操作链路的一部分。

这时工程重点会从“查询性能”和“报表体验”扩展到“业务安全”“动作治理”“运行可靠性”和“责任边界”。

Foundry 和 AIP 的关系

现在很多人关注 AIP，因为它和大模型、Agent、自动化更直接相关。

但如果没有 Foundry，AIP 很容易退化成企业聊天机器人。

AIP 要让 AI 参与真实业务流程，需要几个基础条件：

• 结构化的业务对象。
• 可信的数据上下文。
• 可调用的业务逻辑。
• 清晰的权限和动作边界。
• 可观察、可审计的执行记录。

这些都依赖 Foundry 和 Ontology。

所以 Foundry 是 AIP 的地基。

AIP 让 AI 进入业务，Foundry 决定 AI 进入的是不是一个可靠的业务世界。

如果这个世界本身是碎片化的、脏的、无权限边界的、没有动作接口的，那么再强的模型也只能做表层问答。

Foundry 的工程本质

从工程视角看，Foundry 的关键不是“数据统一”，而是“操作统一”。

它要统一的不只是数据源，还包括：

• 业务对象。
• 对象关系。
• 数据血缘。
• 权限策略。
• 业务逻辑。
• 分析和模型。
• 应用界面。
• 动作写回。
• 反馈循环。

这就是为什么 Palantir 会把 Foundry 放在企业操作系统的底层。

一个普通数据平台通常回答：

数据在哪里？指标是多少？趋势是什么？

Foundry 想进一步回答：

当前业务世界是什么状态？哪些对象被影响？有哪些可行动作？谁可以执行？执行后如何反馈？

这两个问题之间，就是“数据平台”和“运营系统”的差距。

什么时候企业真的需要 Foundry 这类系统

不是所有企业都需要 Foundry 这种复杂平台。

如果业务流程简单、数据源少、决策影响小、系统之间耦合低，用传统数据仓库、BI 和少量自动化就够了。

Foundry 更适合这类场景：

• 数据源多，且来源长期不可统一。
• 决策对象复杂，有大量依赖关系。
• 业务动作影响真实世界。
• 权限、安全和审计要求高。
• 需要跨部门协同。
• 业务变化快，固定 SaaS 难以覆盖。
• 希望 AI Agent 参与真实运营，而不是只做问答。

制造、能源、医疗、供应链、航空、国防这些领域常见 Foundry 的原因，就在这里。

它们的共同点不是“数据多”，而是“操作复杂”。

结尾：Foundry 的真正价值

Foundry 的价值不在于把所有数据都搬到一个地方。

那只是起点。

它真正想做的是把企业数据转化为一个可维护、可治理、可推演、可执行的业务系统。

这也是 Palantir 跟很多数据平台叙事不同的地方。

普通数据平台的终点是让人看到更多事实。

Foundry 的目标是让组织基于这些事实采取更好的行动。

用一句话概括：

Foundry 不是为报表而建的数据平台，而是为运营而建的软件底座。

理解这一点，再看下一篇 Ontology，就会更容易明白为什么 Palantir 一直强调本体论。因为 Foundry 要进入运营层，必须先把企业现实世界建模出来；而 Ontology 正是这个模型的核心。

参考资料

• Palantir 官方文档：AIP、Foundry 与 Apollo
• Palantir 官方文档：Data Connection
• Palantir 官方文档：Application reference
• Palantir 官方文档：Ontology overview
• Palantir 官方文档：Why create an Ontology?