Oracle 把代理程式編排搬進 ERP，治理的盤算就此改變

Oracle 推出了 Fusion Claw，並將其描述為第一個原生嵌入大型 ERP 平台內部的 AI 代理程式編排層。這個訴求範圍狹窄，卻很能說明問題。企業不必在另一個獨立主控台上執行代理程式，然後祈禱它們遵守公司政策；Fusion Claw 讓組織直接在 Fusion Applications 裡定義標準作業程序、風險門檻與決策權限——也就是商業邏輯原本所在之處。

重點就在這個「放在哪裡」。過去兩年，關於代理程式的討論都圍繞能力：模型能不能完成任務。這個月真正重要的產品發表，回答的是另一個問題：代理程式一旦跑起來，企業能不能盯得住它。

人人都在引用的那道落差

說明這股轉變的數字如今已為人熟知。約 85% 的大型企業正在試用 AI 代理程式，但只有約 5% 把代理式技術推進到正式生產環境，能規模化的試辦專案大約只有 11% 到 14%。Gartner 預估，到 2027 年將有超過 40% 的代理式 AI 專案被取消，並將原因歸咎於整合與協調問題，而非模型品質。IDC 則從另一個方向看，預期到 2028 年全球將有約 13 億個 AI 代理程式投入使用。

把這些數字放在一起看，瓶頸就轉移了。模型對很多工作來說已經夠好。真正缺的是管線：身分識別、權限、稽核軌跡，以及跨系統的協調——而這些系統當初根本不是設計來聽命於會自行行動的軟體。

治理本身成了產品類別

Oracle 只是其中一員，而這一個月冒出數量驚人的代理程式治理基礎設施。OpenAI 推出 Presence，這是一層營運層，用來部署具備明確職務範圍、有限知識存取權與已核准動作的語音與聊天代理程式，鎖定帳務客服、保險理賠與員工 IT 請求。Classie Supervise 也同時問世，讓企業能即時追蹤並記帳已在生產環境運作的代理程式。

Salesforce 與 AWS 宣布 Agentforce 360 for AWS，這個聯合平台的 Atlas Reasoning Engine 透過 Amazon Bedrock 執行 Anthropic 的 Claude 模型，而且值得注意的是，它會為代理程式的每一項決策產生不可竄改的稽核軌跡。CrowdStrike 名列早期採用者，理由除了安全性，還有採購單純——這是很企業式的說法，意思是買一樣東西勝過拼湊五樣。

其他方面，OneTrust 以 AI Control Plane 與 Governance Command Center 擴充其平台，並整合 ChatGPT、Claude、Copilot 與 Glean。Red Hat 一向主張，一旦代理程式能執行動作，模型層級的防護就不夠，並力推在身分、執行環境、網路與基礎架構上做到縱深防禦。Nvidia 推出與 100 多家合作夥伴共同打造的 Open Agent Safety Platform，設計目標是在毫秒之內隔離失控的代理程式。

這些產品各自從不同高度攻擊同一個問題。Oracle 的賭注是：稽核軌跡應該就是那筆交易本身，而不是另一份平行日誌。如果代理程式被核准的動作就是 ERP 內定義的規則，那麼它做的每一項決策，本來就已受到財務與法遵團隊用於其他所有事務的控制、權限與報表機制約束。

為什麼 ERP 是理所當然的落腳處

治理需求重的領域很適合作為生產級代理程式的第一個家，因為替代方案更糟。財務團隊無法為把發票處理交給一個存在於系統記錄之外的代理程式背書——它會做出自己無法解釋的動作，並在另一個工具裡產生一份日誌。把編排嵌入 ERP，意味著代理程式繼承了工作流程其他部分早已具備的角色型存取權、職責分工與稽核態勢。

