Google Agent Compute Engine 完整解析：microVM、Agent Substrate、Kubernetes、沙箱安全与暂停恢复

一、Google 为什么要为 AI Agent 重新设计计算服务？

2026 年 10 月 22 日，Google Cloud 正式介绍 Agent Compute Engine，一项专门围绕 AI Agent 执行需求设计的计算服务。

与传统 Web 服务不同，Agent 的工作方式通常具有高度间歇性。

模型先进行推理。

然后要求工具执行一个操作。

工具完成后，模型继续思考。

随后可能等待用户批准。

如果任务持续较长时间，这个过程会不断重复。

对于需要代码执行、浏览器和文件系统的 Agent，还必须提供真正能够运行程序的执行环境。

传统虚拟机具有良好的隔离能力，但启动和管理成本可能较高。

普通容器启动较快，却通常共享宿主机内核。

当 Agent 可能执行不可信代码时，企业又希望获得更严格的隔离。

Google 因此设计了专门的 microVM 平台，希望兼顾启动效率、隔离能力和大规模调度。

不过，产品已经用于 Google 自身系统，不等于外部客户现在就能全面使用。

Google 明确表示，Agent Compute Engine 将于未来数月进入面向客户的 Preview。

二、Agent Compute Engine 的核心能力

这些能力共同解决 Agent 运行时的多个问题。

但其中也有一些属于 Google 更广泛的 Agent 治理平台。

因此，不能将不同产品名称混在一起，把它们描述为一个已经向所有客户开放的单一服务。

三、microVM 与普通虚拟机有何区别？

microVM 可以理解为为特定工作负载优化的小型虚拟机。

它保留虚拟化隔离的核心机制，但尽量减少不必要的设备和启动开销。

例如，一个 AI 编程 Agent 需要 Linux 文件系统、Shell、编译器和浏览器。

它不一定需要完整的传统通用服务器配置。

microVM 可以围绕这些执行需求构建更轻量的环境。

与普通容器相比，microVM 具有自己的 Guest Kernel。

这为执行不可信代码提供了额外隔离边界。

但隔离能力仍取决于具体 Hypervisor、宿主机和运行时实现。

不能仅因为系统使用 microVM，就认为永远不可能发生沙箱逃逸。

安全仍然需要分层设计与持续维护。

四、为什么 Agent 不适合一直占用完整虚拟机？

假设一个企业拥有一万个长期存在的 Agent 会话。

并不意味着这一万个 Agent 每时每刻都在运行工具。

其中一些可能正在等待模型返回下一步计划。

另一些可能等待用户回复。

还有一些已经完成计算，但保留状态以便随后继续。

如果每个会话都长期占据固定 CPU 和内存，就可能造成资源浪费。

Google 在内部研究中发现，Agent 会话相当多的时间处于等待状态。

因此，系统需要理解哪些 Agent 正在真实执行代码，哪些只是保留任务上下文。

这种差异为资源优化提供了机会。

五、Checkpoint/Restore 解决什么问题？

Checkpoint 是对执行状态进行快照。

Restore 则是在之后恢复快照。

对于 Agent，这意味着执行环境不需要始终保持活跃。

例如，Agent 完成了一次浏览器操作。

随后它需要等待模型规划下一步。

这时系统可以将执行环境转入闲置状态。

当新的工具调用到达，再恢复原有状态。

这种方式能够减少等待期间的资源占用。

但快照和恢复不是简单保存一份聊天历史。

执行环境还可能包含文件系统、内存状态和程序上下文。

实际恢复过程需要保证相关数据的一致性。

因此，平台需要处理快照生命周期、存储、身份验证和错误恢复等问题。

六、Copy-on-write 如何提高资源密度？

Copy-on-write 通常简称 COW。

其基本思想是，让多个执行环境共享相同的基础内容，只有需要修改时才创建独立副本。

例如，多个 Agent 可能都使用相同的 Linux 基础环境。

如果每个 microVM 都完整复制一份相同的基础系统，就会产生重复内存和存储开销。

通过 COW，平台可以共享部分相同的页面。

当某个 Agent 修改自己的状态时，再使用独立副本。

这有助于降低多实例资源成本。

但实际共享范围需要受到隔离与安全机制约束。

不同用户的敏感数据不能因为内存优化而随意互相可见。

因此，资源共享与租户隔离必须同时满足。

七、为什么 Google 强调“Brain”和“Hands”分离？

Google 在技术文章中使用了一个直观的架构解释。

Agent 的 Harness 可以视为负责规划的“大脑”。

Sandbox 则是执行具体操作的“双手”。

Harness 调用模型，决定下一步应该执行什么任务。

Sandbox 负责运行命令、文件操作和浏览器。

将二者分离，可以让模型规划层与不可信执行环境形成清晰边界。

