Palantir Ontology 到底是什么？——深度研究

一句定调：Palantir Ontology 不是数据模型，也不是知识图谱。它是一套把企业的数据（名词）+ 逻辑 + 行动（动词）+ 安全在运行时融合为一个可被"人"与"AI Agent"共同读写的决策操作系统。它建模的不是"企业有什么"，而是"企业如何做决定，并让决定在现实世界里生效"。

0. 开篇：先别急着定义，看两个场景

想象一个画面。

场景一（战场）：乌东前线，一名侦察兵用手机拍下一段视频。十分钟内，这段视频、卫星图、信号情报、历史目标库被自动关联到"同一个俄军防空阵地"对象上；系统给出打击建议，经指挥官一键批准，工单写回火炮单位的指挥系统。Palantir 在乌方自称"负责大部分目标定位"——这正是 Ontology 在干活：把散落各处的情报碎片，粘成"一个对象 + 一组可执行的动作"。

场景二（工厂）：一台风力发电机振动异常。Ontology 里它不是一个数据库行，而是一个"对象"——连着它所属的风场、它的维修历史、备件库存、班组排班。系统不只能"告诉你它坏了"，还能"派一张维修工单、改它的状态、通知班组长、在 SAP 里建单"。从知道到行动，闭环在一套受治理的权限下完成。

这两个场景的共同点：数据被建模成"业务里真实存在的事物"，并且这些事物能被"操作"。这就是 Ontology 的起点。

1. 一句话定义：Ontology 到底是什么

Palantir 官方最权威的定义（Architecture Center《The Ontology system》）原话：

"The Ontology is designed to represent the complex, interconnected decisions of an enterprise, not simply the data."

翻译过来：Ontology 是用来表示企业里那些复杂、相互关联的决策的，而不只是数据。

它把企业表示为四者的融合（官方称之为 four-fold integration）：

• Data（数据）：对象、属性、链接——企业的"名词"
• Logic（逻辑）：函数、规则、模型——如何判断与计算
• Action（行动）：受治理的写操作——企业的"动词"
• Security（安全）：行/列级权限，对人、对 Agent 一视同仁

官方还给了两个关键比喻：

• Ontology 是企业（组织）的 operational layer（运营层），也是其 digital twin（数字孪生）——既含语义元素（objects/properties/links），也含动态元素（actions/functions/dynamic security）。
• 名词必须配上动词——semantics must be paired with kinetics（语义必须与动力学配对）。一个只有"名词"的知识图谱，只能回答问题；加上"动词"的 Ontology，才能改变世界。

一句话总结其本质：Ontology 是"决策的操作系统"，不是"数据的目录"。

2. 三阶段演进：从情报工具到决策操作系统

Ontology 不是 2016 年 Foundry 凭空发明的，它的基因早在 Gotham 情报时代就已定型。

注意一个口径漂移陷阱：2020–2022 年 Palantir 自己营销时称 Ontology 是 "semantic layer"；到 2025–2026 年则明确否认"The Ontology is not a semantic layer"。任何引用"官方定义"都必须带抓取日期。

3. 架构三件套：Object Type / Link Type / Action Type

这是 Ontology 最常被讲清楚的部分，也是它与"普通数据模型"分道扬镳之处。

3.1 Object Type（对象类型）—— 企业的"名词"

现实世界实体或事件的 schema 定义。单个实例叫 object，集合叫 object set。与数据集严格类比：

关键点：它不是抽象数据模型，必须绑定 backing datasource（Foundry dataset / 流式源 / virtual table）才"活"。每个 object type 必须有 primary key（唯一、确定性生成）和 title key（显示名）。OSv2 支持单类型最多 2000 个属性、数百亿量级对象。

例：Wind Turbine（风力发电机）对象类型，属性含 turbine_id（主键）、型号、额定功率、当前状态。

3.2 Link Type（链接类型）—— 对象间的关系

两个 object type 之间关系的 schema 定义，天然双向——一个 link type 有两个 side，各自有独立显示名，可双向遍历（flight.assignedAircraft.get() 与 aircraft.flights.all()），无需定义反向链接。支持自链接（Employee 的 Manager↔Direct Report）。

例：Wind Turbine —位于→ Wind Farm。

3.3 Action Type（动作类型）—— 分水岭，企业的"动词"

一次性对对象、属性值、链接做出的一组变更 schema，外加提交时的 side effect。 构成要素：parameters（带约束的表单）、rules（增删改对象/链接）、submission criteria（校验与权限）、side effects（通知、webhook、触发构建）、function-backed logic。单个 Action 最多可编辑 10,000 个对象。

