Google API Gateway 支持流式传输并进入公开预览

Google Tag Manager（noscript）结束 Google Tag Manager（noscript） HTML 流式传输登陆 API Gateway：实时且面向 AI 的 API，无需更改您的规范 2026年10月22日 Mak Ahmad 产品经理 Geir Sjurseth 产品经理 Jeremy Whitlock 软件工程师

Streaming feature in API Gateway _ Header

在过去十年的大部分时间里，一次 API 调用就像一笔交易。客户端发送请求，等待，然后一次性收到完整的响应。这正是大多数 API 管理工具——包括 API Gateway——所构建来处理的情形，而且它仍然描述了大量的生产流量。

但这已不再能描述所有流量类型。模型在生成响应时会随着生成过程逐个输出 token，而不是在最后一次性批量输出。一个执行多步骤任务的智能体会在过程中持续报告进度。仪表盘、协作编辑器、实时推理端点——这些都需要一个保持打开、双向传输数据的连接。

在此之前，在 API Gateway 中构建这类体验的开发者不得不做出一个令人为难的选择：要么把 API Gateway 放在其 API 前面，从而放弃流式传输；要么让流式端点绕过网关，从而放弃正是网关不可或缺的认证、API 密钥强制执行和可观测性。团队最终得到一个割裂的资产格局——受治理的 API 走一条路径，未受治理的流式流量走另一条路径。

我们宣布，API Gateway 中的流式传输支持现已进入公开预览。 您的流式端点现在可以与您提供的其他所有服务一样，置于同一个网关之后，并遵循相同的策略。

对于 AI 应用而言，流式传输还加强了 API Gateway 与 Gemini 平台的连接。使用模型路由的网关现在会随着 Gemini、Claude 和 Gemini 平台模型库中的 OpenAI gpt-oss 模型生成响应而流式返回这些响应，您托管在其他任何地方的流式后端也以同样的方式工作。与 Gemini 平台中的 Apigee 和 Agent Gateway 一起，API Gateway 是 Google Cloud AI 网关能力的轻量级入口。

您可以流式传输的内容

API Gateway 现在支持现代 API 所依赖的全套流式传输模式：

服务器发送事件（SSE） ——将模型输出流式传输到浏览器或客户端 SDK 的事实标准，也是大多数 OpenAI 兼容聊天补全 API 背后的传输方式。
分块传输编码和 HTTP 响应流式传输 ——包括换行分隔 JSON（NDJSON）以及任何其他逐步交付的响应体。响应会随着您的后端生成而透传，而不是被缓冲并在最后交付。
WebSocket ——用于聊天、协作、实时仪表盘、通知和交互式会话的全双工连接。
gRPC 流式传输 ——服务器端流式传输和双向流式传输，因此您可以将网关置于此前无法代理的 gRPC 服务之前。

流最长可保持打开一小时。与任何长连接一样，客户端应实现重连逻辑，以便会话在流结束后仍能存续——行为良好的 WebSocket 或 SSE 客户端本来就应该这样做。

您的 API 契约不会改变

这是最令我们满意的部分： 没有任何新东西需要学习。

流式传输不是不同的产品、不同的资源类型，也不是描述 API 的不同方式。没有需要添加的新扩展，没有流式传输专用的注解，也没有针对流式操作的单独规范。描述您现有 API 的同一份文档就描述了您的流式 API。

您已经依赖的一切都继续照常工作：

API 密钥强制执行
JWT 验证，包括 Firebase、Auth0、Okta 和 Google ID token
向后端的服务账号认证
Cloud Logging 和 Cloud Monitoring 集成
路径模板化和请求路由

在公开预览期间，您在创建网关时选择启用：

gcloud api-gateway gateways create GATEWAY_ID \
  --api=API_ID \
  --api-config=CONFIG_ID \
  --location=REGION \
  --enable-streaming

纯文本已复制

这一个标志就是全部差异。在正式发布（GA）时，计划让流式传输直接成为 API Gateway 的默认行为，无需选择启用，并且与预览期间一样，无需更改您的 API 配置。

一个可预测的主机名

除了流式传输之外，网关还获得了一个确定性的默认主机名：

GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev

(Example: streaming-test-12345.us-central1.gateway.dev)

纯文本已复制

此前，默认 gateway.dev 主机名包含一个生成的哈希值，这意味着在创建网关之前您无法知道其 URL。这是一件小事，却造成了很多摩擦：在资源存在之前，您无法将端点写入客户端配置、Terraform 模块、CI 流水线、防火墙允许列表或合作伙伴集成文档——而如果您拆除环境并重建，URL 会在您脚下发生变化。

现在，主机名是您已经选定的值的纯函数。您可以在网关存在之前生成它、为其制作模板、记录它并将其提交到源代码控制，而且每次在同一项目和区域重建同一网关时，您都会得到相同的 URL。对于任何以代码方式管理环境，或将配置从开发环境推广到预发布环境再到生产环境的人来说，这消除了一整类引导问题。

为什么这对 AI 工作负载很重要

流式传输并非 AI 应用的细分功能——它是预期的交互模式。

用户期望看到模型的响应在生成时即出现，而不是在三十秒的停顿之后。智能体需要报告中间步骤。工具调用协议和远程 MCP 服务器依赖于长期存在、逐步交付的连接。无法流式传输的 API 管理层会严重限制 AI 应用的用户体验。

借助流式传输，API Gateway 成为承载此类智能体流量的可行前端入口——而前端入口的价值与以往完全相同，只是更加紧迫。AI 端点成本高昂、消耗配额，需要按消费者进行身份验证和速率限制，并且需要具备可观测性。这些正是 AI 网关旨在解决的治理问题。另一种做法——每个团队都在自己的模型端点前搭建自己的代理——正是导致组织最终无法回答“谁在调用什么”这类基本问题的原因。

模型路由在 API Gateway 中，您可以暴露单个兼容 OpenAI 的端点，并根据请求负载中的 model 字段将请求分发到 Gemini、Claude 或 OpenAI gpt-oss 模型。模型路由加上流式传输意味着客户端获得熟悉的、基于标准的流式接口，同时您仍可集中控制哪些模型可被访问、由谁访问以及遵循何种策略。

流式传输、模型路由和 MCP 支持都是 API Gateway 中的功能，为 Google Cloud 内的 AI 网关能力提供轻量级入口。这些 AI 网关能力让团队能够监控、保护和控制其生态系统中工具、模型和智能体的智能体流量，并且它们以可组合套件的形式提供，因此您可以为每个用例选择合适的网关。如需更广泛的 AI 策略和完整的生命周期管理，请使用 Apigee。如需管理和保护智能体连接，请使用 Gemini 平台中的 Agent Gateway 。您还可以组合使用这些网关：API Gateway 或 Apigee 可以位于您的智能体和 API 之前，也可以位于 Agent Gateway 之后，以便您的智能体能够访问模型、工具和 MCP 服务器。例如，您可以通过 Agent Gateway 路由智能体的出站流量以实现严格的安全治理，然后将请求传递给 API Gateway 以处理模型路由。

公开预览期间须知

在该功能处于预览阶段时，有几件事需要提前规划：

流式传输在创建网关时启用。 现有网关无法就地转换；请使用该标志创建新网关以进行试用。
部分 API Gateway 功能在预览版首次发布时不可用，但将在预览期间推出。
- 通过无服务器 NEG 和外部应用负载均衡器使用自定义域名
- 通过 Cloud 控制台启用流式传输
- Terraform
延迟指标反映流持续时间。 流式连接的请求延迟衡量的是流的生命周期，而非首字节时间，因此预计长连接会改变延迟图表的形态。