阿里巴巴MCP分布式落地：HSF快速转为MCP服务

可以先说几个核心判断。

MCP在资源访问与多智能体互操作方面，确实提供了一种标准化的可行性路径。当前开源社区围绕MCP生态的建设热情空前高涨，mcp.so已上线近万个MCP Server，各类生态组件更是层出不穷。AI大厂们也纷纷积极拥抱MCP，相继推出自己的MCP Server。对于开发者而言，如何让自身业务快速融入这一生态，是否需要跟进以及如何高效推进，已经成为一个无法回避的现实课题。

这篇文章源自阿里巴巴内部的MCP实战经验。核心思路是：应用代码完全无需改动，借助Higress AI网关实现MCP协议的卸载，从而将内部庞大的HSF服务快速转换为MCP Server，让现有微服务平滑接入MCP生态。这样既能帮助业务和技术紧跟趋势、不掉队，又能保留未来对AI原生应用基础设施的选择权。

背景：HSF与Higress

先简单交代一下这两个关键组件。

HSF是阿里巴巴内部以Apache Dubbo为内核的RPC框架，专为超大规模、高性能场景设计，为内部研发同学提供了稳定、易用、高效的微服务生态。目前阿里内部拥有百万级别的生产级实例，经历过多年双十一百亿级洪峰的实战考验。围绕HSF，还沉淀出了一套支持超大规模稳定运行的注册中心和配置中心，大家熟悉的Nacos正是基于其设计思想脱胎开源的。

Higress是阿里巴巴开源的一款AI网关。2020年，它承担了集团跨VPC通信的重任，在保证高性能的同时，丰富的特性显著降低了业务研发成本，成为内部跨域通信的网关事实标准。2022年，在内部稳定运行两年、经历单集群百万QPS流量验证后，Higress宣布开源。凭借出色的性能和易用性，很快获得大量关注，成为众多商业化客户的首选网关。到了2024年，Higress作为最广泛使用的AI网关，在大模型和MCP领域获得了官方认证。

在MCP生态中，Higress的角色是核心基础设施。它通过协议转换能力，实现了现有服务无代码改动地接入MCP。具体来说，Higress负责接收MCP请求并完成协议卸载，提供统一的身份认证、流量调度、参数映射与安全审计等能力。开发者不需要深入了解MCP协议细节，就能把现有服务暴露为MCP Server。这种hosting模式，有效解决了MCP协议快速迭代、SDK不稳定等现实挑战，为企业在AI原生应用发展中提供了灵活的选择空间。

为什么选Hosting，而不是原生SDK？

阿里内部HSF服务那么多，为什么最终选择用Hosting的方式接入MCP，而不是直接上原生SDK？

答案在于几个关键的挑战。

挑战

• MCP自身演进太快。 0326的SPEC距离上次发布只过了4个月。根据MCP 2025的RoadMap，未来可能还会有3次以上的SPEC发布，而且这些SPEC不保证协议层面完全前向兼容。如果现在用官方开源的SDK接入了，后面就得处理线上老版本MCP如何升级到最新版本的重复投入和稳定性成本，这对核心应用的研发来说，简直是噩梦。

• 现有MCP SDK还比较初级。 目前SDK只是对SPEC做了简单实现，可用性远没达到生产级别，需要很长时间才能稳定。比如Java SDK的0.7.0到0.8.0版本，API改动非常多。对应用开发同学来说，不光要升级，还得改接入代码，成本与风险都直接翻倍。

• 缺乏系统化实践。 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的应用）、服务名和方法名。注意：工具描述需要准确具体，便于大模型识别工具用途。

step3：补充标注为"TODO"部分的Method入参的fieldName和description。请求参数结构会自动生成，只需添加名称（key）和描述（description）。

step4：通过工具以MCP SSE方式访问域名：http://{MCP endpoint prefix}/{applicationName}/sse

实际效果

以Cherry Studio为例：

从AI Infra视角看MCP

从一个AI基础设施的视角，想聊几个更底层的思考。

• 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是AI业务工程化的起点里程碑，但不是终点。在投入MCP的同时，持续关注A2A和ANP这些AI Agent交互协议的发展，是做Infra团队的必然选择。

总结

这篇文章分享了阿里内部大规模HSF服务快速转换为MCP Server的实践，核心目标是帮助业务同学降低改造成本，快速融入MCP生态，紧跟AI原生应用的发展节奏。目前看，MCP只是第一步，AI原生应用的路还很长。希望这篇文章能对AI Infra领域感兴趣的同学和团队有所启发。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：阿里巴巴MCP分布式落地：HSF快速转为MCP服务要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题