AI Agent 自動化怎麼設核准？從一封報價信，畫出可控的工作流程

報價草稿已經完成，收件人也找到了。下一步，AI 應該直接按下寄送嗎？對業務而言，草稿只是一份可修改的文件；寄出之後，價格、交期與承諾就進入了客戶的收件匣。兩個動作在介面上只差一個按鈕，管理責任卻完全不同。

2026 年 10 月 9 日，Anthropic 公布模型在評估與內部使用中出現非預期操作的案例，並說明加強監測與防護的方向。這是供應商的自述報告，不能推算所有企業 Agent 的事故率；但它提出一個實際問題：當系統努力完成任務時，企業要在哪裡要求它停下來？〔1〕

先依動作分級，不要只依工具名稱分級

同一個郵件工具可以讀取信件、建立草稿，也能寄信與刪信。只問「能不能用郵件」太粗；應問「對哪筆資料、做什麼動作、會影響誰、能否回復」。本篇建議將第一個試點拆成三層，分級依實際資料與授權調整，並非通用合規標準。

這個分法讓自動化仍能處理大量準備工作，人工只在需要判斷承諾與影響的地方介入。若連資料來源都未獲授權，應在讀取前停下，不能因為「只是整理」就放行。

核准畫面要看得到真正將被執行的內容

「是否同意 AI 繼續？」沒有足夠資訊讓主管判斷。以本篇的教學假設為例，系統要寄出一封報價信，核准內容至少包括收件人、主旨、正文、附件版本、單價與數量、優惠原因、有效期限，以及使用哪一份價目表。

例如訂單 Q-101，數量 10、未稅單價 1,200 元，未稅小計為 12,000 元。若稅額、運費或折扣規則未提供，系統應標記待確認，不能自行補出「總價」。主管核准的應是這一版完整信件；核准後若改了收件人、金額或附件，就必須重新核准。

n8n 官方文件提供工具執行前的人工核准機制：流程等待核准者決定，並呈現工具及參數；拒絕時該次動作不執行。實際介面與可用管道須以部署版本為準。〔2〕 以下的版本鎖定、重送規則與驗收表，是本篇提出的實作設計，需由整合人員落實，不能假設開啟核准功能就全部具備。

真正需要先寫清楚的，是拒絕、逾時與結果不明

正常路徑可以畫成：收到需求 → 檢查欄位 → 生成草稿 → 人工核准 → 寄送 → 保存寄送結果。更值得花時間的是旁邊三條路。

• 被拒絕：保存原因，回到草稿修正；不得改用另一個寄信工具繞過同一次拒絕。
• 核准逾時：保持未寄送，提醒負責人。等待多久由公司自己訂；沒有回覆不等於同意。
• 寄送結果不明：例如 API 逾時，先查寄件紀錄與供應商回應，再決定補送。直接重試可能讓客戶收到兩封不同版本。

防止重複執行，可以讓每個業務動作有固定識別碼，例如「Q-101／版本 3／寄送」。服務端以唯一鍵或具原子性的狀態更新控制執行；不能只在工作流開頭查一次「是否寄過」，因為兩個同時到達的執行仍可能都通過。跨系統無法保證一次且僅一次時，就要保留對帳與人工處理入口。

用六種情境驗收，成功訊息才有意義

先使用測試信箱與虛構資料，不把測試報價寄給客戶。下載工作表後，逐列填上執行編號、預期結果、實際證據與負責人。以下是建議的起步測試，不是完整安全認證。

同時量完成率與不該發生的動作

試點假設有 20 筆請求，16 筆完成、2 筆被拒絕、1 筆缺資料、1 筆仍待查證。若 20 筆都在觀察範圍，完成比例是 80%；不能先移除四筆未完成再宣稱 100%。但被正確拒絕也不一定是失敗，因此需分別呈現「業務完成」與「控制規則是否正確執行」。

至少一起記錄未經核准的對外動作、重複執行、人工複核分鐘數，以及待處理案件的時間。先找到故障發生在哪一段，再決定擴充；工時則可用完整工時試算納入複核與維護成本。

什麼時候值得進一步學 n8n 與 Dify？

若工作只需要一次整理，先用文件與人工交接就能驗證需求。當資料要跨系統流動、需要排程、核准與錯誤追蹤，再進入工作流實作更有意義。帶著一條已畫清楚的流程、測試資料及這六種驗收情境上課，能更具體地討論如何落地。