从亚百毫秒级启动到生产级部署，腾讯云为何重构 Agent 沙箱？

2026 年初，OpenClaw 以一己之力掀起了本地终端 Agent 热潮，人们开始习惯把文件系统、浏览器、邮件、终端，以及各种账号权限交给 Agent。“养虾”，一度成了上半年最时髦的事儿。

但“养虾”的背后，潜藏着比模型幻觉更直接的风险。

Meta 超级智能实验室对齐负责人 Summer Yue 曾公开表示，她的“小龙虾”擅自删除和归档了数百封个人邮件，完全无视她给出的停止指令，最后只能通过手动关闭运行设备来终止相关进程。担忧很快从个人用户延伸到企业。多家科技公司出于安全考虑，开始限制员工在工作设备上使用“小龙虾”；中国工业和信息化主管部门也公开提醒，配置不当的“小龙虾”实例可能面临网络攻击和数据泄露风险。

OpenClaw 把 Agent 推到了聚光灯下，也把它脚下那层长期被忽略的基础设施带到了台前。大家开始意识到，一个拥有系统权限、行为却无法被完全预判的 Agent，如果直接运行在个人电脑或生产环境里，几乎等同于“裸奔”。它需要一个 独立、隔离、随时能够恢复的执行环境 ——这也是沙箱近期受到开发者和云厂商集中关注的原因。

围绕这层新基础设施，国内外已经出现了一批探索。Anthropic 以公开测试的形式发布了 Claude Managed Agents，提供一套完整的托管式 Agent 运行平台；E2B 则把隔离沙箱封装成开发者可以直接调用的服务，成为不少 Agent 项目主动兼容的一套接口参照； 2026 年 4 月，腾讯云正式开源 Cube Sandbox，将其定位为一套面向 AI Agent 的执行环境底座 。 （Cube Sandbox 源码： https://github.com/tencentcloud/CubeSandbox ）

在这些探索中，Cube 可以视作观察 Agent Infra 演进的一个特殊样本。原因在于， 它做的是一个足够新的 Agent Infra 课题，但底层是一套从 Serverless 生产系统中演进而来的基础设施 。

与不少在 Agent 爆发后快速出现的沙箱项目不同，Cube 的研发最早可以追溯到 2023 年前后，彼时它解决的还是 Serverless 场景中的底层问题。随后，Cube 陆续进入代码执行、数据分析、Agent RL 等场景，并最终转向 Agent Runtime。开源后，Cube 快速进入海外 Agent 生态。今年 7 月，OpenClaw 创始人 Peter Steinberger 主动为 Crabbox 提交并合并 PR，将 Cube 接入其 provider 体系，与 E2B、Modal 等沙箱服务并列。

从 Serverless 到 Agent 沙箱，哪些能力能够直接继承，哪些能力必须围绕 Agent 重新设计？Cube 系统有哪些设计思考？一个沙箱要从“能运行”走到“大规模生产可用”，真正的门槛是什么？腾讯云为什么选择把这套系统全面开源？围绕这些问题，InfoQ 日前采访了腾讯云 IaaS 前沿技术团队负责人、腾讯 14 级研发工程师金峰，以期了解 Cube 从 Serverless 底座转向 Agent 沙箱的过程，以及团队对下一代 Agent Infra 的判断。

Agent 对基础设施的要求，正在发生根本变化。

过去，无论是虚拟机、容器还是 Serverless，基础设施要解决的核心问题都比较明确：提供可用的计算资源，让应用稳定运行。但 Agent 不是传统意义上的应用，它由大模型驱动，可以自主规划、调用外部工具、访问网络，以人的身份做任何事情。在最新的探索中，大家期望 Agent 可以自主执行长达数天乃至数周的长程工作任务，在这么长的生命周期里，如何保证 Agent 的自主行为依然可控？显然，这个问题传统的计算资源解决不了，需要一个匹配 Agent 行为方式的运行环境。

金峰认为，Agent 本身具有非常鲜明的特点，按照不同场景可以将需求大致分为三类。

第一类是为 Agent 的工具执行提供一个完全隔离的环境。 这也是当前沙箱使用最普遍的场景，对沙箱的要求是高并发下的拉起能力足够强，仿佛本地调用函数一样；同时资源利用率要高，能在一台普通服务器上承载数百甚至上千个并发实例。

第二类是由 Agent Harness 承载的长时运行任务。 Agent Harness 本质是个有状态服务，在它的长时运行过程中，会不断产生各种中间状态和持久化状态产物。承载 Agent Harness 的沙箱需要有快速的状态保存/恢复能力，以匹配用户对 Agent 本身的快速暂停恢复及克隆回滚需求。

