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）与 RPM 系（CentOS / Rocky）均已支持，一键部署脚本与预编译内核包同步提供，主流 Linux 发行版的安装路径全面打通。
OC9 深度集成：Cube 的 PVM 内核模块已开源合入 OpenCloudOS 9 主线内核，使 OC9 成为目前对 PVM 支持最顺滑的发行版之一，内核直接集成了 Cube 的 PVM 宿主内核支持，而其它发行版则需要额外安装预编译内核包。
目前，OpenCloudOS 社区已发布 Cube 的 RPM 包，OC9 用户可通过 yum 直接安装部署（4 天斩获 4K Star 的 Agent 沙箱，5 步在 OC 上跑通）
随着部署链路进一步标准化，Cube 也开始收到国内外开发者的早期实践反馈，这种社区验证正是基础设施项目走向成熟的重要信号。
Cube 解决了 Agent 执行层的隔离与调度问题，但一套完整可落地的 AI Infra 方案，还需要底层操作系统的支撑。这正是 OpenCloudOS 9（OC9）的位置。
OC9 是腾讯云主导、多家厂商联合发起的国产开源服务器操作系统，从内核到软件包全面自主维护，不再依赖第三方发行版（包括 CentOS），发布于 2023 年。目前已支撑超过 2000 万节点级生产环境，覆盖金融、互联网、政务等行业，是国内三大服务器操作系统根社区之一。
与其它发行版对 Cube 的支持方式不同，OC9 对 PVM 的支持不是通过外挂补丁包实现，而是将 Cube 的 PVM 内核模块直接合入主线内核。这意味着：
OC9 用户无需额外操作，内核已原生具备运行 Cube PVM 模式所需的全部支持；
后续通过 yum 安装 Cube 的整个部署流程，在 OC9 上的复杂度将降至最低；
随着 Cube 版本迭代，内核级集成意味着更稳定的底层适配，而非依赖外部包的滞后更新。
从操作系统到执行环境，OC9 与 Cube 的组合，提供了当前少有的 “全链路开源与可控” 路径。OC9 负责底层 OS 的内核级维护与长期支持，Cube 负责上层 Agent 的安全隔离与弹性调度，两者的内核级集成，让从 OS 到沙箱的部署不再有断层。
对金融、政企及内部研发平台等对数据主权高度敏感的场景而言，这套组合的价值不局限于单一技术指标的提升，而在于它给出了 一条完整、可审计、且无需依赖海外托管服务的落地路径。
而在 Cube 与 OC9 之外，腾讯云也在推进 TACO AI 加速引擎与 FlexKV 多级缓存系统，在缓存复用与推理效率上补齐关键拼图。
整体来看，腾讯云正围绕“安全沙箱 + 推理加速 + 缓存优化”构建技术闭环，逐步深化 Agent 基础设施的全栈能力，致力于突破智能体在大规模生产级应用中的运维与性能瓶颈。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。