企業 AI Ontology：為什麼業務語義層應該是開放協議

先給結論：AI 進企業需要一個受治理的業務語義層；但這一層更適合像 Linux 一樣是開放協議、歸企業自己所有，而不是鎖進某個封閉平臺。定義層開放，執行時承擔執行、許可權、審計和運維責任。

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

某家企業立項做“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 來寫，這就不只是營銷問題，而是機器可學習性問題。

等等——封閉平臺不是也贏過很多次嗎？

到這裡，一個聰明的反駁應該出現了：開放未必贏。雲端計算時代贏的是 AWS，移動時代贏的是 iOS，都是封閉的。

這個反例值得認真接，因為接完恰好能看清規律。

看一眼 AWS 是怎麼賺錢的：它託管的是 Linux、Kubernetes、Postgres——清一色的開放標準。iPhone 封閉，但它跑的網路是 TCP/IP 和 HTTP。再往前數：資料庫廠商殺成紅海，SQL 這個語言本身是公共的；容器編排打了三年，最後大家都跑在開放的 OCI 映象格式上。

規律其實很整齊：被整個生態依賴的“定義層”最終走向開放——因為沒有人敢把自己的資產建立在單一廠商的語法上；而“執行層”可以封閉、可以收費——因為執行意味著持續的運維、效能和責任，這是真實的持續成本。 AWS 自己就是最大的例證：定義歸社群，執行收錢。

業務語義層是典型的定義層。你的物件模型、許可權規則、審批流程，未來會被你的應用依賴、被你的 agent 依賴、被你的審計系統依賴——依賴的東西越多，它就越不應該鎖在某一家的平臺數據庫裡，而應該是你自己倉庫裡可閱讀、可版本管理、可帶走的檔案。

企業花了二十年把資料從一個個封閉系統裡解放出來，不應該在 AI 時代把比資料更核心的資產——業務的定義本身——再鎖進去一次。

這層“定義”長什麼樣

說了這麼多，看一眼實物。下面是 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 },
  },
};

關鍵不在語法，在於這幾十行就是系統本身。執行時（ObjectOS）讀取這份定義，自動生成資料表、REST API、管理介面，以及——AI agent 可以直接呼叫的受治理工具。折扣超過 30% 要走財務審批？那是一條掛在這個物件上的流程定義，同樣是宣告式的，同樣在版本庫裡。

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

這帶來三個直接後果：

開頭那三個安全問題，有了結構性的答案。 AI 能看什麼——許可權集裡寫著；它執行動作按什麼許可權算——它以登入使用者的身份行動，執行時強制執行，而不是靠提示詞約束；審計記錄在哪——人和 agent 的每一次讀寫共用同一本賬，誰、什麼、何時、為什麼，合規團隊只看一本。
業務變更變成了程式碼評審。 AI 要給系統加一個“續約提醒”？它提交的是一份後設資料 diff，改了什麼欄位、動了什麼許可權，一目瞭然。出問題可以回滾，因為定義是版本化的。
整個系統裝得進一個 agent 的上下文視窗。 一個典型的企業模組，從幾萬行 CRUD 和膠水程式碼收斂成幾百行宣告——小到 AI 可以完整讀懂每一處依賴，然後跨資料、API、介面、許可權做一次安全的整體重構。這是“AI 當共同維護者”和“AI 當代碼補全”的分界線。

協議歸社群，執行時做生意

現在可以把整個論證收攏了。

Ontology 這個判斷是對的，Palantir 已經替行業證明過。但按“定義層開放、執行層收費”的規律，這一層在 AI 時代的健康形態是：業務語義協議像 Linux 一樣屬於開放生態，治理執行時在你自己的環境裡執行它。

這正是 ObjectStack 和 ObjectOS 的分工：

ObjectStack 是描述業務應用的開放協議（Apache 2.0）：物件、關係、許可權、流程、API、UI、AI 工具，一次定義。它存在於你的倉庫裡，可 diff、可遷移、可被任何 agent 讀取——也因此存在於公網和未來模型的訓練資料裡。
ObjectOS 是這些定義的執行時：在你自己的伺服器上、你自己的資料庫上執行一切，並在執行時強制許可權、記錄審計。治理不寫在提示詞裡，寫在執行引擎裡。

一邊是任何團隊、任何 agent 今天就能用得起、讀得懂、帶得走的協議；一邊是企業願意為之付費的東西——託管、合規、多環境釋出、持續運維。定義歸你，執行的麻煩歸我們。

結語

那個九個月死掉的 AI 試點，死因從來不是模型不夠聰明，而是沒有一個能讓安全團隊簽字的業務語義層。行業裡最貴的公司用十年證明了這一層的價值；接下來的問題，是讓它不再是頭部企業的奢侈品。

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

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

五分鐘後，定義你的第一個業務物件，然後看著它同時變成資料表、API、管理介面，和一個 AI 可以安全呼叫的工具——每一次呼叫都帶著許可權，記著賬。