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

先给结论：这篇文章 2026 年 6 月首发时问的是”谁会拥有业务语义层”。这场竞赛现在已经跑完了：九个月里，五家平台各自交付了一层。 它们还做了一件没人预料到的事——把访问本体的通道用 MCP 开放了出来，而定义本身仍留在平台内部。可以叫它协议开放，定义封闭。agent 现在能读到五份它搬不走的本体。这让归属问题变得更尖锐，而不是更无关；答案也没有变：被你的应用、agent、审计、甚至多家厂商共同依赖的业务定义层，应该是一份你自己持有的中立定义。

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

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

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

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

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

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

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

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

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

这篇文章点名的那场竞赛，已经跑完了

这篇文章首发时，参赛者还是一份预测。现在它们是一份记录。2025 年 11 月到 2026 年 8 月，五家平台各自交付了业务语义层：

平台	交付了什么	时间
Microsoft Fabric IQ	Ontology 条目，外加一整套 agent 工作负载——Graph、Data Agent、Operations Agent——公开预览中，任何 agent 都能通过公开的 Ontology MCP 端点访问	Ignite，2025 年 11 月；2026 年 3 月 FabCon 亚特兰大补上规则与自动化
Snowflake	Semantic View Autopilot 正式可用——它从你现有的查询历史和 BI 资产里起草语义视图，而不是让一个委员会从零开始定义”收入”	2026 年 2 月 3 日
Google	Looker BI Agents 以 Looker 语义层为依据；Dataplex 更名为 Knowledge Catalog，把目录元数据变成一张语义图谱，并为 agent 提供上下文 API	Cloud Next ‘26，2026 年 4 月
Databricks Unity Catalog	Business Semantics 正式可用——在数据层一次性定义受治理的指标视图与 agent 元数据，核心实现正在开源进 Apache Spark	2026 年正式可用；Business Glossary 与 Domains 见于 2026 年 6 月 Data + AI Summit
Palantir Foundry	Ontology MCP 在全部 Foundry 部署上正式可用——对象类型、动作类型和函数都作为可调用工具暴露给任意 MCP 客户端	2026 年 6 月 16 日当周

在往下讲之前，关于这张表有两件事值得先说清楚。

这篇文章不是逐格对比它们的地方。 逐项能力、每一格都溯源到厂商自己的文档，是另一篇：Fabric IQ vs Palantir vs Unity Catalog vs Snowflake。它厘清了其中哪几家真正建模动作、而不只是描述业务——那是最决定性的一行。你在选型，就去读那一篇；你在决定该拥有什么，就读这一篇。

真正构成论点的是日期，不是功能清单。 九个月，五家平台，五个各自独立作出的判断：这一层值得建。“AI 进企业是否需要一层机器可读、受治理的业务定义”——这半个问题已经不需要再争了。

有一处澄清仍然属于这里，因为这三个词经常被当作同义词，而它们不是：ontology vs semantic layer vs knowledge graph 讲清了每一个各自能回答什么、不能回答什么。下面关于归属的讨论，默认你已经想清楚自己说的是哪一层。

转折：协议开放，定义封闭

接下来这一段，是六月以来变化最大、也最出人意料的一件事。

这些平台没有把墙砌死。它们开放了——用 MCP。Fabric IQ 提供公开的 Ontology MCP 端点；Palantir 的 Ontology MCP 在全部 Foundry 部署上正式可用，时间恰好就是这篇文章首发的那一周；Snowflake 提供托管的 MCP server；Google 在 Knowledge Catalog 前面放了一个上下文 API。上面那篇对比里的四家平台中，有三家把自己的语义层通过 MCP 开放给了 agent。

乍一看，这像是开放的答案自己走了过来。它不是，而且这个区别值得说得非常精确：

MCP 标准化的是 agent 怎么”够到”你的本体，它没有标准化这份本体归谁”持有”。

MCP 端点是一条读取通道，不是一张地契。你的 agent 得到了一条干净、受治理、厂商中立的提问路径，而它问的那份定义，仍然住在别人的平台里，仍然由别人的发版节奏决定版本，你离开的时候它仍然跟着别人走。协议是开放的，定义是封闭的。协议开放，定义封闭。

这件事要紧，是因为这两者恰好在最花钱的那个方向上容易被混淆。“任何 agent 都能读它”听起来像可迁移性。它其实是可迁移性的反面：它让”搬不走”这件事变得不再难受。

为什么这让分裂更严重，而不是更轻

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

五家平台各自持有自己的本体，制造的是另一种东西：分裂。 远峰的”客户”不是被锁住了，是被切成了三份，分别躺在三个互不相认的平台里。有两层机制保证了它不会自己愈合，而 MCP 现在又加上了第三层。

第一层是利益。 你可能会想：那让微软的本体去理解 Salesforce 的”客户”不就行了？难点在于，各家的语义层也是各自平台护城河的一部分。如果微软单方面把”客户”语义和竞争对手统一了，等于帮对手把数据搬得更顺，同时削弱自己的差异化。对竞赛里的每一位选手来说，统一在战略上都不划算。 这不只是技术疏忽，这是理性的平台行为。

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

第三层是新的，也是最不舒服的一层：MCP 降低了”忍受分裂”的成本。 过去，把一个 agent 接进五个互不相认的语义层，痛苦到总有人会把它升级上报，于是对齐项目拿到了预算。现在，这是一个下午注册五个端点的事。agent 会心安理得地同时握着五个工具，每一个对”这个客户是谁”给出的答案都不一样，然后它会用最先够到的那一个自信地作答。过去逼着你去做对齐的那份集成痛苦被消除了；它当年警示的那个分裂，一点没少。

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

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