第三类更进一步：给 Agent 访问的服务提供一个统一的底座。 不同于传统服务更多的强调稳态运维能力，面向 Agent 的服务，可能会直接成为 Agent 训练和推理循环的一部分，对服务本身的快速启停、分支探索回滚等能力提出了更高的要求。此外，传统服务如何零代码修改变成对 Agent 友好的服务，也是 Infra 需要解决的问题。

面对这些需求层面的新变化，如果还在沿用传统基础设施，显然不够用了。“Agent 确实需要一种更好的、更先进的 Infra，而不是继续复用老式的 Infra。”金峰认为，如果从提供计算资源的角度看，虚拟机、容器和 Serverless 这些传统基础设施都能运行 Agent，但它们都只解决了一部分问题。

比如，传统虚拟机虽然能提供较强的安全隔离，但启动速度可能在数秒左右，如果计算上控制面调度、资源分配和网络准备等环节，从 API 请求到实例真正可用，端到端可能需要 5-10 秒。相比，CubeSandbox 的冷启动时间不到 60ms，更适合高频工具调用和突发弹性扩容场景。

Docker 容器启动快、资源利用率高，也是当前不少 Agent 应用的过渡方案。但它的硬伤在于，共享宿主机内核，安全隔离能力天然很弱。随着 Agent 权限不断扩大、承载的任务越来越重要，容器在安全隔离层面暴露出的问题将越来越突出。

Serverless 函数在快速弹性和按需计费方面更接近 Agent 的需求，也适合执行短时间、无状态的工具任务。但它通常围绕事件驱动和无状态服务设计，通过横向扩缩容实现资源弹性，空闲时直接缩容至零，难以匹配 Agent 的有状态运行模式。

沙箱能受到关注，是因为它在试图补上这些传统方案之间的空白：既提供接近虚拟机的隔离边界，又具备接近容器的启动速度和资源密度，同时围绕 Agent 的状态保存、暂停恢复、克隆和回滚重新设计运行方式。

真正的难题，不只是做出一个沙箱，是让它成为生产基础设施，真正进入企业生产环境。

“企业对稳定性的关注度，可能会高于性能。”金峰表示，Agent 发展太快，底层基础设施没有形成成熟的最佳实践，很多团队还在沿用容器等传统方案过渡。对 Agent 这类有状态服务来说，除了实例本身能否稳定运行，任务状态、文件和执行环境在异常后能否完整恢复同样关键。此外，企业还会考察项目能否持续维护、部署后是否具备足够的自主可控能力。这也是为什么， Cube 的演进目标始终指向生产级大规模可用：不仅要让沙箱跑起来，还要证明它能在生产环境中稳定、规模化地运行。

如前文所说，Cube 底层是一套从 Serverless 生产系统中演进而来的基础设施，最早启动于 2023 年左右。当时，团队主要面对的还是 Serverless 场景。Serverless 理想中的运行方式是，函数被调用时，计算环境能够快速出现；任务结束后，资源立即释放。但在当时，许多 Serverless 产品只是提供了类似 Lambda 的接口，底层依赖的仍然是传统技术。

腾讯云内部希望在技术上构建一套与这种模式严格匹配的基础设施，这也是 Cube 诞生的背景。Cube 最初的设计目标，就是重新建设一套原生适应小资源粒度、极速冷启动和海量并发的运行系统：不调用时几乎不占资源，需要时在百毫秒内完成环境创建，执行结束后迅速销毁。

这个起点，后来意外成为 Cube 进入 Agent 时代的技术伏笔。

在技术架构上，Cube 采用 RustVMM+KVM。“我们希望构建一套轻量级基础设施，当时，基于 RustVMM 构建轻量虚拟机是行业内较受关注的技术路线。不过，我们的选择与行业常见方案有所不同。很多项目会选择 Firecracker，而我们选择了 Cloud Hypervisor。”金峰表示，腾讯云内部面对的场景更复杂，后续会有很多硬件相关的需求。与 Firecracker 相比，Cloud Hypervisor 原生支持更多能力，例如设备热插拔和硬件直通等。因此团队选择在一个功能相对完整的 VMM 上做减法，将整体开销优化到与 Firecracker 接近的水平。

在这套技术路线之上，Cube 建立了三项核心能力。

第一项是快速启动。 Cube 采用基于快照的启动方式，提前创建好模板快照，请求到来后直接基于快照恢复运行环境，不必重新经历完整的虚拟机启动过程，从而将资源拉起时间压缩至百毫秒以内。

第二项是高并发。 Serverless 场景下，资源需要被频繁创建和销毁，对单机和集群控制面的并发能力都提出了更高要求。在计算节点内部，Cube 进行了大量异步化设计，并组成沙箱所需的网络、存储等资源。在集群层面，Cube 没有直接沿用传统虚拟机或 Kubernetes 的控制面设计，选择让控制面具备横向扩展能力：单个计算节点独立承接沙箱创建，增加节点后，集群整体的并发处理能力也可以同步提升。