为何 Action 是 Ontology 区别于纯数据模型的分水岭？ 三点：

1. 它是受治理的写入通道——OSv2 中直接编辑 API 已废弃，object type 必须开启"仅允许通过 Action 编辑"；
2. 它把编辑封装成单一事务 + 校验 + 权限 + 审计（action log 记录谁在何时做了什么决策）；
3. 它能通过 webhook 写回外部系统。

例：派发维修工单 Action——参数为工单优先级与责任班组，规则是创建 Work Order 对象并链接到该风机、把风机状态改为"待检修"，side effect 是通知班组长 + webhook 在 SAP PM 建单。

4. 解耦与双向绑定：语义层之上，ERP 之下

4.1 与底层数据源解耦

分三层实现：

• 元数据与数据分离：Ontology Metadata Service (OMS) 只存类型级定义；object 实例数据在 object database 中。
• 映射而非搬运：建模是把已有数据源的列映射成属性；同一 object type 可由多数据源拼装；virtual tables 让 Foundry 指针式引用 Snowflake/Databricks/BigQuery/S3-Iceberg 的表而不复制数据（Native Federation）。
• 同步靠 Funnel 管道：Object Data Funnel 编排四步——changelog（算差分）→ merge changes（合并源变更 + 用户编辑）→ indexing（转索引）→ hydration（落盘）。默认增量索引；用户编辑立即写入索引，每 6 小时持久化。

现实约束：对象新鲜度上限 = 上游管道节奏。批处理管道喂养的对象就是"批处理对象"，只有流式数据源才能低延迟。

4.2 双向绑定：读 → 决策 → 写回 → 回流

核心机制是 Action 的 webhook，分两种：

• Writeback webhook：变更之前执行，失败则 Ontology 不做任何改动，形式上实现"事务性"；输出参数可被后续规则捕获写回。
• Side effect webhook：变更之后执行，失败不向用户展示。

⚠️ 诚实标注：Palantir 文档自己承认这不是真正的两阶段提交——"外部请求成功但 Ontology 变更失败"仍可能发生。

对"决策操作系统"叙事的意义，闭环是：读（OSS 查询对象/遍历链接）→ 决策（人或 AIP Logic）→ 写（Action 改 Ontology + webhook 改 SAP/Salesforce）→ 回流（Funnel 重新索引 + action log 归因）。

5. 关键辨析：它常被误认成什么

这是全文最需要"拨乱反正"的一节。

5.0 ⚠️ 首要纠错：Palantir 从未说过"Ontology 不是知识图谱"

中文圈广泛流传一条"官方原话"："The Foundry Ontology is not a knowledge graph. It is a semantic layer..." 声称出自《Foundry platform summary for LLMs》。经逐字核查该页面，此引文系伪造——全页未出现 "knowledge graph" 一词，且真实原句恰恰相反："The Ontology is not a semantic layer."

Palantir 真正的划界对象是语义层，而非知识图谱。它从未正式撰文点名反驳知识图谱。

5.1 与知识图谱（Knowledge Graph）

• 形似：都是"节点 + 边"。
• 神异：KG 目标是"知道得更多"（搜索、发现、GraphRAG grounding、推理）；Ontology 目标是"建模决策并驱动现实改变"。
• Ontology 多出的：Action Types（受治理事务）、双向写回、Functions、security 作为第一公民。
• 认识论差异：传统 KG 采开放世界假设（OWA）+ RDF/OWL 推理；Palantir 采封闭世界 + managed schema，轻推理、重运营。

5.2 与语义层（Semantic Layer，如 dbt MetricFlow / Cube）

• 语义层只读，解决"指标口径统一"（三个部门算出三个营收）。
• Ontology 统一"决策怎么做"，输出一个可执行、可审计、可写回 ERP 的动作。
• 一句话：语义层统一"数字怎么算"，Ontology 统一"决策怎么做"。这正是 Palantir 拒绝"语义层"标签的根因。

5.3 与 Data Mesh / 图数据库

• Data Mesh：互补，不是替代。 Data Mesh 回答"谁负责、怎么治理"（组织范式）；Ontology 回答"业务对象与动作长什么样"。Swiss Re 案例即在 Data Mesh 组织下用 Foundry 做跨域共享语义骨架。
• 图数据库：不依赖。 Ontology 的"图"是逻辑语义结构，非物理图存储。后端是 OMS/OSv2/OSS/Funnel 微服务 + 数据湖列存 + Lucene/ES 索引。不要一上来就买图库。

