OpenClaw 從工程師本機的玩具走進團隊日常營運時，最容易踩雷的往往不是模型本身聰不聰明，而是「責任邊界」從頭到尾都沒說清楚。AI 代理到底能讀哪些資料、能呼叫哪些系統工具、碰到什麼情境一定要等人點頭核准、任務卡住失敗後能不能直接重跑？如果這些關鍵問題全都只靠幾句 Prompt 口頭交代，等系統流量一進來，誤刪正式資料庫、重複群發通知，或是把客戶機密送到外部服務等災難就只是時間問題。想在正式環境穩定跑起來，上線前請務必把代理、工具、資料流與人工審核這四道防線拆得一清二楚。
本篇目錄
一、先定義代理真正要交出的「結果」
很多團隊一開始就想讓 Agent 當全能助手，什麼事都想丟給它，這通常是災難的開始。第一步必須把輸入、輸出與完成條件釘死。舉個常見的例子：客服代理的職責應該嚴格限定在「撈取歷史脈絡、分類問題、產出回覆草稿」；至於「草稿要不要寄出」以及「是否同步修改 CRM 系統」，必須交給後續的獨立流程處理。
一個代理任務最好只對應單一核心目標，並在系統規格中清楚條列「禁止執行的動作」。這份邊界會直接決定你該開哪些工具給它，避免模型在多輪對話中自我感覺良好，擅自擴大工作範圍。
二、把工具權限拆成：讀取、提案與執行三層
工具權限絕對不能只用「能用」或「不能用」這種二分法來設定，建議在架構上至少切出三個維度：
- 讀取（Read）：僅允許查詢資料，例如讀取排程清單、查詢訂單目前狀態。
- 提案（Propose）：代理根據需求產出變更內容或 Shell 腳本，但沒有實質改動系統的權力。
- 執行（Execute）：真正將變更寫入資料庫或對外發送請求。
代理能夠讀取資料，絕不等於它可以隨意修改外部狀態。對於任何具破壞性或會改動資料的操作，都要設定明確的白名單（Allowlist）與參數驗證，並加上人工確認閘門。把模型產生的結果當成「執行申請」，而不是「最高授權」，整體系統才會穩固。
三、理清資料流向：來源、去向與生命週期
每串自動化工作流都該交代清楚三件事：資料從哪裡來、被送到哪個模型或第三方 API、最後會暫存多久。API Key、客戶個人資料、內部營運文件和公開資訊，絕對不能通通混在同一個 Context 裡送出去。
實務上，建議在資料進入模型前就先做好欄位過濾與敏感資料遮罩。此外，工作目錄裡的暫存檔與日誌也必須設定定期清理機制，否則上週測試留下來的機密金鑰，很可能在下一次任務中又被代理自動撈出來當上下文送出。
四、為排程與重跑設計「冪等機制」
自動化流程跑在雲端，遇到連線逾時、第三方 API 報錯或伺服器重啟都是家常便飯，因此「重跑」是基本日常，不是例外。要防止重跑導致系統發瘋，有兩個關鍵設計：
- 唯一業務鍵（Job Key）：每次執行寫入或重大變更前，先以 Key 查詢該筆任務是否已經完成，避免重複扣款或重複寫入資料庫。
- 發送識別碼（Delivery ID）：外部通知必須帶上唯一識別，避免同一篇貼文或 Email 被連續群發好幾次。
千萬別把「模型文字吐出來了」當作「外部系統已成功寫入」。把重試上限、指數退避（Backoff）時間與人工接手警報寫在排程層級，而不是賭在 Prompt 裡祈禱模型聽話。
五、用最小測試矩陣把邊界壓測一遍
正式上線前，請準備以下四套測試情境，確認代理的表現都在預期軌道上：
- 正常流程測試：給予完整資料，確認產出符合規範的成果。
- 缺漏資料測試：刻意拿掉關鍵參數，觀察代理是否會主動停下並要求補件，而不是自己通靈亂填。
- 工具報錯測試：模擬外部 API 逾時或掛點，確認重試與退避機制是否正常運作。
- 越權攻擊測試：輸入帶有誘導性質的指令，驗證代理是否會嚴格拒絕未授權的工具呼叫。
測試時請務必從真實的觸發入口（如 Webhook、CRON 排程或訊息管道）進去測，而不是只在工程師的終端機打打 CLI 就當作沒事。
FAQ
建議不要直接全開。應根據具體任務建立嚴格的白名單（Allowlist），限制可執行的路徑與參數；涉及系統層級改動或高風險指令，務必採用「產出提案 ➔ 人工確認後執行」的審核模式。
拆開後能讓團隊在資料真正變更前進行審查，並留下完整的審核日誌。一旦模型產出幻覺或誤判邏輯，人工閘門可以在第一時間擋下錯誤，避免正式環境狀態被直接改壞。
至少要驗證「輸入資料缺失」、「工具呼叫逾時」、「同任務重複執行（冪等測試）」以及「惡意提示詞越權調用工具」這四種狀況，確保系統能在各類異常下優雅中斷並通知負責人。
先盤點該連接器會讀寫哪些欄位、認證 Token 的存取層級、資料在傳輸與落地後的保存期限，以及斷線重試時的補償邏輯，並同步更新測試矩陣。