Palantir 把 Ontology 炒火了，但国内别把它当成知识图谱V2.0

最近在企业 AI 项目里，"本体（Ontology）"又成了高频词。有人把它等同于知识图谱，有人把它当成数据中台的新包装，也有人认为只要画一张实体关系图，Agent 就有了"世界模型"。

这些理解都只碰到了表面。

企业真正缺的，往往不是又一份数据目录，而是一层能把业务对象、实时状态、权限规则和可执行动作连在一起的工程模型。Palantir 的价值就在这里：它把 Ontology 放在数据资产之上，作为组织的运营层——上面是业务应用和 Agent，下面是已经接入并治理的数据。

这个定位让一个原本偏语义建模的概念，重新进入了企业软件讨论的中心。

但从 Palantir 的产品叙事，直接跳到"国内也做一个 Palantir"，中间隔着数据底座、系统集成、权限治理和交付方式等一整套工程问题。

这篇先回答三个问题：

1. Palantir 的 Ontology 到底解决什么问题？
2. 它和传统知识图谱差在哪里？
3. 国内团队应该借什么、又不该抄什么？

二、为什么要先了解 Palantir？

Palantir 成立于 2003 年，早期服务于政府、国防和情报等场景。它要处理的不是一张干净的业务表，而是来源分散、格式各异、权限分级的数据，并让分析人员在其中识别人、组织、事件和风险之间的关联。

这段经历解释了它后来为什么格外强调三个词：数据整合、权限治理和行动闭环。

对 Palantir 而言，能把关系画出来还不够，系统还要回答"谁可以基于这些事实采取什么行动"。

关于 2011 年本拉登行动使用 Palantir 的说法，长期在媒体和行业叙事中流传；Palantir 并未正式确认具体参与情况。把它当作公司公众形象的一部分可以，但不应把它当成判断产品能力的技术证据。

今天理解 Palantir，抓住三个产品就够了：

• Gotham
  面向政府、国防和情报场景的分析与任务平台。
• Foundry
  面向企业的数据集成、分析与业务应用平台，Ontology 是其中的业务运营层。
• AIP
  将大模型接入企业数据、权限和 Ontology 的 AI 平台。

其中和企业 AI 关系最紧密的，是 Foundry + AIP。Ontology 不是孤立功能，它要承接的是一条完整链路：

接入异构数据 → 按业务语义组织对象 → 在权限边界内查询和分析 → 通过受控动作影响业务系统。

这条链路里，最关键的一步是：Palantir 没有把 Ontology 当成静态 schema，而是把它当成可执行的业务语义层。这也解释了为什么 Palantir 强调它是组织的数字孪生：它试图映射的不是静态主数据，而是企业运行中的对象、关系、状态和操作入口。

三、Palantir 的 Ontology，不只是传统知识图谱

Palantir 官方对 Ontology 的定义很简洁：

"The Ontology is the digital twin of an organization."

（本体是组织的数字孪生。）

它不是要取代传统本体或知识图谱，而是在它们擅长的语义建模之上，补齐面向业务运行的工程能力。

从公开文档看，Palantir 的 Ontology 包含对象类型、属性、链接、动作、函数和接口等构建块。可以把它们理解为：

• 对象、属性、链接
  描述业务里有什么，以及彼此怎么关联。例如供应商、采购订单、物料和库存。
• 函数
  把可复用的计算封装在业务对象附近，例如计算某订单的延迟风险。
• 动作（Action）
  把对业务系统的写操作封装为受控入口，例如创建工单、发起审批或变更订单状态。
• 权限与审计
  决定谁能看到哪些对象、谁能执行哪些动作，并保留执行依据和结果。

其中最值得借鉴的是 Action。

Agent 读到"供应商延迟"后，不能仅凭模型生成一段建议就直接改订单；它应该调用一个定义清楚的动作，并接受参数校验、权限校验、审批、幂等控制和审计记录。

这才是从"知道世界"走向"参与运营"的分水岭。

四、为什么 Palantir 让"本体"又火了？

两个原因。

1. 大模型需要被"接地"的企业上下文

企业里的答案不能只"像是真的"。当问题涉及库存、价格、合规、合同或客户权限时，模型需要从有来源、有权限边界的数据中取数，并把结果落回具体业务对象。

