Palantir没有独立本体平台，中国厂商为什么要单独做一个？

Palantir高度重视Ontology，却没有一条独立的本体平台产品线。在Palantir的标准架构中，AIP、Foundry和Apollo三条产品线共同构成企业操作系统，Ontology并非独立产品。

中国市场呈现出另一番景象。过去一年，越来越多厂商开始建设独立本体平台，围绕平台划分产品模块、参与评测、进入产品分类和项目方案，再以平台为载体承接实施。

同一种核心能力，为什么在Palantir那里藏在系统里，到了中国却要被摆到产品、合同和目录中？

一种常见解释是技术路线不同：Palantir采用全栈一体化架构，中国企业已经拥有大量数据平台和业务系统，只能增加一个独立本体层。这种解释有一定道理，却没有触及决定产品形态的更直接因素。

真正的差异在于，双方以什么作为一笔交易的基本单位。

Palantir的交易对象是覆盖数据、决策和行动的完整解决方案，而国内政企和大型企业软件项目则更多按照“软件产品＋实施服务”成交。前者可以把本体作为系统内核整体售卖，后者需要一个能够报价和验收的软件产品。

爱分析认为，本体是否需要成为独立平台，首先取决于企业购买什么、厂商以什么完成交易。

图1：两种交易结构塑造两种本体产品形态

一、Palantir不需要单独卖本体平台，因为完整系统已经是产品

Palantir没有将本体平台独立，并不是不重视本体，恰恰相反，Palantir将Ontology称为其架构的核心。

Palantir的本体既描述企业中的对象、关系和规则，也承载实时状态、权限、行动和反馈，使数据能够进入具体工作流。

但在Palantir的产品架构中，Ontology并没有被列为与AIP、Foundry、Apollo并列的独立平台。Foundry承担数据运营、逻辑开发、本体建设、分析和工作流开发，AIP进一步把模型、Agent和自动化连接到企业运行流程，Apollo负责底层软件交付，而Ontology贯穿其中。

这背后的关键是，客户购买的是完整解决方案，而非只购买单一某款产品。

客户购买Palantir，购买的是一套能够进入生产环境的完整系统：分散的数据能否被连接起来，业务人员能否更快做出判断，AI能否在权限范围内调用工具和执行动作，最终能否改善一项运营结果。只要这些能力在同一套系统中形成闭环，客户就没有必要分别采购本体平台、Agent平台等诸多产品。

高价值合同和深度交付，使这种模式能够成立。Palantir可以围绕一个复杂业务问题组织多层产品能力，也可以让FDE团队深入客户现场，把数据、模型、流程和应用组合成整体方案。本体的重要性最终体现在整套解决方案的效果中，不需要单独报价和验收。

换言之，Palantir客户购买的是完整解决方案带来的业务结果，而不是逐项购买底层能力。Ontology越接近Foundry和AIP共同依赖的系统内核，单独拆出一套SKU的必要性反而越低。强行切开不仅不能增加客户价值，还可能增加产品边界、系统对接和责任划分成本。

因此，Palantir没有独立本体平台产品线，并不能说明本体平台没有价值，反而真正说明了：本体能力已经深入贯穿到完整产品，不能以独立的形式出现。能力是否核心，与它是否需要单独售卖，是两个问题。

二、国内厂商需要独立平台，因为项目必须有软件产品载体

国内企业软件的市场环境和商业模式相差较大，交易结构也完全不一样。

爱分析在调研中发现，在政企和大型企业的复杂软件项目中，较为常见的合同结构仍然是“软件产品＋实施服务”：厂商先提供一套边界相对明确的软件产品，再投入交付实施人员，根据客户的数据、组织和流程完成配置、集成与开发。

实施解决的是客户差异，产品承担的是交易载体。

一个项目要进入预算，需要说明采购什么；要形成报价，需要区分软件和服务；要完成交付，需要部署一套可运行的产品；要进行验收，需要对应功能模块、技术指标和交付边界。仅仅告诉客户“我们具备本体能力”，很难支撑这套采购制度。

如果本体能力分散在数据治理、知识工程、AI平台和场景应用中，它在技术上仍然可以发挥作用，但在合同中很难被识别为一项独立软件资产。客户可能把它理解为项目定制开发，按低价的实施人天进行预算立项。

这时，把本体做成独立平台就不是一次技术分层，而是一次产品化。

平台可以形成对象建模、关系管理、规则配置、权限控制、行动编排、版本治理等模块，也可以定义部署方式、授权方式、产品版本和验收指标。平台回答交付的标准软件是什么，实施则回答如何让这套软件适配具体客户。

