阿里巴巴 MCP 分布式落地实践：快速转换 HSF 到 MCP server

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 方式访问域名
http://{MCP endpoint prefix}/{applicationName}/sse
实际效果

Cherry Studio

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 的团队的一定选择。
  

总结

本文提供了阿里内部大规模 HSF 服务快速转换为 MCP Server 的实践，用于帮助业务同学降低改造资本，快速融入 MCP 生态，紧跟 AI 原生应用的发展速度。目前看来，MCP 只是第一步，AI 原生应用的路还很长，盼望这篇文章能对 AI Infra 领域感兴趣的同学和团队有所开导。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。