原文出处：Ontology，真的是企业 AI 转型的解药吗？ 研究完 Pala... https://xhslink.cn/o/9Xrq646c7ON 把这段话复制下来，打开【小红书】查看。

三个系统都显示库存 100，为什么不能答应客户交 80 件？

一个客户找过来问：我要 80 件商品，明天能不能交？

你分别去三个系统里查：仓储系统显示实物库存 100 件，电商系统显示可售 100 件，采购系统显示在途 100 件。100 加 100 加 100 等于 300，那是不是最多可以交 300 件？

显然不是。

仓库里那 100 件，可能有一部分已经被别人预定了，有一部分还没完成入库或拣货；电商系统里的 100 件，可能分散在不同仓库，未必能凑成一单；采购系统里确实还有 100 件，但它明天可能根本到不了。

所以，数据查得到，不等于知道这些数据在业务里到底是什么意思。这正是 Palantir 的 Ontology 想解决的问题。

Palantir 把一次真实的业务决策拆成四块

在 Palantir 的框架里，一次真实的业务决策被拆成四个部分：

• Data：现在发生了什么；
• Logic：应该怎么判断；
• Action：接下来做什么；
• Security：什么情况下允许做。

还是用库存这个案例，一块一块看。

Data：不是把几张表拼进来，而是把数据翻译成业务世界

Palantir 所说的 Data，不是简单地把数据库里的几张表拼到一起，而是把系统里的数据翻译成业务世界的语言。

它用到几个最基础的建模元素：Object、Property 和 Link。翻成大白话就是：

• Object：这是什么东西；
• Property：这个东西有什么特征，现在是什么状态；
• Link：它和其他东西是什么关系。

比如订单可以是一类 Object，一张具体的订单会有订单状态、金额、创建时间这些 Property。商品也是一类 Object，可以有商品名称、SKU、品类、价格这些 Property。而订单和商品之间还有一个 Link，也就是关系——这张订单包含哪些商品。一个订单可以包含很多商品，一个商品也可能出现在很多订单里。

Palantir 官方把 Object、Property、Link 叫做 Ontology 的 Semantic Elements，也就是用来描述业务世界的语义元素。

说到这里，很多人的第一反应和我一样：这不就是知识图谱吗？如果 Ontology 只做到定义对象、属性和关系，那它确实和知识图谱、语义层甚至领域建模非常像。但 Palantir 往前多走了一步。

Logic：从"知道事实"到"做出判断"

回到库存问题。现在你已经知道：仓库里有 100 件实物库存，其中 20 件已经被占用、10 件被预留冻结，另外还有 100 件在途，但要后天才能到。你已经能看懂业务世界了。

但老板问你的是：我明天能不能交付 80 件？

所以光知道事实还不够，你得能做出业务判断。这时就进入了 Palantir 更核心的一层：它不只是描述世界，还要让企业在这个世界里做决策。这就是 Logic。

比如企业内部有一条规则：明天可承诺的库存，等于实物库存减去预留、减去冻结，再加上明天之前能到的库存。按这个规则算，100 减 20 减 10，加上 0，等于 70。客户要 80 件，所以不能承诺。

在 Palantir 里，这种 Logic 可以通过函数、规则、模型等方式实现。比如你可以写一个计算可承诺数量的函数，输入库存、预留、在途状态和到货时间，输出可以交付的数量。假设客户要的是 60 件，系统判断就可以答应。

Action：回答"可以"还不够，要真的改变业务状态

但如果 AI 只是回答一句"可以"，它本质上还是一个问答系统。企业真正需要的，是把这 60 件库存真的锁住。

在 Palantir 里，这种真正改变业务状态的能力叫 Action。锁库存是一个 Action，退款也是一个 Action。这是 Ontology 和单纯知识图谱一个很重要的区别：Ontology 不只是告诉机器世界现在是什么样子，它还允许机器去真的改变这个世界。

Security：能执行之后，边界本身就是业务逻辑

一旦 AI 真的能锁库存、退款、取消订单，下一个问题马上就来了：

60 件库存可以自动锁，那 6000 件呢？100 元的退款可以自动执行，那 10 万元呢？哪些操作 AI 可以直接做，哪些需要人工确认，哪些又必须主管审批？

这就是 Security。所以 Security 不是最后再补一个权限配置。当 AI 开始真正执行操作以后，谁能做、什么条件下能做、需不需要审批，本身就是业务逻辑的一部分。

Palantir 具体把它做成了什么

前面讲的是 Ontology 的核心思路。那 Palantir 具体把它做成了什么呢？

