Google 披露 Agent Compute Engine：给 AI 智能体一台会暂停的云电脑
让 AI 帮忙查一张表，下一句话可能就是“接着用昨天的资料做图”。这时有用的不只是对话记录：昨天安装的工具、写好的脚本、下载的文件，最好都还在。但如果每个等待下一条消息的智能体都一直占着一台云服务器，运行成本很快就会成为问题。
此前本站介绍 Gemini 企业智能体的身份与调度时，重点是智能体以什么身份工作。这一次，Google 把更多注意力放到了它实际使用的“电脑”上。
Google 在 10 月 22 日披露的 Agent Compute Engine 技术方案正面处理了这件事：给智能体会话提供硬件隔离的微型虚拟机，同时管理暂停、恢复和持久工作区。它已经用于 Google 内部的智能体工作负载，面向外部开发者的 Google Cloud 预览则计划在未来几个月推出。
等待的时候，把电脑“存起来”
智能体的任务通常是一段一段推进的：调用模型，执行工具，读取结果，再决定下一步。有时模型还在生成指令，有时需要用户回答一个问题，真正运行代码的计算环境却已经闲下来了。
Google 的发布公告说明，系统能够在会话进入空闲状态后保存快照，释放活跃计算资源，下一次需要时再恢复。公共基础环境采用写时复制等机制共享，用户自己的工作状态则继续保留。
可以把它理解为把一张工作桌连同正在做的事情暂时收好，下一次继续展开。这是帮助理解的比喻：技术上涉及内存、文件和执行环境的保存恢复，效果依赖系统如何识别空闲状态、怎样调度资源，并不等于模型凭空记住了所有工作细节。
这一设计也解释了为什么“长期运行的智能体”不一定要“长期占满一台机器”。不过，减少空闲计算消耗不等于所有费用归零。模型调用、持久存储和实际执行仍然需要资源；目前也不能凭架构描述替尚未开放的产品算出一个通用账单。
有自己的电脑，也要有受控的钥匙
为智能体运行代码提供隔离环境，是另一半问题。Agent Compute Engine 把负责选择下一步的编排程序与实际执行代码的沙箱分开，并把对外访问的检查放在沙箱之外。
来源：Google Cloud 技术原文架构图，2026 年 10 月 25 日核查。右侧展示执行环境、生命周期和网关，底部为身份、治理、可观测性与评估。
这里需要分清两类东西：证明“这个请求来自哪个工作负载”的短期身份，以及能持续访问用户邮箱、云服务的长期凭据。Google 所说的外置凭据设计，核心是后者不交给不可信沙箱保管，不应被简化成环境里完全不存在任何身份证明材料。
Agent Identity 文档描述了每个智能体独立的加密身份，以及它与身份验证管理器、网关的配合。在相应集成中，最终用户凭据由外部管理，在网关处处理；审计记录也可以区分智能体与它代表的用户。
其基础之一是 SPIFFE 身份标准。标准说明了工作负载身份和短期、自动轮换的身份文档。身份证明回答的是“谁在请求”，并不会自动赋予所有资源的访问权；允许做什么，还需要单独的权限规则。
沙箱之外，决定一次请求能不能出去
假设智能体正在分析公司文件，却读到一段要求把资料发往陌生地址的文字。隔离环境能够限制它碰到其他机器，外置凭据能够减少直接盗走长期密钥的机会，但这两层机制本身不能决定每一份文件究竟该不该发送。
这正是 Agent Gateway一类治理层要处理的问题。文档把身份、批准的目标目录、访问政策和内容检查放在一起：谁能连接哪个工具、允许哪些请求通过、行为如何留下可审计记录，都需要被明确管理。
因此，独立云电脑不会自动消除提示注入和错误操作。若某个危险操作本来就在授权范围内，仍然需要更具体的业务规则和适当的人工确认。基础设施提升了能够实施控制的位置，组织也必须把控制规则设置清楚。
文档还给出开放节奏：Agent Gateway 面向不同运行环境的支持并非同时交付，GKE、Cloud Run 和跨云扩展仍有预览或即将推出的说明。不能把一张未来架构图当作每个产品入口今天都已经具备的功能清单。
同场公布的另一条路线是 开源 Agent Substrate。它在 Kubernetes 上提供沙箱生命周期、身份和网络管理，可使用 microVM 或 gVisor。仓库也明确标注目前处于 1.0 之前，API 与行为可能显著变化。它与 Google 托管的 Agent Compute Engine 是不同的交付对象，前者的演示性能不能直接当作后者对所有客户的性能承诺。
这次披露把执行环境推到了智能体竞争的前台。对用户来说，价值会体现在一些很具体的时刻：隔天继续任务时文件是否还在，等待确认时是否浪费计算，发生异常后是否查得到请求记录。只有这些环节也可靠，持续性的 AI 工作流才有机会成为可以日常依赖的服务。
资料核查截至 2026 年 10 月 25 日。本文依据公开技术说明分析架构，未独立测试其性能或安全性。
评论