開放與封閉企業本體：誰擁有業務語義層

先給結論：這篇文章 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 進自己的倉庫——那一刻，業務的定義就回到了你手裡，而不是某一家的後臺裡。