5.4 与传统数据建模（ER / 维度建模）

5.5 对比矩阵（一表速览）

6. AIP 时代：LLM + Ontology = 决策级 Agent

2023 年后 AIP 把 LLM 接入 Ontology，核心论点是：Ontology 建模的是决策，而非数据。

关键设计——LLM 不直接碰数据库，也不直接持工具。 AIP Logic 文档原话："LLMs do not have direct access to tools; LLMs can only ask to use tools, and these tool calls are then executed by AIP Logic within the invoking user's permissions." 即 LLM 只输出"调用意图"，实际执行由平台在调用者本人权限下完成。

安全侧：工具的每次调用都依赖对底层 objects/properties/links 的访问权；权限是 marking/purpose/role-based，运行时逐次动态计算，而非静态角色分桶。官方比喻：每个 Agent 可被视为"一名新团队成员，权限随信任逐步放开"。

关键组件

• Ontology SDK (OSDK)：把 Ontology 生成为强类型 SDK（TS/Python/Java，其他走 OpenAPI），"Foundry as your backend"。token 双重收敛：应用 scope ∩ 用户权限。
• AIP Logic：no-code 的 LLM 编排环境，工具分三类——Query objects（控越权）、Call function（确定性计算外包）、Apply actions（用 Action 编辑 Ontology）。且"Logic 函数必须由 Action 调用才会真正写回"。
• Ontology MCP (OMCP)：把 ontology resources 暴露为 MCP tools，让外部 Agent（Claude Code、Copilot Studio、VS Code）作为 MCP client 接入，并沿用同一套安全策略。与之对照的 Palantir MCP 面向 builder（改结构但不能写数据）。
• human-in-the-loop：Action 默认只能被 AI "staged（预演）"，交人终审；只有充分测试的可信流程，客户才主动选择放开自动闭环。AIP Logic × Automate 生成 Proposals 队列，审阅者可看 Agent decision log（LLM 为何这么提议）。

与 LangChain / AutoGPT 等框架的根本区别

一句话：LangChain 给的是"编排自由度"，Palantir 给的是"受治理的执行权"。Agent 每次工具调用都继承调用者权限、在同一套策略下运行时求值、动作默认 staged 待人批、写回真实 ERP 并留完整 decision lineage。通过 OMCP，LangChain/CrewAI 可当"前端"，治理层仍留在 Ontology——这既是"enterprise-grade"卖点，也是锁定来源。

agentic memory（四类记忆，第三方整理，Palantir 仅列名）

• Working：当前 agent loop 内的中间状态
• Episodic：跨会话、带时间标记的执行记录
• Semantic：Ontology 的对象/属性/链接本身（按类别组织）
• Procedural：代码化流程（functions/actions/skills）
  喂养机制 = decision lineage：自动捕获"决策何时做出、基于哪个版本数据、经哪个应用、评估了哪些选项、下游影响如何"，可供微调或蒸馏为提示原则；且所有 memory 与工具调用共用同一套安全架构。

7. OAG vs RAG：不是替代，是上位封装

Palantir 提出 Ontology-Augmented Generation（OAG） 优于 RAG，但需客观看待。

Palantir 视角：OAG 是"更 expansive、更 decision-centric 的 RAG 版本"。差别：①检索单位是带类型、带链接、带实时状态的 object，而非"过去的文本片段"；②该算的交给确定性 logic（预测/优化），而非让 LLM 文字估算；③可写回源系统闭环；④权限贯穿全链路。

客观评价（重要）：Palantir 官方文档中标题叫 "Ontology-augmented generation" 的那一页，内容其实全是经典 RAG 技术——chunking、embedding、semantic search、HyDE、hybrid + RRF——并明写"there is no singular 'best approach'"，长上下文下甚至建议"start without search"。

结论：

• OAG 更优：需要实时业务状态、跨系统关系遍历、确定性计算、权限一致、可执行写回的运营决策。
• RAG 仍合适：法规/手册/合同等非结构化文档问答，及不值得建模成对象的长尾知识。
• 代价：OAG 前置成本极高（集成、建模、治理），且不消除幻觉，只是压缩自由发挥空间、用 Action 门禁限制幻觉后果。
• "OAG" 是 Palantir 自造/营销术语，非学术通用；网上"OAG 碾压 RAG"多为同一篇 blog 的二次转述，须打折。

