為什麼企業 AI Agent 卡在 PoC？從 demo 到 production 的六道鴻溝

從 PoC 到 Production：企業 AI Agent 系統工程第 1 / 12 篇

本篇是「從 PoC 到 Production：企業 AI Agent 系統工程」系列的第 1 / 12 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

這是「從 PoC 到 Production：企業 AI Agent 系統工程」系列第 1 篇（共 12 篇）。這個系列不教你怎麼呼叫 LLM API——那部分網路上已經夠多了。它要補的，是 demo 到 production 之間那段最難、最少人寫、卻決定一個 AI agent 專案會不會死在 PoC 的工程。

兩天的 demo，六個月的卡關

我見過太多這樣的場景：一個工程師花兩天，用 Claude 或 GPT 串了一個 agent，會讀公司文件、會查資料庫、會呼叫內部 API，丟幾個問題進去，答得有模有樣。Demo 給主管看，全場點頭，「這個一定要做」。

然後這個專案就卡在那裡，六個月上不了線。

不是因為團隊不努力，也不是因為模型不夠強。而是因為做出一個會動的 demo，跟交付一個企業敢信任的 production 系統，中間隔著一條大部分人沒看見的鴻溝。Demo 只要在你準備好的那三個問題上答對就行；production 要在你沒想過的第三千個問題上不出包。

我自己這一年大量在用 agentic 的方式工作——Claude Code 幫我寫程式、自己寫過 MCP server 把工具接給模型、用 agent workflow 把一些延遲性的任務交出去跑。這些經驗給我一個很實際的體感：

讓一個 agent「能動」很容易，讓它「能被信任」很難。而企業要的從來不是能動，是能信任。

這篇先把整張地圖攤開：demo 到 production 之間，到底有哪六道鴻溝。後面 11 篇，每一篇就是在過其中一道。

鴻溝一：正確性沒有底線

Demo 階段，答錯一題你會笑著說「啊它有時候會這樣」。Production 階段，答錯一題可能是給客戶錯誤的保固資訊、給工程師錯誤的製程參數、給財務錯誤的數字。

LLM 的本質是機率生成，它不會說「我不知道」，它會很有自信地編一個。在 demo 裡這叫「偶爾幻覺」，在 production 裡這叫「系統性風險」。

企業真正的問題不是「模型會不會錯」——它一定會錯。問題是：

它錯的時候，系統知不知道？
它沒把握的時候，會不會老實講，還是照樣硬answer？
答案有沒有來源可以追，讓人能驗證？

這就是為什麼後面要花三章談 RAG 與權限感知檢索（第 3、4、5 篇）——把答案綁回可追溯的來源，是讓正確性有底線的第一步。

鴻溝二：沒有 eval，你根本不知道有沒有變好

傳統軟體你改一行 code，跑一遍測試，綠燈就敢上。AI agent 你改一句 prompt、換一個模型、調一個檢索參數，你怎麼知道它變好還是變壞了？

「我自己試了幾題覺得不錯」不是工程，是賭博。

Demo 不需要 eval，因為你只 demo 你知道會過的題目。Production 一定要 eval，因為：

換模型版本（連 vendor 自己 silent update 都可能）會讓行為漂移
改 prompt 修好 A 問題，常常默默弄壞 B 問題
沒有一組「黃金題庫」當回歸測試，你每次上線都是裸奔

而且別把 eval 想成什麼龐大基礎建設。起手式可以很小：先盯著你最痛的那幾類問題，整理 30 到 50 題「標準答案我心裡有數」的黃金題庫，每次改 prompt、換模型、調檢索參數就跑一遍，看通過率往哪邊動。光是有這條基準線，你就從「我自己試了幾題覺得不錯」升級成「這次改動讓通過率從 82% 掉到 76%，先別上」。

一個沒有 eval harness 的 agent 專案，本質上是沒有測試的軟體——只是大家因為它是 AI 就假裝這件事不存在。第 9 篇會專門談怎麼把 eval 與可觀測性建起來。

鴻溝三：出事的時候，你看不見裡面發生什麼

傳統後端掛了，你有 log、有 trace、有 metrics，可以一路追到哪個 service、哪個 query、哪一行。

Agent 答錯了，你有什麼？很多 PoC 的答案是：什麼都沒有。一個 prompt 進去、一個答案出來，中間它檢索了什麼、呼叫了哪個工具、為什麼選這條路，全是黑盒。

Production 系統最基本的要求是「可觀測」。對 agent 來說，這意味著你要能回答：

這個答案是基於哪幾份檢索到的文件？
Agent 呼叫了哪些工具、傳了什麼參數、拿回什麼？
每一步花了多少 token、多少時間、多少錢？
哪一步是整條鏈失敗的根因？

我以前靠 tracing 抓過一個 PHP-FPM 的記憶體洩漏——沒有那條 trace，你只會看到「服務又慢了」，永遠不知道是哪一段在吃記憶體。Agent 是一模一樣的處境，只是黑盒更深：一個答案背後可能串了三次檢索、兩個工具呼叫、一輪 reasoning。今天這層觀測已經有現成的標準和工具可以接（第 9 篇細談），差別只在你願不願意把它當成跟後端一樣的基本要求。

沒有這層 trace，你 debug agent 的方式就只能是「再問一次看看」。那不是維運，那是許願。

