AI Agent 的自動化能力再強，真正決定能不能放心放進正式環境的關鍵，從來不是「它能不能做完」，而是「一旦出事，誰來承擔外部系統的副作用」。
讀取內部資料、修改正式資料庫、對外寄信給客戶，或是刪除雲端主機資源，各個動作的風險完全不在同一個級別。如果所有任務都走同一條全自動路徑，維運團隊要不是被迫每筆 Log 盯場、疲於奔命，就是等外部系統收到錯誤指令後，才驚覺完全沒有攔截防線。要避免這種災難，最實務的做法就是替 OpenClaw 建立「4 層核准流程」，把風險清晰轉換成一道道執行閘門。
本篇目錄
任務進入 Agent 前，先回答兩個分級核心問題
在任務派發給 OpenClaw 之前，不必急著寫複雜的判斷邏輯，先在輸入階段問清楚兩件事：
- 這個動作會不會改變外部系統狀態，或對外發送內容？（例如：扣款、發 Email、呼叫外部 Webhook 或改動正式環境資料）
- 操作是否能被復原（Reversible）？出錯時影響範圍能不能被框住？
只要碰到公開發布、金錢支出、權限異動或不可逆的資料刪除，就絕對不能因為「在測試環境跑很順」而直接放行。把這兩題的答案直接寫入任務 Metadata（例如標註 side_effect、is_reversible、audience 與 task_owner），後續的路由閘門才能有一致的評判標準。
OpenClaw 4 層任務核准防禦機制
第一層：低風險任務（自動執行）
- 適用情境：純讀取、可重複執行、完全沒有外部寫入的作業。像是撈取伺服器指定 Log 檔、整理內部數據報表、預先產出草稿內容。
- 放行條件：輸入來源固定、輸出目的地嚴格隔離、執行失敗完全不改寫正式資料。
- 安全機制：跑完後仍要將任務 ID、產出路徑與狀態快照寫入稽核紀錄，方便維運人員抽查，不要把「沒報錯」直接當成「產出內容 100% 正確」。
第二層：通知後繼續（非同步留痕）
- 適用情境：會寫入「可復原的內部狀態」，但不值得每次都暫停流程等人工點擊確認。例如建立待審草稿、更新快取暫存表或寫入低風險佇列。
- 放行條件：系統先自動執行，隨後即時把結果推播到維運頻道或負責人的通訊軟體。
- 安全機制：通知內容必須包含變更前後對照（Diff 摘要）、影響目標、操作者、時間戳記與快速復原連結。如果通知送出後沒有人進一步確認，系統絕不能預設升級成更高權限的接續動作。
第三層：人工核准後才執行（Human-in-the-Loop）
- 適用情境：對外寄發信件、社群推文發布、修改正式環境 Config、觸發金流扣款或存取機敏個資。
- 放行條件：OpenClaw 只能準備並打包好資料負載（Payload），絕對不能直接對外呼叫 API 送出。
- 安全機制：審核面板要列出預計執行的動作、受影響對象、風險等級與失效倒數時間。更關鍵的是，核准權杖（Approval Token）必須綁定 Payload 的雜湊值（Hash），內容一旦有任何改動，Token 必須立即作廢並重新送審，杜絕「人核准 A 版本，系統背後送出 B 版本」的漏洞。
第四層：禁止執行並轉由人工接手（嚴格阻斷）
- 適用情境：不可逆的資料刪除指令、未授權的提權行為、缺少必填防護參數，或根本無法辨識負責人的任務。
- 放行條件：一律由防護層強制阻擋並中斷，派發 Ticket 給工程師人工接手。
- 安全機制：拒絕時不應只回覆單薄的「無法執行」，而是要完整記錄攔截原因與缺少的前提條件；同時必須鎖定重試機制，防止 Agent 透過不斷自動重試、換 Prompt 重新包裝，或換其他 Tool 試圖繞過安全閘門。
如何驗證這套流程真的防得住？
部署到正式環境前，請務必用以下 4 筆任務做一次端到端（E2E）實測演練：
- 純讀取任務：確認它是否自動跑完並寫入 Log。
- 草稿建立任務：確認它是否順暢執行，並及時推播帶有復原入口的通知。
- 對外發布任務：確認它是否乖乖停在第三層等待 Token；接著在背景修改 Payload 參數，確認原核准 Token 是否會自動失效。
- 不可逆刪除/越權任務：確認它是否被第四層直接擋下，並留下完整的攔截日誌。
如果演練只證明了 Agent「能把任務做完」，卻無法證明它在「不該做的時候會被擋下來」，這套人工核准機制就不算真正完工。
常見問題 (FAQ)
不一定。如果動作具備可逆性、有沙盒隔離保護，且影響範圍能被嚴格限縮（例如發送內部測試頻道的通知），可以透過明確的路由規則降級為第二層「通知後繼續」；但只要涉及對外公開發布、真實金流支出或不可逆的資料改動，一律必須進入第三層人工核准。
核准機制必須綁定 Payload 的雜湊值（Hash）。不管是執行的參數、發送目標或呼叫權限，只要內容一有變動，原本核發的 Token 就會自動失效，系統會立刻攔截並強制重新發起審核。
在系統的狀態機（State Machine）設計中，第四層的「拒絕」必須被設為終止狀態（Terminal State），並同步寫入阻斷原因與指派專人接手。除非由管理員手動解除並補齊必要防護條件，否則系統會直接拒絕同一指紋任務的再次觸發。