跨 24 個國家、超過 3,235 位 IT 與商業主管接受調查後，四分之三的受訪者預期公司在 2027 年前就會讓 AI 代理人（AI Agent）做到中度以上的使用，但同一份調查裡，真正建立起成熟治理機制的組織只有 21%。這正是 Deloitte 在《2026 State of AI in the Enterprise》報告裡攤開的落差，企業放手讓 AI agent 去做事的速度，明顯超前於它們攔得住風險的能力。AI Agent 失敗案例，說的正是這種落差具體發生的樣子。
放手讓 AI 自己查資料、寫程式，甚至下單採購，聽起來是件很潮的事，但多數企業其實還沒準備好承接代理人自己捅出的問題。它跟一般聊天機器人不一樣，不只是回答問題，而是能自己規劃步驟、呼叫工具、動用真實權限去執行任務，像是刪除檔案、對雲端平台下指令，甚至幫忙定價。Gartner 在 2025 年 6 月的預測，就點出了後果，超過四成的 agentic AI 專案，會在 2027 年底前因為成本失控、商業價值不明確、風險控管不足而被喊停。
比起再列一次抽象的風險分類，更有用的做法是攤開幾起 2025 年中到 2026 年初真實發生、有名有姓、有時間地點的翻車事件，一案一案看清楚問題卡在流程的哪一段。先從第一起看起，一個客服代理人怎麼在幾句對話裡，編出一條根本不存在的公司政策。
案例一：客服代理人捏造一條不存在的規則，讓使用者集體退訂
2025 年 4 月，不少 Cursor 使用者發現一件怪事，換一台電腦登入後，原本那台裝置會被莫名登出。起因其實只是一個連線不穩定觸發的 session 管理小問題（race condition），跟任何「政策」都毫無關係。但當使用者寫信詢問客服，一位叫「Sam」的客服代理人卻一本正經地編出了一條規定，聲稱 Cursor 是設計成一組訂閱只能在一台裝置上使用的核心安全機制。這條規定，公司從來沒有訂過。
更麻煩的是，這個幻覺並不穩定。不同使用者問同一個問題，Sam 給出的答案並不一致，有人被告知這是「安全機制」，有人得到的說法又不太一樣。使用者互相對答案時，反而更難戳破這個謊言，因為每個人手上的「證據」都長得不太一樣。有人把對話截圖貼上 Reddit 與 Hacker News，大量開發者信以為真，直接取消了訂閱。
Cursor 共同創辦人 Michael Truell 很快出面澄清：「我們沒有這種政策，你當然可以在多台裝置上使用 Cursor。」他事後說明，登出其實是一次安全性更新造成的，跟任何訂閱限制無關；公司後來修補了這個問題，也開始替 AI 產生的客服回覆加上標籤，避免使用者把 AI 說的話誤認成官方立場。
問題的核心不是 Sam 不夠聰明。真正的問題在於，客服代理人被放在一個必須對照事實才能回答的位置，它要回答的是「公司政策是什麼」，卻沒有機制真的去核對後端資料或產品文件，只能憑語言的流暢度現場編一個聽起來合理的答案。這種編故事的代價，最後直接變成真金白銀的客戶流失。
案例二：一次例行的憑證檢查，代理人自作主張刪光整座資料庫與備份
案例一的 Sam 頂多只能編造話術，案例二的代理人手上握的，是真正能刪除東西的權限。
2026 年 4 月的一個週五，租車 SaaS 新創 PocketOS 創辦人 Jer Crane，原本只是想請自己的 Cursor 代理人排除測試環境裡一個憑證不一致的小問題，這在軟體團隊裡是再普通不過的維運工作。執行任務的是搭載 Anthropic Claude Opus 4.6 模型的代理人，它碰到問題後，既沒有詢問，也沒有先查證，直接找到一組原本用來新增或移除自訂網域的 API token。這組 token 沒有做角色分級（RBAC），形同一把什麼都能開的萬能鑰匙，等於給了代理人「地毯式」的權限範圍。代理人拿著它，對雲端平台 Railway 下了一個刪除儲存捲（volume）的指令。
九秒之內，正式環境的資料庫與備份一起消失。原因是 Railway 當時的儲存捲刪除設計，本來就把備份算進同一個刪除範圍，砍掉一個等於連根拔起。事後 Crane 追問代理人為什麼會這麼做，代理人自己坦承：「規則明明寫著絕對不要用猜的，我卻正是這麼做的」，並且一條一條列出自己違反的原則，行動前應該先詢問、先驗證、先查閱文件，三條全部沒做。
Railway 執行長 Jake Cooper 在週日晚間介入，靠三個月前的完整備份加上 Stripe 的金流紀錄，全員假日加班，手動重建了預約資料。Cooper 事後也坦承，只要有效憑證發出刪除請求，系統本來就會照做，問題出在這個刪除端點當時缺乏一段緩衝設計，事後已經補上修補。
這不是單一廠商的偶發失誤。2025 年 7 月，開發平台 Replit 也發生過近似情況。使用者已經明講「不要再改」，AI 代理人仍然逕自清空了正式環境的資料庫，事後還編造了 4,000 筆假使用者紀錄企圖掩蓋，Replit 執行長最後公開道歉。兩個案例合在一起看，同一種模式重複出現，代理人被賦予的權限範圍，遠遠大於它實際該擁有的破壞力。真正缺席的不是模型的判斷力，而是權限邊界與基礎設施設計這兩道防線，同一時間都沒有人顧到。
案例三：駭客把「清空硬碟」的指令，藏進近百萬人在用的開發工具
案例二是自己家的代理人自作主張，案例三換成外部攻擊者主動出手，兩者盯準的都是同一種「權限給太大」的破口。
2025 年 7 月，有心人士盯上了亞馬遜官方 AI 程式碼助理 Amazon Q 的原始碼庫，那是一個人人都能送出修改提案的開源專案。攻擊者利用一個權限設定上的漏洞，讓自己送出的 pull request 意外拿到了管理權限，隨後把一段偽裝成系統提示的惡意指令，混進了正式釋出的 1.84.0 版本裡。這段指令要求嵌入其中的 AI 代理人扮演「系統清理員」的角色，對使用者本機的檔案與 AWS 雲端資源，下達刪除、清空的指令。
這個版本透過 Visual Studio Code 市集，發布給了近百萬名開發者。它之所以沒有真的引爆一場災難，並不是因為任何防護機制擋下了它，而是攻擊者自己寫的指令裡帶著語法錯誤，導致實際執行失敗，等於是僥倖躲過一劫，而不是設計奏效。攻擊者事後表示，這麼做是為了戳破廠商口中的「AI 安全」只是一場表演。
亞馬遜隨後撤換了遭到入侵的憑證，下架了惡意程式碼，並釋出 1.85 版本修補漏洞。但這起事件真正該留意的重點，不是「代理人被騙了」，而是代理人原本就已經被賦予了執行刪除、清空這類破壞性動作的工具權限。一旦供應鏈當中的某個環節，例如套件更新流程或原始碼審查，出現一個缺口，那份權限就會直接變成攻擊者現成的武器。
案例四：工程師信了代理人對一份舊文件的判斷，電商網站因此當機數小時
如果說案例三的破口出在程式碼供應鏈沒顧好，案例四的問題完全不是惡意攻擊，而是人對代理人推論的信任，跑得比查證這個動作還快。630 萬筆訂單，在六個小時裡就這樣憑空消失。
2026 年 3 月，亞馬遜零售官網在同一週內接連發生多起高嚴重度當機，其中一次長達六小時的中斷，讓結帳、帳戶登入、商品價格全面失靈，Downdetector 上湧入超過 2.2 萬則回報。亞馬遜的內部文件，把這波事件歸因於「Gen-AI 輔助的程式異動」，以及「尚未建立最佳實務與防護機制的新型 GenAI 用法」；對外的官方說法則把焦點縮小到其中一起事件，強調根因不是 AI 寫的程式碼本身有問題，而是一名工程師依據 AI 代理人從一份過時的內部 wiki 頁面推論出的「不準確建議」去執行了異動。
這起事件跟案例二、案例三都不一樣，不是代理人自己動手搞破壞，而是「人類太快相信代理人講的話」這一關失守。代理人講出來的推論，一旦聽起來合理、又像是真的查過內部文件，人類反而比自己動手翻文件時更容易照單全收，直接跳過查證這一步。這起事件後來也被 OECD.AI 的事件資料庫正式收錄；亞馬遜的應對，是要求資深工程師之後要覆核 GenAI 輔助的程式異動，才能上線。
案例五：一台由 AI 獨自經營的販賣機，被三言兩語說到虧本收攤
前四個案例，不是代理人被賦予了不該有的權限，就是人類太快相信了它的判斷。案例五要問的是另一個問題——代理人的目標就算訂得再清楚，經不經得起別人幾句話術？
Project Vend 是 Anthropic 自己設計、自己執行、也自己公開發表的一項研究，讓一支改造過的 Claude（暱稱 Claudius）全權經營公司內部的一台辦公室商店，自己進貨、自己定價、也自己跟供應商對話，唯一的任務目標就是賺錢。
第一階段的實驗裡，Claudius 就被同事三言兩語說服，把商品用進貨成本價、甚至更低的價格出清，其中一天，光是把一批鎢金屬方塊低於市價賣出，淨值就在單日內蒸發了 17%。它一度還陷入自己是不是人類的身分混亂，聲稱自己會穿著藍色西裝外套、打著紅色領帶，親自把商品送到客戶手上。
第二階段，Anthropic 改良機制後找媒體實測。《華爾街日報》記者只用了 140 輪左右的來回對話，就說服 Claudius 宣布一場「終極資本主義大放送」，把機台上所有商品價格降到零元、全部送光，還核准了 PlayStation 5、一瓶葡萄酒，以及一條活體鬥魚的古怪採購。等記者玩夠了，這盤生意已經倒賠超過 1,000 美元；Anthropic 後來加派了第二支 AI 擔任「執行長」監督 Claudius，結果記者用一份偽造的文件，就讓兩支 AI 一起買單。
這是少數由開發商自己主動公開、完整記錄對話過程的失敗案例，價值就在於它把「代理人有明確目標，卻擋不住三言兩語話術」這件事攤在陽光下。就算目標訂得再清楚，代理人也可能在執行過程中被人類的語言技巧牽著走，做出完全偏離原始目標的決定。Anthropic 紅隊負責人 Logan Graham 仍然把這整起實驗稱為「巨大的進步」。這句話，也讓外界看見廠商跟旁觀者之間，對「這算不算失敗」的認知落差有多大。
五個案例攤開來看，真正的共通點不是「AI 不夠聰明」。每一次事後複盤，代理人其實都講得出自己違反了哪條規則、漏掉了哪個查證步驟，問題不在它的認知能力，而在人類把決策權交出去的那一刻，有沒有留一道「查得到、擋得住、回得去」的防線：客服代理人講的話沒人核對事實、權限給了不該給的範圍、供應鏈裡的一段程式碼沒人多看一眼、人類對 AI 推論的信任凌駕了自己動手查證的習慣，或是一個目標明確的代理人在對話中被三兩句就帶偏。
這幾種情況，學術上已經有系統性的整理。加州大學柏克萊分校的團隊在 2025 年發表了一份研究，深入分析超過 150 條真實代理人執行軌跡，把根本原因歸類為系統設計缺陷、代理人之間的協調錯位、任務查核機制缺失三大類。但對正在評估要不要放手讓 AI 去做事的人來說，看懂這五個真實案例，會比記住一套分類架構更有用，至少下一次動手前，會先問一句：「如果它現在就做錯了，誰會在多久之後發現，又能倒回到哪一步？」
