【本体论 03】Palantir 把业务语义变成操作层

如果把 Palantir 理解成“帮企业整合数据，再接入大模型”，很难解释它为什么反复强调 Ontology。

数据整合回答数据在哪里，大模型回答如何理解问题和生成内容。企业真正难处理的是中间部分：

一张表代表哪个业务对象？
多个系统里的记录是不是同一个对象？
当前决策需要哪些上下文？
指标、规则和预测模型从哪里调用？
谁可以执行什么动作？
结果如何写回权威系统？

Palantir Ontology 处理的正是这一层。它不替代数据库，也不替代 ERP、CRM 和广告平台，而是在这些系统之上建立一套可被人、应用和 AI 共同使用的业务操作层。

从数据平台到业务操作层

先把 Palantir 相关产品放回各自位置。

Foundry 负责连接、转换和管理企业数据，并为模型和应用提供基础。Ontology 把这些数据映射为客户、订单、库存、供应商、计划等业务对象。AIP 再把大模型、Agent 和自动化接入这套对象体系。

Palantir 从数据到业务操作层

这套结构的重点不在于层数，而在于职责分工。

LLM 不直接面对几百张表，也不应该直接获得生产系统写权限。它面对的是经过治理的业务对象、函数和动作。底层系统发生变化时，只要对象语义和接口契约保持稳定，上层应用与 Agent 就不需要理解全部数据管道细节。

Palantir 官方文档将 Ontology 称为组织的 operational layer。这个词比“语义层”更准确，因为它既解释业务，也参与业务运行。

Object、Property、Link：先重建业务世界

Ontology 的第一部分是语义骨架。

Object Type 定义业务对象类型，比如客户、订单、广告账户、投放计划、商品和库存。Property 描述对象的属性与状态，比如预算、消耗、审核状态、库存水位和客户等级。Link Type 则定义对象之间的稳定关系。

假设一个广告代理商同时从媒体 API、内部 CRM、商品库和订单系统获得数据。

传统集成视角会处理：

媒体计划表与消耗日报如何关联。
CRM 客户 ID 如何映射广告账户 ID。
商品表怎样连接转化订单。

Ontology 视角则会形成：

客户拥有广告账户。
广告账户包含投放计划。
投放计划使用创意并推广商品。
创意产生点击和转化。
商品拥有库存、价格和毛利状态。

前者描述数据连接，后者描述业务事实。

这种转译有三个价值。

第一，业务人员看到的是熟悉的对象，而不是数据源和字段名。

第二，关系成为可复用资产。任何应用或 Agent 都可以沿着“计划—商品—库存—订单”获得相同上下文，不需要每次重新设计 Join。

第三，底层数据与上层语义解耦。对象可以来自数据库、流数据、模型结果或外部 API，但上层始终围绕同一个“投放计划”工作。

对象建模的难点不在于画出几个框，而在于身份和权威来源。一个商品在多个系统中拥有不同编码时，必须明确怎样合并、哪个字段权威、冲突如何处理。没有这一步，对象只是在表上增加了一层好看的名字。

Function：把业务逻辑从页面和 Prompt 中拿出来

业务对象本身不会产生决策。系统还需要计算预算消耗率、ROI、库存风险、供应商评分或素材疲劳度。

传统产品中，这些逻辑容易散落在 SQL、BI 指标、后端服务、Excel 和页面代码里。接入 Agent 后，团队还可能把公式和判断规则继续堆进 Prompt。

这样做的问题是：

同一个指标可能出现多套实现。
规则修改后，不同应用无法同步。
Agent 很难判断哪个版本权威。
计算过程和结果不容易追溯。

Palantir Functions on objects允许函数读取和处理 Ontology 中的对象与关系。函数可以承载指标、评分、预测、优化或约束逻辑，并继续受到数据安全和血缘约束。

以投放计划为例，可以沉淀：

Function	输入	输出
预算消耗率	计划预算、累计消耗、投放时间	当前消耗进度
ROI	消耗、归因订单、收入口径	投入产出比
素材疲劳度	曝光频次、点击率趋势、素材版本	疲劳评分
库存风险	当前库存、在途、销量预测、安全库存	风险等级

LLM 可以理解用户提出的模糊问题，也可以解释多个函数结果之间的关系，但不适合临时编造指标公式。

LLM 负责理解和编排，Function 负责稳定计算。这种分工把非确定性推理与确定性业务逻辑隔离开。

Action：把 API 转成受控业务动作

分析系统通常停在“发现问题”。

报表显示库存不足，运营需要进入 ERP 建采购单；Agent 发现预算消耗过快，优化师还要登录媒体平台调预算；风控系统发现异常，业务人员需要到工单系统发起处理。

