Ossie ，会不会成为“开源 Palantir”的起点？

2026 年年初，我写了《从 SQL 到 OSI》的两篇文章，最近重新看已经进入 Apache 的 Ossie（前身就是 OSI ），我发现这个问题又往前走了一步，它正在定义的东西不再只有指标、维度和数据关系，而是开始出现 Customer、Order、Product 这样的业务概念，以及这些概念之间的关系和业务规则。

如果说以前讨论的是“数据是什么意思”，现在已经开始碰到另一个更大的问题：

企业的世界里到底有什么？

这让我想到 Palantir，如果 Ossie 沿着这条路继续发展，未来 3～5 年，会不会出现一个开源版的 Palantir？

我的判断是：大概率可能会出现 Apache Ossie 加上一系列开源项目，共同组成一套 Open Palantir Stack，也就是开放式的 Palantir 技术栈。

这件事情如果发生，也会重新影响我们今天怎么看语义层和本体论之间的关系。

一、Ossie 正在发生什么变化？

OSI 最初要解决的问题很明确：同一个指标、维度和业务口径，在不同的数据平台、BI 工具和 Agent 之间，应该有一种共同的表达，不需要每套系统重新定义一遍。

这和 SQL 当年解决的问题很像。SQL 统一的是“怎么取数”，OSI 希望统一的是“数据是什么意思”。我在上一篇文章里已经展开过，这里不再重复。

真正值得关注的是进入 Apache 之后 Ossie 的变化。

它今天的官方定位仍然是一个厂商中立的语义模型交换标准，但它正在往上多走一层，它当前的本体规范已经开始定义业务概念、关系、业务规则，以及一个或多个逻辑数据模型如何映射到这些业务概念。

简单看，目前已经有几条比较明确的证据：

1. 本体已经进入规范。 最新开发版已经加入业务概念、关系、业务规则，以及从逻辑模型到本体的映射。

1. 本体已经进入正式路线图。 Ossie 明确提出，希望在物理和逻辑数据模型之上，建立独立于数据存储位置的 Customer、Order、Product 等业务概念，并解决不同模型之间的“概念互操作”。路线图里甚至直接把 Palantir 和 Goldman Sachs Legend 作为这类本体模型的例子。

1. 本体层和传统语义层已经开始被明确区分。 当前表达式语言方案把 Ossie 分成“本体层”和“逻辑层”，后者更接近传统 BI 语义模型，前者则更接近 OWL、RelationalAI、Legend 一类的本体模型。

所以这不是简单地“多支持几种指标”。

“GMV”是一个分析概念，“Customer”却是一个业务概念。前者回答企业如何衡量经营，后者描述的是企业如何认识自己的业务世界。

当一个开放标准开始尝试定义客户、订单、商品，以及它们之间的关系时，它潜在的边界就从“语义交换”继续向“企业世界模型”扩张了。

这和我之前对语义层的理解是一脉相承的。语义层并不只是指标管理，它本来就在通过实体、关系、指标和业务口径，让系统形成对企业经营世界的统一认识。随着 Agent 进入更多业务场景，必然会带动语义层从“怎么衡量客户”到走向“什么是客户”，因此，从指标语义逐渐扩展到更加完整的对象语义，并不奇怪。

这时候再看企业经常问我们的一个问题——“今天到底应该做语义层，还是直接做本体论？”——这个问题本身可能就没有想象中那么非此即彼。

先把数据、指标、实体和关系定义清楚，再随着业务使用逐步增加客户、商品、订单、设备等更加完整的业务对象，本身就是一条可以持续向本体论扩展的路径。

二、Palantir 真正难的地方在哪里？

说到这里，很容易产生另外一个误解：既然 Ossie 也开始定义本体，是不是离 Palantir 已经不远了？

还差得很远。

这几年国内讲 Palantir，最容易被记住的是对象、关系、属性、操作这些概念。但如果 Palantir 只是定义几个对象和关系，它不会成为今天的 Palantir。

Palantir 真正做的是一整套系统。它不仅要定义企业有哪些客户、商品和订单，还要把这些定义和企业真实的数据系统连接起来，让这些对象可以查询、计算、更新，让状态和权限持续保持一致，并在上面完成业务操作、工作流、应用开发和 Agent 协作。

Palantir 自己把这套本体系统划分为建模语言、运行引擎和工具链。模型只是第一步，更重的是后面的运行。

