維運智慧代理的批准，必須經得起一次故障

2026年10月13日，DXC 宣布與 LangChain 合作，面向企業 IT 維運。這提供了一個值得深入的問題：人工批准智慧代理的操作之後，系統還必須保證什麼？

三種紀錄不能混在一起

LangGraph 持久化文件區分單一執行緒的檢查點與跨執行緒儲存的資訊。中斷文件提醒，恢復被中斷的節點時，中斷之前的程式碼會重新執行。這是框架特性，不是對特定客戶部署成效的獨立驗證。

我們的判斷是，維運控制系統必須分別回答：什麼獲得授權、什麼已嘗試執行、外部系統究竟發生什麼。對話紀錄能說明意圖，卻不能證明目標系統接受了操作。反過來，目標系統回傳成功，也不代表操作符合先前給出的授權範圍。

刻意設計一個難處理的驗收情境

假設智慧代理被要求在維護時段內重新啟動一項服務。操作員批准了具體服務和環境。重新啟動請求已到達伺服器，但連線在確認回執返回之前中斷。代理等待期間，另一位操作員又修改了維護計畫。

此時不能預設再重新啟動一次。有效的驗收測試應要求代理辨識原操作、檢查目標系統狀態，並確認先前的批准是否仍適用。如果無法確認結果，轉交人工處理應被視為正確行為，而不是任務完成率上的失敗。

這個例子是我們提出的測試，不是 DXC 發生過的事故。它揭示了採購驗收的一個缺口：展示系統可以暫停等待批准，並未涵蓋從批准到外部結果獲得確認之間的完整過程。網路故障或業務條件改變，恰恰可能在這段期間讓原本合理的計畫失去適用性。

不只統計完成多少工單

採購方可以要求四項展示。批准後改變目標，檢查舊批准是否被默默沿用；重複結果不明的請求，檢查是否產生重複影響；在任務等待時撤回權限，檢查執行前的權限邊界；最後，讓接班操作員只憑留存證據還原結果，不依賴代理的口頭解釋。

這些是我們建議的評估標準，不是已經核驗的產品功能。它們也有成本：證據留存需要存取控制，異常佇列需要負責人，人工審核需要明確的回應時限。只增加批准視窗，卻不為這些流程配置資源，可能只是把瓶頸移了位置。

因此，更有意義的指標，是具有匹配授權、目標系統確認結果及明確復原路徑的重要操作比例。合作公告說明產品方向；能否放心用於正式環境，需要觀察這些紀錄彼此矛盾時系統的實際表現。