Google 于 2026 年 8 月 4 日宣布，Google Cloud API Gateway 的 model routing 进入 Public Preview。它是一层 managed、serverless 的 ingress，接受 OpenAI-compatible 请求，再按配置把请求转发到 Vertex AI 上的 Gemini、Claude 或 open-weight GPT 模型。对开发者来说，应用程序可以维持一套请求接口，把模型选择和部分 provider-specific 转换放到 gateway。
路由规则可以把一个 default model 和多个 override rule 放在同一个 router 中。应用程序仍然发出标准化的 chat request，gateway 会根据 request 中的 model 名称选择后端，并把 OpenAI 格式转换成目标模型需要的 native schema。这种设计减少了应用程序直接管理多个 SDK、endpoint 和认证流程的需要。
这个位置很适合 agent 系统。Agent 往往会根据任务类型、延迟、成本或能力，在快速模型和更强模型之间切换；如果切换逻辑散落在每个 client，测试和治理会变得困难。由 gateway 统一接收请求，团队可以把 rate limiting、token tracking、路由规则和 API 入口放在更接近基础设施的一层，再由应用程序保留任务本身的决策。
但 model routing 仍然是 Public Preview，不能当作成熟的跨供应商抽象层。Google 的文档指出，同一个 router 中的 backends 需要共享相同 host；这个功能主要是在同一个 Vertex AI endpoint 内改变模型和 path，不是任意把请求发送到不同云端。不同模型的工具调用、上下文限制、内容政策、计费和输出格式，也不会因为拥有相同 API 入口而自动一致。
因此，团队仍要保留 provider-specific 的验证。路由成功不代表答案质量相同，也不代表 fallback 会保留完全相同的工具状态。较稳妥的做法，是为每条路由记录 model、延迟、token、错误和输出评估，并把 preview 功能放在可替换的边界，而不是把所有 agent 状态绑定在 gateway 的实现细节上。
这项更新反映模型基础设施的抽象层正在上移。过去开发者主要在 application code 中选择模型；现在 cloud gateway 开始接管路由、转码、流量和部分治理。它可以降低多模型接入的工程成本，但真正的可移植性仍要靠应用程序自己的能力测试、成本策略和失败处理来建立。
