Ontology 會成為 AI 技術棧的標準組成部分嗎？為什麼執行環境必須開放
Ontology 會成為 AI 技術棧的標準組成部分嗎？agent 介面層已經是了：Ontology MCP 於 2026 年 6 月正式可用。定義層正在跟進。執行環境仍然封閉，而可移植性恰恰住在那一層。
先給結論：Ontology 會成為 AI 技術棧的標準組成部分嗎？作為一個層，它已經是了：ontology 是一份機器可讀的模型，描述一家企業的業務物件、物件之間的關係、被允許的動作和審計規則；2026 年，每一家主要資料平台都推出了 ontology，或在旁邊配了一個語義層。尚未標準化的，是它歸誰所有。本文在 2026 年 6 月主張，型別化應用定義與執行它的執行環境都應該開放。此後行業自己讓出了其中一部分：Palantir 的 Ontology MCP 在 2026 年 6 月 16 日當週正式可用——距本文釋出只有四天——任何 agent 都能通過一個開放協議呼叫 ontology 裡的物件與動作；到 8 月，Palantir 又開始把本體定義搬進帶版本的程式碼倉庫。決定可移植性的是三層——介面層、定義層、執行環境——2026 年打開了第一層，開始開啟第二層，而第三層原地未動。執行環境就是最後一層沒有開啟的地方，也是這場爭論裡唯一還值得爭的一半。
先講一個你大機率親眼見過的過程。
某家企業立項做“AI 助手”。第一週，演示驚豔：把客戶資料匯出一份給模型，它真的能回答“華東區哪些客戶續約風險高”。高管看完當場拍板擴大試點。
第三個月，要接生產資料了，安全團隊進場，問了三個問題：
- AI 能看到哪些資料？銷售 A 問“全公司業績排名”，它會不會把別人的提成也答出來？
- 它要執行動作——改折扣、發合同——權限按什麼算？出錯了算誰的？
- 審計要查“這筆折扣是誰批的”，AI 參與的那部分，記錄在哪？
專案組答不上來。不是態度問題，是架構裡根本沒有能回答這些問題的層。資料散在十幾個系統裡，權限寫在各個應用的程式碼裡，“折扣審批”這個業務規則只存在於某個資深員工的腦子裡。AI 面對的是一堆裸表和裸介面，它再聰明，也沒有地方去“看懂”這家企業的規則。
第九個月，試點悄悄結束。模型沒有輸給能力，輸給了沒有人敢簽字。
這件事行業裡有一個名字，叫缺一個 Ontology（業務本體）：一個結構化、機器可讀的語義層，把“這家企業有哪些業務物件、它們之間什麼關係、誰能對它們做什麼、做了之後記在哪”顯式地定義出來。
Ontology 會成為 AI 技術
在展開論證之前，這個問題值得先得到一個直接的回答，因為答案比正反兩方的說法都更少炒作的味道。
一句話說清 ontology 是什麼： ontology 是一份型別化、機器可讀的模型，描述一家企業由哪些東西構成（客戶、訂單、資產）、它們如何關聯、可以對它們做什麼以及由誰來做、每一次變更記錄在哪裡。語義層止步於前兩項。知識圖譜儲存關係，但不儲存權限。正是後兩項，讓 ontology 成為一個可以放心讓 agent 通過它動手的東西。
它正在變成標準嗎？ 就廠商自己已經交付的東西來看，這一層是的：
| 訊號 | 發生了什麼 | 狀態 |
|---|---|---|
| Agent 介面 | Palantir 的 Ontology MCP 把物件型別、動作型別和函式暴露為 MCP 工具（Palantir） | 2026 年 6 月 16 日當週正式可用 |
| 平台廠商 | 微軟在 Fabric IQ 中提供 ontology 項，並附帶一個 MCP 伺服器（Microsoft Learn）；Databricks、Snowflake 和 Google 推出面向 agent 的語義層（對比） | Fabric IQ ontology 處於預覽；各語義層已 GA 或狀態不一 |
| 交換格式 | Open Semantic Interchange 以 Apache Ossie 之名進入 Apache 孵化器，“超過 50 家組織”支援這一面向指標、維度及其關係的廠商中立格式（Apache Ossie） | 自 2026 年 7 月 10 日起孵化中 |
| 定義即程式碼 | Palantir 的 SuperRepo 用 TypeScript 宣告物件型別、連結、介面與動作（Palantir） | 自 2026 年 8 月 3 日當週起 beta |
所以，“AI 技術棧的標準組成部分”在三種不同意義上都成立，而它們推進的速度各不相同：
- 標準的層——是，已經是了。 如今每一個嚴肅的企業 agent 平台都預設：在模型與原始資料之間，有一個受治理的業務模型。
- 標準的介面——是，而且就是 MCP。 各平台為 agent 呼叫這一層採用了一個開放協議，這是這份清單裡標準化最快的一項。
- 標準的格式——只限分析型那一半。 Ossie 覆蓋指標、維度和關係。動作、權限與審批——決定 agent 能否修改一條記錄的那一半——還沒有任何可比的東西。
誠實的反方論點： 很多團隊永遠不需要一個完整的 ontology。如果 agent 只負責回答問題，資料倉儲的語義層加上對文件的檢索就能把事辦成，建模成本只是零頭；而 ontology 專案向來以“建模委員會開了六個月、什麼都沒交付”出名，這個名聲也確實是自己掙來的。ontology 值回成本的時刻，是 agent 必須在某個人的權限之下做一件事——而這恰恰是沒有標準格式的那一半，並且如本文後面所論證的，也沒有開放的執行環境。
Palantir 把這件事
把 Ontology 從論文概念變成企業架構實踐的代表，是 Palantir。值得認真看一下它為什麼成立——看得越公道，後面的問題才越清楚。
Palantir Foundry 的核心動作是兩個。第一，把企業散落各處的資料整合進一個統一的本體層：客戶、裝置、訂單不再只是幾十張表，而是有型別、有關係、有屬性的業務物件。第二，把寫操作收斂成受控的 Actions——每個動作帶校驗、帶權限、帶完整審計。AIP 把這套架構直接對準了大模型：LLM 不直接碰資料庫，而是呼叫本體層暴露出來的受治理工具。 模型可以換，邊界不動。
這套東西為什麼貴？因為它解決的問題確實貴。把一家大企業多年積累的系統梳理成一個乾淨的本體，需要團隊一個系統一個系統地啃，一個概念一個概念地對齊——這是實打實的人力密集型工程。政府、國防、金融、能源這類客戶，對“AI 每一步都在權限之內、都有記錄”的要求是硬性的，也願意為交付質量、責任邊界和長期支援付費。
所以這裡真正值得吸取的，不是某家公司的估值故事，而是一個架構判斷：AI 要進入企業，必須先有一個受治理的業務語義層。
需要重新想的是下一個問題：這一層應該以什麼形態存在？因為有幾件事正在變。
軟體
第一件事最直觀：應用本身越來越多是 AI 寫出來的。
過去“給 50 人的團隊定製一套報銷審批系統”在經濟上不成立——開發費比痛點貴。現在一個 AI agent 幾個小時就能交付一個可用雛形。定製業務軟體正在從稀缺品變成更日常的產物，長尾需求會明顯增加。
注意這個增長髮生在哪：發生在長尾。發生在那些很少出現在企業軟體銷售名單上的團隊裡——他們沒有采購流程，沒有實施預算，不開 POC 評審會。他們只是讓 agent “搭一個能用的”，下午就開始用了。
一個靠駐場工程師和百萬美元合同運轉的模式，結構上夠不到這個市場。這不是誰對誰錯，是兩個市場。但這個新市場裡的每一套系統，同樣會撞上開頭那三個安全問題——只是撞上的時候，旁邊沒有 FDE。
下
第二件事更隱蔽，但影響更深：技術選型這個動作本身，正在從人手裡轉移到 AI 手裡。
今天你讓一個 agent “搭一個客戶管理系統”，它大機率會選 Next.js 加 Postgres。為什麼？不是因為有人給它做了廣告，而是因為這些技術開放、文件完整、大量存在於它的訓練資料裡。它見過幾十萬個用法，知道每個坑怎麼繞。
這意味著一件以前不存在的事：對開發者工具來說，公開的協議文本和開原始碼就是分發渠道本身。 一個協議越開放、越多人討論、越多程式碼可學，下一代模型就越懂它，agent 就越傾向於選它——這是一個會自我強化的迴圈。
封閉平台面對這個迴圈有兩條出路。貴的那條是把格式本身開放，讓模型學會它、讓 agent 不用被提示就想到它。便宜的那條是格式照舊封閉，只在邊緣採用一個開放協議——agent 於是能呼叫這個平台，儘管仍然學不到它。
本文最初的寫法是：封閉平台進不了這個迴圈。不到一週，這個說法就被證明太強了——在位廠商走了便宜的那條路，而且走通了。留下來的是更窄、也更要緊的一句：agent 能呼叫的介面不等於 agent 能學習的定義，而這兩樣都不等於一個你能帶走的執行環境。在位廠商為此做了什麼、又唯獨沒做什麼，見下文。
等等——
到這裡，一個聰明的反駁應該出現了：開放未必贏。雲端計算時代贏的是 AWS，移動時代贏的是 iOS，都是封閉的。
這個反例值得認真接，因為接完恰好能看清規律。
看一眼 AWS 是怎麼賺錢的：它託管的是 Linux、Kubernetes、Postgres——清一色的開放標準。iPhone 封閉，但它跑的網路是 TCP/IP 和 HTTP。再往前數：資料庫廠商殺成紅海，SQL 這個語言本身是公共的；容器編排打了三年，最後大家都跑在開放的 OCI 映像格式上。
規律其實很整齊：被整個生態依賴的可移植底座最終會走向開放——既包括定義，也包括解釋和執行這些定義的基礎執行環境。 廠商仍然可以獲得持續收入，但賣的是託管運營、升級、安全封裝、效能、支援和責任。AWS 自己就是最大的例證：Linux、Kubernetes、Postgres 保持開放，AWS 為可靠運營它們收費。
業務語義層正是這種底座。物件模型、權限規則、審批流程，以及強制執行它們的執行環境語義，未來會被應用、agent、審計系統共同依賴。依賴越多，定義與執行環境就越不應該只存在於某個供應商的平台裡。定義應是你倉庫中可讀、可版本化的檔案，相容執行環境則應可自託管、可替換。只能由一家付費引擎執行的“開放檔案”，並不真正可遷移。
企業花了二十年把資料從一個個封閉系統裡解放出來，不應該在 AI 時代把比資料更核心的資產——業務的定義本身——再鎖進去一次。
Ontology MCP 打開了
這個規律幾乎立刻被檢驗了一次，而檢驗結果比當初的預測更有說服力。
本文釋出四天後，Palantir 的 Ontology MCP 在 2026 年 6 月 16 日當週面向 Foundry 環境正式可用（Palantir 官方文件）。物件型別、動作型別和函式被投影成 Model Context Protocol 工具，任何相容 MCP 的 agent 都能讀取這套 ontology 並驅動它的業務流程，不必再為每個 agent 框架各寫一份對接程式碼。微軟也在 Fabric IQ 上預覽同樣的介面。
隨後在 8 月，Palantir 推出了 beta 階段的「本體即程式碼」：物件型別、連結、介面與動作用 TypeScript 宣告在一個 monorepo 裡，這些程式碼定義就是唯一事實源。
把這兩步放在一起看，上一節那個「底座終將開放」的判斷成立了——但成立的理由和當初寫下它時不一樣。底座確實在開放。它之所以開放，是因為在位廠商自己把它打開了，而且是按對自己代價最小的順序開啟的：
| 層 | 它是什麼 | 2026 年把它留在哪 |
|---|---|---|
| 介面層 | agent 如何呼叫 ontology | 已開放。 MCP，由平台廠商自己採用 |
| 定義層 | 物件、動作與權限 | 形式上在開放。 以程式碼入庫，仍要落到單一廠商的平台上 |
| 執行環境 | 執行動作、並在執行時強制規則的那一層 | 原地未動。 沒有廠商交出一個你能換個地方跑的執行環境 |
第三行值得慢慢讀，因為整個論點就在那裡。
開放的介面讓 ontology 可被呼叫；放進倉庫的定義讓它可讀、可評審。但這兩樣都不能讓它換個地方跑起來。可移植的定義不等於可移植的系統：一個裝滿本體程式碼的 monorepo，最終仍要落在一套 Foundry 環境上。而且工具面是從定義投影出來的，誰執行這次投影，誰就決定了工具是什麼。定義檔案自己不執行任何東西。
這就是這次更新真正依賴的那個數字。把 Palantir 那套寫進文件的投影規則套到一箇中等規模的應用上——12 個物件型別、30 個動作型別、6 個對外函式——你會得到37 個說著開放協議的 MCP 工具，而底下只有一臺引擎能回答其中任何一個。介面變得可移植了，依賴一寸也沒動。
把最有力的反駁如實擺出來：團隊真正想從可移植性裡拿到的東西，如今大半已經拿到了。你可以讀自己的模型、以 diff 的方式評審它、把任何 agent 指向它；分析型語義還能通過一份 2026 年進入 Apache 孵化器的中立規範來交換。如果你的 ontology 只需要回答問題，那已經接近夠用了，本文不該假裝不是。
而回答它的那條線，和「語義層」與 ontology 的分界線是同一條：它一直成立，直到有事情必須真的發生。當一個對外暴露的動作真的改寫了一條記錄，你在意的一切——權限校驗、事務、超過閾值時的審批、那一行審計記錄——都是引擎的性質，而不是檔案的性質，也不是協議的性質。你能匯出那句話，導不出那道強制。
把這個缺口叫作最後一層沒有開啟的地方。這不是指控，而是對這個賽道停在哪裡的描述。九個月裡有兩層開放了，而且多半是靠自身慣性；第三層一動沒動——因為那是平台生意在不改變自己賣什麼的前提下無法開啟的一層。
這層
說了這麼多，看一眼實物。下面是 ObjectStack 型別化應用定義裡的一個商機物件（節選自真實示例）：
export const Opportunity = ObjectSchema.create({
name: 'crm_opportunity',
label: '商機',
fields: {
name: Field.text({ label: '商機名稱', required: true }),
account: Field.lookup('crm_account', { label: '客戶', required: true }),
amount: Field.currency({ label: '金額', min: 0 }),
probability: Field.percent({ label: '贏單機率', defaultValue: 50 }),
expected_revenue: Field.formula({
label: '預期收入',
expression: cel`amount * probability / 100`,
}),
discount_percent: Field.percent({ label: '折扣', max: 100 }),
},
});
// 權限同樣是宣告的：銷售可讀寫商機，但不能刪除
export const SalesUser: Security.PermissionSet = {
name: 'crm_sales_user',
objects: {
crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
},
};關鍵不在語法，在於這幾十行就是系統本身。開源 ObjectStack 執行環境讀取這份定義，派生資料表、REST API、管理介面、MCP 工具，並強制執行權限與審計。折扣超過 30% 要走財務審批？那是一條掛在這個物件上的流程定義，同樣是宣告式的，同樣在版本庫裡。ObjectOS 在同一應用之外增加瀏覽器內 Build 與 Ask、團隊審閱和審批、託管雲或私有部署運營、SSO 與支援——但不會把定義或執行引擎重新變成專有依賴。為了執行它，ObjectStack 倉庫提供 ObjectOS Community —— ghcr.io/objectstack-ai/objectstack 映像、os start 和 Console，免費且自託管 —— 而 ObjectOS Cloud 是託管版本，ObjectOS Enterprise 是自管理、需許可的版本。
這帶來三個直接後果：
- 開頭那三個安全問題，有了結構性的答案。 AI 能看什麼——權限集裡寫著；它執行動作按什麼權限算——它以登入使用者的身份行動，由 ObjectStack 執行環境強制執行，而不是靠提示詞約束；審計記錄在哪——人和 agent 的每一次讀寫共用同一本賬，誰、什麼、何時、為什麼，合規團隊只看一本。
- 業務變更變成了程式碼評審。 AI 要給系統加一個“續約提醒”？它提交的是一份中繼資料 diff，改了什麼欄位、動了什麼權限，一目瞭然。出問題可以回滾，因為定義是版本化的。
- 整個系統裝得進一個 agent 的上下文視窗。 一個典型的企業模組，從幾萬行 CRUD 和膠水程式碼收斂成幾百行宣告——小到 AI 可以完整讀懂每一處依賴，然後跨資料、API、介面、權限做一次安全的整體重構。這是“AI 當共同維護者”和“AI 當代碼補全”的分界線。
定義
現在可以把整個論證收攏了。
Ontology 這個判斷是對的，Palantir 已經替行業證明過。本文最初寫下時，“定義開放、獨家引擎收費”還是一種值得提前警告的失敗形態。九個月過去，它不再是警告，而是對這個賽道最終落點的如實描述——由一群把除了自己所賣之外的一切都開放了的廠商，一個個合理決定累積而成。這反倒讓另一條路更好講了：型別化業務定義與可移植的治理執行環境都屬於開放生態；收費產品提供圍繞它們的生產運營體驗。
這正是 ObjectStack 和 ObjectOS 的分工：
- ObjectStack 是一套開放業務本體（open business ontology）：型別化的應用定義，加上執行它的開源執行環境（Apache 2.0）。物件、關係、權限、流程、API、UI、AI 工具在你的倉庫裡一次定義；執行環境從中派生資料庫、REST API、渲染介面與 MCP 服務，並在每次呼叫上強制權限與審計。定義和引擎都可 diff、可自託管、可遷移——而後一半，正是這個賽道其餘玩家留著沒開的那一層。
- ObjectOS 運營的是同一份 ObjectStack 應用。它銷售瀏覽器內 Build 與 Ask、團隊審閱和審批、託管雲或私有部署運營、SSO、企業控制與支援，而不是一臺把業務本體重新鎖回廠商手裡的封閉執行引擎。為了執行它，ObjectStack 倉庫提供 ObjectOS Community —— ghcr.io/objectstack-ai/objectstack 映像、os start 和 Console，免費且自託管 —— 而 ObjectOS Cloud 是託管版本，ObjectOS Enterprise 是自管理、需許可的版本。
一邊是任何團隊、任何 agent 都看得懂、可自託管、帶得走的應用定義與可移植執行環境；另一邊是企業真正願意付費的生產體驗：協作編寫、審批、託管、私有部署、SSO、支援、升級和運營責任。應用及其基礎執行環境歸你，為團隊可靠運營它們才是生意。
結語
那個九個月死掉的 AI 試點，死因從來不是模型不夠聰明，而是沒有一個能讓安全團隊簽字的業務語義層。行業裡最貴的公司用十年證明了這一層的價值；而 2026 年只用九個月證明了一件更窄、也更有用的事：這一層裡便宜開放的部分，現在都已經開放了。介面是一個公開協議，定義是一份你能讀的檔案。剩下的，是那臺把定義變成介面、並在變的過程中強制規則的引擎——而這一層，什麼都沒開啟。
所以本文在 6 月提出的問題，現在有了更鋒利的形式。不再是「本體該不該開放」——那已經有了答案，而且是廠商自己給的。而是：當最後一層沒有開啟的，恰好是執行你業務規則的那一層，你希望那臺引擎是誰的？
如果你想驗證這套東西是不是真的：
npm create objectstack@latest my-app && cd my-app
# 用你的編碼 agent 開啟它，說清業務需要什麼
npx os dev --ui五分鐘後，定義你的第一個業務物件，看開源 ObjectStack 執行環境把它變成一張表、一個 API、一個管理介面和一個 AI 可以安全呼叫的工具。每次呼叫都帶權限，每次呼叫都記賬。如果團隊需要瀏覽器內 Build 與 Ask、共享審閱和審批、託管雲或私有部署、SSO 與支援，ObjectOS 運營的仍是同一份 ObjectStack 應用，不會換成專有格式或獨家引擎。