8. 实战与局限：光环与阴影

8.1 实战案例（区分厂商口径与独立核实）

国防 / 情报

• 乌克兰：Karp 2022-06 访基辅（首位战时访乌西方科技 CEO），签 Gotham 协议；2026-01 启动 Brave1 Dataroom 用战场数据训反无人机模型（Reuters 2026-05-12，Zelenskiy/Fedorov 证实用于纵深打击规划）。Karp 自述"负责大部分目标定位"属厂商声明；乌方人士称自研 Delta 在数据采集上优于 Palantir，Palantir 强在可视化/语义整合。
• Maven Smart System：2023-05 被定为唯一来源供应商；2024 年扩至各战斗司令部，合同累计上限 \(10 亿+。NGA 局长称在乌把"发现到打击"压到 10 分钟内（二手转述，待核原始发言）。 - **Army Vantage**：整合 180+ 数据源、10 万+ 用户；2024-12 获\)4.007 亿（上限 \(6.189 亿）；2025-07 另获美陆军 10 年/最高\)100 亿企业协议。

医疗

• NHS COVID Datastore（2020）：首期象征性 £1，无竞标；后转两年 £2,350 万。合同原文写服务含"integration into a data ontology"。
• NHS Federated Data Platform（2023 起）：£3.3 亿/最长 7 年。最大规模医院资源调度部署，也是批评最集中靶子（见 8.3 数字核查）。

商业

• Airbus / Skywise：2015 起合并 25 个数据孤岛；官方称 A350 交付提速 33%；现连 10,500+ 飞机 / 50,000+ 用户（2026-02 续约）。Ontology 角色：把 SAP/CATIA/MES/IoT 中同一零件的多 ID 绑到一个对象。
• Swiss Re：2018 起以 Foundry 做 data mesh 底座（半官方客座文）。
• 其他官方 Impact 自述：Citi Wealth 开户 9 天→秒级、Heineken USA、Sompo、General Mills、United Airlines 等（均为客户高管在 Palantir 活动自述，缺独立验证）。

8.2 成本与门槛

• 合同量级：政府端 NHS £3.3 亿、英国国防部最高 £7.5 亿/5 年、美陆军 \(100 亿上限；企业端头部 20 客户年均贡献据年报口径约\)9,390 万（待核 SEC 原文）。
• FDE 依赖：Palantir 早期 20 年亏损根因即"重人力驻场"。前 FDE 称"Foundry 不是永久许可证，须培训才能用，且需持续支持"。做空方 Burry 指控其把 FDE 人力成本计入研发/销售而非 cost of revenue，虚高毛利率（做空方观点，谨慎）。
• 实施周期：官方话术"days, not years"；实际 Airbus 两年试点到产品化，Skywise 生态十年。

8.3 数字核查警示（本研究的硬成果）

8.4 厂商锁定（铁证）

• NYPD 案（最硬一手）：2017 年合同期满转投自建 Cobalt，要求导出分析成果，Palantir 拒绝以可迁移格式交付，主张"组织/连接/可视化数据的方式属 Palantir 知识产权"。争的不是喂入的数据，而是软件产出的分析。
• 英国议会（Hansard 2026-02-10）：议员指出 MoD 透明度公告写"only Palantir"能运行该服务、更换有"significant cost"，"被彻底锁定在涨价的合同里"；防长未否认锁定，只回应"数据主权留英国"。
• 反例（锁定非绝对）：法国 DGSI 2026-06 换 ChapsVision（主权考量，报价 €1,000 万→€4,000 万）；瑞士陆军拒绝 Palantir；英国住房社区部改自建后称年省数百万英镑。

8.5 权威批评

• Donald Farmer（TreeHive Strategy 创始人，前微软/Qlik）：核心立场是 ontology/metadata 是"组织知识的机制，不是治理企业如何运作的业务逻辑"，并反复批评 "human in the loop 是一种推诿"。其金句"一个不完整的本体比没有本体更危险"目前仅见中文转述，未定位英文原文，引用须标注"据中文评论转述"。
• 中文"本体论骗局"论（自媒体，可信度低）：①同构论（ObjectType=表、Link=外键、Action=存储过程，称"严格同构"）；②概念轮回（亚里士多德→ER→OOP→语义网→Foundry）；③护城河在政商关系+FDE+路径依赖；④认知税（说"建表"要不到钱，说"数字孪生"能卖几千万）。该论有明显简化（忽略 Action 治理、动态安全、decision lineage），可作"论点素材"不宜作事实源。

