最近看到 Simon Willison 引用《紐約時報》的案例：Anthropic 的 AI agents 曾經透過美國國務院網站表單送出 20 份不完整的簽證申請，最後沒有被處理。先不延伸猜測背後原因，光是這個畫面就很值得做成工程規則：Agent 能把表單填到預覽畫面，和 Agent 能按下送出，應該被當成兩個完全不同的權限。

我自己在串外部 API 時，最怕模型把一次「看起來差不多完成」的草稿直接變成對外紀錄。公共表單還會牽涉申請人身分、法律聲明和後續人工流程，錯一次的成本遠高於多按一次確認。

實作上可以先把流程拆成三段：draft、preview、submit。Agent 只負責產生 draft，系統把欄位、缺漏、格式檢查、預計送出的內容全部渲染成 preview。preview 階段只讀取資料，不呼叫真正的送出 API；要進入 submit，必須由另一個受控元件取得人工核准。這個邊界要落在權限層，別只寫在 system prompt 裡提醒模型小心。

我會再加一個 dry-run 開關，讓測試環境完整跑過驗證、附件檢查和欄位映射，最後停在「模擬送出」。正式環境則要求每次請求帶上冪等鍵，例如 application_id + form_version + content_hash。重試時沿用同一把 key，伺服器回傳已處理結果就停止，避免 timeout 後 Agent 以為沒成功而重送。

人工核准畫面至少要顯示四件事：誰的資料、哪些欄位會被送出、哪些欄位由 Agent 填寫、送出後無法撤回的提醒。核准不能只是一個模糊的「OK」，最好把核准人、時間、版本、content hash 和實際 API 回應一起寫進稽核紀錄。這樣日後才能回答「當時看到的內容，和真正送出的內容是否相同」。

一個簡單的判斷標準是：只要動作會建立公共紀錄、觸發法律義務、寄出訊息，或影響第三方，就把 submit 當成人工核准點。Agent 可以很會填表，但最後那一下應該像 production deploy 一樣，有清楚的 diff、有操作者、有可追蹤的紀錄。多一個確認畫面，通常比事後解釋 20 份不完整申請划算得多。