80% 已採用 agentic AI,為什麼企業仍難從試點走向規模化?
約 80% 的財富 500 強已採用 agentic AI,卻仍有許多困在孤立試點。本文用 MIT Technology Review、海信實測、量子位百萬級使用者資料與 OpenAI 的 AI 原生方法論,拆解“試點→全公司”之間真正的組織、治理與度量差距,並給出一條可執行的規模化路徑。
TL;DR： 許多企業的 AI 卡在試點,不是因為模型不夠強,而是因為組織把 agent 疊在了舊流程上、餵給它的是沒被記錄下來的隱性知識。據 MIT Technology Review(2026-09-03),約 80% 的財富 500 強企業已經採用 agentic AI,但"progress toward meaningful scale remains uneven, with many organizations still working through isolated pilots"——真正推到全公司規模的進展並不均衡,許多仍困在孤立試點裡。規模化的鑰匙只有一句話:先把 agent 繫結到業務戰略、重構工作流,再談鋪開,而不是在低效的老流程上加一層 AI。
本文用 MIT Technology Review、InfoQ 報道的海信實測、量子位 的百萬級使用者行為資料,以及 OpenAI 的 AI 原生方法論,拆解"試點→全公司"之間真正的組織、治理與度量差距,並給出一條可執行的規模化路徑。
為什麼很多企業的 AI 專案卡在試點階段,推不到全公司?
答案先行:卡點幾乎從不在模型能力,而在組織、工作流和知識底座。 換句話說,試點能跑,是因為它被人為地圈在一個乾淨、邊界清晰、有人盯著的小場景裡;推到全公司會散掉,是因為真實業務裡到處是沒被記錄的歷史、互不連通的系統和缺位的治理。
MIT Technology Review 把這種失敗模式稱為"新型碎片化"(a new kind of fragmentation):各個團隊各自為戰、各建互不連通的孤立系統,試點越多、割裂越重。文章引述 NiCE 營運長 Arun Chandra 的一句話點破了最常見的誤區——"The last thing you want to do is to apply AI on an outdated or an inefficient workflow."(你最不該做的,就是把 AI 套在一條過時或低效的工作流上。)當底層流程本身就是壞的,agent 只會把壞的部分執行得更快。
工程一線的證據更直白。據 InfoQ《傳統企業 AI 轉型的最短路徑,藏在研發部門》報道,海信在引入編碼智慧體 Qoder 後跑了 10 個試點:全新系統的開發效率提升了 3–4 倍,歷史系統的提升卻不明顯。 瓶頸不是"AI 不會寫程式碼",而是"它不知道那些從未被記錄的歷史"。這篇報道里有一句很適合釘在牆上的話:"人類工程師不懂時,至少會停下來問一句;AI 有時不懂,但照樣往下寫。"——模型甚至會放大舊系統裡的隱性依賴問題。這正解釋了為什麼同一個 agent,在綠地場景裡是生產力工具,一進入積壓了十幾年隱性知識的老系統就原地失速。
順帶澄清一個坊間高熱的說法:網上流傳"MIT 報告稱 AI 專案失敗率高達 95%"。這是一個未經嚴謹核實的流傳數字,不宜當事實複述。用 MIT Technology Review 本輪的嚴謹口徑校正:真實圖景是"約 80% 已採用、但許多困在孤立試點",問題是"規模化不均衡",而不是"絕大多數徹底失敗"。把"失敗"精確地定義為"卡在試點、沒能規模化",才是解決問題的起點。
試點 vs. 規模化:組織、治理、度量到底差在哪?
試點和規模化不是"同一件事做大一號",而是兩種截然不同的心態。下面這張表把差異一次性講清:
| 維度 | 試點階段(Pilot) | 規模化階段(Scale) | 證據錨 |
|---|---|---|---|
| 目標 | 為實驗而實驗,證明"能用" | 繫結業務戰略(增收 / 降本 / 明確的財務目標) | MIT Technology Review |
| 工作流 | 在舊流程上疊一層 AI | 先重構工作流,再落 agent | MIT Technology Review(Chandra 原話) |
| 知識 / 上下文 | 依賴現成的顯性文件 | 消解從未被記錄的隱性歷史 | InfoQ 海信 |
| 覆蓋人群 | 小範圍試用(~百人) | 全域推廣(海信從近百人擴到 900+ 人) | InfoQ 海信 |
| 組織結構 | 各團隊各建孤島 | 連線式戰略,主動避免"新型碎片化" | MIT Technology Review |
| 治理 | 事後補 | 隱私 / 安全 / 變更管理前置,agent 與人同標準考核 | MIT Technology Review |
| 度量 | 看 demo 效果 | 看可量化產出與真實算力分佈 | 量子位 / OpenAI 案例 |
MIT Technology Review 給規模化開出的第一味藥,就是超越"為實驗而實驗":把每個 agent 明確繫結到業務戰略上,別去"boil the ocean"(妄圖一口氣燒乾整片海),而是圍繞高價值用例、工作流和勞動力變化,建一套"連線式戰略"(connected strategy)。海信的數字給這張表提供了最具體的註腳——從近百人試用擴到 900+ 人,靠的不是把試點複製幾十份,而是把研發在編碼場景裡沉澱的方法論作為底座往外遷。規模化的本質,是把試點裡那套"人為乾淨"的條件,變成組織能持續供給的能力。
agentic AI 怎麼從 pilot 走到規模化生產?
答案先行:五步,順序不能亂——① 繫結業務戰略與可度量結果 ② 重構工作流 ③ 沉澱上下文 / 知識底座 ④ 前置治理 ⑤ 從高價值、可複製的場景起步。
第三步是最容易被跳過、卻最致命的一步。MIT Technology Review 的判斷很硬:"The efficacy of these AI agents is purely a function of the context, the knowledge, and the data they can ingest and use."(這些 AI agent 的成效,完全是它們能獲取並使用的上下文、知識與資料的函式。)也就是說,沒有可供 agent 消費的知識底座,再強的模型在生產環境裡也只是一個更快的猜測機。
第二步的樣板,來自 OpenAI 對"AI 原生公司"的觀察。在 OpenAI《How AI-native companies turn workflows into operating capability》 裡,AI 原生公司的做法不是在既有流程上疊 AI,而是把"工作流本身"重構成一種可運營的能力(operating capability)。這與 MITTR 的"先重構工作流"是同一個道理的兩種說法。
規模化確有可度量的成效,不是畫餅。OpenAI 給出的落地錨點很具體:法律科技公司 Legora 用 GPT-6 Astra,幾分鐘審閱了 41 份文件;律所 Gilbert + Tobin 則是先把治理搭好、再規模化地推 AI。這兩個案例說明:當工作流被重構、知識底座就位、治理前置之後,agent 才能在真實業務裡跑出"可以寫進財報"的產出,而不是停留在 demo。
從哪個部門 / 場景開始更容易見效?
答案先行:從研發 / 程式設計類場景切入,通常是最短路徑,再由此向業務智慧體遷移。
原因有二。其一是工程邏輯:據 InfoQ 報道,海信的經驗是研發智慧體與業務智慧體共享同一套工程底座——模型呼叫、上下文管理、工具編排、任務拆解、執行反饋、質量校驗、許可權管控。研發在 AI Coding 裡沉澱下來的 Spec 驅動、閉環反饋、質量護欄、知識消解這套方法論,可以跨場景遷移到財務、供應鏈、生產、客服等業務智慧體上。先在編碼場景裡把底座打磨好,等於給後續所有業務場景預付了工程債。
其二是需求資料的佐證。量子位釋出的《中國辦公 Agent 使用者行為不完全報告》(資料來源 LobsterAI,8 月使用者破百萬)顯示:泛"程式設計"與除錯類任務佔 agent 任務的 38.5%,居所有任務型別之首;從行業看,軟體 / IT 行業貢獻了 38.9% 的 agent 任務。真實使用量最集中的地方,恰恰是工程場景——這與"從研發起步"的判斷相互印證。
(這條"研發部門作為企業 AI 轉型發動機"的線索本身值得單獨展開,我們會在系列第二篇裡詳談,本文不鋪開。)
規模化階段怎麼治理與度量,才不讓它散掉?
規模化不是"鋪開就完事",真正的難點在鋪開之後:怎麼治理、怎麼度量,才不讓它重新散成一地孤島。
治理必須前置。MIT Technology Review 提醒,當 agent 開始承擔更重要的工作時,治理、隱私、安全和變更管理只會更關鍵;它主張把"勞動力"(workforce)重新理解為"人 + agent"的組合,並且用與人類員工同樣的標準去考核 agent。這句話的分量在於:它把 agent 從"工具"重新歸類為"需要被管理的執行主體"。
度量則要盯真實使用,而不是 demo。量子位的報告揭示了兩個規模化階段繞不開的現實。其一是極端的頭部效應:前 20% 的使用者消耗了 87.4% 的算力,前 5% 的使用者獨佔 53.5% 的 token。 這說明價值高度集中在少數深度場景——規模化的投放要順著高價值處走,而不是平均撒網。其二是"無人值守"正在成為常態:12.2% 的呼叫並非由人即時發起,定時任務裡單條指令平均帶動 64 次模型呼叫,是人工發起(10.6 次)的約 6 倍。 當越來越多的呼叫發生在沒有人盯著的時刻,度量與護欄就必須自動化——否則你根本不知道 agent 在辦公時間之外替你做了什麼、花了多少、對不對。
6AM 視角:用 FDE 工程紀律把試點接到生產
把上面這條路徑拆開看,你會發現每一步都不是"AI 問題",而是"工程問題":重構工作流、沉澱知識底座、前置治理、自動化度量——這些恰恰是軟體工程幾十年來一直在解的事。6AM 的立場很樸素:規模化 agentic AI 的差異化,不在模型選型,而在工程紀律。
具體到落地,我們把研發場景裡被驗證過的那套方法論——Spec 驅動、閉環反饋、質量護欄、知識消解、許可權管控——作為可交付的工程底座,幫企業把"試點能跑"接到"全公司能用"。這不是又一套 AI 諮詢話術,而是由前向部署工程師(FDE)帶著工程標準進現場,把隱性歷史消解成 agent 能消費的上下文,把治理和度量做進流水線裡。
如果你正卡在從試點往外推的那一步,不確定散掉的到底是工作流、知識底座還是治理,可以先做一次 AI 落地體檢,把卡點定位清楚再決定投放。
延伸閱讀:
- 為什麼企業 AI agent 會在生產環境失效——從技術故障視角看落地
- 企業 AI 採用路徑:自建 vs. 平臺 vs. FDE——選型決策框架
- 企業級 agent 平臺的部署要求——規模化的技術底座清單
常見問題(FAQ)
企業 AI 落地失敗率真的有 95% 嗎?
不宜這麼說。"95% 失敗率"是網上未經嚴謹核實的流傳說法,不應當事實複述。MIT Technology Review 的嚴謹口徑是:約 80% 的財富 500 強已採用 agentic AI,真正的問題是規模化不均衡、許多困在孤立試點,而非絕大多數徹底失敗。
agentic AI 怎麼從 pilot 走到規模化生產?
五步:先把 agent 繫結業務戰略與可度量結果,再重構工作流,沉澱可供 agent 消費的知識底座,前置治理,然後從高價值、可複製的場景起步。核心是別在舊流程上疊 AI,而是把工作流本身重構成運營能力(OpenAI 語)。
企業想把 AI agent 用起來,該從哪個部門 / 場景開始?
優先從研發 / 程式設計類場景切入。據 InfoQ 報道,研發與業務智慧體共享同一工程底座,方法論可跨場景遷移;量子位資料也顯示程式設計除錯類任務佔比 38.5% 最高——先在工程場景把底座打磨好,再向財務、供應鏈、客服等業務智慧體擴充套件最省力。
