企业官网建设流程全解析

上午 9:25，恒川工业的 BA 刚把第 2 篇产品地图讲完，项目经理马上问：“知道 Foundry 与 AIP、Apollo 的位置了，可 Foundry 到底替恒川做什么？我们已经有 ERP、WMS、MES、数仓、BI 和低代码平台，为什么还要它？”

如果回答“Foundry 是数据平台”，听起来像数仓；如果回答“Foundry 是企业操作系统”，又像一句宏大口号。真正能指导项目的回答，必须沿着M-1042缺料处置跑一遍：数据怎样进入、逻辑怎样复用、业务怎样表达、用户怎样操作、结果怎样回到系统。

本篇只回答 Foundry，不再重画产品全景

前一篇已经讲清两种分类口径：公司披露可列 Gotham、Foundry、AIP、Apollo；当前标准架构由 AIP、Foundry、Apollo 三个集成平台构成。

本篇只保留必要定位：

• Foundry 是标准架构中的平台级概念，与 AIP、Apollo 平级但职责不同；

• AIP 让生成式 AI 进入受治理的运营过程；

• Apollo 负责持续交付和运行平台服务；

• Ontology 是架构核心系统，也是 Foundry 把数据与运营连接起来的关键。

一句话定义

Foundry 是 Palantir 的基础数据运营平台：它把企业分散的数据、逻辑和治理能力组织起来，通过Ontology、分析工具与运营应用，交付可执行、可审计、可反馈的业务工作流。

关键词不是“把数据集中起来”，而是把数字资产交付到运营工作。一条 Pipeline 成功、一个模型上线、一张报表刷新，都可能是必要步骤，却不等于缺料已经被处置。

把 Foundry 放回正确位置

Palantir 标准集成架构 ├─ Foundry：数据运营、逻辑、Ontology、分析与工作流 ├─ AIP：生成式 AI、Agent、AI 工作流与评估 └─ Apollo：持续交付、升级和平台运行 企业现有环境 ERP / WMS / MES / 数仓 / API / 文件 / 流 ↓ Foundry ↓ 由 Ontology 组织的数据、逻辑、Action 与 Security ↓ 分析、应用、Automation、Agent 与外部应用

Foundry 的上一级是 Palantir 的平台/标准架构语境，不是 Ontology。Ontology 也不是与 Foundry 平级的另一套平台：它是架构核心系统，由 Foundry 的能力建设和运行，并供 Foundry 应用与 AIP 共同使用。

内部结构图：Foundry 里面有什么

现在把镜头推进 Foundry。为了让 BA 建立稳定认知，可以先把它理解成五组相互连接的能力，而不是一长串应用名称。

外部企业系统与数据源 ERP / WMS / MES / CRM / 文件 / 流数据 / API │ ▼ ┌──────────────────── Foundry ────────────────────┐ │ 1. 数据层：连接、Dataset、Pipeline、质量、血缘 │ │ │ │ │ 2. 逻辑层：规则、Function、Model、优化器 │ │ │ │ │ 3. Ontology：Object、Property、Link、Action、 │ │ Function 与动态安全形成共同的运营语言 │ │ │ │ │ 4. 分析与应用：Object Explorer、Quiver、Workshop│ │ │ │ │ 5. 运行闭环：Action、Automate、API / Webhook、 │ │ 审计、写回与反馈 │ └─────────────────────────────────────────────────┘ ▲ AIP 通过 Ontology 获取语境、逻辑和工具 Apollo 在底层部署和运行 Foundry 与 AIP

这不是官方界面的菜单树，也不是严格的网络调用图，而是一张面向 BA 的职责地图。它至少解决了一个常见误解：Dataset、Ontology、Workshop 和 Action 不与 Foundry 平行，它们是 Foundry 内部的数据资产、核心系统、应用工具或运营构件。

Foundry 与 Ontology：平台和它的“运营内核”

这是最需要讲透的一组关系。

Palantir 官方将 Foundry 描述为基础数据运营平台，同时说 Foundry Ontology 是 Foundry 的 heart。Ontology 位于 Dataset、Virtual Table、Model 等数字资产之上，把它们连接到工厂、物料、订单、供应商等现实概念，并加入 Actions、Functions 和动态安全。Palantir：Foundry；Palantir：Ontology overview

没有 Foundry 的数据、逻辑、计算、治理和应用能力，Ontology 无法独立承担完整平台；没有 Ontology，Foundry 仍能加工和分析数据，却很容易退化成一组数据管道、表和孤立应用，难以形成共享的运营世界。

