企業 Agent 上不了生產,卡的不是模型是「接入層」:MCP 標準化 + 資料供給治理怎麼解（2026）
2026 下半場,把企業 Agent 擋在生產門外的不是模型,而是接入層。麻省理工 NANDA 調研顯示 95% 的企業 GenAI 試點沒帶來可衡量回報,Cloudera×HBR 則稱僅 7% 企業資料「完全就緒」。本文拆解 MCP 無狀態新規(12 個月棄用政策、AAIF/Linux Foundation 託管)如何解鎖企業級規模,以及資料供給治理為何決定 Agent 敢不敢被委派,並附「硬接 legacy vs MCP vs FDE 駐場」三路線對比表。
TL;DR： 到 2026 下半場,把企業 Agent 擋在生產門外的已經不是模型能力,而是接入層——Agent 連不進碎片化的遺留系統,也調不動那些「存而不通」的沉睡資料。麻省理工 NANDA 的調研顯示,95% 的企業 GenAI 試點沒能帶來可衡量的 P&L 回報,根因是通用工具不適配真實工作流的「learning gap」,而非模型不夠強。解法是兩條腿並行:一是協議標準化(MCP 無狀態新規把 Agent 接入從「逐個系統硬接」變成可規模複用的地基),二是資料供給治理中樞(把資產從「存而不通」變成 Agent 敢被委派、能跑通閉環的物件)。協議解決「怎麼接」,治理解決「接進來能不能用、敢不敢放手」。
為什麼 2026 下半場,模型不再是企業 Agent 的瓶頸?
因為失敗發生的位置變了。麻省理工 NANDA 的研究《The State of AI in Business 2025》基於 150 場訪談、350 份問卷和 300 個部署案例,給出一個刺眼的數字:95% 的企業 GenAI 試點未能產生可衡量的 P&L 回報。這項研究把失敗根因歸結為 learning gap——通用工具不適配企業的真實工作流,而不是模型能力不足。也就是說,大多數專案不是敗在「模型不夠聰明」,而是敗在「聰明的模型接不進現實系統、跑不出業務回報」。
這不是孤例。據 S&P Global Market Intelligence 的調研,2025 年有 42% 的企業放棄了大部分 AI 計劃——而 2024 年這一比例僅為 17%;平均每家企業在投產前砍掉了約 46% 的 AI 概念驗證(PoC),主因是成本、資料隱私與安全(樣本為 1,000+ 北美與歐洲受訪者)。放棄率一年內翻倍、且大量 PoC 死在投產前,把這兩組資料放在一起,一個判斷就立得住:AI 的競爭重心正從「比誰模型大」轉向「比誰落地深」——當通用模型能力對多數場景已經夠用,差距就由能否穩定地把試點推進到有回報的生產來決定。理解這一點,是選對下一步投入的前提:繼續堆模型,不如先修接入層。
「接入層」到底是什麼?為什麼它是上生產的下一道坎?
接入層,就是 Agent 與企業遺留系統、資料來源和內部工具之間的那層連線與治理。 它決定 Agent 能不能讀到正確的資料、能不能安全地呼叫內部系統、以及出錯時責任落在哪一側。做一個能對話、能調工具的 Agent 模板並不難;難的是讓它接進企業「底下那團亂麻」。
這正是本週 TechCrunch 報道的融資事件所印證的痛點。獲 Time Ventures(Marc Benioff)領投 2000 萬美元 pre-seed 的初創公司 June,把落地難題總結成一句話:「在 AI 創造價值之前,得先有人去處理遺留系統」。報道里一個反直覺的觀察是——「AI 反而抬高了對專業服務的需求」:行業目前對落地的普遍答案,是僱越來越多的人去接線。文中的客戶案例 CMG(美國房貸)一度承諾「帶 100 個 agent 回來」,卻卡在與 Salesforce 的整合上,「一直在和架構師、駐場工程師開會……卻推不動進展」。而所謂「亂麻」到底長什麼樣,一個具體細節說明一切:當系統裡躺著 10 個含義相同的重複欄位,Agent 怎麼知道該用哪一個?
這不是個別工程團隊的手藝問題,而是可被系統歸類的失敗結構。一篇 arXiv 論文(2607.28802)提出了以「互動」為中心的失敗定位分類法,把 Agent 的 41 種失敗模式按責任側拆開——是模型側,還是 harness(腳手架與工具整合)側,抑或環境側。落到企業語境,harness 側就是接入層:同一個可見的「Agent 又出錯了」,修法可能是重訓模型,也可能只是把工具整合和資料介面修對。該分類法的可復現性也不弱,最強判定器對人工標註的一致性達到 Cohen's κ=0.76。這項工作從證據層面支援了一個判斷:很多被當成「模型不行」的失敗,根子在接入層。(想系統瞭解落地為何這麼難,可參見我們此前的《為什麼企業 AI 落地這麼難》。)
MCP 無狀態新規做了什麼?為什麼它解鎖了企業級規模?
MCP(Model Context Protocol,模型上下文協議)是讓 Agent 以統一方式接入外部工具與資料來源的開放標準。 它要解決的,正是上一節那種「逐個系統定製、重複造輪子」的接入困境。而本週的關鍵事件是:據 Ars Technica 報道,MCP 迎來自推出以來最重要的一次更新,協議核心由「有狀態」改為「無狀態」——請求不再繫結某個 server 例項的會話,直接拆掉了長期橫在擴充套件性面前的障礙。主維護者 David Soria Parra 與 Den Delimarsky(均來自 Anthropic)稱,這是「remote MCP 釋出一年多以來最重要的更新」,無狀態也是「開發者呼聲最高的特性之一」。
對企業而言,真正的訊號不止是無狀態本身,還有圍繞它的一整套企業級配套:同版新增了 Multi Round-Trip Requests、基於 header 的路由、可快取的列表結果、授權加固、正式的擴充套件框架和 Tier 1 SDK。更關鍵的是一條棄用政策:功能從正式棄用到實際移除,至少間隔 12 個月(關鍵安全更新除外)——這幾乎是專為企業穩定性寫的承諾。治理層面也換了骨架:MCP 現由 Linux Foundation 旗下的 Agentic AI Foundation(AAIF) 託管,OpenAI、Google、Microsoft、Amazon 均有貢獻。可擴充套件、可路由、可快取、有明確棄用週期、且不綁單一廠商——這些恰好對應企業最看重的「可擴充套件性 / 可靠性 / 穩定性」。(接入層背後完整的平臺側要求,可對照《企業 Agent 平臺的部署要求》。)
光有協議還不夠:資料供給治理中樞
標準化協議解決了「怎麼接」,但沒解決「接進來的資料能不能用、敢不敢把目標委派給 Agent」。而現實是:大多數企業的資料根本沒準備好。Cloudera 聯合哈佛商業評論分析服務的報告顯示,只有 7% 的企業認為自己的資料「完全就緒」可用於 AI,27% 直接表示不就緒;報告裡一句 CTO 的話點破關鍵:「要從試點走向生產,組織需要對 100% 資料的安全訪問。」Informatica 的《CDO Insights 2025》調研也印證了同一方向——資料質量與就緒度是 AI 落地的首要障礙,佔比 43%。用我們的話說,這就是「資料沉睡與 AI 懸浮並存」:資產存而不通、通而不用,Agent 於是只能懸浮在業務之上。
協議把管道接通了,但如果資料本身沒有語義、沒有閉環、不穩定、難以複用,Agent 依然不敢被委派目標、跑不通閉環。要補的,是一層資料供給治理:把專家經驗固化成可複製的系統能力,再為關鍵流程配上目標、策略、記憶與評估這套治理件,讓協作從「人機逐步確認」走向「目標委派、結果審閱」,並用達成率、介入率這類指標來解鎖自主度。(一種可參考的工程框架是數新智慧提出的 SRW+GPME 記憶錨點公式與「輔助→協同→自主」三階段,關鍵在 2→3;此處作為單源例證,不作主論據。)一句話:標準化協議決定「接得進來」,資料治理決定「接進來敢不敢放手」。
對比:三種接入路線怎麼選?
企業把 Agent 接進現實系統,現實中主要有三條路線。它們並不互斥,但代價與適用場景差別很大:
| 維度 | 自己硬接 legacy | 標準化接入層(MCP) | FDE 駐場交付 |
|---|---|---|---|
| 起步速度 | 慢:逐個系統定製 | 快:協議複用 + Tier 1 SDK | 快:專家直接進場 |
| 可擴充套件性 | 差:逐系統定製、連線不可複用、運維碎片化 | 強:無狀態 / header 路由 / 可快取 | 取決於人手規模 |
| 長期穩定 | 技術債持續累積 | 12 個月棄用政策兜底 | 依賴駐場的持續性 |
| 資料治理 | 各自為戰 | 需疊加治理中樞 | 隨交付逐步沉澱 |
| 適用場景 | 一次性 / 小範圍 | 規模化、多系統 | 複雜現場、深度落地 |
| 主要風險 | 黑箱、進度停滯 | 需內部具備工程能力 | 「離了 FDE 就轉不動」的黑箱擔憂 |
結論是:三者不是單選題。標準化接入層(MCP)+ 資料供給治理中樞是可規模化、可長期維護的地基,而 FDE 駐場負責把這套地基鋪進具體現場、啃下最硬的那部分整合。需要提醒的是純黑箱式駐場的風險——TechCrunch 報道里 CMG 的安全負責人 Paul Akinmade 說得很直接:「如果你的產品離不開 FDE,那我不想要這個產品……我不想要一個黑箱,不想要一個只有特定幾個人才搞得懂的東西。」這恰恰指向 6am 的立場:用標準化協議和資料治理搭一個透明、可交接的地基,再讓駐場工程把它鋪進現場,而不是把落地能力鎖進一個離不開人的黑箱。
企業該怎麼第一步落地這套接入層?
不必一步到位,但順序很重要:
- 盤點系統與資料——先把 Agent 要觸達的遺留系統、資料來源和重複/歧義欄位梳理清楚,這一步決定後面接得乾不乾淨,也直接對應「只有 7% 資料完全就緒」的現實。
- 用標準化協議接入,別再逐個硬接——優先走 MCP 這類標準介面,把「一次性整合」換成可複用、可快取、可路由的連線。
- 疊加資料治理——為關鍵流程補上目標、策略、記憶與評估,讓 Agent 從「協同」走向「可委派」。
- 用指標做門禁——定義達成率、介入率作為放開自主度的硬門檻,而不是靠人逐步點頭。
不確定自己卡在哪一層?可以先做我們的免費 AI 落地診斷,用一份問卷定位你的接入層與資料治理短板;想補齊團隊工程能力,也可以看看我們的實戰課程。
常見問題(FAQ)
Q:什麼是 MCP,對企業落地有什麼用? MCP(模型上下文協議)是讓 Agent 以統一方式接入外部工具與資料來源的開放標準。2026 年的無狀態新規讓請求不再繫結單個 server 例項的會話,配合 header 路由、可快取列表結果和 12 個月棄用政策,直接提升了企業最看重的可擴充套件性與穩定性——它把「逐個系統硬接」變成可規模複用的接入地基。
Q:通用 Agent 為什麼接不進我們的核心繫統? 因為核心系統是碎片化的遺留系統 + 尚未就緒的資料——只有 7% 的企業認為資料「完全就緒」可用於 AI。問題往往不在模型側,而在接入層(harness 側):連線不可複用、欄位重複歧義、資料缺乏語義與閉環。解法是標準化接入(MCP)加上資料供給治理,而不是換更大的模型。
Q:有了 MCP 還需要 FDE 駐場嗎? 需要,但角色不同。MCP 與資料治理中樞負責搭可規模化、可維護的地基;FDE 駐場負責把地基鋪進具體現場、啃下最難的整合。關鍵是別讓落地能力變成「離了 FDE 就轉不動」的黑箱——標準化地基 + 駐場交付的組合,才能既跑得快又交得出去。
