开放与封闭企业本体：谁拥有业务语义层

先给结论：被你的应用、agent、审计、甚至多家厂商共同依赖的业务定义层，不该归任何一家平台。它应该是一份企业自己持有、模型和运行时都能读取的中立定义层。

先讲一家公司怎么因为这件事丢了一个客户。细节做了脱敏，但每一步你大概都见过。

远峰是一家工业设备制造商，年营收几十亿，几千家客户。2024 年，它把数据底座押给了微软，在 Fabric 里建了一套干净的本体：“客户”是什么、一个客户连着哪些”设备”、“设备”挂着哪些”工单”，定义得清清楚楚。那一年它是供应商大会上被反复点名的模范案例。

2026 年，三件事几乎同时砸到远峰头上：

• 数据科学团队想用 Gemini 跑一批续约预测，因为在那个具体场景里它确实更准；
• 合规部门接到通知，欧盟客户的数据必须留在欧盟，不能再进美国云；
• 一桩收购完成，带来了一整套跑在 Salesforce 上、几千家客户的销售组织。

于是远峰有了三个”客户”：Fabric 里一个，Salesforce 里一个，合规隔离的欧盟环境里还有一个。

故事的转折发生在一个叫”H 集团”的关键大客户身上。某天，销售总监问 agent：“H 集团明年的续约风险有多高？“agent 答：“低。“——它接的是 Fabric 本体，那里 H 集团近期订单健康，数字漂亮。

但 agent 没看到的是：Salesforce 那份记录（并购带来的）里，H 集团半年内两次把投诉升级到了高管层；欧盟隔离环境里，还挂着一笔拖了 90 天的回款争议。三份数据分属三个互不相认的”客户”，没有任何一层东西知道，它们其实是同一个 H 集团。

一个季度后，H 集团流失，年损失数百万。复盘结论刺眼得让人沉默：agent 技术上没有出错——它看到的那一份数据，确实显示低风险。错的不是模型，是它脚下那层”客户”的定义，被切成了三块。

这不只是远峰的失误。它暴露的是一个结构性结果：当”业务的定义”分别交给不同平台保管时，每个平台通常只保管自己那一份。

不是个例：行业都在补这一层

远峰的处境之所以普遍，是因为整个行业正在补同一层东西：机器可读、受治理的业务语义层。

过去，“业务语义层 / Ontology”常被看作少数平台的专门能力。现在，Microsoft Fabric、Salesforce、Palantir、Google Cloud 等平台都在用自己的方式，把对象、关系、指标和业务规则做成 AI 可读的层。方向本身是对的：agent 进入企业系统以后，只看到表名和字段名是不够的，它需要知道”客户”、“设备”、“续约风险”、“高价值订单”这些概念在业务里到底是什么意思。

为什么偏偏是现在？因为 agent 把这个洞捅破了。过去十年的数据管道只在乎”数据流到哪”，不太在乎”这条数据是什么意思”——反正最后兜底的是人。agent 没有那个兜底的人：它面对几十张表、口径不一的”客户”字段，要么答错（像对 H 集团那样），要么不敢答。很多 agent 试点卡在生产前，不是因为模型不会写字，而是因为业务定义、权限和证据链没有被放进一个可运行的层里。

所以这些平台的判断是对的，而且高度一致：AI 要可靠地进企业，必须先有一层机器可读、受治理的业务定义。 真正该争的，是下一个问题——这一层该归谁。

对的方向，不同的锁

把几类方案摊开，会撞见一个共同点。

	本体存放在哪	谁能读懂它	你能带走吗
Palantir Foundry	Palantir 平台内	驻场工程师 + 平台工具	绑定平台，迁移=重做
Microsoft Fabric / 相关语义层	OneLake / Fabric 内	365 与 Fabric 生态	绑定微软栈
Google Cloud 图谱 / 语义能力	Google Cloud 内	Vertex 与 GCP 生态	绑定谷歌栈

公平地说，每一家在自己的地盘上都做得很好。Palantir 的本体建模质量是真的高；微软把语义层焊进 OneLake 和 365，对一家全员用微软的公司来说顺滑得几乎没有摩擦；谷歌在数据规模和图谱推理上也有真功夫。它们都在帮你把业务梳理清楚——然后把这份清楚，锁进自己的平台。

老一辈 IT 人看到这里会条件反射地说一句：又是厂商锁定嘛，老问题了。

