谷歌推动在模型上下文协议中加入对gRPC的支持

谷歌云宣布，将为Model Context Protocol（MCP）提供一个gRPC传输包，以此填补那些已经在所有微服务中采用gRPC作为通信协议的企业的实际需求。MCP是Anthropic开发的一种协议，它能够将AI代理与外部工具及数据相结合，在企业环境中正逐渐获得广泛的应用。

目前，MCP默认使用HTTP上的JSON-RPC作为传输机制。这种方案在处理自然语言数据时表现良好，但对于那些已经在所有系统中使用gRPC的开发者来说，却带来了不少麻烦。其他解决方案包括：重新编写服务代码以支持MCP的JSON传输格式、搭建转码代理服务器，或者同时运行两种不同的传输机制——但这些方法都不太理想。

Spotify就曾亲身经历过这种困扰。该公司的资深工程师Stefan Särne在谷歌发布的博客文章中详细说明了这一情况：

由于gRPC是我们后端服务的标准通信协议，因此我们内部已经开始为MCP提供基于gRPC的实验性支持。目前我们已经看到了这种方案带来的好处：它让我们的开发者更加容易使用这些技术，并且由于使用了结构化且具有类型安全的API，大大减少了构建MCP服务器所需的工作量。

这一倡议也得到了社区的支持。早在2025年4月，开发者们就已经开始呼吁推广这种方案。在GitHub上，有一个编号为#1144的讨论帖中，许多开发者认为MCP应该从一开始就基于gRPC进行设计；事实上，当时已经有一些团队开始开发自己的基于gRPC的MCP服务器。2025年7月，另一个编号为#966的讨论帖也获得了43个赞，开发者们指出了HTTP上的JSON传输方式存在的种种问题：JSON序列化会带来较高的开销、长轮询机制效率低下，而且API合同的类型安全性也不够强。因此，MCP的维护者们最终同意在SDK中支持可插拔的传输机制，而谷歌也计划自己贡献并分发这个gRPC传输包。

如果用Protocol Buffers来替代现有的JSON传输方式，那么网络带宽消耗和CPU开销都将会显著降低。对于那些已经建立了基于gRPC的基础设施的企业来说，这意味着AI代理可以直接与现有的服务进行通信，而无需添加额外的转换层。此外，Protocol Buffers的结构化、类型化的契约格式也更符合大多数后端服务的设计规范。

然而，这个提案并没有完全解决所有问题。一篇发表在Medium网站上的分析文章指出：“虽然gRPC的服务器反射机制能够提供方法名称、参数等结构化信息，但它缺乏大语言模型所需要的语义性描述和自然语言说明。”而MCP正是从一开始就为AI代理提供了这些必要的信息，包括工具的使用说明、资源的相关解释以及提示指导等内容。因此，gRPC本身并不具备这种功能。

因此，一个更重要的问题依然存在：MCP是应该顺应现有的RPC系统（如gRPC）进行调整，还是这些系统应该学会使用MCP的语言进行通信？业界对此意见不一。一些人认为，强迫已经运行良好的gRPC服务重新采用JSON-RPC格式只会带来不必要的麻烦；而另一些人则认为，如果不在AI相关协议中添加大语言模型真正所需的语义层，就无法将gRPC直接应用到这些协议中。

对于那些正在将AI代理功能投入实际生产的开发者来说，MCP带来的实际好处是显而易见的。那些已经深入使用gRPC的技术企业——比如谷歌本身就利用gRPC“在全球范围内提供各种服务与API”——现在可以轻松采用MCP，而无需修改现有的服务架构。谷歌还推出了完全托管的远程MCP服务器，这些服务器为自身的服务提供了全球统一的标准接口；结合对gRPC的支持，谷歌云能够直接吸引那些已经投资了gRPC技术、希望进一步增强自身AI功能的企业。

目前，gRPC传输机制仍在开发中。谷歌正通过与MCP社区的合作，在Python SDK中积极推进可插拔传输接口的开发工作。如果开发者关注这一进展，那么MCP的GitHub仓库以及相关的贡献者交流渠道就是获取最新信息的最佳途径。