传统 REST API 的转型：Google Cloud API Gateway 终结 MCP 中间件时代

TL;DR 目前处于 Public Preview（公开预览版）的 Google Cloud API Gateway 已原生支持作为远程 MCP 服务器运行。这使得企业能够将 REST 操作转化为 AI 代理工具，而无需构建、托管或维护中间件 MCP 服务器，同时还能完整保留现有的安全和身份验证策略。

传统 REST API 转型是将传统端点直接在流量管理层转化为原生 Model Context Protocol (MCP) 工具的过程，让 AI 代理能够无缝地使用企业数据。在大型企业中引入智能体工程 (Agentic Engineering) 时，往往会面临将大语言模型 (LLMs) 连接到现有交易系统的架构复杂性难题。

传统方法需要开发一个中间 MCP 服务器——这是一种纯粹用于将代理意图转化为基础设施可理解的调用的中间件。这种拓扑结构不仅增加了延迟，重复了安全规则，还推高了平台维护成本。根据 2026年9月24日 Google 发布的公告，这种碎片化的架构已经成为历史。

Google Cloud API Gateway 在其 Public Preview 阶段引入了远程 MCP 服务器功能。这一更新提供了一条快捷且安全的路径，让企业能够管理并直接向代理暴露 Cloud Run 服务。

