从亚百毫秒级启动到生产级部署，腾讯云为何重构 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 不能复用老式 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 的演进目标始终指向生产级大规模可用：不仅要让沙箱跑起来，还要证明它能在生产环境中稳定、规模化地运行。
从 Serverless 到 Agent 沙箱，Cube 如何跨过生产级门槛？
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 的行为逐步改变系统边界。
从“跑得快”到“管得住”，Cube 开始为 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 的支持，进一步延续降低部署门槛的思路。
“Kubernetes 是很多企业基础设施的事实标准，很多公司的机器资源本身就是由 Kubernetes 管理的。”金峰表示，真正使用 Agent 的业务团队和负责集群运维的团队往往并不是同一批人，如果部署 Cube 必须先从现有 Kubernetes 集群中拆出一批机器，再单独搭建和维护一套集群，业务团队很难独立推动落地。
从 v0.6.0 版本起，Cube 的控制面组件和计算节点可以通过 Helm Chart 直接部署到腾讯云 TKE、标准 Kubernetes 或 k3s 集群中。这样一来，企业无需在现有基础设施之外再维护一套独立的部署体系，Cube 的组件也可以作为标准工作负载纳入 Kubernetes 管理，复用企业已经成熟的部署、升级、扩缩容和运维能力。在后续版本中，Cube 还计划让 Kubernetes 部署更“原生”：从 Helm 部署进一步走向以 CRD、Operator 为核心的原生管理，并补齐平滑升级能力。
v0.6.0 新增的另一项备受开发者关注的能力，是正式引入兼容 E2B 标准的 Volume 框架。“Volume 是很多开发者关注的一项能力，因为 Agent 在运行过程中通常需要持久化存储，并不是任务执行结束后，所有数据都可以随沙箱一起销毁。Agent 可能需要加载多个 Skills，也可能在运行过程中产生新的 Skills；在数据分析场景中，它还可能需要读取外部 Excel 文件，并输出新的 Excel 文件。因此，沙箱需要一套与自身生命周期解耦的持久化存储。”
金峰提到，在早期版本中，Cube 提供了一种相对临时的解决方式：将宿主机上的目录绑定到沙箱中。不少外部用户也在使用这项能力，以满足持久化存储需求。引入 Volume 后，Cube 对存储能力进行了进一步抽象。除了 Sandbox，系统中也增加了与其平行的 Volume 抽象，用来代表持久化存储。团队还参考了 Kubernetes CSI 的设计思路，采用插件化设计，用户可以针对不同存储编写类似 Kubernetes CSI 的插件，对接自己的后端存储，同时对外保持统一的接口抽象。
Kubernetes 支持解决的是 Cube 如何进入企业已有的计算和运维体系，Volume 解决的是 Agent 所需文件与任务产物如何进入企业已有的存储体系，早先版本发布的 CubeEgress，则给企业用户提供了充足的网络治理能力。这几项能力的更新，能够加快 Cube 进入企业已有的基础设施体系，也代表着，Cube 正从一个提供隔离执行环境的沙箱，变成一套可以嵌入企业基础设施的 Agent 运行底座。
以开源开放，推动 Agent Infra 向前一步
2026 年 4 月，腾讯云正式开源 Cube。金峰坦言，开源更直接的原因是，Agent 的发展速度已经超过了基础设施的演进速度。直到今天，关于 Agent 究竟需要怎样的运行环境，行业仍然没有形成明确答案。一种常见观点是，企业已经有了 Kubernetes 和容器，没有必要再引入一套新的沙箱系统。毕竟从“把程序跑起来”的角度看，现有基础设施确实可以完成任务。
但很多差异只有真正使用后才会显现。百毫秒级拉起一个隔离环境、一次克隆出多个执行分支、在 Agent 误删文件后回滚状态，以及在会话闲置时释放资源，再无感恢复——这些都不是传统容器最初要解决的问题。
“我们选择将 Cube 开源，就是希望让更多人亲自体验，看到沙箱能够完成一些传统方案难以做到的事情。开发者只有真正部署和使用，才能更直观地理解 Agent 对运行环境提出了哪些新的要求。”金峰说道。
数据显示，Cube 开源后仅用了 4 天，GitHub Star 数便突破 4000；3 个月后，Star 数已经超过 1 万。如此快速的增长，至少能够说明，Agent 的执行环境已经成为开发者普遍关心的问题。金峰判断，随着行业对 Agent 的关注不断上升，与 Agent 相关的基础设施也将会受到更多关注。
对于未来的版本演进，Cube 团队也早已做好了规划。当前，Cube 的快照、恢复和状态管理能力，更多建立在单机维度。团队下一步的重要方向，是把沙箱的抽象从单机提升到集群，让沙箱能够在集群内跨节点迁移和恢复。当某个节点发生故障时，运行在该节点上的沙箱可以快速在其他节点恢复，从而进一步提升沙箱自身的高可用能力。
沙箱一旦跨节点迁移，首先需要解决的便是存储问题。在单机环境中，沙箱可以依赖本地磁盘保存数据；提升到集群维度后，计算环境和状态必须解耦，沙箱在任何节点恢复时，都能够重新挂载原有数据。v0.6.0 引入的 Volume 框架，是这条路径的起点，后续，团队还需要继续适配分布式存储，并在兼容不同企业环境的同时，保证启动速度和 I/O 性能。
另一个需要补齐的方向是可观测性。目前，Cube 已经能够在网络层观察沙箱访问了哪些外部服务，执行流量审计和访问控制。但 Agent 的行为并不只发生在网络中。它还会调用系统命令、修改文件、启动进程，甚至执行一些高风险操作。团队希望将观测能力进一步下沉到操作系统层，更完整地还原 Agent 在沙箱中做了什么。当它执行敏感操作时，系统也有机会及时审计甚至阻断。
“今天我们叫它 Sandbox，但它已经远远超出了一个沙盒。它代表的是一套 Infra 系统。”金峰说道。
结束语：当 Infra 开始为 Agent 重新设计
当 Agent 还只是聊天窗口里的助手时，风险距离普通人还很遥远。但当它获得了文件系统、终端、邮件和生产系统权限，问题就变得具体起来：它在哪里执行，能够访问什么，做错之后如何恢复，又由谁来记录和限制它的行为？
沙箱因此成为 Agent 基础设施中最早被看见的一部分，但绝不是最后一部分。对于未来 Agent Infra 的演进方向，金峰判断，至少有三个变化值得关注。
第一个变化，是 Agent 从单体走向 Agent Teams。今天的基础设施倾向于把每个 Agent 视为独立个体，通过沙箱将它们彼此隔离；但当多个 Agent 开始分工协作，基础设施还需要为它们提供共享上下文、交换任务产物和协同执行的空间。
目前，社区中已经出现了相关实践：将 Sandbox 与 Volume 设计为彼此独立的抽象，再通过 Volume 划分团队共享空间和个体私有空间，让不同 Agent 在保持隔离的同时共享文件和任务结果。未来，如果以存储作为中转无法满足协作效率，Agent 之间也可能产生更直接的通信需求。
第二个变化，是越来越多服务的主要使用者将从人变成 Agent。“今天的很多服务都是为人设计的，强调人眼可见、可以理解，但这些东西对 Agent、对模型来说可能是低效的。此外，当使用者从人变为 Agent 后，服务本身也会面临更多的突发性和分支实验的挑战。
这意味着，所谓“为 Agent 提供服务”，不会只是单独建设一个入口或网站。真正的变化会深入到服务内部，系统的接口、吞吐、权限控制和交互方式，都可能需要随之调整。
第三个变化，是 Agent 的风险边界会逐渐越过沙箱。今天，人们谈论 Agent 的不可预测性，通常还是将风险限制在一个隔离环境中；但随着 Agent 开始操作数据库、调用企业服务和修改生产系统，它的“触手”会伸向更多系统，潜在故障域也会随之扩大。
“Agent 的触手跳出沙箱以后，我们怎么样依然能够管住它？”金峰认为，未来需要解决的问题，不再只是如何把 Agent 关在一个安全环境里，而是如何在它跨越多个系统执行任务时，仍然能够持续观察、审计和约束其行为，并在保留 Agent 自主性和泛化能力的同时，让整个过程处在人类可控范围内。
从 Agent Teams 的协作，到面向 Agent 重新设计服务，再到将安全边界扩展至整个生产系统，沙箱只是这场基础设施重构的起点。当 Agent 逐渐从工具变成数字世界里的主要行动者，Infra 也不能继续停留在“传统系统勉强能跑”的阶段，而是要真正开始围绕 Agent 的行为重新设计。
相关链接：
Cube Sandbox 源码：https://github.com/tencentcloud/CubeSandbox
官网指南：https://cubesandbox.com/zh/guide/introduction.html
Cube Sandbox 系统设计思考：