RAG 仍然适合解释制度、说明书和经验文档，但它不应该单独承担实时业务查询和写操作。Palantir 的路线是把模型放进一个受治理的对象层和工具层：模型负责理解意图、编排步骤；确定性的查询、规则和动作负责给出事实并改变状态。

这个分工比给 RAG 换一个名字更重要。

2. 它把语义模型接进了应用运行时

许多知识图谱项目停在建模、查询或可视化阶段。Palantir 把对象模型继续接到数据管道、应用权限、工作流和 Action 上，才让语义层进入日常运营。

这是其产品化价值，也是国内团队最容易在 PPT 上学到、在工程里却最难补齐的部分。

五、别把它和知识图谱做成非此即彼

传统本体、知识图谱和 Palantir Ontology 不是互斥关系。前者可以提供概念体系、实体关系、推理和检索能力；后者强调的是把这些语义映射到企业数据和业务操作上。

真正的差异不在于是否使用图数据库、三元组或 OWL，而在于下面四件事是否同时成立：

1. 对象有事实来源
   每个订单、设备或客户对象，都能追溯到系统记录，而不是停在离线图谱里。
2. 状态能及时更新
   模型看到的是当前可用库存和当前订单状态，而不是上周同步的快照。
3. 操作有治理边界
   每个写操作都有权限、审批、参数校验、幂等和回滚策略。
4. 应用围绕语义层构建
   BI、流程应用和 Agent 使用相同的业务对象与规则，避免各做各的口径。

所以更准确的说法是：知识图谱可以是语义层的实现方式之一；Palantir 展示的是如何把语义层做成企业运行时的一部分。

六、国内企业为什么不能直接照搬？

在讨论"为什么不能抄"之前，先看看国内 team 现在的几种尝试。

一类是把它做成语义层/指标平台，解决数据分析口径不一致的问题；一类是在已有知识图谱基础上升级，试图让图谱从"可查询"走向"可执行"；还有一类是在Agent 中台里封装 Action，让大模型能调用业务 API。这三条路都没错，但共同问题是容易把"语义建模"当成终点，而忽略后面的数据连接、权限治理和动作执行。

问题不在于国内有没有 ERP、数据湖或大模型，而在于 Palantir 的能力是一个长期积累的平台组合。直接复刻产品外形，通常会漏掉最难的四层。

1. 先有系统事实，才有语义对象

国内企业常见的现实是：主数据没有统一编码，订单状态散落在 ERP、MES、WMS 和 Excel 中，同一个"客户"在多个系统的身份也无法稳定关联。此时先画 Ontology，只会把混乱原样映射到新模型里。

应该先明确每个核心对象的系统事实来源、主键、更新频率和数据质量责任人，再谈对象关系和 Agent。

2. 写操作的风险远大于问答

读取库存报表出错，最多造成一次错误判断；自动变更订单、创建采购单或切换供应商出错，可能造成实际损失。国内落地不能只把 API 包成 Tool 就交给 Agent，而要按风险分级：

• 低风险动作可以自动执行，例如生成提醒、创建草稿。
• 中风险动作必须人工确认，例如发送催货邮件、创建维修工单。
• 高风险动作必须进入既有审批流，例如改价、改交期、切换供应商。

这套规则不是产品展示里的附属功能，而是可执行 Ontology 的前提。

3. 平台能力不能替代集成能力

不论是国产化环境、私有部署、行业监管，还是自研系统的接口质量，都会决定方案形态。更实际的目标不是买一套"企业操作系统"，而是用可替换的连接器、对象 API、规则引擎和工作流接口，把已有系统逐步接到同一语义契约上。

4. 语义资产必须属于企业自己

对象定义、字段映射、规则口径、动作契约和权限模型，都是企业长期资产。它们应当可版本化、可评审、可测试，并尽量保留清晰的导出和迁移路径。否则，平台越成功，迁移和治理成本越高。

所以结论不是"不用 Palantir"，而是：学它把业务语义、数据和动作统一起来的思路，不照搬其产品边界和交付路径。

七、国内更现实的路线是什么？

如果 Palantir 的路线不能直接抄，国内企业应该怎么做？

