拆解 Palantir 本体：在数据之上加入“行动”的运营层

Palantir 本体是什么，为什么称为“运营层”

本文是“本体的虚与实”系列的第 2 篇，把第 1 篇讨论的一般原理（本体是把业务的概念、属性、关系和规则写成机器可读形式的设计图，效果取决于用真实数据填充并持续校准的运营）套用到商业上最成功的案例 Palantir 上。本文借助官方文档拆解其结构，并考察这一结构如何与商业模式相互咬合，以及有哪些批评。

Palantir 官方文档（w1）把本体定义为“组织的运营层（operational layer）”。按其说法，本体位于平台中集成的数字资产，即数据集、虚拟表和模型之上，把它们与工厂、设备、产品等实物资产，或客户订单、金融交易等概念连接起来。文档还称，在许多情况下它充当组织的数字孪生。

关键在于“运营”一词。第 1 篇中提到的语义层或数据目录，止步于整理“这个数字是什么意思”，以辅助分析和报告。Palantir 则试图在同一语义结构之上，把人实际做出决策、执行决策、执行记录再变成数据的整个闭环放进同一个系统。公司文档（w3）写道：“实时闭合行动闭环，是运营系统与分析系统的分界点。”

因此，阅读本文也有两个视角。一是“把分析和执行绑在一处的设计”在技术上做了哪些取舍；二是这种设计催生了怎样的销售方式和锁定效应。

构成要素：语义要素（名词）与动态要素（动词）

官方文档（w1）把本体分为两组。语义要素是对象（object）、属性（property）和链接（link），动态要素是动作（action）、函数（function）和动态安全（dynamic security）。借用公司文档（w3）的比喻，语义要素是企业的“名词”，动作是“动词”，在每个业务流程中，人或 AI 用逻辑把名词和动词组织成“完整的句子”。

核心概念文档（w2）中的定义整理如下。对象类型是现实中实体或事件（如员工、订单、设备故障）的模式定义，对象是其中的一条实例。属性是对象类型的特征，链接类型是两个对象类型之间的关系。动作类型定义了用户一次可以施加的对象、属性值和链接变更的集合，以及随之而来的副作用（如通知）。函数是接收输入、产生输出的基于代码的逻辑，以对象和对象集合为输入，在动作和各类应用中使用。此外还有让多个对象类型共享同一形态的接口、多个对象类型共用的共享属性，以及控制访问的角色（roles）。

有意思的是，Palantir 自己就用数据集来类比这些概念（w2）。它用表格展示：对象类型对应数据集，对象对应行，属性对应列，属性值对应单元格值，链接类型对应连接（join）。也就是说，公司并不讳言：仅看语义要素，它与关系型数据模型几乎一一重合。因此，差异点不应在语义要素中找，而应在其上的动态要素，即同时定义“如何修改”这一点上。

动作文档（w4）中的例子很好地说明了这一点。“员工调配”动作类型定义了如何修改员工对象的角色属性，通过标准表单接收新角色，并自动在员工与新经理对象之间创建链接。它还附带向原经理和新经理发送通知的副作用，以及只有人事负责人才能执行的校验规则。公司的说法是，不是逐个修改单元格，而是“以业务目标为单位处理数据”。

把数据源变为对象，把决策送回源系统：映射与回写

本体并不是从一张空白设计图开始的。官方文档（w1）称，定义组织语义的工作就是“把现有数据源映射为对象、属性和链接”。据公司文档（w3），ERP（企业资源计划）、MES（制造执行系统）、WMS（仓库管理系统）等运营数据，IoT 和边缘数据流，非结构化文档库以及地理空间数据，经同步后以对象、属性、链接的形式组织起来。也就是说，顺序是先用数据管道接入源数据，再把数据集的列声明为属性、把连接关系声明为链接。

反方向就是“回写（write-back）”。动作文档（w4）说明，用户执行动作后，对象、属性值和链接的变更会反映到本体中，并立即在所有用户应用中可见；包含用户修改的最新对象数据会写入该对象类型的回写数据集（writeback dataset）。公司文档（w3）更进一步称，人和智能体的动作可以先以场景方式模拟，再经过与数据、逻辑相同的访问控制，安全地回写到交易系统、边缘设备、定制应用等企业底层系统。

回写之所以重要，有两个原因。第一，减少了在分析界面上做出“这台设备需要检修”的判断后，还要再到另一个系统里录入的断层。第二，会积累公司文档（w3）所说的“决策数据”。其主张是：某个决策在何时、基于哪个版本的数据、通过哪个应用做出，这种“决策血缘”会被自动记录，并再次成为训练和智能体记忆的素材。