這也是為什麼 Oracle 此舉會對競爭對手形成壓力。如果編排層成為核心平台的一項功能，那麼獨立代理程式閘道看起來就只是又一個要買、要保護、要對帳的額外元件。買方可能會發現，標準化在一個或兩個嵌入式編排層上，勝過再加一個外部控制平面。

一種懷疑論者的讀法

治理的框架站得住腳，而且在買方被那些從未上線的試辦專案燙過之後，這也是很好的行銷訴求。任何評估都值得帶著幾點警惕。稽核軌跡只有在有人去看的時候才有用，而代理程式決策的不可竄改日誌，並不等於能事先阻止錯誤決策的控制措施。把編排嵌入單一供應商的平台，也會造成新型態的鎖定，因為代理程式的歷程與政策現在都住在某個應用套件裡。而且那些專案取消的統計數字是兩面刃：一個讓代理程式更容易部署的平台，本身並不能解決協調問題，因為那個問題既存在於軟體，也同樣存在於流程的權責歸屬。

該怎麼運用這件事

這個月的產品發表所帶出的實務建議相當一致。從一個狹窄、高價值的流程開始，例如發票處理或存取權審查，把單一代理程式放進現有系統，並搭配嚴格的日誌與核准機制。觀察你的核心供應商如何回應 Fusion Claw。如果他們也推出自己的編排層，把標準化集中在其中一兩個，很可能比再加一個外部閘道更重要。

更大的轉變很容易被忽略，因為這些發表聽起來都很像。代理程式的「能力」已不再是頭條。現在的頭條是：代理程式能不能被賦予一份工作、一筆預算和一條牽繩，以及公司能不能在事後證明它究竟做了什麼。

整併的難題

從個別產品發表退一步看，會浮現一個結構性問題。如果每個主要平台都推出自己的編排層，買方最後會得到好幾層彼此重疊的控制平面，各有各的政策語言、各有各的稽核日誌，也各有各的描述代理程式權限的方式。這與治理本應提供的東西正好相反。標準組織與開源專案已在著手可攜式的代理程式身分與授權，但商業誘因卻往反方向走，因為專有的控制平面正是讓人不想離開的強大理由。

Oracle 決定把這一層嵌進 ERP，讓這件事變得具體。一家執行 Fusion Applications 的公司，有明顯理由使用內建的編排，也有同樣明顯的理由不信任另一層必須與之對帳的外部層。供應商懂這一點。問題是客戶會不會接受一套破碎的治理堆疊——每個套件各有一個控制平面——還是會要求能橫跨全部進行稽核的東西。

最可能的近期答案是混合模式。ERP 與 CRM 這類核心系統，會為它們原本就治理的流程掌握編排權，因為稽核軌跡該放在交易旁邊。其他一切，包括橫跨多個系統的代理程式，則會依賴一個試圖與所有系統對話的獨立層。評估平台的團隊應該同時為兩種情況做準備，並設計政策定義，以便市場整併時能重新表述。

賣方沒說出口的事

有兩項說法值得細究。第一是「有稽核軌跡就等於有問責」。一份記錄代理程式每項決策的日誌，在事故發生後很有價值，但它不等於能在事故發生前阻止它的控制措施。不可竄改的紀錄與預防性的護欄是兩種不同的產品，而這些發表往往把兩者混為一談。第二是「平台出貨後，治理問題就解決了」。這個月被引述的失敗案例，大多涉及權限設定錯誤、權責不清，以及流程本身沒有任何團隊能描述得足夠精確，讓代理程式遵循。軟體可以強制執行一項政策，但它無法決定企業真正想要的是哪一項政策。

對已經度過實驗階段的團隊來說，有用的做法是在採購前先把答案寫下來。代理程式可以碰哪個流程？在它的職權範圍內，最糟能做什麼？發生時誰會被通報？當它請求存取權時，如何辨識它的身分？照目前的建議，把單一代理程式部署在現有系統中並搭配嚴格日誌與核准，就等於一次測試這四個答案。平台會讓這個測試更容易執行，但不會替你執行。