从服务器 OS 到 Agent 沙箱：腾讯云如何打通 AI Infra 的生态底座

Agent 弹出授权请求，询问你能否访问目录，或执行脚本。你瞥了一眼，直接点下 Allow，继续手头的工作。 这个场景是不是似曾相识？ Anthropic 统计，类似的请求 最终有 93% 都会被用户盲目批准。所谓的安全拦截，早已在频繁的授权弹窗里形同虚设。无人细究那段被放行的代码究竟做了什么。与此同时，CodeRabbit 对 470 个开源 GitHub PR 的分析显示，AI 生成代码里的安全漏洞，最高可达人工代码的 2.74 倍。 它们都指向了 Vibe Coding 时代同一个悬而未决的问题：代码生成的速度远超人工审查的极限，但代码执行的边界，却缺乏足够可靠的基础设施来支撑。 想划定这道边界并不容易。过去，行业长期在“隔离要够硬、启动要够快、成本要够低”之间反复妥协。容器、传统虚拟机（VM，Virtual Machine）、托管云沙箱各有答案，也各有死角。 近期，腾讯云开源 Cube Sandbox，一个面向 AI Agent 的沙箱项目。4 天后，GitHub Star 突破 4000。（https://github.com/TencentCloud/CubeSandbox） 在 Agent Infra 这个从不靠话题出圈的赛道，这条增长曲线说明的不只是关注度，它更像是一次集体表态：开发者已经不愿再在"安全"与"性能"之间将就，也不愿将执行环境长期绑定在海外托管云服务里。 一个可以自己部署、自己掌控的沙箱，正在从可选项变成刚需。 沙箱为什么难做？ 沙箱不是新概念。 在线 IDE、代码评测、安全测试、Serverless、浏览器自动化，都早就需要隔离环境。但 Agent 带来的变化在于，过去大多是人写代码、人审代码、人运行代码；现在，Agent 会动态生成代码，调用 Shell，读写文件，安装依赖，访问网页，并在多轮执行中根据反馈继续调整动作。 这让沙箱要承受的工程压力完全变了。 它不只是要隔离一段预期明确的代码，而是要 承接模型生成的、不确定的、可能连续执行的任务链条。执行环境既要足够安全，又不能慢到破坏交互体验；既要支撑高并发，又不能把成本推到企业难以接受的程度。 这就是 Agent 执行环境长期绕不开的三座大山。 Docker 容器 最轻，启动快、成本低，也最容易被开发者接受。但容器本质上 仍共享宿主机内核。NIST 在容器安全指南中也指出，容器虽然提供隔离，但并不像虚拟机那样具备清晰、具体的安全边界。对普通业务应用来说，这未必不可接受；但对执行模型生成代码、用户输入脚本和不可信任务的场景来说，这道边界显然不够可靠。 传统虚拟机 把隔离做得更彻底。每个实例都有独立操作系统内核，攻击面收敛，安全边界更清楚。但代价也明显：启动慢、资源重、密度低。Agent 的任务往往是高频、短生命周期的，一次代码片段执行、一次浏览器操作、一次工具调用，都可能需要快速拉起一个干净环境。传统 VM 很难成为默认答案。 以 E2B 为代表的海外托管云沙箱 则绕开了自建复杂度。它开箱即用，接口友好，也已经在不少 Agent 项目中形成使用习惯。但对国内企业来说，执行环境不在自己手里，代码和数据要进入外部云端，成本、延迟、合规和供应商锁定都会随规模放大。 这也是为什么，一个可自部署、可审计、可掌控的开源沙箱，会在 Agent Infra 里变得越来越重要。 这正是 Cube Sandbox 切入的位置。 在不可能三角里找到第四条路 Cube Sandbox （以下简称 Cube） 选择的是 MicroVM 路线。 它基于 RustVMM 与 KVM 构建，官方基准测试显示，可以在 60ms 内创建具备完整服务能力的硬件隔离沙箱，同时把单实例内存开销控制在 5MB 以下。在腾讯云提供的 50 并发基准测试中，平均冷启动为 67ms，P95 约 90ms，整体保持在百毫秒级。 Cube Sandbox 测试数据 这套特性背后，突破的正是 Agent 执行环境里的几道硬门槛。 首先是隔离。Cube 的每个沙箱拥有独立 Guest OS 内核，不再依赖 Docker 式的共享内核边界。对 Agent 来说，这一点很关键。因为它执行的不是一段完全确定的业务代码，而是模型在上下文中生成的命令、脚本和操作链条。一旦没有硬边界，错误就不只是一次输出失误，而可能变成对系统状态的污染。 其次是速度。 传统 VM 的问题在于隔离够硬，但太重。Cube 通过资源池预置、快照克隆等方式，把冷启动压到 60ms 以内。对 Agent 交互来说，这不是锦上添花。沙箱一旦变慢，工具调用、代码执行、调试反馈都会被拖慢，整个 Agent 体验会迅速失去连续性。 再次是密度。Agent 一旦进入规模化场景，沙箱不会一个、十个地跑，而是成百上千地并发。Cube 通过 CoW 内存复用等机制，把单实例开销压到 5MB 以下，目标是在单机上承载更高密度的沙箱实例。 对基础设施来说，指标只是第一层。更关键的问题是：这些能力有没有在真实业务里经受过足够复杂的压力？ Cube 值得讨论的地方正在这里。它不是一个只在实验室里跑通的 Demo。它来自腾讯云 Serverless、虚拟化和大规模弹性调度场景的长期积累，并在元宝 AI 编程、MiniMax Agentic RL 训练等真实场景中验证过高并发沙箱调度能力。 对元宝这类 AI 编程场景来说，沙箱不是一个外围组件，而是代码生成之后能否安全执行、低成本执行的基础设施。 最后是迁移门槛。原生兼容 E2B SDK，仓库中也提供了 OpenAI Agents 相关接入示例。已有应用理论上只需替换 URL 环境变量，就能把执行后端迁移到 Cube 上。 可以看到，Cube 并不是在容器和虚拟机之间简单二选一，而是在尝试把 VM 的硬隔离、容器的轻量化和云沙箱的易用性，压进一套可自部署、可掌控的 Agent Runtime 里。 跨过硬件部署的最后一道门槛 如果说，Cube 开源初期回答的是：这个沙箱能不能足够安全、足够快、足够轻。 那么本月上线的 v0.2.0 版本要回答的则是更深层次的问题：它能不能被更多开发者和企业更低门槛地部署和管理。（https://github.com/TencentCloud/CubeSandbox/releases/tag/v0.2.0） 关键来自于 PVM （Pagetable-based Virtual Machine，基于页表的虚拟化部署模式）。 它让普通云服务器无需裸金属或嵌套虚拟化，也能运行 CubeSandbox。这意味着 Cube 的部署边界被明显拓宽：它不再只面向具备底层环境条件的团队，而是开始进入普通 CVM 场景。 这件事看起来很底层，但对 Agent Infra 很关键。 基础设施要进入生态，第一步不能太难。如果一个沙箱项目要求开发者先解决裸金属、内核包、虚拟化配置和一堆复杂依赖，它就很难成为主流开发者的默认选择。 此外，v0.2.0 还带来了三项更新： Web 控制台上线：集群、沙箱、模板的可视化管理能力首次整合进来，开发者不再需要纯靠命令行管理沙箱实例，操作链路大幅收短，运维可观测性同步提升。 兼容范围扩大：DEB 系（Ubuntu / Debian）