一行程式碼不用改！搞定HSF轉MCPServer

MCP 為資源訪問和 Multi Agent 互操作提供了標準化的可能。開源社群目前對 MCP 的生態建設非常火熱，mcp.so 已經提供了近 1 萬的 mcp server ，其他各種 MCP 生態元件更是層出不窮。AI 大廠們積極擁抱 MCP ，並紛紛提供了自己的 MCP server。對於開發同學，如何讓自己的業務能快速進入 MCP 生態，要不要跟進和如何快速跟進，已經成為了必須面對的挑戰。

本文產生自阿里巴巴內部 MCP 實踐經驗，實現了應用不做程式碼改動，透過 Higress AI 閘道器實現 MCP 協議解除安裝，快速將內部的 HSF 服務轉換為 MCP Server ，將現有微服務接入 MCP 生態。在業務和技術同時不踏空的前提下，保留對 AI 原生應用基礎設施的選擇權。

HSF 是阿里巴巴內部以 Apache Dubbo 為核心的 RPC 框架，提供了支援超大規模高效能的 RPC 協議和高質量框架層實現支援，為阿里巴巴內部研發同學和業務提供了穩定易用高效的微服務生態。目前阿里內部 HSF 有百萬級別生產級例項，經歷了多年雙十一百億級洪峰考驗。圍繞 HSF，內部也有多年演進出的支援超大規模穩定執行的註冊中心和配置中心，Nacos 就是基於其設計思想脫胎而生的開源產品。

Higress 是阿里阿巴開源的 AI 閘道器。2020 年，Higress 承擔了集團跨 VPC 通訊的重任，在保證高效能的前提下，其豐富的特性顯著降低了業務研發的成本，成為內部跨域通訊的閘道器事實標準。2022 年，在內部穩定執行兩年，經歷了單叢集百萬 QPS 的流量驗證後，Higress 宣佈開源，由於其出色的效能和易用性，迅速就獲得了大量使用者關注，併成為眾多商業化客戶的首選閘道器。 2024 年後，Higress 作為最被廣泛使用的 AI 閘道器，在大模型和 MCP 領域成為官方認證的閘道器方案。

有關 Higress 的開源經歷可以參考這篇文章，https://higress.cn/blog/higress/ 。

在 MCP 生態中, Higress 作為關鍵的基礎設施元件，透過其協議轉換能力，實現了將現有服務無程式碼改動地接入 MCP 生態。在MCP服務託管方案中，Higress 負責接收 MCP 請求並完成協議解除安裝，提供統一的身份認證、流量排程、引數對映與安全審計等能力，使開發者能在不深入瞭解 MCP 協議細節的情況下，快速將現有服務暴露為 MCP Server。這種 hosting 模式有效解決了 MCP 協議快速迭代、SDK 不穩定等挑戰，為企業在 AI 原生應用發展中提供了靈活選擇的空間。

接下來回答一個問題，阿里內部這麼多的 HSF 服務，為什麼選擇 hosting 的方式接入 MCP，而不是原生SDK 的方式接入？

挑戰

MCP 自身演進非常快，內部使用者非常難跟上其迭代節奏。0326的 SPEC 距離上次釋出只過了 4 個月，根據 MCP 2025 的 RoadMap，未來可能還會有 3 次以上的 SPEC 釋出，這些 SPEC 不保證協議層面完全前向相容。很容易遇到現在接入了官方開源的 SDK，後面還需要處理線上的老版本 MCP 如何升級到最新版本的重複投入和穩定性成本問題，對集團核心心應用的研發而言會非常痛苦。
現有 MCP 的 SDK 還比較初級，僅對 SPEC 做了簡單實現，在可用性上遠遠達不到生產級別，需要較長的時間穩定。比如 java-sdk 的 0.7.0 和 0.8.0 的 API 有非常多的改動項，MCP Java SDK Migration Guide: 0.7.0 to 0.8.0。對於應用開發同學而言，不光要升級，還要改接入的程式碼，成本和風險都是翻倍的。
MCP 生態雖然熱火朝天，但缺乏系統化和最優實踐，達到共識的時間成本和個人的學習成本不可忽視。如何快速掌握 MCP 協議和 MCP 應用開發，最快的方式當然是在現有的業務場景裡先跑起來，然後一邊執行一邊學習。那麼如何才能在不懂 MCP 的前提下跑起來自己的 MCP Server ？

