Google 把 Agent 网关伸出自家云：EKS / AKS / OpenShift 也能被管

要点

• 2026-11-11，Google Cloud 把 Agent Gateway 伸到自家云外：Agent Gateway for cross-cloud 进入 Limited Preview，覆盖任何 CNCF 合规 Kubernetes 集群——官方点名 Amazon EKS、Azure AKS、Red Hat OpenShift 与裸金属集群。
• agent 不动，治理上来：集群里装一个 in-cluster controller（agent-governance-cross-cloud-controller，监听 service / workload / 自定义资源并同步到 Google Cloud）+ 各 namespace 自管的 Envoy 代理，代理旁边跑 Agent Identity Runtime（AIR）sidecar 负责工作负载身份与证书。
• 身份是主轴：每个 agent 拿一个 SPIFFE ID，默认由 Context-Aware Access 用 mTLS + DPoP 做强认证；访问默认全拒，必须显式 IAM 策略把身份与 Agent Registry 里登记的目的地配对才放行。
• 策略分五类：IAM 统一访问策略、Model Armor（实时扫提示词与工具返回，拦注入 / 泄密 / 有害内容）、语义治理策略（用自然语言写业务规则，拦「危险工具组合」）、token 管理策略（跨 agent 的共享预算）、自定义授权引擎（把决策委派给第三方系统）。
• 日志与 trace 回 Cloud Logging / Cloud Trace，代理在集群侧执行、证据在 Google 侧汇总。
• 预览期免费，但 Model Armor、Cloud Logging、Cloud Trace 按标准价收费；接入要填官方申请表单。
• 次日（11-12）Agent Gateway for GKE 也进 Preview：需 GKE ≥ 1.37.2-gke.1042000（当前走 Rapid 通道），仅 europe-west1 与 us-central1。可见 Google 在同时往「自家云内」和「别家云上」两头铺。

背景与分析

这条消息的价值不在「Google 又发了个网关」，而在一个很具体的架构选择：它把策略执行点放在客户集群里，把策略控制点留在自己云上。

官方文档给的「三平面」结构值得逐层读：

这个切法解决了一个真实痛点：企业上云早就不是单云了，但agent 治理工具通常只认自家云。于是要么把 agent 搬回自家云（推翻既有架构），要么放弃统一治理（各云各管一套，审计口径对不上）。跨云网关给的是第三条路——身份与策略集中，流量不过 Google。

注意「流量不过 Google」这句要打个折扣。代理在集群里执行策略，但配置与日志要出去：controller 要把工作负载信息同步到 Google Cloud 做注册，代理要把 access log 与 agent trace 发到 Cloud Logging / Cloud Trace。对数据出境敏感的团队，这两条出向链路得单独评估。

另一个很实用的一手细节是官方自己列的已知问题，它暴露了这类「外部代理 + 云端策略」架构的固有裂缝：

1. failOpen: true 在连不上 Google Cloud 时不生效——也就是说，控制面断连时网关走的是 fail-closed，不是你以为的 fail-open。若你的业务依赖「云侧挂了本地继续放行」，这个假设不成立。
2. ready 可能早到两分钟——自动化流水线若按 ready 判据立刻压测，会打到还没接连接的代理上。
3. in-cluster service URL 必须全项目唯一——多集群同名 namespace 会撞车。

这三条都不是文档角落里的小字，而是上线前必须写进 runbook 的东西。第 1 条尤其容易被误读成「配了 failOpen 就高可用」。

对开发者的影响

• 多云 / 混合云的 agent 团队，第一次有了「不迁集群也能统一治理」的官方选项。选型时可以拿它跟「自建网关 + 自建 registry」对比：省掉的是策略引擎与身份联邦的实现，付出的是对 Google 控制面的依赖。
• SPIFFE ID + mTLS + DPoP 这套身份模型值得直接抄。不管你用哪家网关，「每个 agent 有可验证身份、默认全拒、显式授权」这三条都比「给 agent 发一把万能 API key」安全一个量级。
• 语义治理策略是个新东西：用自然语言写「不允许先改数据库再删备份」这类业务规则，在运行时拦工具组合。它把「策略即代码」的门槛降到了「策略即描述」，但也带来一个新问题——自然语言策略的误判你怎么测？官方文档给了审计模式（先只记「本该拦下」的命中，确认后再转 enforcing），这个顺序别搞反。
• 国内团队用不上（GCP 预览 + 集群在外），但 failOpen 不生效这个坑是通用的：任何「集中策略 + 本地执行」的网关方案，都要实测一次「控制面断开后本地还放不放行」，别信配置项名字。
• 同类对照：Portkey、MCP Toolbox 这类做「模型 / 工具流量治理」的产品，现在多了一个往上走一层（身份 + 语义策略 + 跨云）的竞争者。

AI 之家 观点

把 11-11 和 11-12 两条新闻并排看，这一周的行业信号非常清楚：agent 的竞争焦点已经从「模型能不能干」挪到「谁管得住它」。

Google 的做法是上收：身份、策略、审计都往 Google Cloud 收，算力留在原地。Anthropic 的做法是下放：控制面整套搬进客户机房，只留模型在外面。两家路线相反，赌的是同一件事——企业级 agent 的付费理由，是可控，不是能干。

AI 之家 推荐结论：判断这两种路线哪个适合你，问三个问题就够了。① 合规要求数据落地在哪——必须落地自家机房的，只有自托管那条路；② 集群是不是多云/混合——是的话，跨云网关比「每云一套」省事得多；③ 你有没有 7×24 值班——自托管把你的运维责任实打实接过来，跨云网关则把一部分责任留在 Google。

最后提醒一句方法论上的事：这类「预览版」的官方文档，最有价值的部分往往不是功能列表，而是「Known issues」和「Your responsibility」两节。前者告诉你哪里会炸，后者告诉你炸了算谁的。本次两条新闻里最有信息量的内容，都在那两节里。

相关阅读

• 同日相反路线：Anthropic 自托管 Managed Agents
• 概念：Agent 控制面 · MCP · Agent 沙箱 · fail-closed · Agent 验证
• 相关工具：Portkey · MCP Toolbox · OpenAI Agents API
• 同期：Gemini Decisions API 与 Decision 1

来源

• { title: "Gemini Enterprise Agent Platform 官方 Release Notes（2026-11-11「Govern agents on any CNCF-conformant Kubernetes cluster with Agent Gateway for cross-cloud (Limited Preview)」；2026-11-12「Agent Gateway for GKE in Preview」，一手逐条读取）", url: "https://docs.cloud.google.cn/gemini-enterprise-agent-platform/release-notes" }
• { title: "Agent Gateway for cross-cloud overview（三平面架构、责任划分、计费与已知问题，一手）", url: "https://docs.cloud.google.cn/gemini-enterprise-agent-platform/agents/governance/agent-gateway-cross-cloud/overview" }
• { title: "Govern your agents（Agent Identity / Registry / Policies / Gateway 全套治理组件，一手）", url: "https://g.dev/cloud/adventofagents-season3-gemini-enterprise-govern" }