Model Context Protocol（MCP）模型上下文協議（如下圖所示）是 Anthropic 發布的一種標準化協議，使得 Agent 智能體應用可以方便快捷地與下游異構的數據或者工具進行交互，還不熟悉的同學可以看下這兩篇文章《??王炸！MCP 架構設計深度剖析 & 使用 Spring AI + MCP 四步教你實現 Agent 智能體開發????》、《???MCP 架構設計演進：從 Local MCP Server 到 Remote MCP Server 開源架構設計實現???》。

最近，兩大關鍵事件標志著 MCP 已從事實標準邁向行業標準：一方面，OpenAI 正式宣布跟進 Anthropic 的 MCP 協議，另一方面，Anthropic 發布了新版本 MCP 協議，在 Remote MCP Server 的場景進行了顯著改進。

但是，云原生存量業務架構中的 API 改造成 MCP Server，既面臨時間成本，還有人力上的挑戰。企業對能提升 MCP 構建效率的開源和商業方案愈加渴望。

阿里 Nacos（Naming and Configuration Service）作為云原生注冊配置中心，最近發布了 MCP Registry，讓存量業務 API “0改動”就可以適配 MCP Server。

Nacos 在作為 MCP Registry ，承擔著控制面板的關鍵角色。它不僅負責管理 Tool 的元信息，還能將現有的 API 轉化為符合 MCP 協議的接口。借助 Nacos，云原生存量業務應用可以迅速將其已有的業務 API 接口轉換為 MCP 協議接口，并通過與 Higress AI 網關的結合，實現 MCP 協議與現有協議之間的無縫轉換。在這個過程中，Nacos 提供了對現有服務的管理以及動態服務信息的定義，使得業務能夠在不改動現有接口的前提下，通過 Nacos 的服務管理功能，動態地應用 Higress 網關生成的 MCP Server 協議。

下文對 Nacos MCP Registry 架構設計詳細剖析之。

1、Nacos MCP Regisry 架構設計剖析

第一、Nacos 0代碼適配 MCP Server 的架構原理剖析

我們先來了解一下普通的服務調用過程。首先，調用方（Consumer）需要知道服務提供方（Provider）的地址（可以是一個域名或 IP 地址）。然后，調用方根據事先約定好的參數，對服務接口進行調用。整個調用流程如下圖所示：

在日常開發中，我們通常已經熟悉了當前服務提供方的接口集合以及接口參數的具體作用。因此，我們可以在業務代碼中編寫調用邏輯，實現服務之間的調用。對于大模型來說，這些調用上下文同樣是必不可少的。大模型需要了解服務提供方的接口集合以及接口的詳細描述，才能根據上下文進行接口調用。

對于已經使用 Nacos 作為注冊配置中心的存量服務，Nacos 中已經保存了服務的調用地址。我們只需要增加服務的接口信息，就可以實現大模型調用上下文的構建。

為此，Nacos 引入了“應用全局描述”這一概念，用于描述當前應用及其接口的詳細信息。通過統一的接口描述協議，我們可以對 Nacos 中的服務進行 MCP 化改造。對于之前未在 Nacos 中注冊的服務，我們可以通過 Nacos 的持久化服務發現功能手動進行注冊。在配置完服務相關信息后，MCP 協議所需的數據已經完備。接下來，我們需要考慮如何通過 MCP 協議將這些數據暴露出去。這里，我們利用 Higress 的插件機制來實現 MCP 協議的暴露能力。調用流程圖如下：

第二、Nacos MCP Registry 整體架構設計剖析

1.Nacos MCP Regisry 架構設計

MCP 協議目前支持多種資源（Tool、Prompt、Resource 等），Nacos 優先實現了使用量較高的 Tool，并借助 Higress 提供的統一 SSE 協議支持，加速了 MCP Server 的構建，整體架構設計如下圖所示：

在架構設計上，Nacos 通過在 Higress 中的 MCP Server 插件實現了 Nacos 中管理的 Tools 的暴露。對外通過 MCP 協議暴露普通 HTTP 服務，需要先完成以下兩件事：