定义一个 Customer 不难。一家大型企业的 CRM、ERP、电商、会员、门店系统里可能都有 Customer，如何持续把它们映射成同一个业务对象，保持数据更新及时、对象关系正确、权限一致，业务变化以后还能继续维护，这才难。

定义一个“取消订单”的操作也不难。真正执行的时候，谁有权限、需要修改哪些数据、会触发哪些流程、中间失败怎么办、能不能回滚、整个过程如何审计，这些才是一个企业系统真正需要面对的问题。

所以 Palantir 真正难复制的，从来不是几个本体概念。

难的是把企业的业务世界真正运行起来。

这也是为什么我之前一直强调，本体论和语义层都不能只看模型本身。从概念到产品、从产品到企业级系统，中间还有建模、运行和持续演进的成本，而越接近真实业务操作，灰度空间越小，系统要求越高。

Ossie 今天开始拥有描述这套世界的公共语言，并不意味着它已经成为 Palantir。

但公共语言一旦形成，另一个问题就出现了：Palantir 今天做在一个平台里的这些能力，未来是不是还必须全部做在一家公司里？

三、这套体系一定要做在一家公司里吗？

回到上一篇文章里的“定义和执行”，这个变化其实会看得更清楚。

在 OSI 最初的语境下，“定义”主要是指标、维度和数据关系，“执行”主要是把这些定义变成查询和数据服务。

现在两边都在扩大。

定义这一边，开始从指标、维度扩展到业务对象、对象关系和业务规则；执行这一边，也不再只是生成 SQL，而会继续涉及对象查询、图关系、状态、操作、工作流，以及 Agent 如何使用这些能力。

所谓 Open Palantir Stack，本质上就是原来被封装在一个大平台里的“定义”和“执行”，都有可能被逐层拆出来。

这件事以前很难发生。

过去不同系统之间要协作，通常需要工程师提前开发好流程。数据、语义、业务操作和工作流绑定得越紧，系统反而越确定，所以 Palantir 选择高度一体化的方式有它非常合理的历史背景。

今天几个条件同时变了。

语义正在标准化；数仓、数据湖、数据目录、工作流、权限等企业基础设施已经大量解耦；更重要的是，Agent 出现以后，系统之间的组合方式也发生了变化。

业务系统可以通过 API、CLI、MCP 等方式开放自己的操作能力，具体场景的工作经验可以沉淀成 Skill，Agent 再根据当前任务决定调用什么工具、按照什么顺序完成工作。

原来必须由工程师提前固化在一个大平台里的部分能力，开始有机会在运行时重新组合。

从 Ossie 当前公开的方向，也已经能看到几条从“定义”向“运行”延伸的迹象：

1. 语义服务。 路线图已经提出独立的语义注册和服务能力，用于模型发现、版本管理和访问控制。

1. 查询和参考引擎。 后续规划已经包括统一的语义查询语言、从语义查询生成执行计划，以及 Ossie 到 SQL 的参考编译器。

1. 面向 Agent 的语义服务。 路线图专门规划了 AI 相关能力，包括标准上下文、经过验证的查询，以及控制哪些语义可以暴露给 AI。社区讨论中也明确提到，希望由参考查询引擎稳定执行语义，而不是让 Agent 每次临时生成一套 SQL。

如果继续沿着这条路推演，未来企业原有的数仓、数据湖、ERP、CRM 和业务系统仍然各自运行；Ossie 提供一种开放的语义和本体表达；不同的运行引擎负责查询、计算、关系和推理；数据目录与治理系统管理这些模型；各种业务系统继续提供操作能力，最后由 Agent 把它们组合起来。

Palantir 把这一整套能力做在了一家公司里，开源世界则可能把它们做在一个生态里。

四、拆到哪里为止？

不过，这套体系也不可能无限拆下去。

我觉得这里存在一条比较清楚的边界：

描述一个企业，比改变一个企业更容易标准化。

什么是客户，什么是订单，客户和订单是什么关系，什么是销售额，库存怎么统计，这些内容虽然每家企业的具体定义不同，但本质都是在描述业务世界，因此适合被定义、交换和治理。

取消订单、修改价格、审批折扣、调整库存、创建采购单则完全不一样。

这些不是在描述世界，而是在改变世界。真正执行的时候，会涉及事务、权限、审批、回滚、审计，以及错误操作可能造成的真实业务损失。

所以我之前把企业语义分成数据语义、指标语义、对象语义和行动语义四层时，第三层和第四层之间其实存在一道比想象中更深的边界。