鴻溝四：權限與資料治理，是企業的生死線

這道鴻溝，是把「給個人玩的 agent」和「給企業用的 agent」分開的那條線，也是最多 PoC 直接跳過、然後永遠過不了資安那關的地方。

你的 RAG agent 會檢索公司文件。問題來了：

一個沒有 HR 權限的員工問「某某人的薪資」，agent 會不會因為那份文件剛好在向量庫裡，就大方檢索出來回答？
不同部門、不同機密等級的資料，retrieval 的時候有沒有照使用者的權限過濾？
答案引用了某份文件，那位使用者本來有沒有資格看那份文件？

在 demo 裡，所有資料對「你」這個 demo 帳號都是開放的，所以這個問題隱形了。在 production 裡，越權檢索等於資料外洩，而且是 AI 幫你自動化的外洩。第 5 篇「權限感知檢索」會專門拆這一關——我會老實說，這是企業 RAG 最難、也最容易被低估的一塊。

鴻溝五：成本與延遲，不是「之後再優化」

Demo 一天被呼叫 20 次，你不在乎一次花多少 token。Production 一天被呼叫 20 萬次，每次多串一個 model call、多檢索 10 份文件、多跑一輪 reasoning，乘上 20 萬，就是真金白銀和使用者等到關掉分頁的延遲。

AI agent 有個 demo 階段看不到的特性：它很容易「想很多」。一個 multi-agent 的設計、一個 reasoning chain，在 demo 裡是「哇好聰明」，在 production 裡可能是「一個問題燒掉 5 萬 token、跑了 40 秒」。

這不是憑感覺嚇你。Anthropic 自己揭露過他們的 multi-agent research 系統：一個 multi-agent 流程用掉的 token，大約是一次普通 chat 的 15 倍（單一 agent 也有 4 倍）。multi-agent 之所以顯得聰明，很大一部分就是因為它燒得多——這在 demo 裡你看不到帳單，乘上 production 每天幾十萬次呼叫，就是會被約談的數字。

更現實的是，這三件事——延遲、可靠性、成本——是會互相打架的三角：

想可靠 → 加 retry、加 fallback model → 變慢、變貴
想便宜 → 用小模型、少檢索 → 品質掉
想快 → 少 reasoning、激進 cache → 可能犧牲正確性

LLM app 說到底還是個 distributed system，這些 trade-off 是要當成系統設計來做的，不是上線後再說。第 10 篇整篇在談這個三角怎麼權衡。

鴻溝六：沒有 fallback 和人類介入點

最後一道，是心態問題。很多人潛意識把 agent 當成「會自己搞定一切」的東西。但 production 系統的成熟度，恰恰體現在它承認自己會失敗、而且為失敗做了準備。

Agent 沒把握的時候，能不能降級到「我幫你找到這幾份文件，請你自己判斷」，而不是硬掰一個答案？
高風險的動作（刪資料、送出訂單、改設定），有沒有一個 human-in-the-loop 的確認關卡？
主要模型掛了、或回了垃圾，有沒有 fallback 路徑？

一個 tool-using agent 真正可怕的地方，不是它會講錯話，是它能操作外部系統。它能講錯話頂多丟臉；它能用錯工具，那是真的會改到資料、動到錢。所以 action boundary 和 approval flow（第 6、11 篇）不是加分項，是 production 的入場券。

把六道鴻溝變成一張地圖

把上面整理起來，這就是這本書的骨架——每一道鴻溝，對應後面一到幾篇：

#	鴻溝	在哪幾篇過河
1	正確性沒有底線	第 3、4、5 篇（RAG / 向量檢索 / 權限）
2	沒有 eval / 迴歸	第 9 篇（可觀測性與評估）
3	看不見內部	第 2、9 篇（架構 / trace）
4	權限與資料治理	第 5、11 篇（權限檢索 / 治理）
5	成本與延遲失控	第 10 篇（系統權衡）
6	沒有 fallback / HITL	第 6、8、11 篇（tool use / 多代理 / 治理）

還有一個工程師容易忽略、但在 2026 越來越硬的視角：這六道鴻溝不只是你內部會卡的工程問題。其中正確性、資料治理、可追溯、人類介入這幾道，剛好就是 EU AI Act、NIST AI RMF、ISO/IEC 42001 正在要求企業做到的事——而像 ISO/IEC 42001 這種 AI 管理系統認證，已經開始被寫進大型企業的採購盡職調查清單。所以過這幾道河，不只是讓系統能被信任，也是在替合規鋪路。第 11 篇會把這層治理視角收成一張框架圖，也會把法規時間表講清楚。

下一篇（第 2 篇），我會把這六道鴻溝收斂成一張企業 AI Agent 的系統架構藍圖——一張圖看懂一個能上 production 的 agent 系統長什麼樣，每個元件為什麼存在、少了它會怎樣。先講清楚，那是一張參考架構（設計提案），不是哪個已經部署好的成品；但它背後的每一個取捨，都是從上面這六道鴻溝推出來的。

如果你現在手上正好有一個「demo 很漂亮、但遲遲不敢上線」的 agent，先別急著怪模型。把它對著這六道鴻溝檢查一遍，你大概就會知道，卡住的從來不是 AI，是工程。