谷歌 API 网关开放实时流支持

Google Cloud API Gateway 的流式支持进入 Public Preview。过去，团队为了让模型逐字输出、让 Agent 持续汇报进度，可能需要把这些接口绕过网关；现在，SSE、WebSockets 和 gRPC 流可以走同一个入口，继续使用原有的认证、路由与日志能力。

这次更新最有用的地方，是不用为了流式传输重写 API 描述。不过，「API 配置不用改」不等于迁移没有成本：预览期必须新建网关，连接最长保持一小时，延迟指标也要重新理解。

流式接口为什么值得重新放回网关

传统 API 管理围绕一次完整的请求响应设计：客户端发请求，后端处理完，再一次性返回结果。流式接口则允许连接持续存在，数据产生一点就传一点；其中 WebSockets 还能让两端持续互发消息。

对 AI 产品，这直接影响使用体验。原文用等待三十秒后才看到完整答案作对比，强调用户希望看到模型边生成边输出。这是交互示例，不是性能测试数据。Agent 的中间步骤、工具调用协议和远程 MCP server，也可能依赖持续连接与增量传输。

过去，API Gateway 不支持这些流量，团队就容易维护两条路径：普通 API 经过网关，流式接口另走代理或直接访问后端。认证、API key 校验和可观测性因此需要另行补齐。

这次更新解决的是流式接口难以接入统一治理入口的问题。

原文列出了四类支持：

• Server-Sent Events（SSE）用于向浏览器或客户端 SDK 推送事件，也是多数 OpenAI-compatible chat completion API 使用的传输方式。
• Chunked transfer encoding 和 HTTP response streaming 支持逐步返回响应体，包括换行分隔的 JSON（NDJSON）；网关按后端产出转发，不再等完整响应后才交付。
• WebSockets 提供全双工连接，适用于聊天、协作、实时看板、通知和交互会话。
• gRPC streaming 支持服务端流和双向流；原文没有列出客户端流，不宜自行补全。

流连接最长保持一小时。客户端需要实现重连，但恢复连接和恢复业务会话是两件事。原文要求考虑会话延续，却没有说明断线后的事件补发、生成任务恢复由哪一层负责，接入时仍需单独设计。

不改 API 描述，为什么还得新建网关

Google 强调，流式传输没有引入独立的资源类型，也不用增加扩展字段、专用注解或另一份 API spec。现有 API 描述可以继续使用。

JWT 校验也保留，包括 Firebase、Auth0、Okta 和 Google ID tokens；后端的 service account authentication、Cloud Logging、Cloud Monitoring、路径模板与请求路由继续工作。

预览期通过下面的命令，在创建网关时启用流式支持：

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

关键是最后一行 --enable-streaming：它是创建阶段的开关，现有网关不能原地转换，需要新建网关。Google 计划在 GA 时默认支持流式传输，不再要求显式开启；目前这仍是计划。

另一个更新是默认域名可以提前计算：

GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev

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

要看清其中的 PROJECT_NUMBER，它是项目编号。此前默认域名带生成的哈希，必须等资源创建后才能拿到地址；现在，在同一项目、同一区域重建同名网关，可以得到相同 URL。

这对前端配置、CI、合作方接入文档和防火墙白名单都很实用：后端资源还没创建，地址就能先确定。不过，可预测域名解决的是配置依赖顺序，不代表 Terraform 已经支持启用流式能力。

原文把 Terraform、通过 Cloud console 开启流式支持，以及通过 Serverless NEGs 和 external Application Load Balancer 使用自定义域名，列为初始预览阶段尚不可用、计划在预览期间补齐的能力。

一个模型入口，能管到哪一步

API Gateway 的 model routing 允许团队暴露一个 OpenAI-compatible endpoint，根据请求体中的 model 字段，将请求分发给 Gemini platform 的 model garden 中的 Gemini、Claude 或 OpenAI gpt-oss 模型。

这里的 OpenAI gpt-oss 是原文明确列出的模型名称，不能理解成所有 OpenAI 托管模型都在支持范围内。流式更新让这些路由后的响应可以边生成边返回；部署在其他位置的流式后端也能经过网关。

对客户端而言，好处是可以沿用熟悉的请求方式。对平台团队而言，则是集中决定哪些模型可以访问、谁能调用，以及应用什么策略。原文认为，AI 接口成本高、消耗配额，需要按调用方认证、限流和观测；各团队分别维护模型代理，会让调用关系更难追踪。

但 API Gateway 在这套产品组合里承担的是轻量入口。更广泛的 AI 策略和完整生命周期管理交给 Apigee；Agent 连接的管理与安全交给 Agent Gateway in Gemini platform。它们也能组合，例如先由 Agent Gateway 管理 Agent 出站请求，再交给 API Gateway 做模型路由。

另一个容易误读的地方是延迟图表。流式请求的 request latency 衡量整个连接存续时间，不是首字节时间（time-to-first-byte）。连接保持越久，这个指标就越大，不能仅凭它判断用户等第一段输出等了多久。

我的判断

我认可它把流式传输纳入现有 API 管理路径的方向。对于已经使用 API Gateway 的团队，延续原有认证、路由与日志体系，比额外维护一套流式代理更容易保持规则一致。

但这是一篇产品发布说明，没有给出吞吐、并发连接、额外延迟、成本或稳定性的对照数据，也没有展示 SSE、WebSockets 和 gRPC 的完整实测。因此，「无需修改 spec」可以作为明确的接入承诺；「更省钱」「性能更好」「能替代所有自建代理」都没有证据支持。

协议能够通过网关，不等于业务已经具备完整的流式体验。

客户端取消生成、断线恢复、事件解析，以及服务端任务是否继续执行，都需要端到端验证。和自建 Node 代理相比，托管网关能减少部分入口治理工作，但原文没有证明它能覆盖所有应用层行为。已有代理承担了哪些职责，应先列清楚，再决定能否替换。

能拿来做什么

• 已经使用 API Gateway 的团队，可以新建带 --enable-streaming 的网关，接到现有 SSE 后端，先验证浏览器是否逐条收到事件，再验证认证失败、客户端断开和连接到期时的行为。
• 维护前端 AI 聊天界面或 Node 客户端时，应把重连与业务恢复分别处理，并确认重复连接是否会重复触发模型请求；原文没有提供恢复机制，不能默认网关会代办。
• 使用 model routing 时，可以围绕请求体的 model 字段整理模型访问策略，并检查现有 OpenAI-compatible 客户端对各模型流式响应的解析是否兼容。
• 调整监控时，应将整条流的持续时间与首字节时间分开观察；部署配置则可以提前生成确定性域名，同时核对预览期尚未支持的部署方式。