OSCHINA

MCP （Model Context Protocol）作為連接大模型與外部工具的通信協議，近期因谷歌推出 A2A（Agent-to-Agent）協議引發爭議。

MCP 憑借其簡潔的設計和 OpenAI 等巨頭的支持，迅速成為大模型與外部工具交互的事實標準。其核心價值在于解決了兩個關鍵問題：一是標準化接口：將工具能力封裝為統一的函數描述（如 API 格式、參數定義），降低模型調用復雜度；二是上下文管理：通過動態維護工具調用記錄，輔助大模型生成連貫的操作鏈條。

這種 “模型中心化” 的設計思路，使其在開發者中廣受歡迎。然而，隨著谷歌推出 A2A 協議，MCP 的 “護城河” 開始遭遇挑戰。

MCP 能否抵御谷歌 A2A 的生態攻勢？不久前，開源中國舉行了一場以 “全網爆火的 MCP 到底是啥？” 為主題的直播，業內專家對這個問題進行了討論。

谷歌的生態圍剿：A2A 的“包裹戰術”

谷歌的入局讓戰局陡然升溫。A2A 出現之后，MCP 自身的定位成為關鍵：它是想變成 A2A 體系下的附屬品，還是說它也想升到和 A2A 平級的位置？

A2A 協議直指智能體（Agent）間的高階協作場景。Bytebase 聯合創始人兼 CEO 陳天舟認為，如果 MCP 想上升到 A2A 層面，勝算很小，因為必須這要有應用場景支撐。“MCP 背后的公司 Anthropic 主要做模型基礎設施層，本身沒有應用。但谷歌不一樣，A2A 發布時候，就把應用層廠商都集中起來了，生態優勢很大。” 根據公開信息，A2A 首批合作企業包括 Salesforce、SAP、ServiceNow、MongoDB、Intuit、Workday、德勤、埃森哲等全球頂級企業應用平臺，覆蓋金融、零售、醫療、供應鏈等多個領域。

陳天舟指出，現在 A2A 和 MCP 的關系，有點像當年云原生時代谷歌經歷的 K8s 和 Docker 的關系。而A2A 的野心，類似 Kubernetes 對 Docker 的替代路徑 —— 先兼容 MCP，再通過上層生態完成 “包裹式替代”。“不過，谷歌應該吸取了當年對 Docker 反應太慢的教訓，這次對 MCP 反應很快 —— 它用更接近應用層的抽象協議把 MCP 包裹起來了。現在這種情況下 MCP 如果不集中精力鞏固地位，反而繼續突圍的話，下一步可能真的會被谷歌這個協議體系收編。”

智能體通信協議 ANP 作者常高偉認為，長遠來看，如果未來所有工具都實現智能體化，那么 A2A 可能直接繞開 MCP 的交互場景，逐漸侵占 MCP 的份額。MCP 甚至有可能被徹底干掉。

Gitee 私有云產品總監林靖靖對 MCP 的未來持悲觀態度。他認為，MCP 目前的作用是連接大模型和工具，但隨著 A2A 協議的出現和工具智能化、Agent 化的發展，MCP 可能會被取代。“大模型的交互方式可能會變化，上下文處理可能不再集中在 MCP，未來 Agent 可能直接通過 "上下文封裝 + 預處理" 與大模型交互，而無需經過 MCP 的 "任務標識觸發" 機制。

這就導致MCP 的戰略困境面臨兩難選擇：如果收縮戰線專注大模型交互優化，很可能被 A2A 協議架空；如果冒險拓展 Agent 間交互場景，這需極高投入且成效存疑。“結果就是可能哪個方向都沒吃透，最終被邊緣化。” 林靖靖如此預測。

Gitee 公有云技術負責人羅雅新則看好 MCP 作為 “USB 式標準” 長期存在，因其解決了工具調用的標準化問題。他認為，MCP 和 A2A 是解決不同場景的方案：前者是基礎連接標準，后者是生態交互協議，二者可以并存發展。“無論 Agent 如何進化，要減少幻覺就必須與現實世界交互，獲取事實數據。通過 MCP 這種標準化協議實現數據調用，既便利又可復用，各個 Agent 都能采用統一方式接入。MCP 只要持續解決關鍵問題（比如傳輸效率這類基礎能力提升），就有長期存在的價值，就像 USB 歷經多代升級仍保持核心價值。當然未來可能出現更好的協議替代它，但設備互聯的場景需求不會消失。這本質上不是生態構建，而是協議標準的建立。”