• 暴露 tool/list 接口

    功能：由 Higress AI 網關返回所有的 Tool 列表。

    實現：tool/list 方法主要負責將當前 MCP Server 支持的 Tool 的詳細信息列表返回給 MCP Client。返回信息包含 Tool 的作用描述和 Tool 的參數描述（包含類型、作用等）。通過將 Nacos 存儲的描述信息轉化為標準的 MCP 協議里的 tool/list 結果，返回給 MCP Client。

• 協議轉化

    功能：將 MCP 協議的 JSON RPC 轉化為普通 HTTP 請求，并轉發到后端服務。

    實現：當 MCP Client 調用 Tool 時，Higress 將 tool/call 的 JSON RPC 請求解析出來，通過用戶配置的參數映射信息、Path、后端地址等信息，Higress 生成后端的 HTTP 調用請求，并進行調用。調用完成后，再將后端的調用結果包裝成標準的 tool/call 接口調用的返回結果。

在整體實現中，Nacos 作為 MCP Registry，扮演控制面的角色，管理 Tool 的元信息。Higress 在數據面負責協議轉換和 RPC 調用。存量服務只需添加接口描述，無需進行任何改動。

2.使用 Nacos MCP Registr 架構設計的優勢

• 存量 API 快速構建 MCP Server

    Nacos 集成 Higress 的方案：通過 Nacos 和 Higress 的集成，用戶可以實現零代碼快速構建 MCP Server，迅速跟進 MCP 協議，無縫對接存量 API。

• MCP 信息動態下發實時生效

動態調試與優化：MCP 描述信息、Tools 以及 Prompt 都需要經過調試才能達到最佳效果。Nacos 能夠幫助管理和下發這些信息，實現動態調整和實時生效，提高調試效率。

• MCP 信息歷史版本管理

版本管理與回滾：Nacos 會管理和存儲 MCP 信息的歷史版本，方便進行 Diff 對比差異，在出現問題時能夠快速回滾到之前的版本，確保系統的穩定性和可靠性。

• MCP 信息灰度管理

灰度分批生效：在 MCP 信息生效時，Nacos 支持灰度分批生效，允許逐步推廣新配置，方便對比不同版本的效果，降低風險。

• 密碼配置加密

敏感信息保護：在 MCP 信息和 API 調用過程中，涉及密碼等敏感信息時，Nacos 提供了 敏感信息加密 的能力，確保數據的安全性。

• MCP 返回格式 JSON 轉換 XML

格式優化：在與大模型交互時，JSON 格式可能不如 XML 格式直觀。Nacos 可以幫助將 MCP 的返回格式從 JSON 轉換為 XML，使大模型更容易理解和處理。

• MCP 服務管理及健康檢查

服務管理與監控：隨著 MCP 服務數量的增加，Nacos 提供了大規模服務管理能力，包括健康檢查、實時更新和負載均衡，確保 MCP 服務的高效運行，同時作為 MCP 服務發現中心的托管平臺。

通過這些功能，Nacos 和 Higress 的結合為 MCP Server 的構建和管理提供了全面的支持，幫助用戶快速、安全地實現 MCP 協議的落地。

2、Nacos MCP Regisry 架構設計總結

借助 Nacos 與 Higress 的組合方案，能夠實現無需代碼改造，將 AI Agent 智能體無縫連接至現有應用，從而大幅削減現有應用的改造成本。目前，用戶需手動配置接口描述信息，但未來 Nacos 計劃通過工具化手段進一步簡化這一流程，使用戶僅需進行微調即可完成配置。在實際場景中，我們面臨著海量的存量服務與接口。按照接口到 Tool 的映射規則，我們將產生大量的 Tool。當 Agent 獲取 Tool 列表并將其傳遞給大模型時，這將導致大量的 token 消耗，進而可能影響大模型的性能。因此，如何在上下文中精準篩選出有效的 Tool 列表，并將其高效返回給 Agent 智能體，將成為后續發展的關鍵方向之一。除了 Tool，MCP 協議還涵蓋 Prompt、Resource 等多種資源，MCP 社區也在持續對協議進行更新。相信 Nacos 將逐步支持這些新特性，為 MCP 生態的繁榮貢獻力量。

本文轉載自公眾號玄姐聊AGI  作者：玄姐

原文鏈接：??https://mp.weixin.qq.com/s/nQF-bUcmODpqo_SGPSxfbg??