MCP 架構設計剖析:從 Service Mesh 演進到 Agentic Mesh 原創 精華
MCP 最近越來越火熱,MCP 從架構設計的角度來看,它本質上是數據或者工具的代理層(Proxy),隨著多 Agents 智能體應用在企業復雜業務場景中的落地,如何讓自主 Agent 間能夠相互發現、協作、互動和交易?Agentic Mesh 應運而生。而 MCP 架構正是 Agentic Mesh 的一種落地實現方式,下我詳細剖析。
為了幫助大家理解 Mesh 架構的設計,我們先剖析下 Service Mesh。
1、Service Mesh 架構設計剖析
第一、Service Mesh 架構定義
微服務架構繼續演進,就變成了 Service Mesh 架構(服務網格)。Servie Mesh 架構最早由開發 Linkerd 的 Buoyant 公司提出,并在內部使用。2016年09月29日第一次公開使用,2017年初進入國內技術社區視野。Service Mesh 到底是什么?我們來看看 Linerd 公司 CEO Willian Morgan 對 Service Mesh 的定義如下圖所示:

Service Mesh 是一個基礎設施層,用于處理服務間交互。云原生應用有著復雜的服務拓撲,Service Mesh 負責在這些拓撲中實現請求的可靠傳遞。在線上實踐中,Service Mesh 通常實現為一組輕量級的網絡代理(Sidecar 邊車),它們與應用程序部署在一起,并且對應用程序透明。

如上圖所示,應用程序A和應用程序B交互,請求調用關系如下:應用程序A調用本地的 Sidecar A,Sidecar A 在通過網絡交互調用遠端的 Sidecar B,再由 Sidecar B 把請求傳遞給應用程序B。請求回應關系也是類似:應用程序B調用 Sidecar B,Sidecar B 在通過網絡交互調用遠端的 Sidecar A,再由 Sidecar A 把請求回應傳遞給應用程序A。通過把服務治理功能從服務自身中物理剝離出來,下沉形成獨立的進程,從而物理解耦。
在這樣的架構模式下,業務應用程序再也不需要關注服務治理的功能,服務治理的功能升級也不要依賴于服務自身,從而能夠讓業務迭代更快速和高效。同時由于服務治理功能變成一個獨立的進程,只需要使用一種語言打造即可,業務服務自身可以選擇業務團隊擅長的語言進行編寫,從而能夠真正達到馬丁福勒對微服務的期望。
我們再深入分析下協議,在通信協議方面,業務應用程序和 Sidecar 的通信可以基于 TCP 長連接,也可以基于 HTTP 1.0 或者 2.0 的長連接(思考下:是否一定要使用長連接?),Sidecar 間的通信協議沒有特殊要求;在數據傳輸協議方面,可以是 JSON/XML 等跨語言的文本協議,也可以選擇 Protobuffers/MessagePack 等跨語言的二進制協議。
保證了通信協議和數據傳輸協議的跨語言,不同語言的應用程序就可以無縫地和 Sidecar 進行交互。在應用程序和對應的 Sidecar 部署層面,需要部署在同機(可以是同一臺物理機/虛擬機,也可以是同一個Pod)。
思考下:如果部署在不同的機器上,就會又引入服務通信交互的問題,那么就會變成無解的難題:為了解決通信交互的問題,又引入新的通信交互的問題。
第二、Service Mesh 架構落地實踐
在企業中落地 Service Mesh 的架構設計如下圖所示:

Service Mesh 架構框架方面,業內陸續開源了不少的優秀框架,Istio 是集大成者,由 Google、IBM、Lyft 等三家公司聯合打造,并已經開源,社區版本也已經發展到 Istio 1.25.0。IstioService Mesh 邏輯上分為數據面板(執行者)和控制面板(指揮者),數據面板由一組智能代理(Envoy)組成,代理部署為 Sidecar,調解和控制微服務之間所有的網絡通信。控制面板負責管理和配置代理來路由流量,以及在運行時執行策略。如下圖所示,控制面板(Pilot、Mixer、Citadel)加數據面板(Envoy Proxy)即是服務治理功能,svcA 和 svcB 是業務服務自身。

2、MCP:Agentic Mesh 架構設計剖析
第一、AI 大模型新時代的應用:Agent 智能體
Agent 智能體正逐漸成為企業 AI 的中流砥柱。這些數字化的“員工”能夠獨立完成任務、做出決策,并與其他 Agent 智能體協同工作,幾乎不需要人工干預。目前面臨的主要挑戰包括:

