Google推出企业级Gemini智能体完整平台

Google Cloud NEXT '26 挑战赛投稿

Google Cloud NEXT '26 传递出了一个明确的主题：Gemini Enterprise Agent Platform。这是对 Vertex AI 的一次全栈品牌重塑。它带来了 Agent Designer、拥有持久化记忆的长时间运行 Agent，以及 Unilever 和 Team USA 的精彩演示。Thomas Kurian 站在拉斯维加斯的舞台上，向 32,000 名与会者宣布：我们已经告别了 AI 试点时代。

他说得没错。但如果你想理解为什么这种转变如今真正成为可能——无论从技术、机制还是生产环境的角度来看——就需要关注一项可能只获得主题演讲十分之一时间的公告。

GKE Agent Sandbox。现已正式 GA。

下面我想谈谈，为什么我认为这是 Google 在 NEXT '26 上发布的最重要成果，以及为什么构建 Agent 工作负载的开发者应该先关注它，再去关注那些光鲜亮丽的新功能。

一个没人愿意谈论的问题

每一篇 Agent 教程最后都殊途同归：Agent 推理接下来该做什么，编写一些代码，然后……执行它。通常是调用 exec() 或启动一个 subprocess，而且一般会直接在运行应用的那台机器上执行。

如果你已经把这种方案部署到了生产环境，就一定体会过那种关乎系统存亡的恐惧。LLM 生成的代码本质上是不可信的——它不是经过人类工程师审查的代码。它可能写入错误的路径，可能发起出站网络请求，可能无限循环并耗尽 CPU。而在任何多租户环境中，一个 Agent 的错误输出，都可能彻底污染另一个 Agent 的运行环境。

大多数团队通常会采用以下“解决方案”，但效果都不算理想：

• 人工审核关卡：违背了自动化的初衷。
• 严格的输出解析器：非常脆弱，模型一更新就可能失效。
• 每个 Agent 使用一台完整 VM：速度慢（冷启动需要 10～30 秒）、成本高，而且运维负担重。
• Docker 容器：有所改善，但容器共享宿主机内核——默认情况下仍然没有 gVisor 或类似级别的隔离。

因此，大多数团队只能……接受风险，快速推进。这种做法在出问题之前，一直都显得行之有效。

GKE Agent Sandbox 到底做了什么

GKE Agent Sandbox 是一个 GKE add-on，可以为 Agent 代码执行提供隔离、有状态、单副本的运行环境——通过 gVisor 实现内核级隔离，同时具备足以满足实时工作负载要求的配置速度。

下面是几个真正重要的数字：

• 从启动到执行第一条指令不到一秒
• 每个集群每秒可创建 300 个 sandbox
• 在 Axion N4A 上，相比排名紧随其后的 hyperscaler，性价比提升约 30%

真正改变局面的，是前两项。过去，你只能在“速度快但不安全”和“安全但速度慢”之间做选择，而团队通常都会选择速度。现在，这个取舍已经不存在了。亚秒级隔离意味着，你可以把每一次 Agent 工具调用都放进 sandbox，而用户根本察觉不到。

它的架构也很干净。每个 sandbox 都由一个 Kubernetes CRD（即 Sandbox 资源）表示。controller 负责管理它的生命周期，包括创建、稳定身份、网络和存储。Sandbox Router 会为每个 sandbox 提供稳定的 endpoint，这样应用无须追踪 Pod IP，也能把流量路由过去。整个系统都建立在 Kubernetes 原语之上，因此如果你已经在运维 GKE，就不需要学习新的心智模型。

# This is the level of simplicity we're talking about
`apiVersion: sandbox.gke.io/v1
kind: Sandbox
metadata:
  name: agent-task-abc123
spec:
  template:
    spec:
      containers:
        - name: executor
          image: my-agent-executor:latest
          runtimeClassName: gvisor`

Claim Model：为什么这个 API 设计确实很好

这里有一个我特别想强调的设计决策：Claim Model。

