微軟 Agent Control Specification：為什麼 Agent 審批會成為企業 AI 基礎設施

微軟發布了 Agent Control Specification，一個用於 AI Agent 執行時治理的開放、供應商中立規範。TechCrunch 也報導了這次發布，重點是讓開發、安全和合規團隊用更一致、更細粒度的方式控制 Agent 行為。

重點不是 Agent 又多了一個設定檔。

真正重要的是：企業 AI 正在進入 Agent 可以檢索資料、呼叫工具、執行工作流、跨系統行動的階段。一旦軟體開始代表人類行動，核心問題就不再只是「模型能做什麼」，而是 Agent 到底被允許做什麼，誰來批准它繼續做。

ACS 把治理放進執行時

很多組織現在仍然用 prompt、應用程式碼、框架 callback 和零散檢查來管理 Agent 行為。實驗階段可以，生產環境會很脆弱。

微軟把 ACS 定義為 controls layer，而不是 agent framework。它用一個可移植的 manifest，定義 policy 在 Agent 生命週期的哪些位置、什麼時機、以什麼方式被評估和執行，並且不綁定某個 Agent 框架、執行時或 policy engine。

ACS 給企業 Agent 控制提供了一份共同契約：

• 在使用者輸入進入模型前檢查；
• 在模型呼叫前檢查完整上下文；
• 在 runtime 根據模型輸出行動前檢查；
• 在工具呼叫執行前檢查；
• 在工具返回結果重新進入上下文前檢查；
• 在最終回覆離開 Agent 前檢查；
• 在啟動和關閉時檢查設定、日誌和審計條件。

每個節點上，policy 都可以給出 allow、warn、deny 或 escalate。

這是很關鍵的變化。Guardrails 不再只是寫在 prompt 裡的建議，而變成綁定在 Agent 行為上的執行時決策。

企業真正的新問題是審批

Agent 越有用，越會接觸真實業務系統：郵件、工單、CRM、程式碼倉庫、客戶資料、財務流程、內部文件、部署工具。

傳統權限控制可以回答「這個 credential 能不能呼叫這個資源」。但 Agent 時代的問題更複雜：考慮到這個 Agent 已經看過什麼、即將呼叫什麼工具、涉及哪些資料標籤、目前有沒有審批狀態，這個動作現在還安全嗎？

所以審批會變成基礎設施。

不是老式 OA 裡層層卡人的審批，而是更精確的控制面：

• 哪些動作可以自動執行；
• 哪些動作必須人類批准；
• 哪些敏感資料需要遮蔽；
• 哪些工具呼叫必須阻斷；
• 哪些證據必須留下來方便審計；
• 哪些失敗必須 fail closed。

Agent 管理正在成為產品層

ACS 也說明，Agent 管理不能被簡化成模型選擇。

更強的模型也許推理更好，但它不會自動生成 policy、審計、升級處理、證據收集和人類接管機制。這些是系統責任。

對企業來說，真正長期有價值的是 Agent 外圍那一層：身份、權限、工作空間上下文、工具邊界、日誌、審批門和改進閉環。Agent 會越來越像數位員工，而不是插件。

這和 Buda 的關係

Buda 的判斷也是一樣：Agent 應該在 human-led system 裡工作。

Buda 的 Space 定義組織邊界。Agent 在這個邊界裡使用檔案、會話、終端、瀏覽器、channels、artifacts 和任務。人類可以審查工作、調整指令、批准敏感動作，也可以在需要時接管。

ACS 說明整個生態也在走向同一個方向。Agent 越能幹，公司越需要顯式控制面：審批、policy、審計、升級處理和 human oversight。

企業 AI 的未來，不只是更多 autonomous agents。

而是更好管理的 agents。

你可以在 buda.im 開始構建 human-led agent workflows，也可以閱讀 Buda Agent Workspace 文件。