但这次最该担心的不是锁定。这次有个更糟的新问题。在拆它之前，得先认真把封闭平台赢的那套剧本讲清楚——因为它并不弱。

先讲讲封闭平台赢的剧本

如果只会喊”开放好”，那是布道，不是分析。封闭平台手里有四张真牌：

第一，建模质量。 把一家大企业二十年攒下的烂系统，啃成一个干净、自洽的本体，是极重的工程。Palantir 靠驻场工程师一个概念一个概念对齐，质量短期内开源社区比不了。本体这东西，建得烂还不如不建。

第二，一个能负责的主体。 出了事有人接电话、有 SLA、有合同兜底。对一个 CIO 来说，“一家厂商替我担住整层的责任”本身就值钱——这叫 one throat to choke。

第三，很多公司确实”基本在一家”。 如果你 80% 的业务就在一个生态里，那”生态内最优”对你就是字面意义上的最优，开放带来的好处你根本用不上。

第四，集成深度。 同生态内，数据、身份、权限都是现成的，省掉的脏活是以人月计的。

这四张牌都是真的。所以结论不是”封闭平台都是坑”——对处在它们前提里的公司，它们往往就是正确答案。问题出在远峰这类公司身上：它们的前提，正在失效。

这一次，剧本有个新漏洞：分裂

单一厂商锁定，至少你的业务定义还是完整的一份，只是搬不走。痛，但完整。

三家巨头同时建封闭本体，制造的是另一种东西：分裂。 远峰的”客户”不是被锁住了，是被切成了三份，分别躺在三个互不相认的平台里。这比锁定难受得多，而且它难受得有道理——有两层机制保证了它不会自己愈合：

第一层是利益。 你可能会想：那让微软的本体去理解 Salesforce 的”客户”不就行了？难点在于，各家的语义层也是各自平台价值的一部分。主动把跨平台语义完全统一，可能会削弱自己的平台差异化。统一不是没有价值，而是商业激励并不天然站在中立的一边。所以，不能把跨平台语义一致性完全寄托在某一家套件供应商身上。

第二层是技术。 就算抛开利益，跨本体的语义对齐本身也是个没被解决的难题：A 系统的”客户”等于 B 系统的”Account”吗？两边的字段口径、生命周期、去重规则、什么算”同一个实体”，全都不一样。这件事 AI 也不能可靠地自动做——恰恰相反，agent 正是因为缺了这层确定的定义才会出错。回到 H 集团：让 agent 自己去猜”这三份记录是不是同一家公司”，它猜错的代价，就是那几百万。

合起来一句话：你以为买了三个工具，其实买了三个互不相认的”事实来源”。 系统越多、并购越多、合规隔离越多，这种分裂就越严重，而 agent 时代偏偏把它的代价放大了——因为人脑还能勉强在三个系统间手动对齐，agent 不能，它需要一层确定的、跨系统一致的定义才能推理。

要让分裂不发生，逻辑上只有一个出路：业务的定义，不能属于任何一个参与竞赛的平台，它必须是一层中立的东西——一份你自己持有、三家的工具都能去读的定义。封闭平台结构上给不了这个：它们是竞赛的选手，没法同时当裁判。

怎么判断你正在被分裂

这件事不抽象，有很具体的早期症状。对照下面几条，中三条以上，分裂已经在你公司里发生了：

1. 同一个”客户 / 订单 / 设备”，在不同系统里口径不同、对不上号，每次做报表都要人工拉通。
2. 让 agent 回答一个跨系统的问题，它要么含糊其辞，要么只答对了一半（看到了一个系统，没看到另一个）。
3. 每接入一个新系统，你都要重新教 AI 一遍”这是什么、字段什么意思”。
4. 一桩并购过去一年多了，两边的主数据还没真正合一，各报各的。
5. 合规要求把某类数据隔离，于是同一个实体被迫存了好几份，谁也不认谁。

远峰在丢掉 H 集团之前，这五条占了四条。它们当时都被当成”数据治理待办事项”，没人意识到那其实是一个 agent 迟早会踩响的雷。

先泼一盆冷水：开放不是银弹

到这里得诚实地停一下，否则就成了卖膏药。

第一，把定义换成开放协议，并不会自动把远峰那三个”客户”合并成一个。 该做的语义建模、去重、口径对齐，一样得做——这部分没有银弹，谁吹这个都别信。开放真正改变的，是这份苦活的归属：你今天花力气对齐出来的定义，是写在你自己仓库里的，而不是沉淀在某家平台的后台里。明年你换模型、换云、被并购，重做的是连接，不是定义本身。

