Hooks 與 Joule：企業代理取得控制平面
--- title: Hooks 與 Joule：企業代理取得控制平面 slug: hooks-and-joule-enterprise-agents-get-a-control-plane meta_title: 企業代理取得控制平面 meta_description: Microsoft 將 Hooks 加入 Copilot Studio，讓工作流程依事件觸發，而非依代理判斷；同時 SAP 將 Joule 推進為受治理的代理式工作層。 category: ai tags: Microsoft Copilot Studio,Hooks,SAP Joule,代理治理,確定性護欄,企業 AI,工作流程自動化,控制平面 ---
Microsoft 與 SAP 本月在幾天內相繼推出代理功能，而這兩項發布都承認了同一件事：讓模型決定業務工作流程是否啟動，是一種可靠性風險。
Microsoft 的 Hooks 能做什麼
Microsoft 正在預覽一項名為 Hooks 的 Copilot Studio 功能，它會在事件發生時自動執行代理式工作流程，而不只是在代理判斷應該執行時才執行。一個 hook 包含兩部分：代理生命週期發出的事件，以及事件發生時觸發的動作。當事件觸發時，Copilot Studio 會呼叫綁定的工作流程、傳入事件細節，並將工作流程的回應讀回對話中。
與工具之間的區別正是重點。工具是在代理認為相關時才執行。Hook 則會在事件每次發生時執行。
Microsoft 列出四種情境。在對話開始前查詢未結案支援案例，以便在工作階段開始時加入背景資訊。在工具執行前檢查它，若違反業務規則就封鎖該動作。對工具結果進行後處理，例如遮蔽敏感資料或寫入稽核記錄。處理失敗，方法是告訴代理重試、略過或停止。
這些注意事項與功能本身一樣具有資訊量。Hooks 會附加到特定代理，新增 hook 並不會改變其底層工作流程。Hook 失敗時不會讓代理停止：如果工作流程逾時或傳回無法讀取的內容，代理會繼續執行，就像 hook 什麼都沒傳回一樣。工作流程必須已發佈，否則不會執行。輸入應視為不可信，而編輯工作流程會影響所有使用它的 hook。
最後一點是隱而未顯的維護風險。一個工作流程可以服務多個代理，因此為某個使用案例所做的變更會波及到其他案例。存在於共享成品中的治理需要版本控管紀律，而這是大多數自動化團隊過去不必建立的能力。
這樣的設計也留下一個值得指出的缺口。一個無聲失敗的 hook，是一種什麼都控制不了的控制機制。Microsoft 對於驗證輸入的指引很重要，因為代理無法分辨真實答案與空答案，事後閱讀日誌的稽核人員也無法分辨。
SAP 在同一時期做了什麼
SAP 將其 Joule 助理擴展為其所稱的代理式工作層，並與 Autonomous Enterprise 計畫連結。該公司表示，其代理中樞目前監管約 150 家公司、超過 100,000 個代理；並有 50 多個領域助理協調 200 多個專門代理。SAP 還宣稱其 Autonomous Close Assistant 能將財務結帳從數週縮短至數天。
將兩者放在一起看，模式就很清楚。供應商正在把解讀與決策分開。模型讀取發票；程式碼決定是否付款。
時間點並非巧合。兩家供應商都在客戶部署中看到同樣的失敗模式：代理在示範中運作良好，卻在生產環境中、沒人注意的時刻做出錯誤判斷。修正方式就是把決策移出模型之外。
有一種治理框架能讓買方理解這項轉變。監管機關已經從詢問代理是否安全，轉為詢問當代理不安全時由誰負責。能指出確定性觸發條件、強制分支與稽核軌跡的供應商，就有答案。販售自主性的供應商則沒有。
為何規模密度迫使改變
當代理數量達到 100,000 個，瓶頸就不再是能力，而是監督。知道每個代理做了什麼、為什麼這麼做，以及是在誰的授權下做的，與讓代理能夠運作是截然不同的問題。
SAP 公布的數字讓這一點更具體：50 多個領域 Joule 助理協調 200 多個專門代理，遍布約 150 家公司，而其 Autonomous Close Assistant 將財務結帳從數週壓縮到數天。在這種密度下，非正式監督會崩解。沒有人會閱讀每一筆追蹤記錄，而真正重要的失敗，正是沒有人注意到的那些。
成本也有相同的形狀。一份實務工作者對 Copilot Studio 定價的分析估計，每個 Copilot Credit 約 0.01 美元，動作成本為 1 到 100 個 credits，而一個典型有依據的工作流程約落在 30 個 credits，也就是約 0.30 美元。這在量還小時看似微不足道：100,000 次執行大約就是 30,000 美元，而代理不會等人類點擊。嚴格的每月用量上限成為架構需求，而不只是管理員的偏好設定。
還有第三種壓力。調查顯示，開發者每週使用 AI 編碼代理的比例達到 90%，這表示這些工作流程底下的許多邏輯本身也是由機器起草，因而提高了測試關卡、程式碼審查與可重播日誌的價值。90% 這個數字來自一份 JetBrains 調查，而這也與另一項發現相符：更快的程式碼產生並不會自動帶來更快的交付。
三層模式
隨之而來的架構包含三個部分。意圖層讓模型解讀混亂的請求。確定性執行層執行小型、無狀態、可測試的函式。控制平面則強制執行預算、權限與稽核軌跡。
無伺服器邊緣工作者很適合中間層，因為它們每次請求成本低廉、彼此隔離，而且容易進行版本控管。這個模式並不新穎；它類似支付系統一直以來處理不可信輸入的方式。改變在於，業界現在預設就將它套用到代理，而不是等到發生事故後才做。
Microsoft 自己列出的使用案例完全符合這個模式。在工作階段開始時加入背景資訊、在工具執行前驗證、對結果進行後處理，以及處理失敗，全都是生命週期中的攔截點。Hooks 將這些形式化為確定性程式碼能看到代理即將做什麼的位置。
這種工作流程設計還有次要好處：它讓代理的行為在事後可被解釋。一個會記錄輸入與輸出的 hook，會產生代理本身永遠不會產生的稽核記錄。對於需要向監管機關交代的團隊而言，這份記錄就是描述預期行為與證明實際行為之間的差別。
有一個值得重複的警告：寫在單一供應商 studio 內的治理邏輯，是你租來的治理邏輯。重要的業務規則應該存在於你能夠搬移的程式碼中，因為控制層才是現今持久價值所在。
從競爭角度解讀，兩家供應商從不同起點得出相同結論。SAP 來自業務流程軟體，簽核流程是其原生詞彙。Microsoft 來自低程式碼 studio，觸發條件與條件式早已為人所熟悉。兩者都不再販售自主性。它們賣的都是拒絕的能力。
這個框架也改變了買方評估這些產品的方式。問題不再是哪個代理最聰明。而是哪個代理能被精確限制到足以無人看管地運行，以及哪個代理在做出非預期行為時會留下記錄。