本體（Ontology）

在實踐中

本體即軟體。在 ObjectStack 裡，本體不是某個託管平臺內部的一層：它就是應用自己的定義——物件與欄位、關係、動作、權限、流程，以及 Agent 與工具定義——由執行時直接執行：資料庫、REST API、介面和 MCP 工具都從它派生，權限與審計在每一次呼叫上執行。這個詞帶著四條邊界。它是可執行的，不是知識表示意義上的本體：沒有繼承、沒有公理、沒有推理機——定義被校驗，然後被執行。它不是架在你現有系統之上的語義層：它本身就是系統，聯邦外部資料來源預設只讀，且尚在早期。檢視、儀表盤、應用和翻譯是本體的投影，不是本體的一部分。程式碼也沒有消失：它以鉤子、動作體、CEL 和受限 JSX 的形式搬進了執行時。

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

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

待議的問題是：這份檔案在誰手裡。在 ObjectStack 裡，這份定義就是你的業務本體：開放、帶版本、歸你所有，放在你自己的倉庫裡，既不是散落在框架各處的程式碼，也不是鎖在廠商系統裡的一張圖。一份你能讀、能 diff、能搬到另一個宿主上去的定義，和一份同樣優秀但住在廠商引擎裡、遷移等於重建的定義，是兩種不同的資產。並且，本體不會讓 AI Agent 變正確：把業務建模好依然是緩慢的、充滿分歧的人的工作，沒有哪種格式能替你走完。格式能決定的事情要窄得多——結果是否小到 Agent 能一次讀完、是否嚴格到能在編寫時點就把 Agent 的錯誤擋回去、是否可移植到能活過它最初被寫下的那個平臺。