現在的問題是，雖然 MCP 已集成主流工具擴展能力，但存在明顯局限。羅雅新解釋，當使用超過 40-60 個 context 時，系統就開始崩潰，有些客戶端甚至直接限制數量。這導致人為篩選 context 時面臨困境：面對海量 MCP 接口，用戶根本不知道哪些該喂給模型，而模型自身也缺乏主動發現和篩選能力。不過如果進化到 Agent 間交互，協議層 —— 比如谷歌發布的 A2A 協議，應該能解決這個問題。

“Agent 間交互，這才是真正的生態問題”。羅雅新認為，每個 Agent 都有特定業務場景和商業訴求，是否與其他 Agent 協作需要市場博弈。A2A 協議現階段可能不是爆發時機，更像是提前布局。當單個 Agent 無法滿足用戶完整需求時，自然會產生交互需求，生態才會逐步成型。

長遠地看，MCP 會消亡

也有人認為，MCP 面臨的最大危機，可能不是 A2A ，而是 AI 不斷發展，具備一定程度智能后，已經不需要任何協議。

“長遠來看，MCP 這類協議終將消失。” 陳天舟認為，現階段之所以需要 MCP，本質上是因為當前智能體的認知能力有限。“當 AI 發展到足夠智能的階段，除了原始數據資源本身，所有中間層的協議規范都會失去存在價值—— 足夠強大的智能體完全可以自主理解數據。我們不再需要像繪制地圖、編寫說明書那樣，通過數據加工來指導智能體獲取信息。考慮到 AI 的發展速度，或許根本不需要三到五年，這類過渡性協議就會退出歷史舞臺。”

作為數據庫從業者，Pigsty 作者馮若航注意到，微軟 CEO Satya Nadella 在不久前的演講中也提到類似趨勢：未來應用范式可能是 Agent 直接對 Database 進行 CRUD 操作。如果智能體真能實現原生數據理解能力，中間協議層確實可能被繞過 —— 最終形態將是 Agent 與 Database 的直接對話。

字節跳動技術專家劉康認為，MCP 能否繁榮不取決于它自身的表現，而是取決于 Agent 范式本身能否成功。若三到五年后 Agent 未成主流，MCP 仍會是工具層的最優解。

“當前 MCP 受關注的根本原因，是整個行業注意力轉移到了 Agent 范式 —— 前幾年大家聚焦預訓練模型，現在應用層開發者開始轉向 Agent 架構。但關鍵在于，Agent 能否真正形成繁榮生態？這個命題本身仍然存疑。

“我們不得不思考：這個范式未來是否會被新范式取代？現階段 MCP 協議的熱度完全依賴于大家對 Agent 范式的預期。至于三五年后的發展，時間跨度其實非常微妙。如果用最樂觀的 AI 發展視角來看，屆時可能已經實現 AGI（通用人工智能）—— 如果真到那個階段，MCP 是否存在根本無關緊要，就像今天我們不再關心 CPU 總線協議的具體實現。“

回到現階段，高常偉認為，Agent 協議正確的技術路線確實是工具化 ——MCP 完全契合當前發展需求。下一步無論是 A2A 還是 ANP 協議，本質上都是為未來布局。目前智能體生態尚不成熟，通信協議都處于早期研究階段。但正因如此，現在正是制定標準協議的關鍵窗口期。

“至于更遠期的未來，當 AI 發展到高級階段，人類設計的協議可能反而成為限制 —— 也許智能體自主協商的協議會更高效，就像牛津大學提出的自然語言協商協議。讓每個 Agent 暴露自然語言接口，通過對話協商交互協議。這種動態協議機制正是 ANP 框架支持的演進方向，是未來的主流。”

MCP 的生存之道：技術做減法與生態做加法

在技術上，大家一致認為 MCP 應該做減法。

