一句话看懂：两位 Google Cloud 工程师基于大量实测，指出智能体沙箱在冷启动、隔离、安全性和状态恢复等维度存在严重的营销宣传与实际表现偏差，为企业选择执行环境提供了决策框架。
事件核心：发生了什么
Google Cloud 技术团队工程师 Ryan Ismert 与 Alan Blount 在 2026 年 9 月 1 日发布公开评测，针对当下热门的 AI 智能体沙箱市场提出五大核心判断。测试显示，供应商宣称的 100-150 毫秒冷启动数据基于空循环测量，实际使用 e2b_code_interpreter SDK 引导一个 2 vCPU/1 GB 沙箱平均耗时约 610 毫秒，是标称值的 4 倍；升级到 8 vCPU/8 GB 桌面容器后，引导延迟攀升至 2.3 秒，加载无头 Chromium 还需额外约 10 秒。评测还指出，对于自主智能体，网络出站请求比虚拟化层本身是更大的攻击面，而状态分叉与内存快照能力比原始启动时间更能决定生产环境体验。
为什么重要
智能体应用正从演示走向生产部署，但现有云基础设施假设在自主智能体上并不成立——智能体 95% 的会话时间在等待模型推理或外部工具，只有短促的密集计算突发。这意味着传统微服务或批处理作业的资源配置逻辑不再适用，沙箱选型直接影响延迟预算和成本结构。此外，当大模型被授予终端权限后，能编译二进制文件、安装第三方包并发出网络请求，一个恶意包或内核漏洞利用就可能波及整个基础设施。这次评测为行业提供了基于实测的选型参照，而非依赖供应商主页的营销数字。
对用户/开发者/创作者的影响
对于正在构建智能体应用的开发者，最大启示是不要轻信冷启动横幅数据，应测量真实工作负载下的表现，并为高频使用的环境模板建立预热工作节点池，以把稳态分配延迟压到 p90 约 200 毫秒。同时需明确隔离谱系：与邻居共享了哪一层代码决定了安全边界。对于企业采购方，建议在确定沙箱技术栈前，先回答评测提出的四个问题，涵盖隔离需求、网络出口策略、状态持久化方式以及流量形态匹配度。普通创作者若使用平台提供的智能体工具，应理解交互卡顿可能源自沙箱引导开销而非模型本身。
值得关注的后续
目前公开信息显示，该评测聚焦于最常见的沙箱解决方案，还有数十种专业场景未覆盖。后续值得关注三点：一是 kubernetes-sigs/agent-sandbox 等开源预热池项目会否成为事实标准；二是各沙箱厂商是否会调整宣传口径，或推出面向真实负载的优化方案；三是围绕网络出口安全和状态快照的能力是否会成为差异化竞争焦点，推动新一轮产品迭代。