借助 API Gateway 的新功能暴露 MCP 工具所需的中间件服务器数量 — [Google Developers Blog](https://developers.googleblog.com/en/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/)

彻底消除 MCP 中间件服务器

对于 IT 领导者和云架构师而言，这项更新的主要技术优势在于大幅降低了代理集成的复杂性。在此更新之前，将代理集成到传统数据库意味着必须实现一个 Node.js 或 Python 服务来注册为 MCP 服务器，通过 JSON-RPC 接收调用，重新对请求进行身份验证，执行 REST 调用，然后将响应格式化并返回给代理。

从安全角度来看，这种方法充满风险。架构中引入的每一个中间件都是一个新的攻击媒介和一个新的故障点，必须与代理流量同步进行监控、更新和扩展。

凭借原生充当远程 MCP 服务器的能力，Google Cloud API Gateway 成功打破了这一困境。开发人员现在可以将其现有的 REST 操作直接暴露为供代理即插即用的 MCP 工具，而完全无需构建、托管或维护独立的底层基础设施。

❌ 没有原生 MCP 路由

• 为 MCP 服务器维护独立的容器。
• 身份验证和授权逻辑（API Keys、JWT）的冗余设计。
• 分布式追踪与日志的跨系统手动同步。
• 新工具的部署时间拉长且成本增加。

✅ 采用 API Gateway 原生 MCP

• 直接在 API 管理层进行数据转码 (Transcoding)。
• 现有安全策略的开箱即用与无缝复用。
• 零额外基础设施，省去托管和监控烦恼。
• 通过 OpenAPI 规范中的注释实现可配置暴露。

JSON-RPC 转码与安全策略的完整保留

AI 代理对工具的编排需要极其严格的通信协议。Model Context Protocol 主要依靠结构化 payload 和远程过程调用 (RPC) 运作。此项新功能背后的工程设计，其核心正是对这一通信过程进行了优雅的抽象。

根据 Google 公开发布的技术规范，API Gateway 现可接受集中于单一端点的标准 MCP JSON-RPC 请求。当代理判定需要查询数据库或触发工作流时，它会发送 tools/call 指令。

网关接收到该指令后，会自动将 JSON-RPC 请求转码 (transcoding) 为企业后端对应的 REST 请求格式。执行完成后，它还会将 REST 响应重新翻译回 MCP 语义。

这里的核心架构优势在于治理：这个过程是在保持所有现有安全策略完全不变的情况下进行的。

治理层级	API Gateway 行为 (MCP Mode)
身份验证 (JWT / API Key)	在转码前进行透明验证，完全复用现有 REST 策略。
配额与速率限制	保持激活状态。代理请求会消耗传统服务预先配置的配额。
日志与监控	执行日志保持企业格式不变，确保审计追踪的完整性。

这种安全机制的不退化保证是大规模采用的关键所在。正如我们在探讨建立企业级代理部署基础的分析中深入讨论的那样，当 CTO 明确知道 LLM 无法绕过数据库使用配额，并且一旦 JWT 令牌过期就会被立即拦截时，这项技术的落地就能迅速获得高层的大力支持。

实现与 OpenAPI 规范要求

如果不严格遵守 API 文档标准，将传统的企业 REST 端点转化为可用工具绝非易事。云基础设施需要清晰的正式契约，才能将 MCP 参数准确映射到 HTTP 参数（Path、Query、Body）。

要启用网关内部的 MCP 服务器，对技术文档有一个严格的先决条件：规范必须强制采用 OpenAPI 3.0.x 或 3.1.x 格式。

旧版本（如 OpenAPI 2.0，即以前的 Swagger）不被此路由功能原生支持。在使用版本 2.0 运行旧系统的企业，必须在尝试暴露工具之前，将其规范进行技术迁移至 3.0.x 或更高版本。

注释流程 (Opt-in)

针对代理可暴露哪些内容的精细控制，是通过直接在 OpenAPI 规范文件（YAML 或 JSON）中进行注释来实现的，从而淘汰了碎片化的可视化面板配置模式。这种基础设施即代码 (IaC) 模型十分有利于 CI/CD 流水线的无缝接入。

文档全局启用

开发人员必须使用 x-google-api-management.mcp 注释在文档全局级别启用 MCP 服务器暴露。

操作层级的精细控制

可以使用特定注释 x-google-mcp-tool 对每个端点（操作）进行定制、单独包含或排除。

工具验证标准

为了让注释生效并成功创建工具，操作 [必须具有后端配置且其描述不能为空](https://developers.googleblog.com/en/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/)。描述至关重要，因为这是 AI 代理阅读并决定是否调用该工具的核心文本依据。

# Exemplo conceitual de estrutura de anotação na especificação OpenAPI 3.0.x
openapi: 3.0.3
info:
  title: API Corporativa de Clientes
  version: 1.0.0
x-google-api-management.mcp: true # Opt-in global
paths:
  /clientes/{id}:
    get:
      summary: Retorna dados do cliente
      description: Busca os detalhes completos de um cliente específico pelo ID. # Obrigatório não ser vazio
      x-google-mcp-tool: true # Exposição da operação
      x-google-backend:
        address: https://backend-service.internal

自动化发现：API Hub 与 Agent Registry 的关键角色

工具的技术创建仅仅解决了挑战的一半。在大型企业中，要知晓哪些工具存在、哪些已被弃用，以及针对特定数据流应使用哪些工具，是一个不折不扣的治理（可发现性）问题。

Google Cloud 生态系统通过将该流程集成到 API Hub 中来解决这个问题。将 API 网关连接到此中心后，配置的 MCP 服务器及其特定的 MCP 层元数据将被自动发布。

一旦发布，该服务器及其相应的后端工具就会出现在 Agent Registry 中。这意味着企业工具会瞬间被 AI 代理以及负责编排这些代理的开发人员发现。

这种自动化治理水平消除了传统架构中存在的摩擦：过去，数据团队必须手动将 MCP 端点记录在内部存储库中，并将中间件的主机地址提供给管理 LLM 的团队。对于那些已经在利用工作空间中的互联应用战略的组织来说，将这种自动发现功能扩展到其专有 API 是编排演进的自然结果。

类似于在处理异步进程的更复杂集成和 webhook 策略中所执行的操作，将路由及其契约直接集中在网关层面，有效消除了企业架构中的不透明盲区。

云工程的终极展望

通过原生支持 Model Context Protocol 的 API 管理器来转换传统 REST API，重新定义了基础设施团队的工作边界。

Google Cloud API Gateway 的 Public Preview 模型证明了企业级代理的未来不再依赖于创建更多的应用孤岛（如隔离的 Node.js 中间件），而是通过调整网络边缘（网关）以深入理解 AI 生成的请求。

责任的重心回到了 API 契约本身。一份严格的 OpenAPI 规范——带有妥善的注释并原生支持 JWT 策略——将成为企业真正的长期资产。代理流量被仅仅视作企业现有基础设施的另一个 B2B 消费者，在保持安全合规密不透风的同时，将额外的基础设施成本压缩至接近零。

改造您的传统系统

使用代理编排企业 API

在您的 Cloud Run 基础设施中实施原生 MCP 转换，在确保数据安全完好无损的同时，彻底消除中间件带来的技术债务。

联系专家 → 了解 Agent Factory

常见问题解答

启用 Google Cloud API Gateway 中的 MCP 服务器需要什么条件？ 需要拥有正确配置的 OpenAPI 3.0.x 或 3.1.x 规范。OpenAPI 2.0 版本不被支持，必须在暴露工具前强制迁移至最新版本。

在 MCP 转换过程中，身份验证和配额规则是如何处理的？ API Gateway 在执行转码时，会保留原有基于 JWT 或 API Keys 的身份验证策略。此外，消费配额和访问日志规则对代理请求仍然保持激活并有效。

代理和开发人员如何发现这些新工具？ 当 API Gateway 连接到 API Hub 时，MCP 服务器会被自动发布，将其元数据发送到 Agent Registry。这使得工具目录能被即时发现并随时准备进行编排。

资料来源：

Turn your REST APIs into MCP tools with Google Cloud API Gateway - Google Developers Blog (2026年9月24日)