- 如何構建可擴展的 Agent 系統;
- 確保 Agent 系統的安全性和可靠性;
- 實現不同 Agent 間的順暢協作;
- 使 AI 決策與企業目標高度一致。
Agentic Mesh 被視作企業的“AI 協作平臺”,它提供了一個標準化框架,使得:
- 不同功能的 Agent 能夠安全高效地互聯互通;
- 支持復雜業務流程的自動化處理;
- 確保整個 Agent 系統隨著業務發展的靈活擴展。
這相當于為企業建立了一個“數字員工團隊”,他們各司其職且緊密協作,顯著提高運營效率和決策質量。
Agent 是一種能夠感知環境、處理信息并執行行動以實現特定目標的系統,其主要特性包括:

- 自主性/自治性:無需直接人為干預即可運作的能力;
- 反應性:能夠實時響應環境變化;
- 主動性:能夠預測未來的需求并采取相應行動;
- 社交性:能夠與其他個體、人類和系統進行互動與合作。
這些特性使得自治 Agent 能夠推動企業環境中的自動化、優化流程和改進決策。
第二、MCP:Agentic Mesh 架構設計
Agentic Mesh 是讓自主 Agent 能夠相互發現、協作、互動和交易的互聯生態系統。Agentic Mesh 生態系統組成包括:

- Marketplace:用戶發現和使用 Agent 的主界面;
- Registry:Agent 元數據的中央存儲庫;
- DNS 系統:Agent 定位和連接服務;
- 自主 Agent:由 GenAI 驅動的執行實體
Agentic Mesh 包括3大核心流程:Agent 注冊流程、Agent 發現流程、Agent 執行流程。
1.Agent 注冊流程
Agentic Mesh 的注冊流程包括:通信 API、控制服務、元數據管理、運行時等4個模塊層,詳細如下:

2.Agent 發現流程

3.Agent 執行流程

為了打造一個具備彈性和可伸縮性的 Agentic Mesh,我們需要遵循以下關鍵原則來設計系統:
- 可發現性:Agent 必須能夠動態注冊、定位以及與其他相關節點進行交互。
- 互操作性:跨平臺和跨 Agent 的通信必須無縫,利用開放標準,比如:API、語義本體和協議緩沖。
- 安全性和信任:必須嵌入加密方法、身份管理和訪問控制,以防止未經授權的交互并確保 Agent 的完整性。
- 可伸縮性:體系結構應支持越來越多的 Agent 和任務,同時不降低性能。
- 治理和合規性:必須制定政策和執行機制,以規范 Agent 行為并確保遵從企業法規。
通過整合這些原則,組織可以構建一個模塊化、有彈性的生態系統,Agentic Mesh 能夠有效處理不同的企業工作負載。
AI Agent 不僅能執行預定義的任務,而且能夠產生新見解、綜合信息并自主地改進策略。Agentic Mesh 將在確保這些 AI 驅動的系統保持互操作性、安全性和與企業目標一致方面發揮關鍵作用。
為了構建 Agentic Mesh,需要實踐:
- 開發標準化的 Agent協議:建立 Agent 到 Agent 通信的最佳實踐。
- 實施 AI 治理框架:確保 AI 的道德使用和遵守監管準則。
- 采用混合 AI 部署策略:利用云部署、私有部署和邊緣部署來實現最佳 Agent 性能。
- 多 Agent 仿真實驗:在產品推出之前在沙箱環境中測試大規模的 Agent 交互。
設計這些生態系統時,首先考慮可伸縮性、安全性和治理,以確保可持續和有效的采用。通過擁抱 Agentic Mesh,企業可以釋放新的效率,提高決策,并加速AI驅動的大規模創新。
然而,Agentic Mesh 的解決方案尚未經過大規模的實際考驗,也未形成業界的最佳實踐,需要我們去探索和實驗。
最近興起的 MCP(Model Context Protocol)是個不錯的選擇,本質是 Agentic Mesh 的一種架構設計和實現,它提供了一種連接 AI 應用與外部系統的開放標準,有助于推動 Agentic Mesh 的發展和實現。
總之,Data Mesh 面向的是數據產品, Servcie Mesh 面對的是服務的復雜性管理,而 Agentic Mesh 則是多 Agent 系統的一種實現方式 ,它們的架構設計理念是類似的,只不過 Agentic Mesh 仍然在實踐探索之中,MCP 有望成為 Agentic Mesh 架構設計落地的一種優雅實現方案。
本文轉載自公眾號玄姐聊AGI 作者:玄姐

