例如，某个工具执行了第三方代码。

即使执行环境受到影响，也不应该自动获得管理整个 Agent 平台的权限。

这种分离还可以让系统审计每一次真正下发给沙箱的工具调用。

对于企业级 Agent，执行可追踪性和权限隔离同样重要。

八、为什么不能把长期 API Key 放进沙箱？

Google 在技术设计中强调零长期凭据的沙箱理念。

传统应用可能通过环境变量保存服务密钥。

但如果 Agent 可以读取全部环境变量，那么执行的第三方代码也可能访问这些信息。

一旦发生 Prompt Injection 或沙箱内代码被控制，长期密钥就可能成为高价值目标。

Agent Compute Engine 因此采用独立的凭据代理方式。

沙箱本身不直接持有长期有效的用户密钥和 OAuth Refresh Token。

它使用短期身份标识，与外部的可信服务建立受控连接。

真正访问业务系统时，由安全网关根据授权策略处理凭据。

这种方式能够缩小秘密信息在不可信环境中的暴露范围。

但它不能代替目标业务服务自身的权限检查。

九、SPIFFE 在 Agent 身份中有什么作用？

SPIFFE 是面向工作负载身份的开放标准。

Google 在 Agent Compute Engine 中使用基于这一体系的短期身份。

其目的，是区分某次请求究竟来自哪个 Agent 执行环境。

例如，同一个用户可能同时启动多个 Agent。

它们可能承担不同任务，访问不同资源。

不能因为它们属于同一个用户，就允许它们拥有完全相同的权限。

通过独立工作负载身份，系统可以为每个 Agent 记录来源，并实施相应网络策略。

Google 还将实际用户、代理授权、工作负载身份和 Agent 自身业务身份分开管理。

这种分层设计有助于建立更加精确的授权与审计机制。

十、为什么 Agent 的网络访问必须受到控制？

一个能够运行浏览器和命令行的 Agent，可能向外部服务器发送请求。

如果所有网络目标都默认允许，模型可能访问与任务无关的服务。

当它读取恶意网页内容时，还可能受到诱导。

因此，Google 的设计不允许沙箱直接获得无限制的标准外部网络访问。

相关流量需要经过受控代理，再由外部网关执行权限检查。

例如，只有指定业务允许访问的 API，才应得到授权。

对于内部数据库、云资源和第三方插件，还需要进一步结合实际用户权限处理。

网络白名单不是万能保护，但能够减少明显越界行为。

十一、Hyperdisk 如何保存 Agent 工作空间？

对于代码编程 Agent，文件系统状态非常重要。

例如，Agent 已经修改了多个文件，并正在等待测试结果。

如果执行环境被完全销毁，可能需要重新构建工作空间。

Google 介绍，Agent Compute Engine 可以为 microVM 提供独立 Hyperdisk，用于持久化执行工作目录及部分上下文。

这样，Agent 能够在多个执行阶段之间保留必要状态。

但持久化也带来数据生命周期问题。

例如，任务完成后，文件应该保留多久？

谁有权重新访问？

是否需要加密？

是否需要删除临时敏感数据？

因此，持久化存储既提升使用体验，也要求更加明确的数据治理。

十二、Agent Substrate 与 Agent Compute Engine 是同一个产品吗？

不是。

Agent Compute Engine 是 Google 计划面向客户推出的托管 Agent 计算服务。

Agent Substrate 则是另一条开源、以 Kubernetes 为基础的技术路线。

Google 表示，Agent Substrate 可以运行在 GKE 或其他 Kubernetes 环境中。

它同样采用面向 Agent 的执行和暂停恢复设计。

对于已经使用 Kubernetes 的企业，Agent Substrate 提供了更高的自定义空间。

但开源软件的可用性，不等于托管 Agent Compute Engine 服务已经 GA。

两者应分别评估。

十三、Agent Substrate 公布了哪些性能数据？

Google 提供了部分基准测试结果。

例如，在特定配置下，Agent Substrate 的计算密度最高可达到传统方案的十倍。

Google 还报告，在涉及 20 万 Agent 的验证场景中，实现每秒约 500 次激活，以及低于 500 毫秒的暂停和恢复延迟。

这些数字具有参考价值。

但必须结合测试环境理解。

它们不是任意 Kubernetes 集群都能直接得到的保证。

真实环境的节点规格、存储系统、网络、Agent 工作量和并发模式，都会影响最终性能。

因此，企业应在自己的工作负载上独立验证。

十四、Agent Substrate 的隔离方式有哪些？

Google 介绍，Agent Substrate 可以根据部署方案选择 microVM 或 gVisor 等隔离机制。

microVM 更强调独立虚拟化执行环境。

gVisor 则通过用户态内核等机制减少容器工作负载直接触及宿主内核的范围。

两者都可以增强不可信代码执行隔离，但并非完全相同。

