
如何在Python中使用ChatGPT API?
對于開發者來說,如何將他們的業務快速融入 MCP 生態系統,以及是否需要跟進和如何快速跟進,已經成為他們必須面對的重要挑戰。這不僅涉及到技術層面的適配和集成,還包括對 MCP 生態系統的理解和規劃。開發者需要評估 MCP 對他們業務的潛在價值,以及如何利用 MCP 來增強他們的產品和服務。
本文介紹了一種無需修改應用代碼即可實現 MCP 協議的方法。通過使用 Higress AI 網關,可以將微服務無縫轉換為 MCP Server,從而快速將現有的微服務集成到 MCP 生態系統中。這種方法的優勢在于,它允許業務在不中斷現有技術棧的情況下,平滑過渡到 MCP 生態。這意味著企業可以在不影響業務連續性和技術債務的前提下,探索和利用 AI 原生應用的基礎設施。通過保留對 AI 原生應用基礎設施的選擇權,企業可以靈活地評估和選擇最適合其業務需求的技術解決方案。
在 MCP 生態系統中,Higress 扮演著至關重要的角色,作為一個基礎設施組件,它通過強大的協議轉換功能,使得現有微服務能夠無需修改代碼即可融入 MCP 生態。Higress 的核心能力在于它能夠接收 MCP 請求并執行協議轉換,同時提供一系列關鍵的服務,包括統一的身份驗證、流量管理和參數映射,以及安全審計等。
這種服務托管方案極大地簡化了開發者的工作流程,他們無需深入理解 MCP 協議的復雜細節,就能迅速將現有的服務轉化為 MCP Server。這不僅提高了開發效率,還降低了技術門檻,使得更多的微服務能夠快速接入 MCP 生態。Higress 的托管模式還有效應對了 MCP 協議快速迭代和 SDK 不穩定的挑戰。它為企業提供了一個靈活的選擇空間,使他們能夠在 AI 原生應用的發展中,根據業務需求和技術發展靈活地選擇合適的技術和服務。這種模式不僅加速了企業對新技術的采納,還為企業提供了更大的靈活性和自主性,以適應不斷變化的市場和技術環境。
阿里 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 協議。
—1—
我們先來了解一下普通的微服務調用過程。
首先,調用方(Consumer)需要知道微服務提供方(Provider)的地址(可以是一個域名或 IP 地址)。然后,調用方根據事先約定好的參數,對微服務接口進行調用。整個調用流程如下圖所示:
在日常開發中,我們通常已經熟悉了當前微服務提供方的接口集合以及接口參數的具體作用。因此,我們可以在業務代碼中編寫調用邏輯,實現服務之間的調用。
對于大模型來說,這些調用上下文同樣是必不可少的。大模型需要了解服務提供方的接口集合以及接口的詳細描述,才能根據上下文進行接口調用。
對于已經使用 Nacos 作為注冊配置中心的存量服務,Nacos 中已經保存了服務的調用地址。我們只需要增加服務的接口信息,就可以實現大模型調用上下文的構建。
為此,Nacos 引入了“應用全局描述”這一概念,用于描述當前應用及其接口的詳細信息。通過統一的接口描述協議,我們可以對 Nacos 中的服務進行 MCP 化改造。對于之前未在 Nacos 中注冊的服務,我們可以通過 Nacos 的持久化服務發現功能手動進行注冊。
在配置完服務相關信息后,MCP 協議所需的數據已經完備。接下來,我們需要考慮如何通過 MCP 協議將這些數據暴露出去。這里,我們利用 Higress 的插件機制來實現 MCP 協議的暴露能力。調用流程圖如下:
MCP 協議目前支持多種資源(Tool、Prompt、Resource 等),Nacos 優先實現了使用量較高的 Tool,并借助 Higress 提供的統一 SSE 協議支持,加速了 MCP Server 的構建,整體架構設計如下圖所示:
在架構設計上,Nacos 通過在 Higress 中的 MCP Server 插件實現了 Nacos 中管理的 Tools 的暴露。
對外通過 MCP 協議暴露普通 HTTP 服務,需要先完成以下兩件事:
暴露 tool/list 接口
協議轉化
在整體實現中,Nacos 作為 MCP Registry,扮演控制面的角色,管理 Tool 的元信息。Higress 在數據面負責協議轉換和 RPC 調用。存量服務只需添加接口描述,無需進行任何改動。
存量 API 快速構建 MCP Server
MCP 信息動態下發實時生效
MCP 信息歷史版本管理
MCP 信息灰度管理
密碼配置加密
MCP 返回格式 JSON 轉換 XML格式優化
MCP 服務管理及健康檢查
通過這些功能,Nacos 和 Higress 的結合為 MCP Server 的構建和管理提供了全面的支持,幫助用戶快速、安全地實現 MCP 協議的落地。
—2—
借助 Nacos 與 Higress 的組合方案,能夠實現無需代碼改造,將顯存微服務快速改造成 MCP Server,從而大幅削減現有應用的改造成本。目前,用戶需手動配置接口描述信息,但未來 Nacos 計劃通過工具化手段進一步簡化這一流程,使用戶僅需進行微調即可完成配置。
在實際場景中,我們面臨著海量的存量服務與接口。按照接口到 Tool 的映射規則,我們將產生大量的 Tool。當 Agent 獲取 Tool 列表并將其傳遞給大模型時,這將導致大量的 token 消耗,進而可能影響大模型的性能。因此,如何在上下文中精準篩選出有效的 Tool 列表,并將其高效返回給 Agent 智能體,將成為后續發展的關鍵方向之一。
除了 Tool,MCP 協議還涵蓋 Prompt、Resource 等多種資源,MCP 社區也在持續對協議進行更新。相信 Nacos 將逐步支持這些新特性,為 MCP 生態的繁榮貢獻力量。
原文轉載自:https://mp.weixin.qq.com/s/4lHIY4HBLMUip9NpCtH09Q