本文首发于 InfoQ系 InfoQ 对腾讯云 IaaS 前沿技术团队负责人、Cube Sandbox 研发负责人金峰的独家采访经授权在 Cube Sandbox 公众号转载发布。文章从 Cube 的 Serverless 技术起源出发探讨了 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 可以视作观察 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 的演进目标始终指向生产级大规模可用不仅要让沙箱跑起来还要证明它能在生产环境中稳定、规模化地运行。◆2 从 Serverless 到 Agent 沙箱Cube 如何跨过生产级门槛◆Agent 爆火之前Cube 已经跑了两三年如前文所说Cube 底层是一套从 Serverless 生产系统中演进而来的基础设施最早启动于 2023 年左右。当时团队主要面对的还是 Serverless 场景。Serverless 理想中的运行方式是函数被调用时计算环境能够快速出现任务结束后资源立即释放。但在当时许多 Serverless 产品只是提供了类似 Lambda 的接口底层依赖的仍然是传统技术。腾讯云内部希望在技术上构建一套与这种模式严格匹配的基础设施这也是 Cube 诞生的背景。Cube 最初的设计目标就是重新建设一套原生适应小资源粒度、极速冷启动和海量并发的运行系统不调用时几乎不占资源需要时在百毫秒内完成环境创建执行结束后迅速销毁。这个起点后来意外成为 Cube 进入 Agent 时代的技术伏笔。在技术架构上Cube 采用 RustVMMKVM。“我们希望构建一套轻量级基础设施当时基于 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.0Cube 想解决的是“稳、省、广”。这一版本的核心特性就是让沙箱学会自动暂停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 数便突破 40003 个月后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.htmlCube Sandbox 系统设计思考https://xie.infoq.cn/article/510579436d9f297700292cac4
从亚百毫秒级启动到生产级部署，腾讯云为何重构 Agent 沙箱？
本文首发于 InfoQ系 InfoQ 对腾讯云 IaaS 前沿技术团队负责人、Cube Sandbox 研发负责人金峰的独家采访经授权在 Cube Sandbox 公众号转载发布。文章从 Cube 的 Serverless 技术起源出发探讨了 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 可以视作观察 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 的演进目标始终指向生产级大规模可用不仅要让沙箱跑起来还要证明它能在生产环境中稳定、规模化地运行。◆2 从 Serverless 到 Agent 沙箱Cube 如何跨过生产级门槛◆Agent 爆火之前Cube 已经跑了两三年如前文所说Cube 底层是一套从 Serverless 生产系统中演进而来的基础设施最早启动于 2023 年左右。当时团队主要面对的还是 Serverless 场景。Serverless 理想中的运行方式是函数被调用时计算环境能够快速出现任务结束后资源立即释放。但在当时许多 Serverless 产品只是提供了类似 Lambda 的接口底层依赖的仍然是传统技术。腾讯云内部希望在技术上构建一套与这种模式严格匹配的基础设施这也是 Cube 诞生的背景。Cube 最初的设计目标就是重新建设一套原生适应小资源粒度、极速冷启动和海量并发的运行系统不调用时几乎不占资源需要时在百毫秒内完成环境创建执行结束后迅速销毁。这个起点后来意外成为 Cube 进入 Agent 时代的技术伏笔。在技术架构上Cube 采用 RustVMMKVM。“我们希望构建一套轻量级基础设施当时基于 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.0Cube 想解决的是“稳、省、广”。这一版本的核心特性就是让沙箱学会自动暂停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 数便突破 40003 个月后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.htmlCube Sandbox 系统设计思考https://xie.infoq.cn/article/510579436d9f297700292cac4