代价也随之而来。一旦有了写入源系统的通道，本体就不再是只读副本，而成为业务处理的一根支柱。权限、校验和变更管理设计不当，造成的就不是分析错误，而是运营事故；反过来，设计得越好，业务就越深地绑定在这一层上。后文的转换成本之争正是由此而起。

设计原则与 AIP：为决策建模，并作为工具交给智能体

公司文档（w3）称，本体“表达的不是数据，而是企业的决策”。它把每个运营决策视为四个要素：数据（决策所用的信息）、逻辑（评估决策的启发式规则和计算）、动作（所选决策的执行与协调）、安全（对决策遵守运营政策的保证）。公司提出的问题是：现有数据架构无法承载决策背后的推理和随后的行动，现有分析架构又与运营脱节。

在逻辑方面，公司强调“逻辑绑定”（w3）。其说明是：把 CRM、ERP 中的业务规则，数据科学环境中的预测模型，领域工具中的优化和仿真算法，无论位于本地、云端还是 SaaS，都用同一接口绑定起来，让确定性（相同输入给出相同结果）的函数和统计方法弥补 LLM 的非确定性推理。可以理解为：让智能体调用经过验证的计算工具，而不是“猜”数字。

AIP（Palantir AI 平台）是在这一结构之上叠加 LLM 的层。据 AIP 文档（w5），用户可以通过 AIP Logic、AIP Chatbot Studio（原名 AIP Agent Studio）、AIP Evals 等构建工具，在本体和开发工具之上构建 AI 工作流、智能体和函数，并在现有安全、审计和资源管理体系内作为沙箱化的应用运行。文档称可以选用多种 LLM，并提供审计记录和评估工具。

对智能体来说，本体就是工具清单。公司文档（w3）说明，工具使用由与数据访问相同的安全体系动态强制执行，至少工具调用取决于对其底层对象、属性和链接的访问权限。为防止跨组织边界的查询或调用未指定外部系统等权限提升，需要明确列出允许操作的授权。从智能体设计的角度看，“动作类型 = 附带校验规则的函数调用（Function Calling）模式”，“角色和标记 = 最小权限原则”，可以理解为把本站所说的 harness 和护栏概念内置到了数据层中。

商业结构：从数字看增长与前线部署工程师

以下数字均来自 Palantir 向美国证券交易委员会（SEC）提交的 2026 年第二季度业绩新闻稿（w6）中的公司公布数据，并标注为未经审计。第二季度营收为 19.35 亿美元，同比增长 93%。公司称，美国营收为 15.73 亿美元（增长 115%），其中美国商业部门为 7.64 亿美元，增长 149%；美国政府部门为 8.09 亿美元，增长 90%。公司公布，签订了 220 份 100 万美元以上的合同、98 份 500 万美元以上的合同、73 份 1000 万美元以上的合同，总合同价值（TCV）为 33.73 亿美元，其中美国商业 TCV 为 21.32 亿美元（增长 153%）。全年营收指引上调至 81.50 亿至 81.58 亿美元，美国商业营收指引上调至 34.24 亿美元以上（增长 134% 以上）。

把这些数字与本体话题连起来的纽带是美国商业部门。政府业务是长期基础，但以本体和 AIP 为主打、扩大一般企业客户，才是当前增长的重心，这是公司公布内容的基本框架。不过，同一份新闻稿（w6）中的风险因素清单也应一并公正地阅读。公司自己写明：销售周期长且难以预测；平台部署过程可能复杂且耗时；由于合同选择权或任意终止条款，总合同价值未必能全部转化为营收；平台需要变得更易于安装和使用。本文仅把业绩数字用作理解商业结构的素材，与股价或投资判断无关。

销售方式中引人注目的是前线部署工程师（FDE，Forward Deployed Engineer）。工程师进驻客户现场，共同分析业务，把数据映射为对象，打造第一个用例。如前一节所述，本体从映射现有数据源开始，如果没有熟悉客户业务和数据的人参与，很容易停留在“空平台”状态。因此，FDE 不只是销售团队，而是构建本体本身的人力，销售与构建紧密融为一体。类似训练营、在短时间内做出原型来展示的销售方式也常被提及，但本次依据材料中没有相关官方说明，本文不作讨论。

韩国的案例有 LG CNS 的合作。据 2026 年 3 月 12 日的公告（w8），两家公司宣布深化战略合作，以加速 LG 集团的 AI 转型（AX）。内容是：2025 年底 Palantir 软件首次引入 LG 集团旗下一家子公司，用于改进质量管理，并计划将其推广到全公司。值得注意的是，LG CNS 内部组建了专门的 FDE 团队，与各子公司共同挖掘用例。这终究只是公布的计划，本次材料中没有推广结果或量化成效。不过，由韩国 SI（系统集成）企业承担 FDE 角色的结构，与前文“本体业务最终离不开人工集成工作”的分析相吻合。

护城河还是咨询：公正看待双方逻辑

