物件型別 / 動作型別

在實踐中

這一對詞來自 Palantir Foundry，並隨它擴散開來。物件型別就是一個類——客戶、工單、裝置——帶著型別化的屬性和指向其他物件型別的連結型別；人們預設「本體」就是由它構成的。動作型別是另一半：一個具名的寫操作，帶型別化引數、校驗規則和呼叫所需的權限，於是呼叫方永遠碰不到資料庫，只能執行本體暴露出來的那些操作。Foundry 多年來一直把寫操作收攏進受治理的 Action，並把這套架構對準了 LLM，這個設計值得它得到的所有認可。

通常缺席的正是動作那一半，而它的缺席有一個可辨認的失敗形態。只由物件型別搭起來的本體是一個讀模型，所以當 Agent 終於要「轉化這條線索」或「發起這筆退款」時，就會有人給它另寫一個工具——寫在業務邏輯旁邊，而不是從業務邏輯里長出來。這就打開了第二條寫路徑：同一個操作現在有兩條進入資料的通道，只有其中一條會校驗權限、跑校驗規則、要求審批、寫審計記錄。它不會僅僅停留在「不完整」，它會漂移——因為之後對真實路徑做的每一次改動，都出自一個根本不知道第二條路徑存在的人之手。

ObjectStack 兩半都有，只是名字更樸素；這個詞彙差異值得說明而不是含糊過去：它並不使用「物件型別」「動作型別」這兩個詞。物件是在一份型別化中繼資料檔案裡宣告的，帶上它的欄位、關係和共享模型；Action 與之並列宣告，帶型別化引數、可見性與停用判定、確認提示、呼叫所需的能力，以及一個執行目標。因為兩者都是執行環境直接讀取的中繼資料，每一個物件、每一個被暴露的 Action 同時就是一個受治理的 MCP 工具——於是人點的那個按鈕和 Agent 調的那個工具是同一份宣告，而不是兩份實現「在出事之前一直吻合」。