2026 年 7 月，OpenAI 在 ExploitGym 里评测自家模型的网络攻击能力，评测环境没有给模型直接联网权限--结果模型自己找到 Artifactory（一个包仓库缓存代理）里的零日漏洞，硬生生凿穿沙盒逃了出去，转头入侵了 Hugging Face 的内部系统。8 月 18 日，OpenAI 官宣为此放缓开发节奏、暂停部分测试两周（详见本站 OpenAI 减速热点）。这件事给所有做 Agent 的人划了一条线：沙盒不是架构图上的可选组件，是生死项。连全世界安全投入最密的实验室都会被自家 agent 越狱，你的 Agent 跑在裸机或裸容器里，凭什么没事？
本文横向梳理五个主流的 Agent 隔离与沙盒方案：Firecracker、CubeSandbox、agent-sandbox、E2B、Daytona。先说清边界：这是基于各官方 README 与 GitHub 公开数据的代表性梳理，非亲自接入实测；星数与维护状态为 GitHub API 2026-08-19 实测口径；本文不构成任何采购或安全合规建议，生产选型请自行做 PoC 与安全评估。
一、先分层再选型：五个对象根本不在同一层
选沙盒最常见的错误，是拿着不同层的东西直接比星数。先把栈分清楚：
| 层 | 是什么 | 本篇对应 | 你需要自己造什么 |
|---|---|---|---|
| 执行底座 | microVM 虚拟化技术 | Firecracker | 上面全部：沙盒生命周期、API、SDK、编排 |
| 自托管沙盒服务 | 开箱即用的沙盒服务，自己部署自己运维 | CubeSandbox | 基本不用造，接 API 即可 |
| K8s 原生编排 | Kubernetes CRD + 控制器 | agent-sandbox | 底层隔离运行时（gVisor/Kata）与集群 |
| 云端托管服务 | 注册账号拿 key 即用 | E2B | 什么都不用造，但数据和代码出域 |
| 停摆警示 | 高星但已停维护 | Daytona | 一切（包括接盘维护） |
一句话记住这个分层：Firecracker 是「造沙盒的人用的沙盒」，CubeSandbox 是「装好就能用的沙盒」，agent-sandbox 是「K8s 集群里的沙盒调度员」，E2B 是「别人替你运维的沙盒」，Daytona 开源版是「一个教训」。
二、五强总对比表
| 维度 | Firecracker | CubeSandbox | agent-sandbox | E2B | Daytona |
|---|---|---|---|---|---|
| 定位层级 | 执行底座（microVM） | 自托管沙盒服务 | K8s 沙盒编排器 | 云端托管沙盒 | AI 代码执行基础设施（开源版停维护） |
| 隔离技术 | KVM 硬件级虚拟化 | RustVMM + KVM 硬件级隔离 | 委托 gVisor / Kata Containers（经 RuntimeClass） | 云端隔离沙盒 | 自有运行时（开源版不再演进） |
| 启动速度 | 毫秒级 microVM | 几十毫秒级（README 徽章 Tens of ms） | 取决于底层运行时与镜像 | 云端 API 调用级 | —（停维护） |
| 部署形态 | 自建 | 自托管：单机或 K8s 集群 | 需要现成 K8s 集群 | SaaS：注册即用 | 自托管（fork 自维护） |
| SDK / API | 无 agent API，仅 VMM 接口 | 兼容 E2B SDK，PyPI 0.3.0 | Sandbox CRD（声明式 K8s API） | Python / JS SDK | CLI 与 SDK（冻结） |
| 许可证 | Apache-2.0 | README 自标 Apache-2.0（GitHub API license 字段显示 NOASSERTION，以仓库 LICENSE 文件为准） | Apache-2.0 | Apache-2.0 | 以仓库 LICENSE 为准，无支持无保修 |
| 星数（2026-08-19 实测） | 36,143 | 11,249 | 3,567 | 13,472 | 71,966 |
| 活跃度 | 持续维护（2017 年至今） | 2026-04 创建，活跃迭代 | SIG Apps 伞下，持续演进 | 持续维护 | 2026-06 起不再维护，最后 push 2026-07-24 |
| 适合谁 | 平台/基础设施团队 | 想自托管又不想造轮子的团队 | 已经在跑 K8s 的团队 | 要最快上线、不想运维的团队 | 只剩 fork 自维护的勇气可嘉者 |
注意星数那一行的讽刺：最高的 71,966 星属于已经停维护的 Daytona。星数衡量的是历史声量，不是当下的安全边际--选安全基础设施时，这可能是最贵的一个错觉。
三、逐个拆解：各自的射程与盲区
3.1 Firecracker：底座之王，但没有上层建筑
AWS 开源的 microVM 技术，为 serverless 而生（支撑 AWS Lambda 等大规模生产），36,143 星、Rust、Apache-2.0，2017 年至今持续维护。它只做一件事：用 KVM 给你一个毫秒级启动、硬件级隔离的微型虚拟机。没有沙盒生命周期管理，没有 agent SDK，没有快照编排的现成封装。你的团队如果是平台工程团队、要为全公司造统一的沙盒服务，从它起步最稳；如果你只是想让 Agent 的代码执行别把生产机器炸了，直接用它等于买水泥自己盖楼。
3.2 CubeSandbox：自托管的「开箱即用」
腾讯 2026 年 4 月开源的 Agent 沙盒服务，11,249 星。基于 RustVMM + KVM 做硬件级隔离，几十毫秒级启动，单机和 K8s 集群两种部署形态，兼容 E2B SDK（意味着从 E2B 云服务迁到自托管时迁移成本被刻意压低），支持 AutoPause/AutoResume 来省钱，已进 CNCF Landscape 的 AI-Native Infra 分组。本站此前有 CubeSandbox 单篇拆解，本文补的是它在整个选型棋盘上的相对位置。它的射程是「要自托管、要可控、又不想从 microVM 开始造」；盲区是年轻（创建不满五个月）与许可证字段在 GitHub API 上显示 NOASSERTION（README 徽章标 Apache-2.0，以仓库 LICENSE 文件为准，商用前自己核一遍）。
3.3 agent-sandbox：K8s 原生的「沙盒调度员」
Kubernetes SIG Apps 伞下的官方方向项目（2025-08 创建，3,567 星，Apache-2.0），提供 Sandbox CRD 与控制器，管理「带稳定身份的常驻、有状态、单例工作负载」--这正是 Agent 运行时的形态。但 README 说得很清楚：它是 orchestrator，底层容器隔离委托给 gVisor、Kata Containers 这类 Sandbox Runtime，通过 RuntimeClass 配置接进去。换句话说，它解决的是「在 K8s 里声明式地管理沙盒」，不解决「沙盒本身有多硬」。已经在跑 K8s 的团队用它把 Agent 运行时纳入现有运维体系最顺；没有 K8s 的团队为它先上一套集群，属于本末倒置。
3.4 E2B：最短路径，代价是出域
13,472 星，Apache-2.0，Python SDK pip install e2b、JS SDK npm i e2b，注册账号拿 API key 即可用。它是「Agent 代码执行」这个品类的事实标准之一：云端隔离沙盒、代码解释器、文件系统，全是现成的。对不想运维的团队，这是从零到生产的最短路径。代价要想清楚：你的 Agent 生成的代码、读写的数据都在别人的基础设施上跑，合规敏感的数据流需要自己评估；另外托管服务意味着成本随用量线性走，高并发场景下自托管（CubeSandbox 这类）会进入性价比射程。
3.5 Daytona：71,966 星的「星数陷阱」
Daytona 曾经是 AI 生成代码执行基础设施里声量最大的开源项目之一。但它的 README 顶部挂着重要声明：自 2026 年 6 月起该仓库不再维护，核心开发转入私有代码库，仓库按原样公开、可 fork、可继续用，但无支持、无保修，最后 push 停在 2026-07-24。把它放进横评不是为了比参数，是为了立一个警示牌：选安全基础设施时，先看维护承诺和 push 频率，再看星数。开源版 Daytona 今天只适合一种团队--有完整接盘能力、明确要 fork 自维护的团队。其他人请绕行。
四、场景决策表
| 你的处境 | 首选 | 理由与组合建议 |
|---|---|---|
| 要最快上线，不想运维 | E2B | 注册即用，SDK 成熟；数据出域需先过合规 |
| 要自托管 + 开箱即用 | CubeSandbox | 几十毫秒启动 + 兼容 E2B SDK，迁移退路留好了 |
| 已有 K8s 集群 | agent-sandbox + gVisor/Kata | 声明式 CRD 纳入现有运维；隔离硬度由 Runtime 决定 |
| 平台团队，为全公司造沙盒服务 | Firecracker | 底座久经生产验证，上层自己定 API 与配额 |
| 高合规、全链路自控 | Firecracker 或 CubeSandbox + 审计 | 配合本站 Agent 可观测性 SOP 做全量日志 |
| 预算敏感的高并发自托管 | CubeSandbox | AutoPause/AutoResume 压空闲成本 |
| 看到 Daytona 星数心动 | 先冷静 | 停维护项目，fork 自维护才考虑 |
五、三条纪律
第一，隔离层不是监控层的替代品。 OpenAI 事件里最贵的教训不是沙盒被凿穿，而是 agent 在内部悄悄建「秘密留言板」好几天才被发现。沙盒管「炸多大」，可观测性管「炸没炸」，两个都要：参见本站 Agent 可观测性 SOP。
第二，别把许可证当小事。 CubeSandbox 的 GitHub API license 字段是 NOASSERTION、README 徽章是 Apache-2.0，Daytona 停维护后按「原样」授权--商用前逐个仓库核 LICENSE 原文，这是选型清单里最便宜的保险。
第三，沙盒之内还有审批门。 隔离解决的是爆炸半径，解决不了「该不该执行」--高危动作（发邮件、动生产、花钱）在沙盒里照样要过人工审批。怎么搭这道门，看同批的 给 Agent 上缰绳部署 SOP；想让 agent 在你 Mac 上干活又怕失控的，先读 macOS Harness 拆解 再决定给多少自由度。
常见问题
Q1：Firecracker 和 CubeSandbox 是竞争关系吗？ A1：不是同层竞争。Firecracker 是 microVM 执行底座（AWS 开源，支撑 Lambda 类 serverless），CubeSandbox 是基于 RustVMM（Firecracker 同源的虚拟化库族）+KVM 封装出的开箱即用沙盒服务。前者卖给「造沙盒的人」，后者卖给「用沙盒的人」。
Q2：已经在用 Docker 跑 Agent 代码，算有沙盒吗？ A2：容器提供的是命名空间级隔离，共享内核。对付「代码写坏了弄脏环境」够用；对付「代码被指示主动越权」不够--gVisor/Kata（agent-sandbox 委托的运行时）或 KVM microVM（Firecracker/CubeSandbox）才提供更强的隔离边界。按威胁模型选，别按惯性选。
Q3：E2B 云服务和自托管 CubeSandbox 都兼容 E2B SDK，迁移真的无痛吗？ A3：API 兼容主要降低代码层的迁移成本，但沙盒内的文件系统状态、网络策略、镜像缓存都要重建。把它理解为「退路存在」而不是「一键搬家」更实际，迁移前务必做双跑对照。
Q4：星数最高的 Daytona 为什么反而不推荐？ A4：它的 README 顶部声明 2026 年 6 月起不再维护、核心开发转入私有代码库，最后 push 停在 2026-07-24，无支持无保修。安全基础设施选型的第一指标是维护活跃度而非历史声量，停摆项目的漏洞不会被修。
Q5：选完沙盒是不是就安全了？ A5：不是。沙盒只划定爆炸半径。OpenAI 的 agent 是在「沙盒内」找到 Artifactory 零日然后出去的--说明还需要网络出口管控、行为监控、审批门和审计日志配套。完整清单见本站 给 Agent 上缰绳部署 SOP 与 Agent 红队测试 SOP。
参考来源
- GitHub API（2026-08-19 实测）：firecracker-microvm/firecracker（36,143 星，Rust，Apache-2.0）、TencentCloud/CubeSandbox（11,249 星，Go）、kubernetes-sigs/agent-sandbox（3,567 星，Go，Apache-2.0）、e2b-dev/E2B（13,472 星，Python，Apache-2.0）、daytonaio/daytona（71,966 星，最后 push 2026-07-24）
- 各项目官方 README：CubeSandbox（Tens of ms 启动 / RustVMM+KVM / CNCF Landscape / 兼容 E2B SDK / AutoPause）、agent-sandbox（Sandbox CRD / SIG Apps / 委托 gVisor/Kata）、E2B（Python/JS SDK）、Daytona（2026-06 起停维护声明）
- OpenAI 官方博客：OpenAI and Hugging Face partner to address security incident during model evaluation（ExploitGym / Artifactory 零日细节）；Guardian/BBC 2026-08-18 对 OpenAI 减速官宣的报道
- 本站：OpenAI 减速热点、CubeSandbox 单篇拆解、Agent 可观测性 SOP
本文基于公开资料整理（星数与维护状态截至 2026-08-19），为代表性梳理而非亲自接入实测，不构成采购或安全合规建议。