批评一方的代表性论点，可以从数据库领域博主 Vonng 的文章（w7）中看到清晰的整理。作者在技术层面把对象类型对应为表、属性对应为列、链接对应为外键、动作对应为存储过程，主张 Palantir 本体是用哲学术语包装的数据库建模。其依据是，Palantir 相关专利的背景说明把本体描述为“以数据库模式实现的数据模型”。作者还把 Palantir 视为“披着 SaaS 外衣的咨询公司”，认为其真正的护城河是政治关系网、安全许可、劳动密集型的 FDE 模式，以及供应商锁定带来的路径依赖。作者还提出疑问：如果本体真是革命性的智能平台，为什么需要让大量工程师长期驻扎在客户现场？

这篇文章（w7）也指出了可移植性问题。作者批评说，与学界本体研究原本以系统间知识共享和互操作为目标不同，Palantir 式建模耗时数月、转换成本高、数据难以迁移。作者举出 2017 年纽约警察局结束与 Palantir 的合作时，提出未能以可移植格式取回分析结果的案例（作者引用了 BuzzFeed News 和 Brennan Center 的报道），并形容本该搭建“桥梁”的本体变成了“墙”。不过，同一篇文章也承认 Palantir 产品的工程价值，以及数据建模和系统集成工作本身是实打实的工作，并划清界限：它质疑的是把这种价值归功于“本体”这一名称的叙事。

相反一方的逻辑可以从公司文档中读到。Palantir 也公开说明语义要素与数据集结构相对应（w2），而把差异点放在别处：附带校验规则和副作用的动作、回写到源系统、在每次执行时计算的基于行、列和标记的权限、决策血缘，以及让人和智能体按同一规则使用这些能力的整合（w3、w4）。其主张是：单个功能或许可以用存储过程或权限表模仿，但价值在于把它们打包成一个产品，让业务应用、智能体乃至审计都一致地运转。

两种视角其实是对同一现象的不同称呼。双方都认同，把整个业务重新映射为对象和动作是一项繁重的工作。一旦投入了这份重量，客户的业务就在这一层之上运转，因而难以离开；从公司角度叫护城河，从客户角度叫锁定。对实务人员来说，重要的问题与其说是“本体是否真是创新”，不如说是“在外部平台上做这项集成工作所获得的速度和控制力，是否值得承受日后的转换成本”。

评估 Palantir 式方法时应提出的问题

第一，确认问题的性质。公司文档（w3）所说的价值在于闭合决策与执行的闭环。如果目的是仪表盘和报告，第 1 篇中提到的语义层或数据仓库很可能就已足够。先要核实“拿到分析结果后再由某人录入另一个系统的断层”是否真的构成成本。

第二，确认映射的所有权。在签约阶段就要问清楚：对象类型、链接、动作的定义，以及回写数据集和决策记录，能否以标准格式导出。正如批评文章（w7）举出的可移植性纠纷案例，终止时的数据导出条件，只有在引入时才有谈判筹码。同时还要制定计划，让内部人员能够理解、修改并接手 FDE 构建的逻辑。

第三，确认对回写和智能体的管控。要明确哪个动作写入哪个源系统，失败或冲突时如何回滚，以及智能体在无需人工批准的情况下可以执行哪些动作。公司声称提供的场景模拟和权限体系（w3），需要由客户用实际业务规则来填充。

常见的错误有三种：试图一次画出全公司模型，再次陷入第 1 篇中提到的“全公司单一模型陷阱”；把第一个用例的成果草率地推广为全公司推广的依据；只按许可费计算引入成本，忽略映射和维护所需的人力。值得记住的是，公司自己也写明部署过程可能复杂且耗时（w6）。

延伸学习，以及第 3 篇预告

若想先把握结构，建议按以下顺序阅读：先在 Palantir 核心概念文档（w2）中看数据集与本体的对应表，再通过本体概述（w1）确认语义与动态的划分，然后通过动作类型文档（w4）中的“员工调配”示例，看动态要素实际定义了什么。公司的设计理念和智能体安全主张整理在“为什么是本体”文档（w3）中，LLM 的接入方式整理在 AIP 概述（w5）中。

商业方面，建议阅读业绩新闻稿（w6）时不仅看数字，也读完后面的风险因素清单。批评视角以 Vonng 的文章（w7）最为系统，韩国背景可通过 LG CNS 合作公告（w8）了解。把公司文档和批评文章放在一起，比较“同一事实被冠以什么名称”，本文的论点就会更加清晰。

第 3 篇将转向金融业等强监管领域。本篇讨论的回写、智能体权限和决策血缘，正是在受监管行业中与模型风险管理、审计和解释责任直接冲突的地方。谁拥有语义结构、谁对自动化决策承担最终责任，将成为比技术选型更优先的问题。