受治理工具層

在實踐中

這一層之所以存在，是因為把 Agent 接進系統最快的做法——把一個現成介面包成工具——包住的往往是為可信後端呼叫方設計的東西。這類介面預設授權已經在上游發生過，所以它自己什麼都不驗證。直接暴露給 Agent，它就以服務的觸及範圍去查詢，而不是提問那個人的；寫操作被歸到服務名下，而不是任何一個可追責的人身上；這些呼叫也壓根不進業務審計賬本。把裸介面包成工具，可能等於悄悄給 Agent 發了一張超級使用者通行證。

「受治理」具體必須落成四條性質。身份要傳遞下去：呼叫以發起它的那個人的身份執行，並且在一個 Agent 呼叫另一個 Agent 時繼續如此——越權往往不出現在第一跳，而是悄悄出現在第二跳。強制點要落在執行時而不是提示詞裡：越權呼叫應當被當場攔下，而不是被勸阻。審批要成為動作本身的屬性：有實質影響的操作，無論從哪個入口被夠到，都會停下來等一次簽字。所有呼叫要落進同一本賬：這樣「誰看了什麼」事後才有答案。還有第五條性質，它決定前四條能不能扛住規模——工具應當由業務物件的定義派生出來，因為手寫的身份檢查撐不過幾十個服務端和幾百個工具。

ObjectStack 把這一層從後設資料裡生成出來。一個動作只有在它自己的定義裡主動選擇開放，才會成為 Agent 可呼叫的工具——ai.exposed 標誌預設為 false，什麼都不寫的動作就是沒有開放；而已開放的動作，走的是與 REST 路由同一道權限閘門、同一個動作執行器，而不是另開一條並行通道。有一條誠實的邊界對任何實現都成立，包括這一個：受治理工具層約束的是影響半徑，不是判斷力。它能阻止 Agent 去做它無權做的事，卻攔不住一次「在權限之內但本不該做」的操作。那個缺口屬於評測、高風險動作的審批閾值和流程設計。