ObjectOS
開始使用
← 全部文章
安全與治理 業務決策者 已釋出 · · · 作者 ObjectStack Team

企業 AI Ontology：為什麼業務定義與執行時都應該開放

2026 年 6 月 Ontology MCP 正式可用：廠商自己把 agent 介面交給了開放協議，定義層也在跟進。唯獨執行時沒人開啟——而可移植性恰恰住在那一層。

企業 AI Ontology：為什麼業務定義與執行時都應該開放
  • 本體
  • MCP
  • Palantir

先給結論：本文在 2026 年 6 月主張，型別化應用定義與執行它的執行時都應該開放。此後行業自己讓出了其中一部分：Palantir 的 Ontology MCP 在 2026 年 6 月 16 日當週正式可用——距本文釋出只有四天——任何 agent 都能通過一個開放協議呼叫 ontology 裡的物件與動作；到 8 月，Palantir 又開始把本體定義搬進帶版本的程式碼倉庫。決定可移植性的是三層——介面層、定義層、執行時——2026 年打開了第一層，開始開啟第二層，而第三層原地未動。執行時就是最後一層沒有開啟的地方，也是這場爭論裡唯一還值得爭的一半。

先講一個你大機率親眼見過的過程。

某家企業立項做“AI 助手”。第一週，演示驚豔：把客戶資料匯出一份給模型，它真的能回答“華東區哪些客戶續約風險高”。高管看完當場拍板擴大試點。

第三個月，要接生產資料了，安全團隊進場，問了三個問題：

  • AI 能看到哪些資料？銷售 A 問“全公司業績排名”，它會不會把別人的提成也答出來？
  • 它要執行動作——改折扣、發合同——權限按什麼算？出錯了算誰的？
  • 審計要查“這筆折扣是誰批的”，AI 參與的那部分，記錄在哪？

專案組答不上來。不是態度問題，是架構裡根本沒有能回答這些問題的層。資料散在十幾個系統裡，權限寫在各個應用的程式碼裡，“折扣審批”這個業務規則只存在於某個資深員工的腦子裡。AI 面對的是一堆裸表和裸介面，它再聰明，也沒有地方去“看懂”這家企業的規則。

第九個月，試點悄悄結束。模型沒有輸給能力，輸給了沒有人敢簽字。

這件事行業裡有一個名字，叫缺一個 Ontology（業務本體）：一個結構化、機器可讀的語義層，把“這家企業有哪些業務物件、它們之間什麼關係、誰能對它們做什麼、做了之後記在哪”顯式地定義出來。

Palantir 把這件事做成了可驗證的企業架構

把 Ontology 從論文概念變成企業架構實踐的代表，是 Palantir。值得認真看一下它為什麼成立——看得越公道，後面的問題才越清楚。

Palantir Foundry 的核心動作是兩個。第一，把企業散落各處的資料整合進一個統一的本體層：客戶、裝置、訂單不再只是幾十張表，而是有型別、有關係、有屬性的業務物件。第二，把寫操作收斂成受控的 Actions——每個動作帶校驗、帶權限、帶完整審計。AIP 把這套架構直接對準了大模型：LLM 不直接碰資料庫，而是呼叫本體層暴露出來的受治理工具。 模型可以換，邊界不動。

這套東西為什麼貴？因為它解決的問題確實貴。把一家大企業多年積累的系統梳理成一個乾淨的本體，需要團隊一個系統一個系統地啃，一個概念一個概念地對齊——這是實打實的人力密集型工程。政府、國防、金融、能源這類客戶，對“AI 每一步都在權限之內、都有記錄”的要求是硬性的，也願意為交付質量、責任邊界和長期支援付費。

所以這裡真正值得吸取的，不是某家公司的估值故事，而是一個架構判斷：AI 要進入企業，必須先有一個受治理的業務語義層。

需要重新想的是下一個問題：這一層應該以什麼形態存在？因為有幾件事正在變。

軟體正在變成 AI 寫的

第一件事最直觀：應用本身越來越多是 AI 寫出來的。

過去“給 50 人的團隊定製一套報銷審批系統”在經濟上不成立——開發費比痛點貴。現在一個 AI agent 幾個小時就能交付一個可用雛形。定製業務軟體正在從稀缺品變成更日常的產物，長尾需求會明顯增加。

注意這個增長髮生在哪：發生在長尾。發生在那些很少出現在企業軟體銷售名單上的團隊裡——他們沒有采購流程，沒有實施預算，不開 POC 評審會。他們只是讓 agent “搭一個能用的”，下午就開始用了。

一個靠駐場工程師和百萬美元合同運轉的模式，結構上夠不到這個市場。這不是誰對誰錯，是兩個市場。但這個新市場裡的每一套系統，同樣會撞上開頭那三個安全問題——只是撞上的時候，旁邊沒有 FDE。

下一個做技術選型的，是 agent

第二件事更隱蔽，但影響更深：技術選型這個動作本身，正在從人手裡轉移到 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 工具，而底下只有一臺引擎能回答其中任何一個。介面變得可移植了，依賴一寸也沒動。

三層結構決定可移植性：介面層通過 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 與支援——但不會把定義或執行引擎重新變成專有依賴。

一份後設資料定義，同時生效為 API、介面、AI 工具和審計權限

這帶來三個直接後果：

  1. 開頭那三個安全問題，有了結構性的答案。 AI 能看什麼——權限集裡寫著；它執行動作按什麼權限算——它以登入使用者的身份行動，由 ObjectStack 執行時強制執行，而不是靠提示詞約束；審計記錄在哪——人和 agent 的每一次讀寫共用同一本賬，誰、什麼、何時、為什麼，合規團隊只看一本。
  2. 業務變更變成了程式碼評審。 AI 要給系統加一個“續約提醒”？它提交的是一份後設資料 diff，改了什麼欄位、動了什麼權限，一目瞭然。出問題可以回滾，因為定義是版本化的。
  3. 整個系統裝得進一個 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、企業控制與支援，而不是一臺把業務本體重新鎖回廠商手裡的封閉執行引擎。

一邊是任何團隊、任何 agent 都看得懂、可自託管、帶得走的應用定義與可移植執行時；另一邊是企業真正願意付費的生產體驗：協作編寫、審批、託管、私有部署、SSO、支援、升級和運營責任。應用及其基礎執行時歸你，為團隊可靠運營它們才是生意。

結語

那個九個月死掉的 AI 試點，死因從來不是模型不夠聰明，而是沒有一個能讓安全團隊簽字的業務語義層。行業裡最貴的公司用十年證明了這一層的價值；而 2026 年只用九個月證明了一件更窄、也更有用的事：這一層裡便宜開放的部分，現在都已經開放了。介面是一個公開協議，定義是一份你能讀的檔案。剩下的，是那臺把定義變成介面、並在變的過程中強制規則的引擎——而這一層，什麼都沒開啟。

所以本文在 6 月提出的問題，現在有了更鋒利的形式。不再是「本體該不該開放」——那已經有了答案，而且是廠商自己給的。而是：當最後一層沒有開啟的，恰好是執行你業務規則的那一層，你希望那臺引擎是誰的？

如果你想驗證這套東西是不是真的：

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

五分鐘後，定義你的第一個業務物件，看開源 ObjectStack 執行時把它變成一張表、一個 API、一個管理介面和一個 AI 可以安全呼叫的工具。每次呼叫都帶權限，每次呼叫都記賬。如果團隊需要瀏覽器內 Build 與 Ask、共享審閱和審批、託管雲或私有部署、SSO 與支援，ObjectOS 運營的仍是同一份 ObjectStack 應用，不會換成專有格式或獨家引擎。