AI接手關鍵操作前，先把“決定”和“執行”拆開

一句“把生產環境的 payments-gateway 切到備用區域”，背後可能牽動算力、數據庫、緩存和流量。Intuit 最新披露的災備智能體 EWOK Agent，讓值班工程師用自然語言發起這類切換；但它最值得企業借鑑的，並不是“AI 會執行故障恢復”，而是一個剋制的分工：模型決定該做什麼，確定性系統決定怎樣執行。

Intuit 原有的災備編排系統已把受支持工作負載的恢復時間從數小時縮短至約20分鐘，但選擇恢復流程、確認資產是否就緒、處理變更凍結期的例外，仍依賴資深值班人員經驗。EWOK Agent 補的是“理解與協調”：它識別資產、列出可用流程、做就緒與策略檢查、創建變更記錄、發起執行，並持續回報各階段狀態；真正改變生產環境的動作仍由既有 API 和工作流完成。

把經驗寫成技能，但別把控制權交給提示詞

該案例把災備知識改寫為帶輸入輸出約束的技能：既有機器可讀的字段定義，也有逐步操作、停止條件和策略分支。變更凍結期並不被當成可由模型繞過的報錯；系統只會要求工程師提供事故編號或緊急理由，用戶拒絕則停止。失敗步驟也必須立即結束，不能讓模型自由嘗試替代路徑。

這是生產級智能體與聊天助手的分界。模型適合解釋模糊請求、在已批准選項中選擇、串聯結果並和人溝通；權限校驗、狀態改變、重試策略和審計記錄，應留在傳統、可測試的執行器中。模型不持有云端憑證，也不直接連接災備系統；執行器在請求範圍內取得身份，返回結構化成功或失敗狀態。每個關鍵動作因而沿用與人工操作相同的審批和審計鏈。

每向前放開一步，都應把可變的判斷留給模型，把不可逆的執行鎖進可驗證的系統。

星盒視角：給智能體一張“動作雙賬本”

星盒的組織層應先定義誰能請求、誰能批准、什麼情形必須停止；BOX 層保存經確認的技能版本、允許動作、例外分支和結果證據；智能體層只負責把請求映射到已授權能力。這裏需要兩本賬：一筆記錄模型為什麼提出動作，另一筆記錄執行器是否按規則完成、由誰批准。兩者不能混成一段自然語言總結。

DDABC 也因此多了一條生產線：Define 劃清判斷與執行接口；Deploy 讓智能體接入受限工具；Analyze 看哪些請求頻繁被拒絕或轉人工；Benchmark 比較成功率、等待時間與誤觸發；Calibrate 再更新技能和策略。企業真正要規模化的，不是“讓 AI 有更大權限”，而是讓它在更清楚接口內承擔更多協調工作。

當智能體開始觸及訂單、付款、發佈或設備，最重要的問題不再是“它聰不聰明”，而是：它提出行動後，誰用什麼規則把行動變成事實？把這道邊界設計好，AI 才能從演示進入關鍵工作，而不會把風險一起放大。

這套邊界對營銷、客服和運營同樣適用。比如內容智能體可以根據品牌知識提出發佈計劃，卻不應自行越過審批把內容推送到外部渠道；銷售智能體可以整理客戶信號、建議下一步，卻不應直接改寫合同條款或授予折扣。企業需要預先寫清哪些工具只是讀取，哪些可以創建草稿，哪些動作必須附帶審批號、工單號或負責人確認。這樣，人的判斷不是在每一步重複點擊，而是集中在真正改變業務承諾和風險敞口的節點。

來源：AWS《How Intuit built an agentic disaster recovery assistant with Amazon Bedrock》（2026-09-04）。文中恢復時間與運行時長均按 Intuit/AWS 案例表述，不外推為行業平均。