AI Agent 成本別只算 Token：把人工覆核、錯誤修復與回復演練列入預算

AI Agent 的模型費用容易量化，但錯誤寫入、重複寄信、權限誤用與人工回復的代價往往不在帳單上。本文以企業作業與工程治理為出發點，建立完整成本模型、風險分級、回復機制與上線驗收方法，協助主管在自動化之前先計算「失敗的價格」。

專題編輯：Iris Hsieh｜AI 資安與治理編輯

成本盲點：Token 很便宜，錯誤有時很貴

假設一家企業建置 AI 客戶服務系統，每次模型呼叫成本看似很低，卻在某次回覆中把未經核准的折扣條件寄給數十位客戶。實際成本可能包括人工逐筆確認、重新通知、主管協調、申訴處理及商譽損失。這是假設情境，不表示某個特定產品曾發生事件。模型帳單只揭露運算成本，並不會替企業支付恢復業務秩序的費用。

OWASP 的 2025 版 LLM Applications Top 10 列出提示注入、敏感資訊洩露、不當輸出處理與過度代理權限等風險。對管理者而言，這不是要求禁止 Agent，而是確認可執行的動作、可存取的資料與可挽回的影響。當一個模型從回答問題升級為可以修改資料庫或執行付款，系統的風險曲線已經改變，不能只把它當成比較聰明的聊天工具。

NIST 的 AI Risk Management Framework 是自願性風險管理框架，可協助組織辨識、衡量及管理風險，並非強制法規或安全認證。以下成本表是本文提出的管理方法，不是 NIST 規定的會計公式。

必須分開計算四種成本

第一是推論與基礎設施費，包括 Token、模型請求、儲存、監控與連接器。第二是建置與維護，包括流程設計、提示詞調整、API 相容性、版本更新與資安管理。第三是品質成本，包括人工覆核、例外重跑與資料核對。第四是事故成本，包括錯誤通知、重複寫入、恢復資料、停機、客服、法律評估及聲譽損害。若只用第一種成本比較人工工作，就會系統性低估風險。

建議財務與技術團隊共同建立月度總成本：TCO＝固定平台成本＋每次執行成本×執行量＋人工檢查與維護＋預期失敗損失。所謂預期失敗損失可用「錯誤機率×單次可估損失」作為概念起點，但罕見且高衝擊的事件不能只看平均值；企業還應設定最大容忍損失與停止門檻。若損害無法合理估價，應直接納入高風險待審，而非填零。

為什麼代理系統比文字生成更需要邊界？

一份摘要寫錯，可能透過修改文件補正；一個會操作 CRM、檔案與郵件的 Agent 寫錯，可能同時影響多筆真實紀錄。當它串起「讀信、判斷、修改客戶狀態、寄出通知」四步時，前一步的錯誤會傳給下一步。流程越長、每步可寫入的系統越多，排查和復原的難度就越高。從這個角度看，可靠性不只由模型單次正確率決定，也與工具權限和系統設計有關。

若一條流程有五個彼此獨立、單步成功率皆為 99％的步驟，理論上全部一次成功約為 95.1％；這是用簡化獨立事件假設計算，實際系統常有相關錯誤，不能據此預估特定產品品質。重要啟示是：局部看似可靠，不保證整段流程可靠。任務還必須設計去重、驗證、重試與人工接手，才能避免局部失敗累積。

常見事故一：重試造成重複寫入

網路逾時後，Agent 不知道前一個請求是否已成功，便再次建立訂單、發出通知或寫入報表。對使用者來說，可能是同一筆訂單兩次扣款或同一封通知寄兩次。單純告訴模型「不要重複」並不能提供可靠保證。應在程式與資料層建立不可重複的操作鍵，例如由業務案件 ID、動作類型與版本組成唯一識別碼，讓重跑時能查詢既有結果而非重新執行。

另外，寫入成功與通知成功要分開記錄。假如資料庫已寫入，但通知失敗，重新執行時應只重送通知，不應重建整筆資料。這可用事件紀錄、狀態機與交易外盒等工程設計支援；對小型企業，至少需要明確欄位記錄每一步完成與否，讓人工能判斷安全的重跑起點。

常見事故二：模型有比任務需要更多的權限

為了方便測試，技術人員可能授予 Agent 管理員權限，使其能讀取所有客戶資料、刪除檔案或修改帳戶。這相當於把一份臨時工作交給擁有公司所有鑰匙的訪客。合適做法是最小權限：只為特定任務開啟必要 API、必要資料範圍和必要期間，寫入、刪除或付款等高風險動作應另設獨立核准機制。

安全邊界不能只靠 Prompt 約束。模型即使收到「絕不刪檔」的文字，也不能取代 API 的實際權限檢查。企業應在工具層阻止越權，在業務層核對允許範圍，在稽核層保留誰提出、誰核准、工具執行結果與回復紀錄。這樣即使模型出現誤判，影響也能限制在受控範圍內。

