企業 AI Agent 獲得重大升級：採用 gRPC 的 MCP | 中文配音

谷歌剛宣佈了一項技術 爲MCP貢獻了GRPC傳輸層 如果你一直關注本頻道 就知道我們分別介紹過MCP和GRPC 但這次發佈將它們結合起來 解決了企業一直面臨的實際問題 要理解其重要性 我們得從頭說起 現在開始 看過我之前的MCP視頻就知道 以前每個工具都要單獨對接 連slack要寫對接代碼 內部數據庫又要重寫一遍 格式、認證、接口全都不一樣 MCP通過創建統一標準 解決了這個問題 現在每個工具只需支持MCP協議 不再需要各自的專用連接器 一套協議 一種格式 一種連接方式 詳細原理請看往期視頻 但今天 我們關注的是大多數人忽略的部分 傳輸層 MCP客戶端和服務器究竟如何通信 因爲當MCP客戶端與服務器對話時 實際包含兩個獨立環節 一是消息格式 即請求的具體結構 二是傳輸層 即傳遞這些消息的傳輸系統 好比新的內容和送信的郵政服務 消息格式採用ZSRPC 這一則 就是你在網上到處可見的花括號格式 人類可讀 簡單明瞭 一看就懂 你的瀏覽器能力解JSO 你的API也使用JSO 它是互聯網的通用語言 JSON RPC在此基礎上增加了一些結構 當MCP客戶端發起請求時 格式大致如下 包含版本號 ZSRPC 2.0 ID標識符 以便匹配請求和響應 還有方法明我們想要執行的操作 比如調用某個工具以及具體參數 例如獲取舊金山的天氣 服務器用相同的ID返回響應 這樣我們就知道 這是對應問題的答案 加上數據 就構成完整消息 好了 這就是信封裏的內容 那麼信封究竟如何送達呢 用的是普通的HTTP協議 就是你每次加在網站時 瀏覽器使用的相同協議 調用工具時發送HTTP請求 ZSRPC消息就寫在請求題裏 服務器處理請求後 返回HTTP響應 基於成熟的網絡協議 請求響應模式非常穩定 但如果服務器需要向客戶端推送更新呢 比如智能體正在監控數據庫變化 或等待長時間運行的任務 一問一答 簡單高效 所以MCP敢用SSE服務器發送事件 而不是每次應答後都斷開連接 連接寶卻打開狀態 服務器持續通過同一連接推送更新 狀態更新 新數據 任務完成 單向流 服務器到客戶端 走HTTP MCP的頂層協議邏輯 如工具、資源、提示詞 JSON PC規範的每條消息 HTTP加SSE負責雙向傳輸 這頭配置很簡潔 任何開發者都能讀懂消息 可以用curl調試 瀏覽器工具可查 直接能用 對獨立系統很完美 但現實中 FCP並非孤立運行 它必須融入企業多年來構建的基礎設施 而那個基礎設施 使用着完全不同的語言 這纔是真實的企業後端架構 Spotify Netflix 谷歌等數千家公司 數百個微服務都通過G2P系谷歌的高性能Web系框架相互通信 服務器約 由Porti定義 服務網格負責路由G2P教育 監控工具能理解G2PC源數據 這就是他們的世界 多年來一直如此 現在MCP過來說 用這一層通過HTTP跟我通信 看出問題了嗎 如果你想讓AI智能體通過MCP與現有服務通信 現在需要爲同一後端圍固兩套協議站 一套是用於現有服務間通信的GRUB系接口 另一套是專爲AI智能體準備的JSON RPC接口 同一服務需要並行維護兩套體系 JSON是基於文本的格式 每個字段名 每個代碼 每個括號 都會序列化爲文本 通過網絡傳輸再緊繫回來 單字調用沒人察覺 但當AI智能體每個繪畫進行數百次工具調用 實時監控資源 流逝傳輸數據時 這種基於文本的開銷就會累積起來 協議緩衝區GRPT的二進制格式體積小得多 處理速度也快得多 第三個問題 缺乏類型安全 JSON RPC是鬆散無模式的 你可以發送任意內容 在運行時之前沒有任何驗證機制 基於Parsee-Japortupov提供嚴格類型契約 你清楚知道有哪些字段 類型 以及哪些是必填項 在生產系統中 錯誤的數據格式可能引發連鎖故障 這點至關重要 接着是轉換成本問題 你的選擇是重寫GRPC服務 以支持JSON RPC 設置兩者間的轉碼代理 或者乾脆長期維護兩套系統 這些方案都不理想 Spotify深有體會 爲此自建了實驗性GRPT傳輸層 於是谷歌出手了 他們正在爲MCP貢獻GRPT傳輸包 關鍵詞是傳輸 MCP本身 協議邏輯 工具 資源 提示詞 這些都不會改變 改變的是協議站的底層 JSON負載被緊湊的二進制類型化協議緩衝區取代 HTTP被基於HTTP2的GRPT代 原生支持全雙供流式傳輸 不再需要SSE這種變通方案 客戶端和服務器可以同時向對方推送數據 現在看看效果 那個原本格格不入的MVP服務器 它也支持GRP 你現有的服務網格可以路由到它 現有監控系統可以觀測它 現有的Portfolio定義可以描述它 它就是個普通的GRPC服務 MCP CXChain重構 支持可插載傳輸 HTTP上的JSON RPC仍是默認選項 GRP成爲首選替代方案 你可以選擇適合基礎設施的傳輸方式 Spotify已經驗證了這點 他們的高級工程師直言 G2T傳輸層讓開發者更熟悉 減少了構建MCP服務器的工作量 還享有靜態類型API的優勢 以實際應用 現在說句實話 這不是萬能領要 首先是性能問題 如果你的AI代理在對話中只教用5次工具 JSON和Portfolio序列化的差異微乎其微 大圓模型推理本身才是性能瓶頸 換成輸協議不會更快 那意義在哪 高頻的智能企工作流 當數百個代理同時運行實時監控資源 大規模部署時 序列化開銷會在每秒數千次請求中備責 還有更深層的問題 G2T能告訴你結構 方法名 參數類型 但LLM不僅需要結構 更需要語意理解 這個工具實際做什麼 什麼時候該用它而不是其他工具 MCP專爲傳遞語意設計 JRPC不是 所以不能直接暴露JWPC服務給AI代理 你仍然需要頂層的MCP描述層 傳輸層變了 但語意需求依然存在 儘管如此 對企業而言 這消除了重度JWPC用戶採用MCP的最大障礙 逐一這個時間點 谷歌在雲平臺推出了託管MCP服務器 它們正在構建完整鏈路 你現有的JWPC基礎設施 可以直接接入谷歌的AI代理平臺 這是針對AWS和Azure的競爭舉措 可插拔傳輸協議不限於JRPC 快速基礎傳輸 邊緣計算優化 MCP開始構建協議規範而非傳輸層規範 那麼更大的問題是 每個新協議最終都必須遷就已存在的基礎設施嗎 MCP最初是AI原生協議 現在它適配JRPC 因爲企業已經在用這個 是務實還是妥協 可能都有 如果你還沒看過我頻道 深入講解過MCP和JWPC 我會把鏈接放在這裏 它們能幫你全面理解今天討論的內容 感謝觀看 我們下期再見