轉換 HSF Service -> MCP Server

元件

Higress 閘道器：承接 MCP 流量，提供統一身份認證、流量排程、引數對映、安全審計等切面能力。
MCP 控制檯：AI 應用研發同學建立和維護 MCP server/tools/prompts 的平臺，提供工具託管、除錯、編排能力。
MCP Registry: 註冊中心，負責集團內所有 MCP server 的註冊和 client 發現，由 HSF 註冊中心承擔。
MCP Metadata Center : 儲存提示詞、MCP server 元資料、工具元資料、版本化支援等，由 HSF 配置中心承擔。

操作步驟

step1 ：開啟對應環境的 HSFOPS 後臺，選擇 MCP 側邊欄

step2：選擇需要轉 MCP Tool 的 hsf 應用（自己為 owner/ops 的應用）、服務名和方法名。

注意：工具描述需要準確具體，用於給大模型識別 tool 的用途。

step3：補充標記為 //TODO 部分的 method 的入參的 fieldName 和 description

請求引數結構會自動生成，只需新增名稱(key) 和描述 (description)。

step4：利用上述工具以 mcp sse 方式訪問域名( tool 建立完後一分鐘左右即可被 list )

http://{MCP endpoint prefix}/{applicationName}/sse

cursor 配置如下

{"mcpServers":{"{applicationName}":{"url":"http://{MCP endpoint prefix}/{applicationName}/sse"}}}

實際效果

cursor

AI Infra視角對MCP的思考

MCP 不是銀彈。從分散式領域和 AI 基礎設施的角度看，MCP 作為一個通訊協議或 AI 智慧體協議都不夠成熟，遠達不到生產級別落地的標準。因此，無論是業務還是基礎設施團隊，盲目的選擇 All in MCP 是不負責任的表現。透過快速跟進，快速試錯實現 AI 業務場景的原型落地是更好的選擇。因此，AI infra 團隊關注的重點應是如何降低業務創新的成本，而不是拉上業務一起為自己的錯誤決策埋單。將這一點落實到技術決策，選擇由 Higress 閘道器承擔 MCP 協議解除安裝，再適配內部已有協議是對阿里內部全域性較優的選擇。無論是 MCP 發展到足夠成熟還是被其他的生態取代，業務都可以靈活的選擇跟進或切換，整個公司的基礎設施不會發生 vendor lock-in 。
Market 重要嗎？重要也不重要。AI 智慧體解決的是如何擴充套件 LLMs 的邊界，從而解決更復雜的實際問題。MCP 合理的定位是解決 MxN 的重複建設和標準化資源訪問的問題，MCP Market 是一個自然而然的產品，其存在是有必要性的。但認為掌握了 Market 就掌握了一切，這是本末倒置的想法。合理的路徑是基礎設施適配先做到位，讓業務研發同學能夠有更多的選擇權，更快的迭代速度，自然會有完善易用的 Market 作為門戶存在。前面的積累如果沒有做紮實，後者只能是空中樓閣。
看起來只關注了 Tool 的轉換， Prompts/Roots 和 Sampling 呢？回答這個問題需要擴充套件閱讀一下 MCP 的誕生背景以及使用場景，包括 Anthropic 對其的定位和建立 MCP 的目標。MCP 是 AI 業務工程化的起點裡程碑，但不是終點，在投入 MCP 的同時關注 A2A 和 ANP 這些 AI Agent 互動協議的發展是做 Infra 的團隊的必然選擇。