先讲讲封闭平台赢的剧本

如果只会喊”开放好”，那是布道，不是分析。封闭平台手里有四张真牌，而且过去九个月里有两张变得更硬了。

第一，建模质量。 把一家大企业二十年攒下的复杂度，啃成一个干净、自洽的本体，是极重的工程。Palantir 靠驻场工程师一个概念一个概念对齐，质量短期内开源社区比不了。本体这东西，建得烂还不如不建。驻场这套模式本身有自己的经济学，而它比这个职位名称难迁移得多——照抄驻场模式为什么最后建成的是一家咨询公司 把它下面必须先存在什么讲透了。

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

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

第四——这张牌变硬了——冷启动问题。 Snowflake 的 Autopilot 从你已有的查询历史里起草语义模型；Fabric IQ 让业务专家用无代码可视化工具直接建本体，不必排队等数据工程师。两家打的都是真正的拦路虎：障碍从来不是技术，而是那个六个月的建模委员会。开放格式给你的是一个文件和一页空白。

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

怎么判断你正在被分裂

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

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

远峰在丢掉 H 集团之前，前五条占了四条。它们当时都被当成”数据治理待办事项”，没人意识到那其实是一个 agent 迟早会踩响的雷。第六条是 2026 年新增的，也是最悄无声息的一条——因为”再接一个端点”看上去像是进展。

泼一盆冷水：开放不是银弹，而且这个领域正在标准化

到这里得诚实地停一下，否则就成了卖膏药。有三条站得住的反驳，第三条是新的。

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

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

第三，也是对本文立场最强的一条反驳：厂商们正在自己把定义层标准化。 Snowflake 与 Salesforce、dbt Labs、BlackRock、RelationalAI 共同发起了 Open Semantic Interchange；2026 年 7 月，这个项目以 Apache Ossie 的身份进入 Apache 孵化器，成员组织超过 50 家，其中包括 Databricks、Oracle 和 Collibra。Databricks 还在单独把自己的指标视图实现开源进 Apache Spark。这是真事，比大多数中立层努力推进得都快；今天再说”封闭平台永远不会收敛”，就是在跟证据吵架。

但要看清这轮收敛停在了哪里。Ossie 覆盖的是分析型语义——指标、维度、关系。动作与权限不在范围内。也就是说，你本体中描述业务的那一半正在变得可迁移，而改变业务的那一半——操作本身、谁有权执行、以及什么被写进审计日志——仍然是专有的。这不是一个小尾巴。它恰恰是决定 agent 能不能做事的那一半，也恰恰是分裂代价最高的那一半。

这三条都没有说封闭更好。它们说的是：开放也要花力气、也有风险、而且有一半正在被对方迎上来。把它们和另一边的下行风险放在一起称——把业务定义锁进一家平台，然后让它散在五家之间。两边都不是免费的；只是其中一边，把最核心的资产攥在了你自己手里。

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

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

被整个生态共同依赖的”定义层”，最终都会走向中立。最老的例子是 SQL：数据库厂商杀成红海，可查询语言本身是公共的。更近的两个例子是 OpenTelemetry——可观测性的数据标准，由中立的 CNCF 托管；以及 LSP（语言服务协议）——微软自己开的，却恰恰因为开放，被众多编辑器采纳。

LSP 这个例子尤其值得玩味，因为它是微软亲手证明的一件事：把定义层开放出去、自己靠最好的实现去赚钱，比把它锁死更赢。但要注意 LSP 到底开放了什么——协议，以及”一个语言服务必须提供什么”的定义。对本体来说，MCP 做完了前一半；Apache Ossie 正在尝试做分析部分的后一半。而”会动作”的那一部分，还没有任何人做过。

一个同时被你的应用、你的 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 天回款争议——它会答”高风险，建议提前介入”。同一个模型、同一个问题，只因为脚下的定义不再分裂，结论从”丢了几百万”变成了”提前一个季度预警”。

MCP 那一点在这里同样成立，而且方向恰好是对的：同一份定义，正是运行时作为受治理工具交给 agent 的那一份——读取通道是开放的，同时定义是你的。这正是为什么定义与运行时都该开放完整论证的那件事。

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

• ObjectStack——一份 open business ontology（开放业务本体）：开放的定义协议与开源自托管运行时（Apache 2.0）。定义存在你仓库里，任意厂商的 agent 都能读，运行时负责校验和执行，并强制权限、记录审计；
• ObjectOS——同一 ObjectStack 应用可选的商业生产平台与运营体验：支持云端或自管部署，增加浏览器 AI 构建、部署和运营能力，但不取代底层开放定义与运行时。

开放定义与自托管运行时保持中立，商业生产体验才是产品竞争的地方。和 SQL 与数据库厂商、LSP 与编辑器厂商的关系，是同一种。

也要把交换条件说清楚：在建模深度、冷启动、以及仓库级规模上的分析型语义这三件事上，上面那些平台是领先的，对比那一篇逐项讲了领先在哪。这里不同的地方比”更好”要窄——定义是你仓库里一个普通文件，用的是开放许可；执行它的运行时，也归你自己部署。

结语

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

九个月前这个问题还是假设，因为这个领域还没交付。现在交付了。五家平台证明了这一层值得建，然后它们中的大多数，在一栋不属于你的房子上开了一扇前门。别人本体上的一个 MCP 端点确实有用——它只是和”拥有这份定义”不是同一件事，而这两者之间的那道缝，正是远峰的 H 集团掉下去的地方。

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

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

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