这种边界对本体尤其重要。不同企业对业务对象的定义并不相同，业务规则、权限和可执行动作也很难全部预制。本体项目一定是重实施的项目，但如果所有价值都被放进现场实施，厂商就难以证明自己交付的是一套可复用的软件产品，而不只是专家人天。

因此，中国市场的独立本体平台同时承担两个角色。

图2：独立本体平台具有交付与交易双重价值

对内，是交付团队的生产系统。项目中的对象模型、连接器、规则、权限和行动能力可以被沉淀下来，成为下一次交付的起点。没有平台，每个项目都可能重新集成、重新建模、重新开发，收入增长只能依赖增加实施人员。

对外，是合同中的产品对象。厂商可以围绕平台形成报价、授权、部署和验收，再把无法标准化的部分放进实施服务。

这也解释了一个看似矛盾的现象：不少厂商内部强调平台建设、标准和评测，面对客户时却更愿意讲场景和业务结果。

厂商必须有平台，因为需要沉淀产品和提高交付效率；客户不一定关心平台，因为客户只会为自己的业务问题买单。

爱分析认为，中国厂商建设独立本体平台，并不是简单地比Palantir多造一层技术，而是在项目制中，把原本可以隐藏在完整解决方案内部的能力，转化为可交易的软件产品。

三、评测和产品目录进一步固化了平台品类

当本体被做成明确产品后，围绕它的市场机制也会逐渐形成。

产品需要边界，于是厂商会定义产品架构、功能模块和技术指标；采购方需要识别不同供给，于是会出现测试评价、标准规范和产品分类；产业需要组织市场，于是本体平台开始进入解决方案目录和厂商版图。

这些机制又会反过来强化独立平台。

图3：项目制与市场机制共同强化本体平台品类

对于一种处于市场早期的新能力，评测和目录能够降低供需双方的识别成本。厂商可以证明自己提供的是一套相对完整的软件产品，采购方也获得了用于初步比较产品能力、设置技术要求和组织验收的共同语言。

由此形成一个自我加强的循环：项目制需要产品载体，厂商把本体能力封装为平台，平台成为评测、标准和目录的对象，评测和目录进一步提升平台品类的可识别性。

四、厂商必须产品化，不等于客户必须单独买平台

讨论到这里，还需要拆开两个容易被混为一谈的问题。

第一个问题是：厂商是否必须把本体能力产品化？

对于缺少成熟产品载体、主要依靠项目交付的厂商，答案通常是需要。没有平台，分散能力很难形成软件和服务的合同边界，项目经验也难以持续沉淀。独立本体平台既是软件产品，也是交付生产工具。

第二个问题是：客户是否需要单独采购和部署一层本体平台？

答案并不是必须。

如果一家企业只在单一应用中使用少量对象和规则，本体也可以成为应用内部能力，没有必要先建设企业级平台。

只有当同一套本体需要被多个应用或Agent复用，需要由独立团队持续治理，并且会随着业务变化长期演进时，客户单独建设本体平台才具有更强理由。

图4：厂商需要产品化，客户未必独立采购本体平台

这意味着，“厂商必须有产品”不能直接推出“客户必须买独立平台”。前者回答厂商如何研发、交付和完成交易，后者回答客户的技术架构和业务资产是否需要独立承载。

把两者混在一起，很容易产生两种误判。一种是因为本体能力重要，就默认每家企业都应该先采购一套独立平台；另一种是因为Palantir没有独立本体平台产品线，就否定国内厂商建设平台的必要性。

前者忽视客户需求边界，后者忽视中国项目制的采购现实。

爱分析认为，更准确的判断是：独立本体平台不是所有企业都必须部署的技术层，却是国内厂商把本体能力变成软件产品、提高交付杠杆并进入采购体系的现实选择。

结语：一个放在系统里，一个放进合同里

Palantir把本体放在全栈系统里，中国厂商把本体放进产品、合同和目录里。

这不是谁更重视本体，也不是谁的技术路线更加先进，而是两种采购制度和交易结构对产品边界作出了不同选择。

当完整解决方案和业务结果是一笔交易的基本单位，本体只需要成为强大的系统内核；当项目主要按照“软件产品＋实施服务”成交，本体能力就需要一个清晰的产品载体，承担报价、交付和验收。

因此，中国独立本体平台不是对Palantir产品架构的简单复制，而是国内企业软件项目制长出的适应性产品形态。