8.6 适用边界：谁别碰 Ontology

1. 数字化底座不足（源系统数据质量差、主数据未治理）——脏数据接进 Ontology 只会更快处理坏数据。
2. 决策无范式（关键决策还没有稳定可复用的动作集，无 Action 可写回）——只会得到昂贵语义层。
3. 只需报表/看板——BI + 语义层 + 数仓即可，成本低两三个数量级。
4. 业务模型高速漂移——刚性 schema 追不上（Farmer 之虑）。
5. 意义断点不在关系层——歧义在定义层先做 business glossary，在分类层先做 taxonomy；只有当关系本身承载临床/合约/监管/安全含义（医疗、生命科学、金融、航空、国防、工业安全）时，ontology 才是控制系统。
6. 主权/合规敏感且无替代退出路径——见法国 DGSI、瑞士陆军、英国 MoD 教训。

9. 结语：给步子哥的三句可背诵金句

1. "Ontology 建模的不是企业有什么，而是企业怎么做决定。" —— 这是它与数据模型、知识图谱、语义层的根本分野。
2. "名词配不上动词，就只是个知识图谱；动词受治理地写回 ERP，才是决策操作系统。" —— Action + writeback 是分水岭。
3. "AIP 时代，Ontology 是 Agent 的骨架：LLM 只许提案，平台按你的权限执行。" —— 受治理的执行权，正是 enterprise-grade 与厂商锁定的同一枚硬币两面。

附：核心来源清单（按深挖价值排序）

1. Palantir Docs — The Ontology system（最权威划界，含 "not a semantic layer"）：https://www.palantir.com/docs/foundry/architecture-center/ontology-system/
2. Palantir Docs — Why create an Ontology?（四要素、nouns/verbs、decision lineage、agentic memory）：https://www.palantir.com/docs/foundry/ontology/why-ontology/
3. Palantir Docs — Foundry platform summary for LLMs（"not a semantic layer" 原页，注意无 KG 一词）：https://palantir.com/docs/foundry/getting-started/foundry-platform-summary-llm
4. Palantir Blog — Connecting Agents to Decisions：https://blog.palantir.com/connecting-agents-to-decisions-277dee8ddb40
5. Palantir Blog — Building with Palantir AIP: Data Tools for RAG / OAG：https://blog.palantir.com/building-with-palantir-aip-data-tools-for-rag-oag-b3b509c8b0f3
6. Palantir Docs — AIP Logic Blocks（三类工具与"LLM 只能请求调用"）：https://www.palantir.com/docs/foundry/logic/blocks
7. Palantir Docs — Ontology MCP Overview：https://www.palantir.com/docs/foundry/ontology-mcp/overview
8. Palantir Docs — Ontology SDK Overview：https://www.palantir.com/docs/foundry/ontology-sdk/overview/
9. Palantir Docs — Ontology Core concepts / Object types / Link types / Action types：https://www.palantir.com/docs/foundry/ontology/core-concepts/
10. Computer Weekly — NHS COVID Datastore 合同（"data ontology" 原文）：https://www.computerweekly.com/news/252484257/NHS-Covid-19-datastore-contracts-published-under-pressure-from-privacy-groups
11. FT/Yahoo — Health Foundation：Palantir 工具"无明显改善"，15% 被推翻：https://finance.yahoo.com/healthcare/articles/palantir-tool-not-cut-hospital-040014432.html
12. UK Parliament Hansard（2026-02-10）— MoD "only Palantir" / "entirely locked in"：https://www.parallelparliament.co.uk/mp/martin-wrigley/debate/2026-02-10/commons/commons-chamber/ministry-of-defence-palantir-contracts
13. Brennan Center — NYPD vs Palantir 数据导出纠纷（引 BuzzFeed 原报道）：https://www.brennancenter.org/our-work/analysis-opinion/palantir-contract-dispute-exposes-nypds-lack-transparency
14. Neo4j Blog — What Is a Knowledge Graph?（KG 官方定义，ontology 作为 organizing principle）：https://neo4j.com/blog/genai/what-is-knowledge-graph/
15. dbt Docs — About MetricFlow（语义层官方定义，只读）：https://docs.getdbt.com/docs/build/about-metricflow

本研究由五路并行深度调研整合而成（概念演进 / 架构实现 / 对比辨析 / AIP 机制 / 实战局限），所有"官方原话"均经逐字核查，流传数字均做一手出处验证。撰写于 2026-08-08。