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

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