为什么又说 Ontology 是整个 Palantir 架构的中心

因为 AIP 也需要它。

Agent 要回答“哪些客户订单会因这次断供延期”，必须知道 Material、Production Order 和 Customer Order 的身份及关系；要提出替代料方案，需要调用受治理的 Function 或 Model；要执行方案，需要使用有权限和提交条件的 Action。

这些对象、关系、逻辑和操作接口都由 Ontology 组织。站在 Foundry 内部看，Ontology 是 Foundry 的核心；站在 AIP + Foundry 的集成架构看，它又是人、软件和 Agent 共用的运营系统。

Palantir 把 Ontology Language、Engine 和 Toolchain 合称为 Ontology system，并将它置于整体架构中心。Palantir：The Ontology system

产品关系因此不是一棵完全无交叉的树，而是一个集成架构。初学者可以先记住：

Foundry 提供建设和运行企业运营世界的平台能力；Ontology把这个世界组织成业务可读、软件可调用、行动可治理的共同语言。

Foundry 与 AIP：一个提供运营基础，一个让生成式 AI 进入运营

AIP 与 Foundry 是平行平台，不是替代关系，也不是“Foundry 新增了一颗聊天机器人按钮”。

Foundry 解决企业现实如何被接入、计算、建模、分析和操作。AIP 解决大模型如何获得受控语境、调用工具、生成建议、运行工作流，并接受评估和治理。Palantir：AIP overview；Palantir：AIP architecture

在供应中断场景中：

• Foundry 接入库存、采购、需求和产能数据；

• Ontology 将其组织成 Supplier、Material、Plant、Order 及其关系和 Actions；

• Function 或 Model 计算缺口、约束和候选方案；

• Workshop 把处置流程交给计划员和经理；

• AIP Agent 可以读取允许访问的对象，调用已有逻辑，解释方案并发起受控 Action；

• Apollo 支撑承载这些服务的环境持续部署和运行。

没有 Foundry 与 Ontology，AIP 可能只得到文档片段和数据表，难以稳定理解“这家企业现在发生了什么、允许做什么”。没有 AIP，Foundry 仍然可以完成数据、分析、应用和行动闭环，只是不会使用生成式 AI 参与部分判断与交互。

Foundry 与 Apollo：业务平台和持续交付底座

Apollo 最容易被业务读者忽略，因为它通常不直接出现在计划员的处置页面上。

它负责管理承载 Foundry 与 AIP 服务的基础设施，持续发布、升级和运行大量服务。可以把 Apollo 理解为“让整套软件在不同环境中安全持续运转的交付与控制系统”。它与 Foundry 同属平台级概念，但主要面向平台运行，不负责定义 Material 对象，也不负责设计缺料审批界面。Palantir：AIP、Foundry 与 Apollo

Foundry 与数仓、BI、ERP、低代码：不是“谁替代谁”

把 Foundry 说成“更强的数仓”或“把 ERP、BI、低代码合成一个产品”都不准确。它们各自解决不同层次的问题，也可以长期共存。

选择 Foundry 的理由不应是“它什么都能做”，而应是用例是否需要把多个系统的事实、复杂逻辑、业务对象、细粒度权限与行动闭环长期连接。如果问题只是把一张稳定表做成每日报表，现有 BI 可能已经足够。

在产品里，Foundry 不是一个页面

不同角色接触到的是 Foundry 的不同切面：

• 数据工程师在 Data Connection、Pipeline Builder 或 Code Repositories 中建立数据产品；

• Ontology 建设者在 Ontology Manager 中配置 Object、Link、Action 和相关逻辑；

• 分析师在 Quiver 等工具中验证对象关系、计算和趋势；

• 应用建设者在 Workshop 中把待办、判断和 Action 交付给运营用户；

• 平台团队通过 Project、权限、lineage、Observability 和 DevOps 管理生产运行。

因此，“我们上线了 Foundry”不是可验收的业务结果。BA 要追问：哪个真实用户能够用哪项资源和 Action 完成什么决定，执行结果怎样返回并被监控。

恒川工业：一次缺料怎样穿过 Foundry

现在让SD-260808-01沿五组能力跑完。这样才看得出 Foundry 与一堆独立工具的差别。

数据：接进来，但不抹掉来源责任

ERP 提供客户订单HC-SO-260801、生产订单HC-PO-260815和采购订单行HC-PO-88210-20；WMS 提供现存、冻结和预留库存；MES 提供排产状态；SRM 提供SUP-0088的最新承诺。