第二，“开放”本身也不保证赢。 历史上开放标准要真正胜出，往往还需要一个足够好的参考实现，加一个活跃的生态——光把协议公开出来、没人把它做得好用，照样会凉。所以选开放，是在赌”会有人把它做扎实”，这是有执行风险的判断，不是稳赢。

但请注意这两条冷水的分量：它们说的是”开放也要花力气、也有风险”，而不是”封闭更好”。相比之下，把业务定义锁进一家平台的下行风险——也就是远峰那种分裂——要大得多，也更难逆转。两边都不是免费的；只是其中一边，把最核心的资产攥在了你自己手里。

被多方依赖的层，更适合中立

这个规律本身不新，但值得用新例子说，因为它正在反复发生。

被整个生态共同依赖的”定义层”，最终都会走向中立。最老的例子是 SQL：数据库厂商杀成红海，可查询语言本身是公共的。更近、也更说明问题的是这两个：OpenTelemetry——可观测性领域的数据定义，各家监控厂商都来接，由中立的 CNCF 托管，谁也没法独占；以及 LSP（语言服务协议）——微软自己开的，却恰恰因为开放，被所有编辑器采纳，成了事实标准。

LSP 这个例子尤其值得玩味，因为它是微软亲手证明的一件事：把定义层开放出去、自己靠最好的实现去赚钱，比把它锁死更赢。业务语义层是同一类东西——它未来要被你的应用、你的 agent、你的审计系统，外加三家厂商的工具同时依赖。一个被这么多方依赖的层，逻辑上不可能长期归其中任何一方私有。它要么变中立，要么持续制造远峰那样的分裂。

中立的那一层，长什么样

说了这么多，看一眼实物，重点不在语法，在于它在哪、能不能带走、能不能把分裂收回来。

假如远峰当初把”客户”建成一份中立定义：把三个系统都接成数据源、各自建模为对象，再用统一口径（统一社会信用代码）对齐成同一个受治理的客户——一份你仓库里的声明，就是它的真源：

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: '客户',
  fields: {
    name: Field.text({ label: '客户名称', required: true }),
    tax_id: Field.text({ label: '统一社会信用代码' }), // 跨系统对齐“同一个客户”的口径
  },
});

这份定义在你的 Git 仓库里，可 diff、可评审、可迁移。它接下来能做的，才是关键——把”可带走”变成可演示的动作，而不是一句承诺：

git add crm/*.ts          # 定义进了你的版本库，可审、可回滚
os start   # 同一份定义，跑在你自己的基础设施上
# 然后把任意模型指向它——Claude、GPT、Gemini 都行，运行时不变

现在再问那个要命的问题：“H 集团明年续约风险多高？“agent 面对的是一个统一的、带权限和审计的”客户”：订单健康，但叠着两次高管级投诉和一笔 90 天回款争议——它会答”高风险，建议提前介入”。同一个模型、同一个问题，只因为脚下的定义不再分裂，结论从”丢了几百万”变成了”提前一个季度预警”。

这就是 ObjectStack 与 ObjectOS 的分工，也是它对这场竞赛的回答：

• ObjectStack——描述业务的开放协议（Apache 2.0），存在你仓库里，三家的 agent 都能读；
• ObjectOS——这份定义的运行时，跑在你自己的基础设施上，强制权限、记录审计。

定义层中立，运行层做生意。和 SQL 与数据库厂商、LSP 与编辑器厂商的关系，是同一种。

结语

这不是一道”开放好还是封闭好”的意识形态题。它是一道更冷静的算术题：当你的厂商组合迟早会变——多模型、多云、并购、合规隔离，它一定会变——那一刻，谁手里攥着你业务的定义？

这些平台用真金白银替行业证明了这一层值得做。但它们也同时把这道算术题摆到了每家企业面前。远峰那三个”客户”，不是单纯的技术事故，而是把定义分散托管之后很容易出现的代价；那个被错判为”低风险”的 H 集团，只是第一张账单。

被多方共同依赖的层，往往更适合成为中立资产。这一次，业务语义层也该按同样的标准来评估。

npm i -g @objectstack/cli && os start

定义你的第一个业务对象，让它的数据来自你现有的两个系统，然后 git commit 进自己的仓库——那一刻，业务的定义就回到了你手里，而不是某一家的后台里。