Palantir Ontology 用 Action Type 定义可以对业务对象发起的变更。官方文档将 Action 描述为改变一个或多个对象的事务。它可以修改属性、创建或删除对象、添加或删除链接，也可以触发外部副作用。

一个“调整计划预算”的 Action，不应只是对媒体 API 的简单封装。它还需要定义：

作用于哪个投放计划。
可以修改哪些参数。
新预算必须满足什么范围。
哪些角色可以发起。
超过什么幅度需要审批。
写回哪个广告平台。
失败时如何处理。
如何记录发起人、原因和结果。

这使 Agent 调用的不是 updateBudget 这样的裸接口，而是“在明确条件下调整某个计划预算”的业务动作。

二者的差异在于，API 描述系统接口，Action 描述业务意图、约束和后果。

对企业 Agent 来说，这是一道安全边界。模型可以建议发起动作，也可以在授权范围内调用动作，但它不能绕过规则直接修改底层数据。

Security：权限是本体的一部分

企业系统中的“能看”和“能做”从来不是同一件事。

一个优化师可以查看计划消耗，但未必能看到客户返点；可以调整小额预算，但大幅修改需要负责人审批。Agent 即使能读取库存风险，也不应该自动更换供应商。

因此，权限不能只放在应用登录层。它需要进入对象、属性、函数和动作：

对象级：哪些客户或计划可见。
属性级：成本、利润、个人信息是否可见。
函数级：谁可以运行风险预测或优化模型。
动作级：谁可以调整预算、修改库存或审批合同。
条件级：在什么金额、状态或风险下需要升级审批。

Palantir Agents会绑定 Ontology，并在限定权限下访问资源和工具。AIP也强调 human-in-the-loop，让高风险决策保留人工确认。

权限设计越晚，返工越大。因为它不只是“给角色打勾”，而是决定对象如何切分、字段怎样暴露、函数输出能否查看，以及 Action 是否允许执行。

Write-back 与 Action Log：完成业务闭环

如果 Ontology 只把底层数据映射为对象，它仍然是一个更友好的分析入口。

要成为 operational layer，还需要两项能力：

把动作结果写回真实业务系统。
记录动作发生时的数据、逻辑、人员和结果。

假设 Agent 建议降低某个计划预算：

Ontology 提供计划、商品、库存和转化上下文。
Function 计算 ROI 与库存风险。
Agent 生成原因和建议幅度。
用户审批 Action。
Action 调用媒体接口更新预算。
新状态回流并更新投放计划对象。
后续消耗和转化继续验证这次决策。

Palantir Action Log可以把 Action submission 本身建模为对象，用于分析、展示和监控 Ontology 变更。

这类日志不只是操作审计，还记录了一条决策链：

当时使用了什么数据。
调用了什么函数。
谁提出和批准了动作。
最终执行了什么。
业务结果如何。

当这些信息持续累积，企业得到的不是聊天记录，而是一套可分析的决策历史。

Palantir 的壁垒不在“发明本体论”

对象、属性、关系、规则等思想并不专属于 Palantir。

ER 模型、DDD、知识图谱、语义层和数字孪生都包含相邻概念。企业也可以用现有湖仓、主数据、API 网关、工作流和权限系统组合出类似架构。

Palantir 的差异在于，它把以下能力放进了同一套持续运行的平台：

多源数据映射与血缘。
稳定业务对象和关系。
可复用函数与模型。
对象级和动作级安全。
应用、Agent 和自动化。
Action、写回和决策日志。

因此，更准确的判断是：

更准确的判断是：本体论概念的门槛不高，把它工程化、治理化并接入真实业务闭环的门槛很高。

这既是技术问题，也是组织问题。对象口径由谁负责，数仓和 Ontology 是否重复计算，流程变化后谁维护 Action，多个部门对同一客户定义冲突时谁有裁决权，这些问题不能靠建模工具自动解决。

用六个问题评估企业 AI 平台

不论平台是否使用 Ontology 这个名称，都可以用六个问题检查其真实能力：

是否将多源数据映射为稳定的业务对象？
对象关系是否具有统一语义和权威来源？
指标、规则和模型是否成为可复用函数？
工具调用是否被封装为受控业务动作？
权限是否覆盖对象、属性、函数和动作？
执行结果是否写回并留下完整决策记录？

缺少前三项，Agent 只能在碎片数据上临时拼上下文。缺少第四、第五项，它很难安全进入生产系统。缺少第六项，组织无法判断动作是否有效，也无法形成长期学习。

下一篇会把视角从 Palantir 拉回企业 AI：为什么 RAG、ChatBI、工作流和 API 工具还不够，以及产品经理如何从一个最小本体闭环开始。

参考资料

系列导航

上一篇：【本体论 02】别再把本体论等同知识图谱
下一篇：【本体论 04】企业 Agent 缺的是可控业务世界

【本体论】Palantir 把业务语义变成操作层