本文定位：常青實務指南。 近 24–72 小時沒有足夠的獨立新消息可支撐新聞稿，因此本文不把趨勢包裝成即時新聞；內容整理可驗證的公開框架與企業交付經驗，供 FDE 與導入團隊建立上線證據。
先定義「可上線」，再選模型
企業 AI Agent 的難點通常不在示範一次成功，而在於它能否穩定地完成真實工作：讀對資料、呼叫對系統、遇到例外停下來、留下可追溯紀錄，並由業務主管驗收結果。
Infor 在 2026 年 8 月 12 日的 FDE 文章，把交付描述為持續 scope、build、review、validate，而不是把原型丟給客戶。來源：Infor，2026-08-12 Gartner 也提醒，Agent 應依自主程度與存取範圍採取分級治理，而不是所有 Agent 套同一套規則。來源：Gartner，2026-05-26
因此，FDE 的第一份交付物不應是 prompt，而是「上線定義」：哪一個流程、哪一類使用者、哪些資料、哪些工具、什麼錯誤率與人工接管率，才算完成。
六道上線前驗收閘門
1. 流程閘門：從單一決策開始
把需求寫成可觀察的工作流，例如「收到客戶詢問後，從知識庫找出適用規格，產生回覆草稿，交由客服主管批准」。避免一開始就寫「讓 Agent 自動處理客服」。前者有輸入、步驟、權限與完成條件，後者無法驗收。
2. 資料與整合閘門：確認系統才是來源
列出 CRM、ERP、工單、雲端硬碟與知識庫各自的 system of record，標註擁有者、更新時間、欄位缺漏與衝突處理方式。Agent 不能用搜尋到的文件取代正式資料來源；若資料過期，應顯示不確定並轉人工，而不是猜一個答案。
3. 權限閘門：先 read-only，再逐步放權
把工具分成讀取、草稿、寫回與不可逆動作。第一階段可只開 read-only；第二階段讓 Agent 產生 draft；涉及報價、退款、合約、客戶通知或刪除資料時，必須由指定角色批准。IMDA 的 Agentic AI 治理框架同樣強調風險分級、人工責任與部署後監控。來源：新加坡 IMDA，2026-05-20
4. 評估閘門：測試軌跡，不只測答案
建立一組包含正常、邊界與惡意輸入的代表性案例，記錄答案正確率、工具呼叫正確率、越權率、人工接管率、延遲與成本。每次執行都要能回放：讀了什麼、呼叫什麼、哪一步失敗、為何允許或拒絕。這能把「看起來不錯」改成可重複的驗收證據。
5. 可靠性閘門：設計停止與復原
為外部 API 逾時、資料缺漏、重複執行與模型不確定性定義行為：停止、重試、轉人工或回滾。不要讓 Agent 在沒有上限的情況下重試，也不要把錯誤訊息吞掉。每一個自動動作都應有 owner、告警管道與復原手冊。
6. 交接閘門：把現場判斷變成可維護資產
FDE 離場前，交付的不只是程式碼，還包括流程圖、權限矩陣、評估案例、觀測儀表板、已知限制、變更紀錄與培訓。2026 年 8 月 22 日在杭州舉行的 FDEC 2026，也把「連接資料、系統、工作流、權限、評估與組織協作」列為企業 AI 最後一哩的核心問題。來源：OpenFDE，2026-08-22 活動頁（活動資訊於 2026-08-21 可查）
一張可直接使用的 FDE 驗收表
| 面向 | 上線前要有的證據 | 未通過時的處置 |
|---|---|---|
| 流程 | 一個明確輸入、輸出與 owner | 縮小範圍，禁止泛用聊天入口 |
| 資料 | 來源、版本、更新時間與衝突規則 | 改為顯示來源並轉人工 |
| 權限 | 工具白名單、角色與審批點 | 降為 read-only 或 draft-only |
| 評估 | 正常、邊界、拒答與越權案例 | 暫停發布，補齊測試集 |
| 觀測 | 執行軌跡、錯誤、成本與告警 | 不允許無監控自動寫回 |
| 交接 | runbook、回滾、owner 與培訓 | 延後擴大範圍 |
FDE 應如何把驗收連到商業結果
最後不要只報「模型準確率」。客服流程可看首次回覆時間、人工接管率與重開工單率；業務流程可看資料整理時間、CRM 欄位完整度與商機跟進準時率；財務流程可看例外件處理時間與人工覆核比例。每個指標都要有基準期、資料來源與負責人，否則很難證明 AI 真的改善了工作。
企業 AI Agent 的成熟度，不是它能否做更多事，而是團隊能否清楚說明它在什麼邊界內可靠、何時必須停下、出了問題誰能接手。這正是 FDE 把技術能力轉成可治理企業結果的價值。