建议走一条更容易验证的渐进路线：领域对象 → 受治理的数据连接 → 受控动作 → Agent 编排。

第一步：不要一上来就建"大一统本体"

先选一个业务闭环，例如"供应商交付异常"或"设备故障处理"。对象不宜超过十几个，先把对象、关系、关键状态和责任角色定义清楚。目标不是画一张大图，而是让一个明确问题能被稳定地查询和处理。

第二步：从业务语义采集开始，而不是先做 schema

业务专家不需要写 OWL，但他们必须确认语义契约。用访谈或工作坊把自然语言整理为一组可评审的问题：业务对象是什么？对象怎样关联？什么状态可被视为异常？谁能看、谁能改？动作的前置条件、输入和失败处理是什么？

这不是字段清单。它应该沉淀为可版本化的对象定义、规则定义和动作契约，成为数据工程、业务系统和 Agent 共用的语义资产。

第三步：补上下文、补数据、补事件

本体只是骨架。要让 Agent 真正活起来，还需要：

• 数据连接与质量控制
  明确每个对象的数据源、同步方式、主键和刷新延迟。
• 当前状态
  让 Agent 查询可追溯的实时事实，而不是把历史摘要当成现状。
• 事件与上下文
  记录异常发生、人工处理、审批决策和执行结果，供后续判断使用。
• 观测与评估
  持续检查查询是否正确、动作是否成功、人工是否频繁纠正 Agent。

第四步：让 Agent 能执行动作

最后才让 Agent 参与执行。Agent 负责识别意图、选择工具和汇总证据；业务动作仍由企业 API、工作流和审批系统执行。每个 Action 至少需要具备输入校验、权限检查、幂等键、执行回执和审计日志。

换句话说，Action 不是一个函数名，而是一份带治理约束的业务契约。

八、我们在做什么？

我们团队正在做的，是把企业业务语义沉淀为 Agent 可执行、可治理的认知与行动契约。

我们没有选择复刻 Palantir 平台，而是做了几件事：

1. 从业务问题采集语义
   让业务专家能够确认对象、规则和动作边界。
2. 把语义设计成可版本化资产
   下游可以生成对象、关系、规则、权限和查询模板。
3. 接入真实数据源
   为对象保留可追溯的事实来源和更新机制。
4. 记录决策上下文
   沉淀异常处理、审批例外和人工修正。
5. 让 Agent 在受控边界内执行动作
   而不是只会检索和问答。

这个路线不是 Palantir 的复制品，而是借鉴其"把本体放进运营闭环"的思路，按国内企业已有系统和治理约束逐步落地。

一个简化的落地场景

以一个常见的业务场景为例：供应商延迟交付。

没有本体时，流程通常是这样：采购员发现供应商延迟，需要登录 ERP 查订单、登录邮件看沟通记录、在 Excel 里算影响范围、再手动发邮件催货。整个过程中，数据分散、判断依赖个人经验、动作无法沉淀。换个采购员，处理方式可能完全不同。

有本体之后，流程会变成这样：

1. 语义层
   定义"供应商""采购订单""物料""库存"等对象，以及它们之间的关系。
2. 数据编织层
   从 ERP、邮件系统、WMS 接入实时数据，形成统一视图。
3. 上下文图谱层
   记录历史延迟案例、专家处理先例、审批例外。
4. Agent 执行层
   系统检测到供应商延迟后，Agent 汇总影响范围和候选方案；在人工确认后，才通过受控 Action 发起催货或供应商切换流程。

这个场景里不需要 Palantir 平台，但需要同样的工程纪律：用统一业务语义连接数据事实和受控动作，让系统能辅助运营，而非只生成一段解释。

九、结语

Palantir 让更多企业看到：Ontology 的价值不只在于描述概念和关系，还在于把业务对象、数据事实和受控动作放到同一运行闭环里。

但国内企业不能简单照搬 Palantir 平台。更现实的做法是：

从一个高价值业务闭环开始，用统一语义连接数据和动作；先做可验证的人工协同，再逐步扩大 Agent 的自主范围。

本体不是终点，Agent 也不是终点。真正困难的是，让业务语义、运行状态、决策上下文和治理规则在变化中持续一致。