“我認為當前協議架構需要簡化，特別是客戶端采樣這類冗余設計。” 常高偉解釋，雖然理論上存在應用場景，但實際幾乎沒有客戶端使用該功能，建議直接精簡。另外服務端訪問客戶端文件的設計也值得商榷 ——這種雙向訪問機制導致服務端與客戶端耦合度過高，這是審閱協議時最突出的問題。理想狀態應該是服務端與客戶端保持松耦合關系。

陳天舟的觀點可能更為激進：“。我認為應該全面移除所有與鑒權相關的功能，將其移交交基礎設施層，專注核心通信邏輯因為我們本質是數據庫系統開發者，應該回歸數據庫最核心的架構邏輯來看待這個問題。”

具體來說，MCP 當前的核心任務應該是明確定義關系型數據庫的基礎函數集，并基于這些關系函數構建類 SQL 的標準語法體系。但需要澄清的是，鑒權機制本就不屬于 SQL 層的職責范疇，而是應該由數據庫管理系統（DBMS）承擔的基礎設施功能。現階段需要聚焦于關系型數據庫最核心的組件。

“需要重點構建的是關系函數集與 SQL 語法體系這兩大支柱，除此之外的附加功能都應該被精簡。從當前架構評估，建議保留三個核心模塊：現有的資源定義工具、查詢解析器、執行引擎，同時必須完善路由功能，即可構建出符合數據庫本質的最小化核心架構。

而在建生態這個方向上，要做加法，從解決 "工具發現難"" 開發者動力弱 ""分發渠道散" 這三大問題入手。

模型如何自主發現執行任務所需的 context？當前已經出現的 MCP 工具市場（marketplace）或許能提供解決方案。但接下來的問題是，這些資源應該直接開放給模型調用，還是需要人工篩選？羅雅新觀點是：最終應該建立 Agent 可直接調用的注冊中心（registry），讓智能體能自主發現所需的 context 資源或 MCP 服務節點。這才是作為終端用戶真正需要的技術實現路徑。

劉康認為，從生態發展角度觀察，MCP 協議落地的關鍵在于降低接入門檻。作為開發者，最期待的是更完善的開發工具鏈 —— 當前協議設計明顯偏向模型所有者（Model Owner），資源提供方（Tool Developer）的接入收益相對滯后。雖然長期看雙方都能獲益，但以模型為中心的架構天然會導致資源側動力不足。

因此，要推動 MCP 社區繁榮，必須解決工具開發者的核心痛點：提供極簡轉換工具，比如將現有 REST API 一鍵遷移為 MCP 接口的自動化方案。只有讓資源擁有者以最小成本接入協議，才能真正激發生態活力。這本質上是在模型中心和技術普惠之間尋找平衡點，而開發體驗的優化正是破局關鍵。

林靖靖指出，從當前 MCP 的分發機制來看，最關鍵的缺失是統一的 "應用商店" 角色。目前各家 MCP 工具 / 客戶端都在構建自己的 marketplace。“開發者開發完 MCP 客戶端后，不得不面對多平臺分發的困境 —— 需要同時在十幾個渠道部署維護，這種碎片化狀態嚴重制約生態發展。應該要有一個聚合平臺。至于該平臺由誰來主導，不論是云服務商、還是模型廠商，亦或是代碼托管平臺都有機會嘗試。現階段正處于格局未定的窗口期。不過，最終可能通過市場競爭自然篩選出用戶信任度最高的平臺。”

所有協議都是時代的產物。這場關于 MCP 的爭論，或許正是 AI 技術從 “工具時代” 邁向 “智能體時代” 的序章。短期來看，MCP 需警惕谷歌的 “生態降維打擊”，在工具層構筑技術壁壘；長期來看，協議的價值終將取決于能否順應 Agent 范式的進化 —— 是成為智能世界的 “基礎設施”，還是淪為過渡期的 “臨時腳手架”。

【數智漫談】

OSCHINA 視頻號直播暢聊欄目【數智漫談】，每期一個技術話題，三五位專家圍坐，各抒己見，暢聊開源。給大家帶來最新的行業前沿、最熱門的技術話題、最有趣的開源項目、最犀利的思想交鋒。如果你手上也有新點子、好項目，想要跟同行交流分享，歡迎聯系我們，講壇隨時開放～

↓分享、在看與點贊~Orz