企业想把智能体接进老系统，最别扭的一截一直是「中间那层」。传统做法要专门养一个 MCP 服务器：用 Node 或 Python 写个服务，注册成 MCP server，接收智能体的 JSON-RPC 调用，重新认证，再翻译成后端 REST 请求，最后把结果格式化回去。这层中间件既是延迟来源，也是新的攻击面，还得跟着智能体流量一起扩容、一起盯日志。9 月 24 日 Google Cloud 宣布 API Gateway 在 Public Preview 阶段原生充当远程 MCP 服务器，等于把这一层从「你要自己建」变成「网关顺手做」。
机制说白了是转码。API Gateway 现在能在一个端点直接收标准的 MCP JSON-RPC 请求；智能体发 tools/call，网关把它翻译成对应的 REST 请求打给后端（比如 Cloud Run 上的服务），执行完再把 REST 响应翻译回 MCP 语义。对智能体来说，调用的还是 MCP 工具；对后端来说，来的还是它熟悉的 REST。中间不再有独立容器、不再重复一套认证授权逻辑、不再手动同步日志和链路追踪。
真正让企业 CTO 点头的，不是「少养一个服务」，而是安全策略不退化。网关转码时，既有的认证（JWT / API Key）在转码前透明校验，直接复用原 REST 策略；既有的配额和限流继续生效，智能体请求照样消耗老服务的额度；执行日志保持企业原有格式，审计链不断。换句话说，CTO 敢放开接入的前提——「模型绕不过数据库配额、JWT 过期就被拦」——在网关这层天然成立。一份新工具暴露出来，不用重写一遍安全边界。
代价也有。这功能不是开箱即用无门槛：要启用网关内置的 MCP server，规范必须是 OpenAPI 3.0.x 或 3.1.x；跑在 2.0（旧 Swagger）上的老系统得先迁规范，网关才能把 MCP 参数映射到 HTTP 的 Path、Query、Body。也就是说，它奖励的是「API 文档规范、契约清晰」的团队，对文档稀烂的遗留系统帮助有限。这其实和 MCP 生态的整体走向一致：协议成熟后，拼的是工程卫生，不是再堆一层适配。
把这件事放进 9 月的 MCP 图景里看。前几周安全方反复提醒：MCP 今年夏天的协议升级（去会话态、Tasks 扩展、企业托管授权）解决的是「好跑、好登录」，不是「行为可信」；而 Morgan Stanley、Cloudflare 等也在推各自的 MCP 网关思路。Google 这步的方向和他们一致——把 MCP 终结在流量管理层，让治理复用既有的 API 网关能力，而不是在智能体侧另起一套。对企业来说，这意味着「接智能体」的边际成本进一步下降，离「凡是 REST 都能被智能体调用」又近一步。
照例冷静：以上来自 Google 9/24 的发布说明与开发者博客，具体配额、预览限制、地域可用性以官方文档为准；「零额外基础设施」是相对自建 MCP 中间件而言，网关本身的配置与 OpenAPI 迁移成本仍需计入；对已经大量使用其他云 MCP 网关的团队，迁移收益取决于现有债务。但信号清楚：MCP 的 adoption 故事，正从「多一个服务器」转向「网关一层搞定」。对仍用自建 MCP 中间件的团队，迁移前先算清网关配置与 OpenAPI 迁移的隐形成本，再决定是否切换。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。