官方把 Ontology 这套系统分成 language、engine 和 toolchain：language 用来定义业务世界，engine 让这些对象可以被查询及修改，toolchain 让开发者的应用和 agent 能够真正使用这套 Ontology。所以准确地说，Palantir 的 Ontology 不是一张静态的业务模型，而是一套业务模型加可运行状态的组合。

至于大家经常听到的 Foundry、AIP 和 Apollo：Foundry 更偏数据和运营，AIP 是大模型和 agent 的平台，Apollo 负责平台的部署和持续交付。Ontology 不是第四个平台，而是整套架构的核心系统，Palantir 官方直接称它为整套架构的 heart。

对大部分企业来说，理解到这里就够了，不必去追究每个平台内部具体怎么实现——因为我们本来也不会去复制 Palantir 这套技术体系。真正有意思的是下一步：大模型时代，我们可以借鉴什么。

大模型时代，可以借鉴什么

以前企业有很多系统——ERP、CRM、WMS、OA，彼此也很割裂。但为什么以前没觉得特别严重，也没觉得需要 Ontology？

因为中间还有一个特别重要的东西：人。一个干了很多年的供应链负责人，不会因为三个系统里都写着库存 100，就真的去承诺 300 件。他知道哪个数字能信、哪个数字要打折扣。大模型给了 agent 推理能力，但企业还得告诉它：它正在推理的是一个怎样的世界。

Palantir 的 Ontology 诞生于大模型之前，它代表的是一种非常典型的显式建模思维：先把业务实际定义清楚，再让软件和 AI 在这个模型上运行。

但今天不一样了。以 Claude 为代表的新一代 agent harness，已经具备了很强的自然语言理解、推理、工具选择、代码执行和上下文管理能力；同时我们还有 skills、知识库和 MCP。很多过去必须提前结构化、工程化、显式建模的东西，现在可以在运行时交给 agent 去理解和组合。

所以如果今天从零开始做一个企业的 agent，我们该参考的是 Palantir 解决问题的理念，而不是照搬它原来的实现方式。

Data：agent 需要订单状态、客户信息、商品、物流这些数据。简单场景下，不一定要先把它们完整地建成 object、property 和 link，可以直接通过 tool 或 MCP 去 ERP、CRM 等系统里查询，再通过 schema 和 context 告诉模型这些数据是什么意思。

Logic：很多带有判断空间的流程，可以放进 skill 里，或者做成工具。

Action：更加直接。退款、锁库存、取消订单，放在 agent harness 里通常就是 tool，底层可以直接调用 API，也可以通过 MCP 暴露给 agent。

Security：这一点在 agent 时代甚至比以前更重要。100 元的退款可以自动执行，1 万元需要人工确认，10 万元则压根不应该把这个权限交给 agent。而这些不应当写在 prompt 或 skill 里，指望模型自觉遵守；真正的边界应该落在 tool 权限、API 权限、审批和审计上。

不要先建 Ontology，再开始做 Agent

企业研究完 Palantir 之后，不要急着立项说"我们也来建一个企业的 Ontology"。

如果你现在只有一个 agent、一个业务场景，那就用 skill、用 MCP，先把业务跑起来。一开始不要为了 Ontology 提前做很多抽象。

但随着 agent 越来越多，你可能会慢慢发现：客服 agent 和销售 agent 都在用同样的 order，但双方对 order 的定义可能不一样；同一句话在三个 skill 里各写了一遍；不同的 MCP 返回的 customer 结构可能完全不同；十几个 agent 都需要退款、创建订单、锁库存，但每个 agent 都自己封了一套工具。

这个时候，才应该把真正重复的东西抽出来：多个 agent 都在反复使用的 customer、order、product，就逐渐统一这些业务概念；多个 skill 都在反复用到的确定性判断，就把它抽象成公共的代码或工具；多个 agent 都需要同一个业务动作，就把它沉淀成公共的 business action。

也就是说：不要先建设 Ontology，再开始做 agent；而是先做 agent，在 agent 越来越多、业务越来越复杂之后，让真正需要稳定和复用的东西逐渐沉淀下来。

对比这两种范式：Palantir 更像是先建 Ontology 再做应用；而在 agent 时代，更多的是先做 agent，再让 Ontology 随着复杂度慢慢长出来。

我觉得这才是今天重新研究 Palantir Ontology 最有价值的地方。我们不是要回到过去，把所有的业务重新建模一遍，而是借它重新检查一个问题：当 agent 真正开始进入企业运营以后，企业 AI 不能只是在一个大模型上加一堆工具。我们仍然需要给 agent 足够清晰的业务世界、判断与行动能力，以及安全边界。