要替 n8n AI Agent 人工審核加上關卡，重點不是讓每一次互動都等待確認，而是管制關鍵的工具呼叫，例如寄出客戶信、更新 CRM 紀錄、處理付款相關資料或刪除資料。
n8n 可要求 AI Agent 在執行特定工具前取得人工核准。當 Agent 呼叫已啟用 Human review 的工具時，工作流程會暫停並等待人工決定；核准後，工具會依 Agent 指定的輸入執行；拒絕後，該工具動作會取消，Agent 也會收到拒絕資訊。這讓團隊能把不可逆、對外或高影響的動作交由人員最後確認。
以下以「Agent 準備呼叫受管制的寄信工具，執行前必須核准」為例，說明如何規劃與設定。Human review 的核心操作可參考 n8n 官方的 Human-in-the-loop for AI tool calls 文件。
先釐清：你要審的是工具呼叫，還是一般流程簽核？
在建立流程前，先把「人工審核」放到正確的一層。不同需求看起來相似，實際上關卡位置不同。
| 審核對象 | 要解決的問題 | 適合放置的位置 |
|---|---|---|
| AI 文字輸出 | 內容是否符合品牌語氣、事實或客服規範？ | 在文字送給使用者或發布前，交由人員閱讀與改寫。 |
| AI Agent 工具呼叫 | Agent 是否真的可以執行「寄出、更新、刪除」這個動作？ | 在 AI Agent 連接的特定工具上啟用 Human review。 |
| 一般工作流程簽核 | 是否需要依表單、部門、案件狀態或業務規則決定下一步？ | 依流程需求設計等待與回覆機制。 |
本文聚焦第二種：AI Agent 的工具級人工審核。它的價值在於，受管制工具不會直接執行，而會先等待人員決定。
範例情境：受管制的寄信工具必須核准
假設 AI Agent 已連接一個寄信工具，而團隊規定所有對外寄送動作都必須經過人工確認。當 Agent 準備呼叫這個已啟用 Human review 的工具時，工作流程會先暫停，等待審核者核准或拒絕。
這個流程的重點不是把所有工具都鎖住，而是建立清楚的風險分級：
- 低風險讀取：例如查詢訂單狀態、讀取知識庫。可視內部風險政策決定是否需要關卡。
- 中風險寫入：例如更新 CRM 聯絡紀錄、建立待辦事項。應視資料影響範圍與可復原性評估。
- 高風險或對外動作：例如寄出信件、修改付款相關資料、刪除資料。通常適合設定人工確認。
n8n 允許將人工審核套用到 AI Agent 連接的全部工具，也可只套用到選定工具。因此，若你的目標是「讀取資料不必每次卡關，只有寄信或更新 CRM 才要批准」，做法是將 Human review 指定給那些高風險工具，而不是一律套用至全部工具。
n8n AI Agent 人工審核設定步驟
- 先建立 AI Agent 與工具清單。把 Agent 需要使用的工具接到 AI Agent 的 Tools connector，並先確認哪些工具會讀取、寫入、對外送出或刪除資料。
- 打開 Tools Panel。在 AI Agent 的 Tools connector 開啟 Tools Panel。
- 進入 Human review 區段。選擇要加入審核的工具範圍：全部工具，或只選取特定工具。
- 設定審核通道。在 Human review 區段選擇並完成審核通道的設定，讓核准請求送到負責決策的人員。
- 以高風險工具做測試。先用測試資料觸發一次受管制工具，確認工作流程是否暫停、審核請求是否送達，以及核准與拒絕是否都能回到預期流程。
- 再擴大到實際使用情境。將開發測試與正式環境分開，並針對實際部署的 n8n 版本完成驗證後再使用正式憑證與資料。
工具級人工審核的行為很明確：當 Agent 嘗試使用已受管制的工具，流程會等待人工決定。人員核准，工具才會以 Agent 提出的輸入執行；人員拒絕，該次工具動作會被取消。
審核通道怎麼選？把使用者互動與主管核准分開
使用者與 Agent 對話的地方，不一定要和主管收取核准請求的地方相同。n8n 官方示例即以 n8n Chat 作為主要互動通道、以 Slack 作為審核通道。這種分工能避免使用者對話與內部核准訊息混在一起。
官方文件目前列出的審核通道包括：
- Chat
- Slack
- Discord
- Telegram
- Microsoft Teams
- Gmail
- WhatsApp Business Cloud
- Google Chat
- Microsoft Outlook
選擇時，先回答三個問題：
- 誰要核准？是客服主管、資料管理者、財務人員，還是值班人員？
- 核准者平常在哪裡工作？優先放在既有、可即時處理的工作通道，而不是要求大家另開新工具。
- 這次動作需要多快回覆？對外寄信可能需要快速決策；高風險資料操作則可能需要較完整的人工確認。
若你想讓使用者在 Slack 對話、主管也在 Slack 收核准訊息，是否可拆分為不同目的地與權限範圍，應依實際通道設定與目標版本測試確認。較穩妥的設計原則是：把使用者對話、核准通知與內部告警分為清楚的責任邊界，避免核准資訊暴露給不該看到的人。
先實測核准請求實際呈現的資訊
人工關卡不能只停留在「有沒有核准按鈕」。審核者是否能據以完成決策，取決於你選擇的通道、實際設定與部署版本。因此，在使用前應實際觸發受管制工具，檢查審核請求實際呈現哪些工具資訊，以及核准與拒絕後的工作流程是否符合團隊要求。
文件明確描述的基本決策是檢視、核准或拒絕。不要預設每一種通道都能修改 Agent 提出的輸入，也不要在未經實測前假定不同通道會呈現相同內容。
若流程涉及客戶個資、付款金額或其他敏感內容，也應檢查所選通道實際顯示的資訊是否符合組織的資料處理與授權原則。
System prompt 範本：拒絕後不要自行繞過關卡
官方建議在 system prompt 說明：哪些工具需要核准、拒絕會造成什麼結果，以及 Agent 收到拒絕資訊後應如何回應。這一步很重要，因為人工審核是工具執行關卡，而 Agent 仍需要明確的行為指示。
以下範本可依你的工具名稱與業務規則調整：
你可以使用已連接的工具協助處理使用者需求。凡是會對外寄送訊息、更新正式客戶資料、處理付款相關資料或刪除資料的工具，都必須等待人工核准後才能執行。
若某次工具呼叫遭拒絕，不得改用其他工具達成同一個受拒絕的動作，也不得重複嘗試相同動作。請向使用者簡短說明此動作未獲核准，並提供下一步，例如請使用者補充資料、改為建立草稿，或交由人工處理。
在提出需要核准的動作前，先整理必要資訊，避免提出目的不明或包含不必要敏感資料的請求。
這段提示詞是行為規範，不應取代測試。請用「主管拒絕寄信」、「主管拒絕 CRM 更新」等案例驗證 Agent 的實際回應，確認它不會以不符合你政策的方式重試或改走其他路徑。
核准、拒絕與失敗後：把流程分成三條路
人工審核不只是加一個按鈕；使用前要把後續處置想清楚。至少規劃以下三種結果。
| 結果 | 工具動作 | 建議後續處理 |
|---|---|---|
| 核准 | 工具依 Agent 指定的輸入執行。 | 依團隊流程回覆結果，並處理必要的後續作業。 |
| 拒絕 | 該工具動作取消，Agent 收到拒絕資訊。 | 要求 Agent 停止重試，改為告知使用者未獲核准、請求補件，或轉交人工處理。 |
| 執行異常或結果不符預期 | 不應把異常視為已完成。 | 通知負責人，並由人員確認是否需要修正資料或重新處理。 |
尤其是拒絕流程，請避免只設計「拒絕後結束」。使用者需要知道下一步能做什麼；值班或業務人員也需要知道哪些案件要人工接手。
何時應評估 Wait node 與自訂簽核流程？
原生 Human review 的官方文件直接界定的是 AI Agent 工具呼叫審核。若你的情境已經不只是單次工具核准，而是需要配合企業自身的案件狀態、表單、責任分工或外部系統，應先把簽核規則拆成明確需求，再選擇合適的流程設計。
例如，你可能需要規劃：
- 案件如何帶著唯一編號進入簽核流程。
- 核准者要查看哪些補充資料，以及這些資料放在哪個受控系統。
- 拒絕後要退回補件、交辦人工，還是產生新案件。
- 決策需要由哪些內部規則與保存政策管理。
n8n 的 Gmail 文件將 Send and Wait for Approval 定位為適合簡單簽核；對較複雜的簽核程序，官方建議考慮使用 Wait node。這是評估更複雜流程的一個明確方向，但不應把它解讀為所有 AI Agent 審核情境都只能使用同一種架構。你仍應依實際流程、風險與內部治理要求進行設計與測試。
上線前安全清單：人工核准不是唯一防線
人工核准可讓受管制的工具呼叫先等待人員決定，但它不是憑證權限、資料保護與流程驗證的替代品。上線前建議逐項檢查：
- 工具最小權限：讓每個第三方憑證只取得完成該工作所需的權限範圍。
- 輸入與參數驗證：在會造成寫入、刪除或對外傳送的路徑上，確認資料格式、必要欄位與業務規則。
- 敏感資料最小揭露：核准通知、錯誤通知與使用者訊息避免包含不必要的個資與機密內容。
- Webhook 保護：檢視所有對外入口是否有適當保護，避免未授權請求直接觸發工作流程。
- 開發與正式環境分離：先使用測試資料驗證核准、拒絕與異常三條路徑，再使用正式憑證與資料。
- 執行與決策治理：依組織要求規劃要保存哪些案件資訊、由誰檢視，以及發生爭議時如何追查。
- 部署版本實測：在預定使用的版本與通道中完成端對端測試，不要假設所有環境都有相同行為。
若你是自行部署 n8n，可將 Security audit 納入例行檢查。官方文件說明，它可透過 CLI、POST /audit 或 n8n node 執行，並報告未受保護的 webhook、遺漏安全設定、過期執行個體與風險節點等項目。
結論：把人的判斷放在「會改變世界」的工具前
n8n AI Agent 人工審核最適合處理這類問題：AI Agent 已準備呼叫工具，但真正執行寄信、更新資料或刪除內容前，必須有人確認是否該做。
先把工具依風險分級，再只替高風險工具啟用 Human review；接著分開設計使用者互動、主管核准與異常告警通道，並在 system prompt 寫清楚拒絕後的行為。這樣的流程不會把所有自動化變成手動作業，卻能在關鍵動作前留下真正有意義的人為判斷。
