本體（Ontology）

在實踐中

這個詞來自哲學，經由知識工程進入企業軟體，但真正幹活的那層含義很窄也很實用：本體為整個組織一次性命名型別（客戶、工單、裝置）、每個型別帶的屬性，以及型別之間的連線。這正是它和資料庫 schema 的分界。schema 描述的是某一個應用怎麼存自己的行；本體描述的是這家公司所說的「客戶」到底指什麼，並且要寫得讓十幾個系統、一個報表工具和一個模型都能解析出同一個答案。2026 年多數人想到這個詞時腦子裡是 Palantir Foundry——它的本體建模質量確實高；微軟 Fabric IQ 和 Google 的企業知識圖譜也在往同一層擠。

大部分本體工作都在風險剛開始的地方停住了。檢索級的本體是一個讀模型：它讓 Agent 把業務說清楚，卻對「Agent 要動手改點什麼」隻字未提。把它補完整的能力，是被宣告出來、且做權限校驗的寫操作——動作（Action）——連同掛在同一份定義上的權限與審計規則。Palantir 多年來一直把寫操作收攏進受治理的 Action，這份功勞應該給它；「這個設計對不對」從來不是待議的問題。

待議的問題是：這份檔案在誰手裡。在 ObjectStack 裡，本體不是某個託管平臺內部的一層，它就是應用自己的型別化後設資料——那份後設資料就是你的業務本體：一份開放、帶版本、由你擁有的定義，寫清你的物件、權限和流程，而不是散落在框架各處的程式碼。這正是 open business ontology（開放的業務本體）這個說法要承載的差別。一份你能讀、能 diff、能搬到另一個宿主上去的定義，和一份同樣優秀但住在廠商引擎裡、遷移等於重建的定義，是兩種不同的資產。

也要把限度說清楚：本體不會讓 AI Agent 變正確，把業務建模好依然是緩慢的、充滿分歧的人的工作，沒有哪種格式能替你走完。格式能決定的事情要窄得多——結果是否小到 Agent 能一次讀完、是否嚴格到能在編寫時點就把 Agent 的錯誤擋回去、是否可移植到能活過它最初被寫下的那個平臺。