常見事故三：外部內容變成了指令

AI Agent 在搜尋網頁、讀取郵件或處理附件時，可能遇到看似普通資料、實際卻包含要求改變行為的惡意內容。這就是提示注入的一種常見情境。若系統沒有區分「不可信文件內容」和「系統真正授權指令」，便可能把外部文字當成新任務，進而讀取其他資料、外傳資訊或執行不該發生的操作。

防護不應依賴單一過濾器。應限制 Agent 可呼叫的工具、對輸出做資料型別與欄位驗證，對對外傳送與敏感寫入要求人工核准，並保留可追溯的工具呼叫紀錄。對連接第三方網站與郵件的工作流，更需將低信任來源與高權限動作隔離。當系統偵測到與原任務無關的權限要求，合理反應是停止並通報，而不是試著讓模型自行合理化。

事故前需要決定的五級動作風險

第一級是只讀查詢，不修改原始資料。第二級是草稿生成，資料只留在待審區。第三級是低風險寫入，例如建立可刪除的內部待辦。第四級是對外影響，例如寄出正式通知或修改客戶狀態。第五級是高不可逆或財務影響，例如付款、刪除關鍵紀錄、調整權限及公開敏感資料。企業可以依情境調整級別，但應事先明確記錄每一級的授權、紀錄、通知與回復方式。

不要用「模型準確率 99％」作為允許第五級動作的充分理由。即使千次只有十次失誤，若單次損害足以中斷營運，也應要求高強度管制。高風險流程可先採建議模式，只讓系統產生草稿與建議，由具權限的人完成關鍵動作；待實際長期紀錄支持再逐步開放。

人工介入應設在哪裡？

常見錯誤是把「人工審核」放在流程最後，等一切都執行完才讓主管看報告。真正的控制點應設在不可逆動作之前，例如正式寄出客戶承諾、修改合約條件、變更付款資訊或刪除資料。審核者應看得到來源、變更前後差異、系統信心限制與取消選項，而不是只按一個缺乏資訊的同意按鈕。

人工也會犯錯，因此審核介面應避免一次核准上千筆高風險動作。可採分批、抽樣、異常優先與雙人核准，依風險調整。若模型無法提供可判斷的來源，或審核者無法理解修改將造成什麼效果，正確處理是退回或暫停，不要逼迫人類成為只是形式上的蓋章者。

監控不只看錯誤率，還要看恢復成本

建議每週追蹤工作流成功率、人工介入率、重跑次數、重複寫入事件、單次事故平均修復時間、最高風險未遂事件，以及單件合格工作的總成本。系統工程常用平均恢復時間描述故障後恢復速度，但對 AI 流程還應加上資料修復與客戶通知所需工時，否則服務看似恢復，業務影響仍可能延續。

範例：一個流程每月執行 1,000 次，每次 API 成本 0.5 元，看似花 500 元；但若每次仍需 2 分鐘覆核，按每小時人力成本 400 元假設，就增加約 13,333 元。若再加上建置和維運，Token 僅是總成本的一小部分。這是示範算式，不是特定模型價目或真實專案成本，實際應按企業工資、工作複雜度及平台計費重算。

上線前必做的故障排練

至少演練工具逾時、模型回傳錯誤欄位、資料表被改欄、外部附件含惡意指令、權限到期、重複觸發，以及人工核准者不在。每次演練都需明確回答：系統是否停止？已完成哪些步驟？是否有錯誤對外輸出？應從哪個狀態恢復？誰能在十分鐘內找到紀錄？這裡的十分鐘是管理者可自行設定的演練目標，不是產業標準。

若測試期間使用真實資料，要先備份並採可回復的測試環境。更安全的方法是使用匿名或虛構資料，在不會影響客戶的環境中操作。對正式系統應保留停止開關、版本回退、權限撤銷和資料復原程序。沒有故障演練的「全自動」，只是尚未見到後果的自動化。

風險成本要和業務價值一起做決策

某些高頻、低風險的內部分類工作，即使節省時間不多，也可能值得自動化；但涉及發票、帳款、聘僱決策與個人權益的流程，即使省時巨大，也未必適合直接讓模型操作。應依執行次數、錯誤後果、可復原性、資料敏感度、品質可檢查性和人工責任共同比較。若自動化帶來的收益小於風險控制與復原的合理成本，改成 AI 輔助工作反而更有經濟價值。

投資評估表應保留三種方案：完全人工、AI 建議加人工確認、受控自動執行。比較同一業務量下的每件合格成本、完成時間、風險暴露及維護責任。做出「暫時不自動化」的結論，不代表轉型失敗；它可能是唯一符合現階段治理能力的選擇。

一份可以交給財務主管的事故成本明細