Data Connection、Dataset、Virtual Table 与 Pipeline 等能力负责连接、清洗、版本、质量和血缘。库存计算保留清楚口径：800 EA 现存，减去 20 EA 冻结、20 EA 预留，得到 760 EA 可用。

此时 Foundry 形成了可信数字资产，但还没有自动回答“这次缺料由谁处理、影响哪张订单”。

逻辑：把一次性 Excel 计算变成可复用能力

团队把可用量、短缺风险、运输时长、替代资格和客户影响分别落入清晰的规则、Function 或 Model。每项逻辑都有输入、输出、Owner、版本和失败方式。

例如，超过 500 EA 的调拨需要供应链经理复核。这是一条教学业务规则，不应写死在某个页面按钮里；Workshop、Automation 或 Agent 需要使用时，应调用同一受治理逻辑或 Action criteria。

Ontology：让资产变成同一个运营世界

ERP 的M-1042、WMS 的MAT1042-SH和供应商门户的P-8821被解析为 canonical MaterialMAT-0001042。它与订单、工厂PLANT-EAST、仓库WH-E01/WH-S02、供应商和缺料事件建立 Link。

Ontology 同时表达可执行 Action：提交调拨、确认催交、批准替代料、调整生产顺序。这样，数据和逻辑不再只服务某张报表，而是成为多个应用与 Agent 可以共同使用的业务接口。

分析与应用：把能力交给真实用户

分析师可用 Quiver 验证库存趋势和影响关系；计划员在 Workshop 中看到待处置事件、受影响订单、四种候选方案和审批状态；经理通过同一对象上下文复核AP-2048。

这里的关键不是把每个工具都用一遍，而是不同工具消费共同 Ontology。分析结果不必靠复制粘贴重新进入运营页面。

行动与反馈：把“批准”推进到“已执行”

Action 通过参数、submission criteria 和权限约束操作。批准后，Ontology edit、API、Webhook、export 或人工复核可按目标系统边界执行；WR-2048-*跟踪各写回请求，区分Approved、Writeback In Progress、Executed、Partially Failed与Failed。

Observability 和审计记录帮助团队定位是数据未刷新、Function 失败、权限拒绝，还是 WMS/ERP 写回超时。执行结果再进入下一次决策，才形成反馈循环。

这条链路说明 Foundry 的平台价值：它不是替代每个系统，而是让分散系统、数据资产、逻辑、Ontology和应用组成同一条可治理的运营链。

BA 工作台：Foundry Platform Scope Map

BA 不需要替架构师画完服务拓扑，但必须把业务闭环分配到正确能力和责任人。下面这张表可直接放进范围澄清会。

完成这张表时，至少要解决四个边界谈判：

1. 哪些事实继续由 ERP/WMS/MES 持有，哪些状态由 Ontology 持有？

2. 哪些计算应成为跨应用复用的 Function/Model，哪些只是页面展示？

3. 哪些用户只读，哪些可以提交、批准或执行 Action？

4. 哪个结果证明用例成功：Pipeline 构建成功，还是缺料决策时间、执行成功率和订单影响真正改善？

如果答案只有“把数据接进 Foundry”，说明项目仍停在平台安装视角，没有进入业务运营视角。

现在，重新回答 Foundry 是什么

Foundry 不是数据库、BI 或 Ontology 的别名。它是 Palantir 标准技术架构中的基础 Data Operations 平台。

向下，它连接企业现有系统，管理数据、逻辑、计算、安全和治理；向中间，它提供建设和运行 Ontology 的能力；向上，它支持分析工具、运营应用、自动化和系统行动。AIP 则通过这套共同的运营基础，让生成式 AI 和 Agent 进入业务流程；Apollo 在底层让平台持续交付和运行。

对 BA 而言，Foundry 的意义不是“把数据搬到一处”，而是让业务对象、逻辑、权限和 Action 被人员、应用和 Agent 共同使用，形成可执行、可反馈的运营闭环。

但“平台能力齐全”不等于项目资源有秩序。恒川已经有 Dataset、Repository、Ontology resource 和 Workshop application，下一步会碰到更具体的问题：它们放在哪个 Space、Project 和 Folder，机器怎样用 RID 稳定引用，权限边界又在哪里？

本文依据 Palantir 公开资料及业务分析与实施研究整理，与 Palantir Technologies 无官方关联。恒川工业及其编号和数据均为虚构教学案例；Platform Scope Map 不是 Palantir 官方固定模板。产品命名和能力可能变化，请以官方文档及具体环境为准。