Palantir 的路线，是把这两边都放进统一的本体系统里。系统既知道“订单是什么”，也知道“订单能做什么”，并通过自己的运行体系真正执行这些操作。

Ossie 今天则明显还在前一侧。

从当前公开规范来看，这一点也比较清楚：

1. 已经正式进入的，是业务概念、关系、业务规则和数据映射。

1. 正在规划的，主要是本体互操作、查询、语义服务、治理和面向 Agent 的上下文能力。

1. 目前还没有看到一套类似 Palantir 的完整业务操作、事务和工作流规范。

未来是不是一定要把“怎么行动”也继续塞进本体标准，我觉得现在没有必要提前下结论。

另一种同样可能的路线是，语义层和本体告诉 Agent 企业世界里有什么、它们是什么关系；ERP、CRM 等业务系统通过开放接口告诉 Agent 自己能做什么；Skill 提供具体业务场景里的工作方法；最后由 Agent 根据任务完成组合。

我在之前《就着 Agent，再谈语义层》里就留下过这个问题：当企业业务系统越来越多地提供 API、CLI、MCP，操作本身是否仍然必须封装在一个类似 Palantir 的统一体系里，Agent 时代可能会给出和过去不同的答案。

所以我现在更愿意把未来的边界理解成：

企业如何描述自己的世界，会越来越开放；企业如何真正改变这个世界，则还会长期竞争。

这也是为什么 Ossie 即使一直不定义完整的 Action，也不妨碍它成为开放本体技术栈里最重要的标准之一。

五、Ossie 最后会走到哪里？

走到这里，再回到文章开始的问题：Ossie 最终会不会成为“开源 Palantir”的起点？它能不能成为一套开放企业本体技术栈的公共语言。

这件事情最终取决于谁在参与这个项目。

如果未来主要还是 BI 和语义层厂商推动，它大概率会成为越来越完善的数据语义标准；如果本体、知识图谱、数据目录和治理方向的厂商不断进入，它会继续向企业世界模型扩展；如果运行引擎、Agent、工作流等方向也开始围绕它形成稳定的开源项目，那么一套 Open Palantir Stack 才可能逐渐成形。

而这件事情对企业今天的选择，也有一个很现实的意义。

过去客户讨论语义层和本体论，经常会有一个顾虑：如果未来 Agent 的企业基础设施最终会走向本体，那今天先做语义层，会不会是一笔以后需要推倒重来的投资？

从 Ossie 今天的演进来看，我反而越来越不担心这个问题。

企业软件很少是按照想象中的终局，一次把所有能力建设完整。更现实的路径，始终是从确定性更高、价值更容易验证的问题开始，再沿着真实业务使用逐步扩张。

数据语义和指标语义今天已经有很明确的业务需求。指标口径是不是统一，一个经营问题能不能更快得到答案，Data Agent 能不能稳定、可信地完成分析，这些价值都能比较快地验证。

企业在这个过程中已经建立了大量指标、实体、关系和业务规则，再进一步把客户、商品、订单、门店、供应商等对象补齐，本身就在向更加完整的企业本体发展。

等到 Agent 真正进入调价、补货、营销触达、流程审批等业务执行场景，再根据真实需要继续增加操作和治理能力。

每一步都有真实需求，每一步都有人使用，每一步都可以通过使用结果反过来校验模型。

相比一开始就试图把整个企业完整地数字孪生出来，这条路建设范围更可控，价值链路更短，也给企业留下了更大的演进空间。

所以今天我会比以前更明确地说：

如果企业未来确实需要走向本体论，语义层很可能不是一个迟早要被替换掉的过渡方案，而是一条更现实的建设起点。

从数据和指标开始，再进入对象和关系，最后走到更多业务操作，这个过程不是从一套系统切换到另一套系统，更像是企业对自己业务世界的认识不断加深。

Palantir 选择了一条从上往下、高度一体化建设企业数字世界的道路；开源生态可能正在提供另一条从下往上、逐层标准化、逐步升级的道路。

也许未来不会出现一家“开源版 Palantir”，但我们很可能会看到一套开放式的 Palantir 技术栈：Ossie 负责建立描述企业世界的公共语言，不同的运行引擎把这些定义真正跑起来，业务系统继续提供真实的操作能力，Agent 再把这些能力组织起来完成工作。

Palantir 把这些能力做在了一家公司里，开源世界则可能把它们做在一个生态里。