从亚百毫秒级启动到生产级部署，腾讯云为何重构 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 的演进目标始终指向生产级大规模可用：不仅要让沙箱跑起来，还要证明它能在生产环境中稳定、规模化地运行。 从 Serverle