挑战
Cloud Native
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
Cloud Native
组件
Higress 网关：承接 MCP 流量，提供统一身份认证、流量调度、参数映射、安全审计等切面能力。 MCP 控制台：AI 应用研发同学创建和维护 MCP server/tools/prompts 的平台，提供工具托管、调试、编排能力。 MCP Registry: 注册中心，负责集团内所有 MCP server 的注册和 client 发现，由 HSF 注册中心承担。 MCP Metadata Center : 存储提示词、MCP server 元数据、工具元数据、版本化支持等，由 HSF 配置中心承担。
操作步骤
实际效果
AI Infra 视角对 MCP 的思考
Cloud Native
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 的团队的必然选择。
总结
Cloud Native
本文提供了阿里内部大规模 HSF 服务快速转换为 MCP Server 的实践，用于帮助业务同学降低改造成本，快速融入 MCP 生态，紧跟 AI 原生应用的发展速度。目前看来，MCP 只是第一步，AI 原生应用的路还很长，希望这篇文章能对 AI Infra 领域感兴趣的同学和团队有所启发。
