--- url: >- https://cubesandbox.com/zh/blog/posts/2026-08-13-cubesandbox-agent-infra-interview.md description: >- 2026 年初，OpenClaw 以一己之力掀起了本地终端 Agent 热潮，人们开始习惯把文件系统、浏览器、邮件、终端，以及各种账号权限交给 Agent。但「养虾」的背后，潜藏着比模型幻觉更直接的风险。本文系 InfoQ 对腾讯云 IaaS 前沿技术团队负责人金峰的独家采访，从 Cube 的 Serverless 技术起源出发，探讨了 Agent 沙箱从「能运行」到「生产级可用」的演进路径。 --- # 从亚百毫秒级启动到生产级部署，腾讯云为何重构 Agent 沙箱？ > 本文首发于 InfoQ，系 InfoQ 对腾讯云 IaaS 前沿技术团队负责人金峰的独家采访，经授权在 Cube Sandbox 公众号转载发布。 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 的判断。 ## 1 "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 采用 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 运行底座。 ## 3 以开源开放，推动 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 系统。"金峰说道。 ## 4 结束语：当 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 系统设计思考：https://xie.infoq.cn/article/510579436d9f297700292cac4