一句话结论
Foundry 是 Palantir 面向企业的本体驱动操作系统，定位在「数据」与「业务应用」之间：它把分散的数据源、模型与决策流程连成一个闭环，让在平台上做出的决策能写回 ERP / CRM / MES 等源系统，而不只是产出一份报表。
- 五层平台架构（自下而上）：① 数据集成 Data Integration → ② 模型集成 Model Integration → ③ 本体 Ontology → ④ 工作流 Workflows → ⑤ 决策编排 Decision Orchestration。
- 本体是平台的心脏：由对象（Objects）、关系（Relations）、动作（Actions）三类要素构成，并通过数据、逻辑、动作、安全四重融合来表征企业的复杂决策。
- 数据集成层内置 200+ 连接器，支持结构化、非结构化、流式、IoT、事务与地理空间数据；集成、转换与决策都会带着完整血缘（lineage）写回源系统。
- 原生联邦（Native Federation）：尽量不复制数据，让外部数据集直接成为本体对象，避免多份过期副本与真相源割裂。
- 工具链：Pipeline Builder（数据接入）、Ontology Manager（本体建模）、Model Objectives（把模型绑定到运营结果）、Ontology Process Orchestration（流程编排）、Workshop / Slate（应用构建）、Quiver / Object Explorer（分析）、OSDK（开发）。
- 实际效果：污水处理厂消除运营罚款并降低温室气体排放；太阳能电站减少停机；AI 驱动的交易监控让多司法辖区客户检索快 90%；NBO 营销活动上线时间从数月压缩到一天。
序章 为什么需要 Foundry？
先从一个你大概率踩过的坑说起。
常见困境：公司里数据散在十几个系统——ERP、CRM、IoT 传感器、Excel 表。你想做个"全局视图"，于是：导表 → 清洗 → 做仪表盘。仪表盘很漂亮，但第二天数据又变了，而你没法反手改回业务系统。看得到问题，却动不了手。
大多数数据工具擅长的是线性流程：接入数据 → 出图表。但真实运营根本不是线性的——工厂、仓库、客服同时在做分布式决策，且彼此互相影响。
Foundry 的核心洞察：你的企业本身就是一个闭环系统——运营产生数据，数据驱动决策，决策又改变运营。软件也该这样工作，而不是只停在"看图表"这一步。这正是 Foundry 要做的事：闭环运营（closed-loop operations）。
下面 8 个小章节，把这个"操作系统"拆成你能一步步理解的部分。每章末尾可"标记已学"，进度会自动保存。
第 1 章 一句话看懂 Foundry
把官方那句定位，翻译成人话。
"The Ontology-Powered Operating System for the Modern Enterprise."
Foundry = 以本体（Ontology）为内核的、现代企业的操作系统。它把数据、分析、运营团队连到同一个地基上，让决策能被"激活"并写回现实。
Foundry = 以本体（Ontology）为内核的、现代企业的操作系统。它把数据、分析、运营团队连到同一个地基上，让决策能被"激活"并写回现实。
注意两个关键词：
- Ontology-Powered（本体驱动）：不是简单堆数据，而是用"本体"把企业建模成一个可计算的数字孪生（后面第 3 章细讲）。
- Operating System（操作系统）：它处在"数据"和"业务应用"之间，像电脑的操作系统一样，统一调度底层资源，让上层应用能跑起来。
和 AIP 的关系（顺带一提）：Palantir 把三件套合称"企业操作系统"——Apollo（持续交付/零停机升级）、Foundry（数据运营地基）、AIP（生成式 AI 层）。本文学的是其中的数据运营地基 Foundry。
📌 随堂小测：Foundry 认为企业软件应该更像什么？
A 一张静态的报表/仪表盘
B 一个闭环系统：运营→数据→决策→再改变运营
C 一个只负责存数据的数据库
答案：B。Foundry 批判"线性分析"，主张业务是闭环的，软件也应闭环——决策能写回源系统，形成"运营↔决策"的持续回路。
第 2 章 五层平台架构
Foundry 的"平台"由五层叠成，每一层都在帮"分析"和"运营"之间再扣紧一环。点击每一层展开看它干什么。
1数据集成 Data Integration地基 · 接数据
软件定义、安全灵活的数据接入——数小时而非数月。内置 200+ 连接器，可同步结构化、非结构化、流式、IoT、事务、地理空间等多模态数据。关键是实时双向连接：用户的集成、转换、决策都会带着完整血缘（lineage）写回源系统。内置基于角色 / 分类 / 用途的访问控制。
2模型集成 Model Integration接模型
灵活接入或注册模型与业务逻辑——自带模型，或原生构建。核心原则是让数据科学家和非技术业务用户都能协作用模型做决策：业务人员有 ML 工具包、无代码建模应用和开箱即用的 AI 服务；数据科学家有端到端的建模工具。
3本体 Ontology核心 · 数字孪生
不止是数据模型，而是一层运营层——企业级的数据与模型的数字孪生。把底层数据和模型连接到真实业务对象（如工厂、配送中心、设备），让分析、数据科学、业务决策者在同一个"动态知识资产"上实时协作。下一章细讲。
4工作流 Workflows搭应用
自助分析、运营应用构建与工作流。因为都基于同一套对象 / 动作 / 关系，工作流越建越多，共享的本体就越厚实——应用开发的边际成本随时间趋近于零。这正是"复利效应"。
5决策编排 Decision Orchestration闭环 · 写回去
探索情景，并把决策同步回源头。通过原生连接器与 ERP / CRM / MES / 资产配置 / 边缘系统等双向打通，让在 Foundry 里做出的决策贯穿整个数据版图。Foundry 因此成为连接历史上彼此孤岛系统的"结缔组织"。
串起来：① 把数据接进来 → ② 把模型接进来 → ③ 用本体把它们变成"企业的数字孪生" → ④ 在上面搭工作流和应用 → ⑤ 让决策写回真实系统。五层合力，把"看数据"升级成"闭环运营"。
第 3 章 核心：本体 Ontology
如果只记 Foundry 一个词，还是它——本体。它是整个平台的心脏。
本体不是"另一张数据库表"。官方定义：它是一层运营层，是数据与模型的企业级数字孪生。它把底层数据/模型，映射到真实世界的业务对象——比如"工厂""配送中心""设备"——让所有人用同一套共同语言和企业的数字替身互动。
本体由三类东西构成：
对象 Objects：真实世界的实体、关系与事件的数字表示。例如：一台设备、一张订单、一座工厂。
关系 Relations：实体 / 事件 / 流程之间的连接。例如：工厂"生产"某产品、订单"归属"某客户。
动作 Actions：对象之间的"动力学"，通过企业系统编排真实世界的改变。例如：下达生产计划、触发检修工单。动作可由现有流程或模型映射而来。
而且，本体是通过数据、逻辑、动作、安全四重融合来表征企业复杂决策的——这也是它能被人和 AI 共同协作的原因。
🕹️ 互动探索：把一家制造企业"本体化"
左边选一个业务对象，右边切换查看它的"对象 / 关系 / 动作"，直观感受本体如何把企业变成可计算的数字孪生。
对象 Objects
关系 Relations
动作 Actions
为什么这很厉害？当工厂、设备、订单都成了"对象"，业务人员不用懂 SQL，也能像搭积木一样在它们上面建应用；AI 也能"读懂"业务上下文。更重要的是——这些对象既能反映现状，也能通过动作去改变现状。
第 4 章 数据如何流动
从"源系统里的原始数据"到"业务人员做出的决策并写回系统"，中间经过一条流水线。点击下面的节点，一步步看清楚每一站在做什么。
点击上方任意节点查看说明 👆
关键闭环在最后一步：用户在本体应用里做的决策（Actions）会写回（Writeback）到 ERP / CRM 等源系统。这不是单向的"ETL 抽取"，而是带完整血缘的双向回路——这正回答了序章里"看得到却动不了手"的痛点。
第 5 章 不搬数据：联邦连接
Foundry 一个反直觉却关键的设计：它尽量不复制你的数据。
❌ 传统做法：复制数据
把源数据拷进新平台
每接一个系统就复制一份 → 多个"真相副本"并存；源系统一变，副本就过期；权限、合规要在多处重复治理；数据越多，孤岛和混乱越严重。这就是 Foundry 说的"fracturing existing sources of truth（割裂既有真相源）"。
✅ Foundry：原生联邦 Native Federation
连而不搬，就地访问
把外部系统的现有数据集直接接入本体成为对象，不复制底层数据。既用上企业既有架构的全部能力，又不撕裂既有的"真相源"。配合实时双向连接与血缘，数据始终唯一、可控、可追溯。
"No Duplication（不重复）"是官方反复强调的原则：把企业和架构里的数据、模型吸收进来，同时不复制底层资产、不割裂既有真相源。这让 Foundry 能接入庞大既存系统，而不制造新的数据沼泽。
📌 随堂小测：Foundry 的"原生联邦（Native Federation）"主要解决什么痛点？
A 让数据复制得更快
B 接入外部数据却不复制、不割裂既有真相源
C 只服务单一数据库
答案：B。联邦连接让外部数据集直接成为本体对象，不复制底层数据，避免多个过期副本和真相源被割裂。
第 6 章 给不同角色的装备
本体之上，Foundry 给"搭应用的人"和"用应用的人"准备了不同工具。点开看看谁该用什么。
🧱
Pipeline Builder 数据接入
旗舰级"本体填充"工具：用点选界面搭生产级数据管道，后端自动写转换代码；支持结构化/非结构化/IoT/地理空间、批/微批/流式。
🗺️
Ontology Manager 建模
精确设计本体：定义对象、关系、属性（含时序/地理）、元数据，把模型映射到可被用户/系统执行的动作，闭合 AI/ML 与运营的回路。
🎯
Model Objectives 模型
把模型绑定到本体、围绕具体"运营结果"组织建模；配置写回路径，把动作与反馈当作新数据捕获，持续改善生产表现。
🔄
Ontology Process Orchestration 流程
在本体里以"一等公民"方式建模、诊断、自动化业务流程（任务/流转/团队），从流程日志找瓶颈与高价值决策。
🛠️
Workshop / Slate 应用
Workshop 是低代码应用构建器；Slate 用自定义 HTML/CSS/JS 做深度定制前端。业务人员也能拖拽搭出运营应用。
📊
Quiver / Object Explorer 分析
面向对象的分析与探索工具，支持时序、地理、图谱等多种视角，把分析嵌入日常运营。
📦
Ontology SDK（OSDK） 开发
把本体变成一套 API/SDK，开发者用熟悉语言在"对象层"上构建自定义应用，连接企业各处——和 AIP 的 OSDK 同源。
小结：从"接数据"（Pipeline Builder）→ "建本体"（Ontology Manager）→ "绑模型"（Model Objectives）→ "编排流程"（Process Orchestration）→ "搭应用"（Workshop/Slate/Quiver）→ "自研集成"（OSDK），技术用户和业务用户各取所需，且都站在同一个本体之上。
第 7 章 真实影响力
Foundry 不是 PPT 概念——它已在最关键的机构里跑了很多年。挑几个带硬指标的例子感受一下。
Jacobs（水务）
厂区节能 20%在已高度优化的污水处理厂，借助智能算法消除运营罚款、降低温室气体排放。
Sonnedix（光伏）
降低停机时间在西班牙 Talayuela 等太阳能电站部署 Foundry，大幅数字化生产流程、减少停机。
某全球银行（反洗钱）
告警处理快 60% · 成本降 90%AI 驱动的交易监控，多司法辖区客户检索快 90% 且更一致，合规与风控显著提效。
某大型银行（营销）
营销上线 数月 → 1 天用 Foundry 驱动"下一个最佳方案（NBO）"营销，活动上线时间从数月压缩到一天。
Cleveland Clinic（医疗）
虚拟指挥中心优化床位分配、出院管理、人员调配与手术室利用率，缩短等待、降低住院时长。
Swiss Re（再保险）
统一风险视图把分散的数据仓库连成统一分析底座，在强安全治理下获得深度风险洞察。
共同点：这些场景都是"数据散、系统老、错不起、要实时"。Foundry 的价值不在于某个炫技功能，而在于把分散真相连成闭环，让组织级决策能被持续、安全、可追溯地执行。
第 8 章 总复习 & 自测
走完全程，来一次综合自测。
1️⃣ Foundry 自称是什么？
A 一个普通的 BI 报表工具
B 本体驱动的现代企业操作系统（Ontology-Powered Operating System）
C 只做数据清洗的 ETL 软件
Foundry 的定位是"以本体为内核的现代企业操作系统"，处在数据与应用之间统一调度，追求闭环运营。
2️⃣ Foundry 认为企业软件应当突破哪种模式？
A 线性分析（接入→可视化就结束）
B 闭环运营（决策能写回源系统，运营↔决策持续回路）
C 纯手工 Excel 统计
Foundry 批判"线性分析"，主张业务是闭环系统，软件也该闭环，决策应写回 ERP/CRM 等源头。
3️⃣ 在 Foundry 的本体中，体现"真实世界改变"的是哪一类？
A 对象 Objects（实体表示）
B 关系 Relations（连接）
C 动作 Actions（编排真实改变）
Actions 是对象之间的"动力学"，通过企业系统编排真实世界的改变；对象表示实体，关系表示连接。
4️⃣ "原生联邦（Native Federation）"的核心好处是？
A 把数据复制多份以便加速
B 接入外部数据却不复制、不割裂既有真相源
C 只支持单一数据库
联邦连接让外部数据集直接成为本体对象而不复制底层数据，避免多个过期副本和真相源割裂。
5️⃣ 数据流动的"最后一步"为什么关键？
A 决策（Actions）写回源系统，形成双向闭环
B 把数据彻底删除以节省空间
C 仅生成一份静态报告就结束
闭环的关键在于用户决策通过 Actions 写回（Writeback）ERP/CRM 等源系统，带完整血缘，形成运营↔决策的持续回路。
🎓 课程结语：回到序章那个坑——"看得到数据却动不了手"。Foundry 的答案有三块拼图：① 把分散数据接成统一本体（不复制）、② 把企业变成可计算的数字孪生、③ 让决策能写回真实系统形成闭环。它不只是"看数据的工具"，而是让数据真正去"办事"的操作系统。
📖 术语速查
关于 Palantir Foundry 的常见问题
以下问答可直接引用；答案整理自 Palantir 官方页面与平台文档。
- Palantir Foundry 是什么？
- Foundry 是 Palantir 面向企业的本体驱动操作系统，处在「数据」与「业务应用」之间。它把分散的数据源、模型与决策流程连成闭环，让企业变成一个可计算的数字孪生，并使在平台上做出的决策能够写回 ERP / CRM / MES 等源系统，而不只是产出报表。
- Foundry 的五层平台架构分别是什么？
- 自下而上依次是：① 数据集成（软件定义的数据接入，内置 200+ 连接器，支持实时双向连接与血缘写回）；② 模型集成（接入自带模型或原生构建，让数据科学家与业务用户协作用模型做决策）；③ 本体 Ontology（把数据与模型连接到真实业务对象，形成企业级数字孪生）；④ 工作流 Workflows（自助分析、运营应用构建，基于同一套对象 / 动作 / 关系，应用开发的边际成本随时间趋近于零）；⑤ 决策编排（探索情景并把决策同步回源头，与 ERP / CRM / MES / 边缘系统双向打通）。
- Foundry 的「本体驱动（Ontology-Powered）」是什么意思？
- 指 Foundry 不是简单堆数据，而是用本体把企业建模成一个可计算的数字孪生。本体由对象（Objects）、关系（Relations）、动作（Actions）三类要素构成，并通过数据、逻辑、动作、安全四重融合来表征复杂决策——这也是它能让人类与 AI 共同协作的原因。
- Foundry 的「原生联邦（Native Federation）」和复制数据有什么区别？
- 传统做法是把外部数据复制进平台，会产生多份可能过期的副本，并割裂既有的「真相源」。原生联邦尽量不复制底层数据，而是让外部数据集直接成为本体中的对象，从而在保留既有系统权威性的同时把它们纳入统一分析。
- Foundry 给不同角色提供哪些工具？
- 搭应用的人用 Pipeline Builder（数据接入）、Ontology Manager（本体建模）、Model Objectives（模型与运营结果绑定）、Ontology Process Orchestration（流程编排）、Workshop（低代码应用构建器）与 Slate（自定义前端）；用应用的人用 Quiver 与 Object Explorer 做面向对象的分析与探索；开发者用 Ontology SDK（OSDK）把本体变成 API / SDK，用熟悉的语言构建自定义应用。
- Foundry 和 AIP、Apollo 是什么关系？
- Foundry 与 AIP 同属 Palantir 的企业操作系统家族：Foundry 负责数据管理与 Ontology 开发，AIP 在同一个本体之上把 AI 接入业务流程，二者共享同一套 Ontology SDK；Apollo 是最底层的部署引擎，负责把 Foundry 与 AIP 持续交付到客户云、本地机房、气隙与边缘环境。