Google公布Agent Compute Engine：AI代理运行环境将如何管理身份与成本
Google Cloud公布面向AI代理的Agent Compute Engine，客户预览预计未来数月开放。本文结合架构解读与身份标准，分析隔离执行、暂停恢复、权限治理及企业试点应核对的条件。
AI代理能写脚本、操作浏览器后，企业面临的新问题是：这些动作在哪里执行，任务等待时如何计费，访问业务系统时又该使用谁的身份？Google Cloud在10月22日公布Agent Compute Engine及扩展的代理治理能力，将执行环境、资源调度与权限问题放到同一张基础设施路线图上。
先说明开放范围：Google表示，该计算服务已支撑Gemini的部分工作任务，但面向客户的预览预计在未来数月提供。公告不等于所有开发者现在都能开通，也不能据此推断区域、定价及正式商用时间已经确定。
背景：代理工作为什么不等于普通云主机任务
传统接口通常接收请求后迅速返回；代理却可能执行一轮工具调用，再等待模型推理、外部接口或用户回应。若运行环境一直保持活跃，等待也会占用资源。另一方面，代理运行的代码和网页内容可能不可信，执行权限需要受到约束。
这意味着评估代理基础设施时，除了机器规格，还要看任务启动、闲置、恢复和结束的完整生命周期。本文认为，对工作负载密集的平台团队而言，这种生命周期的设计可能比单次启动的峰值速度更影响成本和可靠性。
公告核心：每个代理拥有隔离的执行空间
Google将Agent Compute Engine描述为面向代理构建的计算服务，以microVM提供硬件隔离边界，结合Cloud Hypervisor及Titanium基础设施。其技术解读强调检查点、快速恢复及写时复制内存共享：代理等待时暂停执行环境，需要继续工作时再恢复。
官方还说明，每个microVM配备独立Hyperdisk，用于保留工作空间与上下文。对于跨多轮处理文件或代码的任务，持久化意味着恢复后有机会接着处理，而无需每次重新准备整个环境；具体恢复语义和故障处理仍要按后续产品文档验证。
身份与授权：有隔离环境，并不自动拥有业务权限
公告提出为执行环境分配可验证身份，使用短期凭据，并在microVM外的出口链路注入服务凭据。这样设计的目的，是降低代理直接接触长期密钥的需要，同时为策略判断与审计提供身份线索。
Google的Agent Identity文档与SPIFFE项目资料提供了理解这一机制的背景：工作负载身份帮助服务确认请求来自哪个运行主体，但身份验证本身不能替代业务授权。能证明“这是某个代理”，与允许它读取客户库、修改订单或调用付款接口，是两类不同的控制。
两条路线：托管计算服务与Kubernetes运行时
同一公告还介绍Agent Substrate这条开源、Kubernetes原生路线，面向需要定制、可移植性或已有Kubernetes基础的平台团队。它与Agent Compute Engine面向客户的预览计划应分别理解，不能因为开源运行时可以查看，就写成托管服务已经全面开放。
对采购团队而言，选择可能取决于现有运维体系：托管服务需要核对可用区域、服务等级与集成边界；自建运行时则需要承担升级、容量规划及事故响应。官方演示与基准结果只能作为考察起点，不能直接当作自身业务的容量承诺。
影响：从模型效果，扩展到执行过程的可控性
这一动态的行业信号是，代理平台的竞争正在延伸到模型调用之外。企业交付一个可持续运行的代理，需要同时回答资源如何回收、状态如何恢复、凭据如何轮换，以及失败后能否追查动作来源。
落地时可先选择一个文件整理或内部数据处理任务，记录活跃时间、等待时间、恢复失败率及越权拒绝情况，再比较现有方案。本文未独立运行该服务，不对安全强度、成本节省或性能提升作验证结论。
适合哪些人关注
平台工程师可关注暂停恢复与现有任务系统的衔接；安全团队可检查身份映射、出口策略和凭据暴露面；AI应用开发者则应确认浏览器、文件和工具调用在环境恢复后是否保持一致。正在选购企业代理平台的负责人，宜等待预览的实际资格、定价和区域说明，再据真实工作负载做试点决策。
来源参考
公告信息截至2026年10月24日核查。以下链接分别用于核对产品事实、技术背景或评测方法；本文分析由AI导航编辑部独立撰写。
