Google Cloud在大会上公布了Agent Compute Engine，一种为AI智能体提供可隔离、可暂停并可恢复的微虚拟机托管计算服务，旨在平衡隔离安全与资源密度。该服务目前仅用于Google内部支持Gemini，面向外部客户的预览将在未来数月开放，具体时间和区域尚未确定。
Google Cloud在AGNTCon + MCPCon期间公布了专为AI智能体设计的托管计算服务Agent Compute Engine：让执行代码、操作浏览器和调用工具的智能体，拥有可隔离、可暂停、可恢复的独立运行环境。
这不是一项已经面向客户全面开放的服务。Google在官方公告中称，该基础设施已支撑Gemini的工作任务，但对外预览计划在未来数月推出。截至2026年10月24日本次核验，公告仍未给出明确的客户预览日期。
公告页面标注日期为2026年10月22日，其发布时间元数据则记为带有东八区偏移的10月23日。本文将其作为这轮大会期间公布的进展，而不是10月24日当天发生的新发布。
与计算服务同时公布的，还有智能体治理能力向更多云端运行环境、跨云部署和企业终端扩展的路线。两部分指向同一个问题：当AI从回答问题转向实际操作业务系统，企业不仅需要模型，还需要承载执行、限制权限并追踪行为的基础设施。
为什么智能体需要另一种“电脑”
Google在技术详解中，将智能体拆成两个部分：位于沙箱之外的编排程序负责调用模型、决定下一步行动；沙箱则负责运行代码、终端命令和浏览器。前者类似“大脑”，后者类似执行操作的“手”。Agent Compute Engine重点解决的是后者的运行环境，而不是提供一个新的基础模型。
这种负载与长期稳定运行的网站或数据库不同。智能体可能安装依赖、修改文件、执行测试，随后等待模型返回或用户确认；过一段时间，又需要回到此前的工作状态。若每次都重建环境，会丢失上下文并增加等待时间；若为每个等待中的会话保留整台虚拟机，又会占用大量闲置资源。
传统容器启动轻快，但通常共享宿主机内核。对于需要运行不可信代码、获得root权限或控制内核环境的任务，隔离边界尤其重要。Google提出的方案是独立的微虚拟机，即microVM：每个会话拥有自己的来宾内核，以Cloud Hypervisor提供隔离边界，并结合Titanium基础设施处理单元实现更深层的安全控制。
这里的独立环境并不意味着每个会话都占用一台物理服务器。Google表示，同一宿主机上的多个microVM可以利用预热镜像和写时复制机制，共享基础系统、库和运行程序的只读内存页；只有各自修改的部分需要额外分配私有内存。其目标是在保留虚拟机隔离边界的同时，提高运行密度。
等待时休眠，恢复时保留工作现场
另一项核心设计是让基础设施理解智能体何时真正需要执行资源。
按照Google披露的机制，当沙箱没有正在执行的命令或后台任务时，运行时会向宿主机报告空闲状态。宿主机通过检查点和恢复机制保存状态，释放活跃计算资源；下一次工具调用到来时，再恢复环境。
这个条件很重要。智能体在等待模型回答，不代表它的所有后台工作都已经结束；只有满足运行时的空闲判断，沙箱才适合被暂停。因此，不能把这一设计简化为“模型一思考，整个智能体就停止运行”。
持久化也不只涉及聊天记录。Google将存储分为临时数据、只读或共享数据，以及需要长期保留的用户工作区，并使用Hyperdisk承载相关存储。脚本、文件和已保存的分析产物可以跨会话保留，避免下一轮任务从头开始。
对于软件开发和评估任务，平台还支持快照、分叉和回滚，让多个实验从同一环境状态出发，而不是反复安装相同依赖。不过，这些是Google披露的架构能力，不能直接当作独立测试得出的性能或成本结论。
“空闲时不占用活跃计算资源”也不等于整个智能体免费运行。持久磁盘、快照、网络和外部模型推理仍是不同的资源项目；仅凭目前公告，无法确定客户最终会支付多少费用，或在不同工作负载下节省多少成本。
“零密钥”不是没有身份，也不是不会误操作
Google强调，安全设计以沙箱内部可能被攻陷为前提：模型可能读到恶意邮件、网页或工具输出，并据此执行不该执行的操作。因此，长期用户凭据、OAuth刷新令牌和云服务账号密钥不应留在执行环境内。
其方案不是取消身份认证，而是把身份和凭据分层。microVM仍会获得短期、会话范围的身份材料，包括基于SPIFFE的工作负载身份；长期授权和访问后端服务所需的凭据，则保留在沙箱之外。
当沙箱发起外部请求时，请求先经过代理，再由节点外的Agent Gateway核验用户委托、智能体身份、节点身份及相关策略，随后在网关侧注入目标服务需要的凭据。技术详解还称，microVM没有普通的对外虚拟网卡或直接VPC访问路径，通信需要经过受控代理边界。
这一设计试图减少“攻破沙箱后直接窃取长期密钥”的风险，但不意味着沙箱里不存在任何身份令牌，更不意味着所有已授权操作都天然安全。智能体即便拿不到服务密钥，也可能通过获准访问的工具读取不该读取的数据，或发起不符合业务意图的操作。权限范围、数据保护策略和人工审批仍需单独设计。
这与站点此前讨论的智能体运行行为审计形成互补：隔离与凭据代理限制执行环境能够接触什么，行为审计则帮助判断它实际上做了什么。两者都不能单独证明一项自动化业务已经安全。
托管服务与开源运行时，不能混为一谈
本次公告同时介绍了Agent Substrate，但它不是此次才首次公布的项目。Google在9月的官方文章中，已经介绍了这一面向Kubernetes的开源智能体执行运行时。
两者面向的交付方式不同。Agent Compute Engine计划由Google管理底层机器集群，开发者控制环境镜像、身份、网络访问和生命周期；Agent Substrate则面向希望基于Kubernetes进行定制、或需要部署可移植性的团队。
成熟度也需要分别看待。9月公告称，Agent Substrate可供GKE客户用于非生产负载，生产环境的正式支持则通过准入名单提供。不能据此推断仍待客户预览的Agent Compute Engine已经正式商用，也不能将Substrate的恢复延迟、吞吐或密度数字直接套到新托管服务上。
治理版图扩大，落地范围仍要看文档
计算之外，Google计划把治理能力扩展到更多运行时，并通过基于Envoy代理的策略执行点覆盖多云与混合环境；针对受管设备上的本地编码智能体，也计划提供操作系统级沙箱和本地治理服务。公告将后两类扩展描述为即将进入预览。
Agent Gateway的新增路线还包括令牌和成本控制、模型路由、可扩展策略，以及更简化的工具连接方式；公告将这组能力的预览安排在本季度。这些时间表是发布计划，不能改写为已经普遍可用。
实际部署仍需逐项检查。当前Agent Gateway概览文档列出的支持范围，比公告中的扩展版图更窄：Agent Runtime支持客户端到智能体的入站治理及智能体向外访问的出站治理，Gemini Enterprise则仅支持后者。该文档标注更新于10月15日，早于此次公告，可以说明既有文档基线，却不足以确认此后宣布的所有覆盖已经交付。
对企业而言，值得关注的变化，是云平台开始把智能体执行环境、身份、网络策略和资源回收作为一个整体设计。接下来需要验证的，则是客户预览何时开放、哪些区域与运行时真正受支持，以及真实任务中的恢复体验、安全边界和总成本。在这些信息进一步公开之前，Agent Compute Engine更准确的定位是：一项已有Google内部使用基础、但面向外部客户仍待预览的托管计算服务。