第三项是高密度。 为了让单台机器承载更多实例，Cube 引入了大量资源共享和写时复制机制，不同实例可以复用相同的只读内核、根文件系统等底层资源，只有当某个实例真正发生写入时，才为其分配独立资源，从而减少大量重复的内存和存储开销，使单个节点能够承载上千个轻量实例。

这些能力最初都是围绕 Serverless 的运行特点构建的，随着 Agent 兴起，团队发现，它们同样契合 Agent 对运行环境的需求。这也是 Cube 从 Serverless 基础设施走向 Agent 沙箱的技术基础。

“整个过程大致可以分为三个阶段。”金峰表示，第一阶段主要围绕代码执行和数据分析。早期，以 E2B、Manus 为代表的产品，已经开始让 Agent 在隔离环境中执行代码，或者读取 Excel 等文件，完成数据分析和报表生成。Cube 最初也瞄准了这两类相对明确的场景，并逐步进入腾讯元宝等产品中。

第二阶段围绕 Agent 强化学习（Agent RL）。相比普通的代码执行，Agent RL 会同时拉起大量训练环境，对镜像管理、快速启动和高并发提出更高要求。Cube 在 Serverless 阶段积累的架构能力，也在这一阶段得到进一步验证。金峰表示，当时 Cube 在 MiniMax 场景中的多项指标表现明显优于其他方案，并由此逐渐积累起行业口碑。

第三阶段则从服务模型训练，进一步走向 Agent Runtime。随着 OpenClaw 等产品带动本地终端 Agent 兴起，人们发现传统基础设施成为了一种“将就”，Agent 应该拥有更加适合自身运行特点的执行环境。

“我们不是 Agent 火了以后才开始做这套系统。”金峰提到，Cube 的底层能力已经在 Serverless 和腾讯内部业务中经历了两三年的生产磨合，主体架构并不是一个刚刚完成的原型。这也是它与许多新出现的 Agent 沙箱最本质的区别：它先有一套为高并发、短生命周期负载设计的底座，再根据 Agent 的行为逐步改变系统边界。

因此在 v0.3.0 版本中，团队率先为 Cube 增加 快照、克隆和回滚 能力，补足的就是 Agent 对有状态环境复制与恢复的需求。快照（snapshot）可以将运行中沙箱的内存、运行状态和磁盘整体保存为独立快照，源沙箱销毁后也还能用；克隆（clone）能把一个沙箱裂变成 N 个；回滚（rollback）能让沙箱原地恢复到之前某次快照的状态，让内存状态和文件系统完全还原。对于 Agent 来说，这相当于同时获得了环境的“分身”和“回到过去”的能力。

在解决状态复制与恢复之后，Cube 的下一步，是处理 Agent 行为本身带来的风险。“Agent 是大模型驱动的，它会做什么事情，我们是没办法预判的。你可以用沙箱把它关起来，但它在里面干什么，其实并不完全可知。”金峰表示。所以在 v0.4.0 版本中，Cube 重点补齐了出站治理、凭证托管和网络观测审计等能力。增加的这些能力，本质上都是在不削弱 Agent 灵活性的前提下，为其不可预测性增加边界。

到了 v0.5.0，Cube 想解决的是“ 稳、省、广 ”。这一版本的核心核心特性就是让沙箱学会自动暂停（AutoPause）与唤醒（AutoResume），增加对 Arm 架构的原生支持，并将单机 Demo 走向集群部署，为生产环境提供更完整的部署架构示例，降低企业将 Cube 引入真实业务的门槛。

“我们不希望干扰 Agent 的灵活性，因为泛化能力正是 AI 的价值；但它不可控的部分，还是要把边界管好。”金峰说道。从 v0.3.0 的快照、克隆和回滚，到 v0.4.0 的出站治理、凭证托管和网络观测审计等能力，再到 v0.5.0 的自动休眠恢复、Arm 支持和生产部署，Cube 的版本演进既保留了 Agent 的自主性和泛化能力，也将它的不确定性限制在可控范围内。

但对企业来说，这些还不够。一个新基础设施能不能真正进入生产环境，需要看它是否能被部署、运维和接入现有系统。

Cube 最初主要运行在物理机上，虽然能充分发挥 KVM 和轻量虚拟化的性能，但也抬高了外部用户的使用门槛。尤其在云上环境中，要求企业单独准备物理机，成本和运维复杂度都比较高。因此在开源不久后，团队便逐步补齐在云上虚拟机中运行 Cube 的能力。最新发布的 v0.6.0 版本，增加了对 Kubernetes 的支持，进一步延续降低部署门槛的思路。