企业需要根据安全需求、性能和应用兼容性作出选择。

例如，某些特殊系统调用和底层工具，可能在不同沙箱运行时中具有不同兼容表现。

因此，Agent 运行平台不能只测试模型能否生成文字。

还需要验证真实工具和运行环境的完整行为。

十五、Google Agent Gateway 负责什么？

Agent Gateway 是 Google Agent 治理体系中的重要组件。

它可以作为 Agent 访问模型、工具和其他服务时的策略执行点。

例如，检查请求是否来自可信身份。

控制敏感数据流转。

限制某个 Agent 能调用哪些工具。

记录重要的操作事件。

对于需要在多种环境中运行的 Agent，统一治理可以减少不同执行平台之间的权限差异。

但不是所有治理功能都已经以相同状态开放。

Google 官方列出的部分新能力仍计划在后续季度进入 Preview。

因此，不能把未来的费用策略、跨云治理和本地设备管理能力都写成已经正式提供。

十六、如何理解 Agent Registry 和 Agent Identity？

Agent Registry 主要用于记录被批准的 Agent、工具、MCP Server、Skills 和相关端点。

企业可以利用类似目录，知道组织中实际允许使用哪些自动化组件。

Agent Identity 则主要处理执行身份及授权问题。

它帮助系统确认一个 Agent 是谁，以及它可以代表哪个用户开展什么工作。

两者相互配合。

Registry 解决“有哪些受管对象”。

Identity 解决“谁可以使用”。

Gateway 则负责在真实请求发生时执行策略。

这与传统企业管理用户账户、服务账号和网络权限的思路存在相似之处，但需要进一步适应 Agent 的动态行为。

十七、企业怎样建立完整的 Agent 治理体系？

建议先建立四层基础。

第一层是执行环境。

为 Agent 提供隔离的文件系统、命令执行和浏览器环境。

第二层是身份与权限。

明确用户、Agent 和服务账号之间的关系。

第三层是工具与网络治理。

限制 Agent 可以访问的目标服务和操作类型。

第四层是监控与审计。

记录模型调用、工具执行、错误和重要审批结果。

对于生产环境，还应提供取消任务、资源回收和安全事件处理机制。

这种设计可以适用于不同模型供应商。

因此，不应把 Agent 安全完全绑定到某一家模型本身。

十八、Agent Compute Engine 什么时候对外开放？

Google 的 10 月 22 日公告明确表示，该服务已经用于其内部 Agent 工作负载。

但是，面向外部客户的 Preview 计划在未来数月开放。

因此，截至 2026 年 10 月 24 日，不能把它写成所有 Google Cloud 用户均可直接创建并投入生产的 GA 服务。

有兴趣的企业可以按照官方公告提交使用意向。

对于希望立即研究相关架构的技术团队，则可以评估开源 Agent Substrate。

但这两条路线的功能和支持方式不能完全等同。

十九、常见问题 FAQ

Agent Compute Engine 是什么？

它是 Google 面向 AI Agent 工作负载设计的 microVM 计算基础设施。

现在已经 GA 了吗？

没有。Google 表示目前用于内部系统，外部 Preview 将在未来数月提供。

每个 Agent 都有独立虚拟机吗？

官方架构强调为 Agent 会话提供独立的隔离 microVM。

为什么需要暂停和恢复？

因为大量 Agent 会在模型推理和人工等待阶段处于空闲状态。

Agent Substrate 是否开源？

Google 已提供开源 Agent Substrate 资源，它与托管 Compute Engine 是不同路线。

microVM 能保证代码绝对安全吗？

不能。还需要网络限制、权限检查、补丁和审计。

Google 公布的性能提升是独立实测吗？

不是，属于 Google 官方指定测试结果。

二十、结语

Google Agent Compute Engine 展示了 AI 基础设施发展的一个重要方向。

过去，云计算更多围绕长期运行的服务和批量计算任务设计。

而 Agent 的工作方式更加动态。

它需要快速启动、持续保留状态、频繁暂停恢复，并能够安全执行不可信代码。

因此，未来 AI Agent 平台的竞争，不只体现在模型推理速度。

沙箱隔离、身份治理、上下文持久化和资源调度，同样将成为核心能力。

Agent Compute Engine 当前还没有对外全面开放，但其技术设计已经提供了值得开发者研究的方向。

对于企业而言，最重要的是在增加 Agent 自主性的同时，保持可验证的权限和执行边界。

官方参考资料

1. Google Cloud — Introducing Agent Compute Engine and expanded agent governance https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance/

2. Google Cloud — Inside Agent Compute Engine: Building the compute foundation for the agentic era https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/

3. Agent Substrate 官方项目入口 https://ate.dev/

4. Google Cloud Agent Gateway 文档 https://cloud.google.com/