谷歌云宣布将为模型上下文协议（Model Context Protocol，MCP）贡献一个 gRPC 传输包，填补那些在微服务中全面标准化使用 gRPC 的企业所面临的关键空白。MCP 是Anthropic推出的协议，用于实现 AI 智能体与外部工具和数据的集成，目前在企业环境中获得了广泛关注。
目前，MCP 默认使用基于HTTP的JSON-RPC作为传输层。这在处理自然语言负载时表现良好，但对于已全面采用 gRPC 的开发者而言，却带来了极大的不便。其他可选方案包括，重写服务以适配 MCP 的 JSON 传输、搭建转码代理，或并行维护两套独立实现，但是这些方案均不理想。
Spotify 已经亲身体验过这种痛苦。该公司的高级员工工程师兼开发者体验技术负责人 Stefan Särne 在谷歌的博客文章中表示：
由于 gRPC 是我们后端的标准协议，我们已在内部为基于 gRPC 的 MCP 提供了实验性支持，并且我们已经看到了其优势：对开发者而言非常易用且熟悉，同时通过利用结构化和静态类型的 API，减少了构建 MCP 服务器所需的工作量。
这一举措也得到了社区的支持。至少从 2025 年 4 月起，开发者就开始呼吁，在GitHub的一次讨论（#1144）中，从业者们主张 MCP 从一开始就应该围绕 gRPC 构建，部分开发者在此期间已推出了自己基于 gRPC 的 MCP 服务器。2025 年 7 月的一个GitHub 问题（#966）获得了 43 个赞，开发者们指出，基于 HTTP 的 JSON 传输存在 JSON 序列化带来的高开销、资源监听时低效的长轮询，以及 API 契约缺乏类型安全性等问题。MCP 维护者此后已经同意在 SDK 中支持可插拔得传输层，而谷歌计划自行贡献并分发 gRPC 传输包。
通过在底层使用Protocol Buffers替换 JSON，可以显著降低网络带宽和 CPU 开销。对于已部署 gRPC 基础设施的企业而言，这意味着 AI 智能体可以直接与现有服务通信，无需额外添加转换层。Protocol Buffers 的结构化、类型化契约也与大多数后端服务的定义方式更为契合。
但是，该提案并未完全解决一个现实的矛盾。在Medium上，有一篇对比 MCP 与 gRPC 的分析文章指出：“gRPC 的服务反射提供了结构信息（方法名、参数），但缺乏 LLM 所需的语义化、自然语言描述（也就是‘何时’和‘为何’）。”MCP 从设计之初就是为了向 AI 智能体提供这类上下文，即工具描述、资源说明、提示词指导，而 gRPC 本身并不具备这一能力。
因此，更大的架构问题依然存在：MCP 是应该适配 gRPC 这类现有的 RPC 系统，还是这些系统需要学习 MCP 的语言？从业者们对此意见不一。一些人认为，强制将运行良好的 gRPC 服务重写为 JSON-RPC 是完全不必要的麻烦。另一些人则认为，不能简单地将 gRPC 强加于一个以 AI 为中心的协议之上，而不添加 LLM 实际运行所需的语义层。
对于将 AI 智能体投入生产环境的开发者而言，实际优势显而易见。那些已深度使用 gRPC 的企业（包括谷歌自身），它们“在全球范围内依赖 gRPC 来启用服务和提供 API”，现在均可以直接采用 MCP，而无需破坏现有的服务契约了。谷歌还为其自有服务推出了具有全球一致性端点的全托管远程 MCP 服务器，结合 gRPC 支持，使谷歌云能够直接面向那些已投资 gRPC、希望添加 AI 智能体能力的企业。
gRPC 传输层仍在开发中。谷歌正通过 Python SDK 中一个关于可插拔传输接口的活跃pull request，与 MCP 社区合作推进。如果开发者关注该领域的话，MCP 的 GitHub 仓库和贡献者频道是了解最新进展的主要渠道。
原文链接：