假設 AI 把十筆客戶資料寫錯位置，技術人員花兩小時定位問題、業務花三小時聯絡與確認、主管花一小時核准修復、系統暫停造成兩小時額外等待。真正應記帳的是相關人力、外包支援、延誤處理與可能的額外交易成本，而不是只有十次 API 呼叫費用。此例純粹示範分類；如果客戶遭受具體損害，還可能涉及更複雜的法律或商業評估，不能用任意固定金額概括。

請把事故歸為偵測、阻止擴散、資料修復、對外溝通和改善預防五類。每類記錄人員、處理時間、業務影響與可核對的費用。沒有資料的欄位標示未知，不要為了讓 TCO 看起來完整而填零。當管理者能看見一次錯誤可能吞噬多少平常節省的工時，才能合理決定自動化範圍。

用「可逆性」決定是否開放自動執行

同樣是一筆系統寫入，新增可撤銷的內部待辦與修改已寄出的客戶承諾，後果完全不同。可逆性評估應問：能否用原始資料回復？回復是否影響第三方？是否有備份與版本？需要誰核准？能否在事故擴大前停止？如果答案不明確，即使執行頻率很高，也應先採草稿與人工覆核模式。

回復機制應實際排練，而非在文件裡寫「出錯可聯絡工程師」。例如修改資料表前保留變更前值、每次動作帶有唯一交易鍵、保留何時何人核准的紀錄。這些設計讓事故發生時能復原到明確狀態；若不存在對應的技術能力，應避免直接進入高風險自動化。

每月「Agent 健康報告」應回答的問題

除了 API 花費，報告還應顯示執行量、有效完成量、人工覆核量、逾時、重試、撤銷、不可回復錯誤與資料品質問題。若系統在一千次執行中出現二十次錯誤，應先區分二十次是否集中在同一種輸入、是否都被安全攔截，以及是否造成真實業務影響，而非直接宣布成功率為 98％就通過。管理者也需要知道錯誤在何時被發現，以及是否有人在發現前已根據錯誤資料作出決定。

每月另設定一次權限審查：是否仍有離職員工的憑證、是否有多餘的管理員權限、是否擴增了未經核准的外部工具。這類檢查不一定帶來立刻可見的收入，卻能降低單次事故可能造成的損害範圍。

三種架構的真正選擇題

選項 A 是純文字建議，沒有正式系統寫入；適合高變動、低頻但需要人判斷的任務。選項 B 是規則式流程加 AI 分析，模型輸出先經格式驗證與必要人工核准；適合需要語意處理但操作規則相對清楚的場景。選項 C 才是具有多工具權限的 Agent，只有在任務步驟多變、收益足以抵銷維運與事故風險，而且組織已有監控和回復能力時才考慮。

企業採購時應要求供應商同時報出三個方案，並提供各自的資料路徑、權限邊界、測試方式及每月維護費。若對方只展示最自動化的版本，卻無法說明如何回滾與撤銷權限，代表方案尚未具備足夠的治理說明。

一頁可用的事件處置演練範本

事件名稱：「重複通知測試」。觸發方式：在隔離環境對同一案件重送相同請求。預期行為：主資料只寫入一次，外部通知最多送一次，第二次請求返回既有執行結果。異常條件：資料被改寫、寄出第二封信或系統無法確認前次狀態。立即處置：停用寫入權限、保存事件紀錄、人工核對收件人與資料、必要時回復備份。復原證據：重跑測試結果、唯一鍵紀錄與人工簽核。

這份演練可作為任何 Agent 專案的最小起點。真正的驗收標準不是模型是否說了正確的話，而是系統在不可靠網路、重複事件與異常指令下，仍然不會做出超過授權的動作。

延伸閱讀：停止與回復演練。本文著重成本歸屬與預算決策，演練步驟可搭配該文使用。

結語：有能力停止，才有資格自動執行

模型費用只是 AI 工作流的一張小帳單。真正決定系統是否划算的，是它在現實世界中能否保持資料正確、權限受控、錯誤可查、後果可修復。企業在追求 Agent 自主性之前，應先具備觀察、稽核、停止、回復與人工接管的能力。當失敗成本被明確寫入 TCO，投資決策才真正完整。

資料來源與閱讀限制

參考：OWASP 2025 版 LLM Applications Top 10；NIST AI Risk Management Framework。涉及假設事故、價目、工時與失敗機率均作教學用途，非特定產品事件或效能背書。封面為原創 AI 概念示意。

可查核原始來源與其限制

來源 OW01： OWASP GenAI Security Project 。適用限制：安全分類與風險說明，不是特定事故的真實指控。

來源 N01： NIST AI Risk Management Framework 。適用限制：自願性風險管理框架，非強制法規。

來源 T05： 天地人AI Agent既有入門文章 。適用限制：本篇聚焦事故成本及回復，不重述入門原理。