為什麼多數企業的 AI Agent 停在 Demo?五個架構層面的真實死因

季度覆盤會上,某製造業客戶的數位長把一張圖投到牆上:他們去年導入的 AI Agent,Demo 驗收分數 92 分,正式上線第 90 天,真實日活使用率 6%。同一個 Agent,兩個月落差 86 個百分點。

這不是特例。我們接手的專案裡,「Demo 驚艷、上線冷場」幾乎是常態。企業 AI Agent 上不了線,絕大多數時候跟模型聰不聰明無關——GPT 或 Claude 在 Demo 和在生產環境用的是同一個。真正的死因藏在架構層,而且往往在採購當下就已經埋下。

以下是我們反覆踩到、也反覆替客戶拆解的五個架構死因。

死因一:資料層假設了一個不存在的乾淨世界

Demo 用的是精挑細選過的 20 份 PDF,格式統一、欄位齊全。上線後 Agent 要面對的是十五年來的掃描件、命名混亂的 Excel、藏在共用磁碟深處的過期版本。

RAG 系統的召回率在 Demo 資料上有 90%,換到真實知識庫掉到 50% 以下。使用者問三次錯兩次,第四次就不問了。資料層不是「之後再補」的工程,它決定了 Agent 的天花板。我們現在的做法是,任何 RAG 專案第一週先做資料體檢,把召回率基線量出來——數字難看,但至少誠實。

這是最隱蔽的一種死。Demo 裡 Agent 能查訂單、能總結報告,看起來很能幹。但它不能改狀態、不能派工單、不能回寫 ERP。

企業要的從來不是「會講話的搜尋引擎」,是能替人完成一段流程的同事。只讀不寫的 Agent,使用者用兩週就發現:每次還是得自己開系統手動操作,Agent 只是多一個步驟。整合的難點不在讀,在寫——寫要處理權限、交易一致性、回滾、稽核軌跡。這些在 Demo 上全部可以跳過,在生產線上一個都不能少。

Demo 環境裡通常只有一個 super admin,看得到所有資料。真實組織裡,業務看不到別區的客戶、基層看不到薪資、外包看不到內部財務。

當 Agent 沒有繼承使用者的權限邊界,它要嘛洩漏不該給的資料(資安直接擋下上線),要嘛為了安全把所有敏感內容一律遮蔽(於是它什麼有用的都答不出來)。權限不是加在最後的一層濾網,它必須從檢索階段就參與過濾。我們看過太多專案卡在資安複審,原因都一樣:權限模型是事後才想到的。

Demo 只問設計好的問題,答案當然對。上線後使用者會問邊界問題、模糊問題、根本沒答案的問題。沒有信心分數、沒有引用來源、沒有「我不確定」的退場機制,Agent 就會流暢地編一個答案出來。

在金融和醫療場景,一次有把握的錯誤就足以讓整個專案被叫停。可信度層要做的是:每個回答附上出處、低信心時主動說不知道、關鍵決策強制轉人工。這些機制會讓 Demo 看起來「沒那麼神」,卻是上線後唯一能讓人敢用的理由。

前四層都是技術,第五層是最常被整個跳過的:交付之後,誰負責讓 Agent 進到員工每天的動線裡?

系統上線 ≠ 有人使用。沒有嵌入既有工作流、沒有現場陪跑、沒有根據真實使用數據迭代,再好的 Agent 也只是多一個沒人開的分頁。開頭那個 6% 的案子,技術其實堪用,死在沒有人扛採用。

架構層	Demo 的假設	生產環境的現實	上不了線的症狀
資料層	乾淨、齊全、格式統一	髒亂、跨年、格式雜	召回率崩、答非所問
整合層	只讀就夠	必須能寫回系統	使用者還是手動操作
權限層	單一 admin 全看得到	逐角色的資料邊界	卡資安複審、無法上線
可信度層	問題都預設好	大量邊界與模糊問題	一本正經地胡說
採用層	交付即結案	需嵌入動線、陪跑迭代	上線但使用率個位數

回頭看,這五個死因沒有一個是「換更大的模型」能解的。它們全部是架構與交付的問題,而且都在採購合約簽下去的那一刻就決定了大半。

所以當你在評估一套企業 AI Agent 方案,值得問的不是「Demo 能不能跑」,而是:資料髒的時候召回率剩多少、能不能寫回我的 ERP、權限怎麼繼承、答不出來時它會不會承認、上線後誰負責讓人用。這五個問題問完,Demo 的分數就沒那麼重要了。

我們在 Tenten 的做法一直很土:工程師直接進客戶現場,把這五層一層一層打穿,量採用率而不是量 Demo 分數。因為我們相信,Demo 很美不算數,上線且真的有人在用,才算數。