在标准的 Kubernetes StatefulSet 中，如果你想要一个隔离的 Pod，就需要直接管理这个 Pod——你要知道它的名称、追踪它的 IP，并处理重启。这种方式用在数据库上没什么问题，但对于每小时可能创建和销毁数千次的临时 Agent sandbox 来说，简直是一场噩梦。

Claim Model 把“申请一个 sandbox”和“知道这个 sandbox 在哪里”分离开来。你的应用只需要说：“我需要一个执行这项任务的环境。”controller 会负责 placement、节点分配、网络身份以及 volume 绑定。你会通过 Sandbox Router 获得一个稳定的 endpoint，完全不需要接触底层 Pod。

这与 PersistentVolumeClaims 的设计模式相同：它通过对存储进行抽象，为开发者提供了友好的使用体验。对于 Agent 环境来说，这同样是正确的选择。我很高兴他们采用了这种方式，而不是仅仅暴露原始的 StatefulSet 管理能力。

暂停与恢复：一项被低估的功能

长时间运行的 Agent——需要执行数小时、包含许多步骤，并且必须等待外部信号的任务——是 NEXT '26 所描绘愿景的基石。Google 展示了多种演示，包括使用 Agent 执行采购分析、安排销售跟进流程，以及完成隔夜对账工作。

这些 Agent 有时需要等待。如果在等待期间一直占用一个正在运行的容器，就会浪费资金和算力。

GKE Agent Sandbox 与 GKE Pod Snapshots 集成：你可以暂停一个 sandbox，序列化它完整的内存状态，之后再从上次停止的位置恢复。一个在推理过程中暂停的 Agent，可以从中断处继续执行。不需要从头再跑，也不会出现“Agent 忘了自己刚才在做什么”的情况。

对于真正需要长期运行的 Agentic 任务来说，这是必备能力。值得肯定的是，它与 sandbox 同时发布，而不是被留到后续版本。

真实信号：Lovable 每天创建 200,000 个项目

公司发布 GA 公告时，通常都会带上一家参考客户。GKE Agent Sandbox 的参考客户是 Lovable——这是一款 AI 驱动的 Web 应用构建工具，需要持续按需启动隔离的开发环境。

每天新增 200,000 个项目，每个项目都需要一个隔离环境。这正是 GKE Agent Sandbox 为之设计的工作负载，而且它已经在生产环境中运行。

这不是 beta 阶段的试水信号，而是在告诉你：“我们已经在大规模场景下完成了压力测试。”这一点非常重要。

我也想坦率地谈谈 sandbox 无法解决的问题。

gVisor 隔离的是 syscall，而不是意图。

如果 Agent 生成的代码通过出站 HTTPS 请求窃取数据，gVisor 并不会阻止它——因为这是一个合法的 syscall。如果 Agent 调用某个会产生破坏性副作用的外部 API，隔离层也无法理解这一点。sandbox 可以保护宿主机内核安全，但它无法让你的 Agent 变得可信。

这个问题的答案是 network policy、egress controls，以及 Google 的 Agent Gateway 和 Agent Identity 功能——但 sandbox 级网络限制与 Agent 级权限范围之间的集成方案仍在不断演进。对于“究竟应该如何配置 Agent sandbox，使其只能调用 API X 和 Y”，现有文档提供的说明还很有限。这是 NEXT 之后几个月里我会持续关注的缺口。

另外，30% 的性价比提升是专门针对 Axion N4A 的说法。如果出于其他原因，你的工作负载目前运行在 N2 或 C3 实例上，经济账会有所不同。在接受这个醒目的宣传数字之前，请先根据自己的情况进行测算。

为什么它比平台类公告更重要

Gemini Enterprise Agent Platform 是一款产品。它会不断演进，功能会增加、弃用或更名，路线图也会变化。

GKE Agent Sandbox 则是一种原语。基础设施原语往往比构建在它们之上的产品更加长寿。Kubernetes PersistentVolumes 发布时，没人能预料到有状态工作负载最终会以多少种方式使用它。AWS 发布 Firecracker 时，“快速 microVM”也催生了许多最初愿景中并不存在的 Lambda 使用场景。

