企業內部 AI Agent 導入的 4 個失敗模式
2026-03-15 · Vincent Liaw · 9 分鐘閱讀
整理我們協助客戶與自家 admin 上線後觀察到的 4 個最常見失敗模式：Chat Bubble 症候群、Scope 失控、沒有 Evaluation 基準、沒有 Ops Owner。附反模式與實務作法。
TL;DR
- Gartner 統計 70% 的企業 AI 專案走不到 production。我們看下來，死因高度集中在 4 個地方。
- Chat Bubble 症候群：買了漂亮 UI，但 Agent 接不到 CRM / ERP / 資料庫，只能講廢話。
- Scope 失控：一開始就想做「萬能 AI」，accuracy 被 edge case 拖垮，半年後全面退貨。
- 沒有 Evaluation 基準：沒有 golden dataset、沒有 eval pipeline，改 prompt 像在賭運氣。
- 沒有 Ops Owner：把 AI Agent 當一次性交付物，6 個月後 model deprecated、prompt stale，沒人修。
- 共通點：用軟體專案思維做 AI Agent 導入。AI Agent 不是模組，是活生生的流程。
先講結論：4 個失敗模式 at-a-glance
| # | 失敗模式 | 核心症狀 | 反模式 |
|---|---|---|---|
| 1 | Chat Bubble 症候群 | UI 漂亮，接不到真實系統 | AI Agent first-class citizen，從架構層介入 |
| 2 | Scope 失控 | 「什麼都能做」，每個 edge case 都在扣分 | 窄而深，accuracy > 95% 才擴大 |
| 3 | 沒有 Evaluation 基準 | 改 prompt 靠直覺，退步了也不知道 | Golden dataset + 週期 eval + error taxonomy |
| 4 | 沒有 Ops Owner | 交付完沒人管，半年後爛掉 | 上線前就定 Ops owner、月維運預算、retrain trigger |
我們自己的 admin 也是這樣一步一步從錯中走出來的，不是旁觀評論。
失敗模式 1：Chat Bubble 症候群（只做 UI 層，沒接系統）
怎麼發生的
採購流程的第一關是 demo。Demo 最好看的永遠是 UI——對話視窗、打字動畫、氣泡特效。技術整合評估被排到 POC 之後，等到要接公司的 CRM、ERP、內部資料庫時，才發現供應商只提供一個 embed 用的 <script> 標籤，能讀的東西僅限於 FAQ 文件跟公開網頁。
於是企業買回去的，是一個掛在官網右下角、只會回答「請洽客服」的氣泡。
實際後果
- 業務問「我們上個月華南區訂單前五大是誰？」——Agent 不知道，因為它沒有 CRM 權限。
- 財務問「這筆請款有沒有超出預算？」——Agent 不知道，因為它沒有 ERP 連線。
- 三個月後業務主管在會議上說一句：「這個 AI 沒用。」專案靜靜下架。
這種失敗其實最可惜，因為錢花了，期待也拉高了，但從第一天就注定做不出價值。
反模式：AI Agent 必須從架構第一天就是 first-class citizen
能讀真實資料、呼叫內部 API、執行實際工作流，不是「之後再說」，而是 day one 就要設計。
我們自家 admin 的作法是把四個工作流各自包成一個 MCP server：PM / Dev / CMS / Biz，總計約 150+ 個 tools。Claude 和 Cursor 透過 MCP 協議直接操作這些伺服器，讀 Firestore、寫 journal entry、開 PR、排 milestone。AI Agent 看到的資料結構跟工程師看到的一模一樣，不是一層抽象過的 FAQ。
這不是我們發明的，Anthropic 在 2024 年開源 MCP 協議的初衷就是解這個問題——讓 Agent 能連上真實系統，而不是被困在對話框裡。詳細可以看 MCP vs 傳統 API：企業 AI 整合路徑比較。
失敗模式 2：Scope 失控（什麼都讓 AI 做）
怎麼發生的
內部會議通常是這樣開的：「我們要做一個 AI 客服，能回答產品問題、處理退貨、查訂單狀態、安排維修、推薦商品、做 upsell、還要能講英日韓三語。」
老闆低估了 AI 的能力邊界，工程師礙於組織動態不敢說不。於是專案規格越寫越長，第一版上線時在每個子流程都只做到 70-80% 準確率。
實際後果
這是 Gartner 那個著名的「70% AI 專案走不到 production」統計背後的主要死因之一。MIT Sloan Management Review 跟 BCG 2023 年合作的調查裡也指出，scope 過度擴張是 AI 專案失敗的前三大原因。
具體發生的事情是這樣：每個 edge case 在內部 demo 都被抓出來放大檢視，主管問「為什麼會錯？」工程師說「我們調一下 prompt」，調完這個壞了那個，三個月後整體準確度低於 80%，業務端完全不敢用。系統活著，但沒有使用者。
反模式：先做一個窄但深的流程
選一個高頻、低風險、結果明確的流程——例如「財務請款單的初步審核」或「客服對話的分類與路由」——把 accuracy 做到 95% 以上再擴大。
我們自家 admin 一開始只做一件事：每天早上 8 點，PM Agent 會讀昨天所有 commit、backlog 變化、milestone 進度，生一份 briefing memo 推到 Slack。就這樣。沒有萬能助理，沒有對話框。把這個流程穩到 99% 可用以後，才加上記帳 Agent、然後才是 scope guard、然後才是 Epic 自動拆解。現在 4 個 MCP server 全部併起來跑了超過 6 個月，中間出錯的次數一隻手數得完。
如果你正在被內部要求「做一個萬能 AI」，建議先看 台灣企業 AI Agent 導入指南 裡關於 scope 切片的段落。
失敗模式 3：沒有 Evaluation 基準（看不到進步）
怎麼發生的
傳統軟體測試有明確的 input/output：給定 a=1, b=2，add(a, b) 必須回 3。LLM 測試不是這樣——同一個 prompt 給 10 次，可能 10 個措辭不同的答案，其中 8 個對、1 個部分對、1 個離題。
很多團隊第一次做 AI Agent 時不知道怎麼開始做 eval，就乾脆先不做，想說「先上線看看」。
實際後果
上線後，PM 提出一個 prompt 修改建議，工程師改了，好像有變好，也好像沒有。三週後發現某個類型的 query 準確度掉了，想 rollback，結果又沒人記得到底改了哪幾行。整個團隊陷入一種「不敢動它」的狀態——系統還活著，但停止進化。
這比完全沒上線還可怕，因為沉沒成本高、預算已編、沒有退路。
反模式：每個 Agent 都要有 golden dataset + 週期 eval pipeline + error taxonomy
- Golden dataset：20-50 個代表性的 input/expected output 對，涵蓋正常 case、edge case、adversarial case。
- Eval pipeline：每次改 prompt 或換 model 版本，自動跑一次全集，產生一個分數。
- Error taxonomy：把失敗分類——是 hallucination？是格式錯？是 tool 呼叫錯？——而不是籠統說「這次不太好」。
我們自家 4 個 agent 都有自己的 golden dataset。例如 morning briefing agent 有 30 個 golden examples（不同類型的一天：正常工作日、週一、pre-release 前、milestone slip 當週），每週自動跑一次，分數低於 baseline 會在 Slack 出 alert。
這套東西的初始成本確實高——大約佔整體 agent 開發時間的 20-25%——但它是你之後六個月敢不敢動這個系統的分界線。
關於這部分的工程投入估算，可以參考 AI Agent 開發成本全解析。
失敗模式 4：沒有 Ops Owner（沒人承接上線後的生命週期）
怎麼發生的
技術團隊把 Agent 做好，交接給業務單位。業務主管很高興，但他不懂 prompt engineering、不懂 model version、不懂 token cost，也不知道什麼叫 embedding drift。技術團隊覺得「交付完成」，下一個專案已經排進來了。
問題的積木從這裡開始疊：
- Anthropic 在某個週五 release 了新的 model，舊的三個月後 deprecate。沒人注意。
- 供應商 SDK 升版，破壞性變更。沒人升。
- 使用者輸入的型態逐漸偏離當初設計的 persona（例如原本是給門市店員用，後來變成總部主管也在用）。Prompt 沒跟著調。
- Log 堆到 100GB，沒人看。
實際後果
六個月後，系統爛掉。不是某一天突然壞，是慢慢 degrade，到某個臨界點使用者直接放棄。這時如果問當初的 PM「現在系統狀態如何」，他只會說「我以為還在運作」。
這是把活系統當成交付物的代價。
反模式：上線前就定義 Ops owner、月維運預算、eval schedule、retrain trigger
具體包含：
- 指定 Ops owner：一個有 admin 權限、會 prompt engineering、看得懂 eval report 的人。可以是內部工程師，可以是外部顧問，但必須有名字。
- 月維運預算：涵蓋 model cost、eval 成本、prompt 迭代工時、SDK 升級工時。
- Eval schedule：週度跑自動 eval，月度人工抽樣審查。
- Retrain / re-prompt trigger：當 eval score 跌破某個 threshold、或新增 use case 超過 N 個時，啟動迭代。
我們自家 admin 的 MCP server 每個月我自己會花大約半天看 log、跑 eval、更新幾個 prompt。BotsUP 給客戶的月維運方案從 NT$40,000 起，包含的就是這一塊 AI Agent lifecycle ops——不是賣佛心，是因為我們自己知道這塊不做會死，而這正是大多數企業最容易漏掉的預算項目。
Meta-lesson：AI Agent 不是軟體模組，是活生生的流程
把這 4 個失敗模式放在一起看，共通點很清楚：它們都是用軟體專案思維做 AI Agent 導入的結果。
傳統軟體專案的世界觀是：需求 → 設計 → 開發 → 測試 → 交付 → 結案。交付之後系統的行為在統計上不會變，除非有人改 code。
AI Agent 不是這樣。它的行為會因為：
- Model 版本更新而變
- 使用者輸入分布偏移而變
- 外部系統 schema 變動而變
- 同一個 prompt 在不同 context 下的表現而變
所以 Chat Bubble 症候群的本質是「把 AI 當成 UI 元件買回來」；Scope 失控是「把 AI 當成一次性功能規格寫」；沒有 Eval 是「用軟體測試思維看 LLM」；沒有 Ops Owner 是「用專案結案思維處理活系統」。
四個問題，同一個病根。
解法不是買更好的 AI 平台，是換一套做事的方法論——把 Agent 當成一個會長大、會老化、需要長期照顧的系統來對待。
FAQ
Q1：我們公司沒 AI 經驗，要從哪裡開始才不掉進這些坑？
從一個高頻、低風險、結果明確的單一流程開始。例如：每天早上自動生一份昨日營運摘要推到 Slack。這種專案有三個好處：(1) 範圍小，失敗成本低；(2) 使用者是內部同仁，feedback loop 快；(3) 做完之後團隊有了做 eval、管 prompt、處理 ops 的基本功，再擴大比較有本錢。
Q2：是否該先做 POC 還是直接 production？
POC 只做到驗證「技術可行」即可，大約 2-3 週。不要 POC 做 3 個月——那已經是一個沒有維運支援的產品了。POC 後直接規劃 production 版的 eval、ops、budget，不要中間塞一個「進階版 POC」。
Q3：Chat bubble 真的這麼糟嗎？為什麼還有人做？
Chat bubble 形式本身沒錯，錯在背後沒接系統。如果 bubble 背後是一個能連 CRM、能查 ERP、能執行工作流的 Agent，那它是個好東西。如果背後只能讀 FAQ，那不管 UI 多漂亮都是錯的。會有人做，是因為它是最容易賣的 demo。
Q4：我們沒數據科學家，怎麼做 eval？
Eval 不需要數據科學家。你需要的是：(1) 一個懂業務的人寫 20-50 個 golden examples；(2) 一段簡單的 Python script 跑 diff；(3) 一個 Slack channel 收週度報告。我們自家 admin 的 eval pipeline 加起來不到 400 行 code。難的不是技術，是紀律。
Q5：月維運成本大概多少合理？
一個單一 Agent 流程（例如財務記帳 Agent）的月維運合理範圍是 NT$30,000–60,000，包含 model cost、eval 跑批、prompt 迭代、log 審查、SDK 升級。如果是多 Agent 組合（像我們 admin 這種 4 個 MCP server 的規模），NT$80,000–150,000 比較合理。低於 NT$20,000 的方案要小心是不是只包 model cost、沒包人工。
延伸閱讀
參考資料
- Gartner, "Why Projects Fail: 2024 AI Implementation Survey"——70% 的企業 AI 專案無法走到 production 階段。
- Anthropic, "Building Effective Agents" / "Claude best practices for production"——關於 Agent 架構、tool use、eval 的官方建議。
- OpenAI, "Enterprise AI Adoption Playbook" (2024)——企業導入的常見模式與反模式。
- MIT Sloan Management Review & Boston Consulting Group, "Expanding AI's Impact with Organizational Learning" (2023)——scope 擴張與組織學習能力的關係。
- Harvard Business Review, "Why Most Companies Fail at AI and What to Do About It" (2024)——關於 AI ops 與人才配置的失敗案例研究。
BotsUP 自家 admin 就是 AI-native 系統：4 個 MCP server（PM / Dev / CMS / Biz）+ AI Agent 第一公民架構，production 運行超過 6 個月。想在你公司做一套？30 分鐘需求診斷。