同样的事情也会在这里发生。亚秒级、由 gVisor 隔离、原生支持 Kubernetes 的临时环境，将催生出尚未有人构建的工作负载——而且不仅限于 AI Agent。比如为每位用户自动配置的交互式 notebook、用于 CI pipeline 的安全 eval sandbox，以及为多租户开发者工具提供的单请求隔离环境。

Google 为自己的 Agent 叙事打造了一个工具，而开发者会把它用到另外十种场景中。

如果你想亲自试用：

• 在现有 GKE 集群上启用这个 add-on（Autopilot 支持即将推出；目前，使用 Axion N4A 节点的 Standard 集群可以获得最佳性价比）。
• 从 GitHub 安装 Agent Sandbox Python SDK，以编程方式管理 sandbox，无须直接处理原始 Kubernetes 资源。
• 从 Claim Model 开始——以声明式方式申请 sandbox，让 controller 负责 placement。不要直接使用原始 StatefulSet。
• 立即设置 egress policies——即使还在制作原型，也不要让 sandbox 的网络访问保持开放。越早养成这个习惯越容易。

文档地址是 cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox。

Google Cloud NEXT '26 是这样一场大会：“我们正在探索 AI”在这里变成了“我们正在生产环境中运行 AI”。Gemini Enterprise Agent Platform 获得了主题演讲的核心位置，TPU 8t 成为基础设施焦点，Agentic Data Cloud 则占据了数据工程演讲。

而 GKE Agent Sandbox 只得到了一张幻灯片，以及一篇罗列 260 项内容的总结文章中的一个要点。

这没什么不好。最优秀的基础设施总是安静地发布，然后让工作负载自己说话。Lovable 每天运行 200,000 个 sandbox，这个声音已经相当响亮了。

如果你正在构建能够执行代码的 Agent，我建议你本周少花点时间探索 Agent Designer UI，多花点时间阅读 gVisor 隔离文档。平台固然令人印象深刻，但真正让它落地的，是这个基础原语。

已经试用过 GKE Agent Sandbox 了吗？欢迎在评论区分享你的体验——我尤其想知道，是否有人已经端到端地接通了 egress controls。

如果你想亲自试用：

• 在现有 GKE 集群上启用这个 add-on（Autopilot 支持即将推出；目前，使用 Axion N4A 节点的 Standard 集群可以获得最佳性价比）。
• 从 GitHub 安装 Agent Sandbox Python SDK，以编程方式管理 sandbox，无须直接处理原始 Kubernetes 资源。
• 从 Claim Model 开始——以声明式方式申请 sandbox，让 controller 负责 placement。不要直接使用原始 StatefulSet。
• 立即设置 egress policies——即使还在制作原型，也不要让 sandbox 的网络访问保持开放。越早养成这个习惯越容易。

文档地址是 cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox。

Google Cloud NEXT '26 是这样一场大会：“我们正在探索 AI”在这里变成了“我们正在生产环境中运行 AI”。Gemini Enterprise Agent Platform 获得了主题演讲的核心位置，TPU 8t 成为基础设施焦点，Agentic Data Cloud 则占据了数据工程演讲。

而 GKE Agent Sandbox 只得到了一张幻灯片，以及一篇罗列 260 项内容的总结文章中的一个要点。

这没什么不好。最优秀的基础设施总是安静地发布，然后让工作负载自己说话。Lovable 每天运行 200,000 个 sandbox，这个声音已经相当响亮了。

如果你正在构建能够执行代码的 Agent，我建议你本周少花点时间探索 Agent Designer UI，多花点时间阅读 gVisor 隔离文档。平台固然令人印象深刻，但真正让它落地的，是这个基础原语。

已经试用过 GKE Agent Sandbox 了吗？欢迎在评论区分享你的体验——我尤其想知道，是否有人已经端到端地接通了 egress controls。``

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。