Agent Sandbox 沙箱方案调研

摘要

「让 agent 安全地跑不可信代码」在 2026 年成了独立品类。我们记录五个事实：

1. (1) 隔离方案分三档，按威胁模型选：容器/进程级（Docker、gVisor）→ 内核级 → microVM 硬件级（Firecracker、Kata）。跑自己写的代码容器够用；跑网上抓的 skill 和 AI 生成代码，microVM 档才够硬。[E09,E10,E11]
2. (2) 「agent 沙箱」作为独立品类在 12 个月内成型：OpenSandbox（2025-12）、agent-sandbox（K8s SIG，2025-08）、CubeSandbox（2026-04）、Docker Sandboxes（2026-03）全部在这段时间出现——此前沙箱是基础设施话题，现在它是 agent 平台的一等组件。[E01,E02,E05,E08]
3. (3) 大厂全部落子：阿里系背景的 OpenSandbox（15.6k）、腾讯云 CubeSandbox（12.8k）、AWS 的 Firecracker（37.1k）、Google 的 gVisor（19.5k）、K8s 官方 SIG 的 agent-sandbox、Docker 的商业 Sandboxes——隔离层被当成平台竞争力建。[E01,E02,E05,E08,E09,E10]
4. (4) star 最高 ≠ 最贴合 agent：Daytona 71.7k 榜首，但它的定位横跨开发环境与沙箱；「为 agent 工作流设计」的 OpenSandbox/E2B star 更低但集成面（SDK/MCP/持久会话）更完整。[E01,E03,E04]
5. (5) 选型的第一问是「跑谁的代码」：自研代码 → 容器基线够用；不可信 AI 生成代码 / 第三方 skill → 至少 gVisor，最好 microVM。这个分界比任何 star 数都重要。[E18]

12 个方案逐个对比见第 2 章；选型路径与性能画像见第 3 章。

1 三个隔离档：威胁模型决定选哪档

沙箱方案的所有差异都能归结为一个问题：你要防什么？防误操作、防恶意依赖、还是防蓄意逃逸——三档隔离对应三种答案。

为什么 2025 年底开始爆发：机制的解释是「skill 生态把威胁模型变了」——agent 开始执行网上下载的第三方 skill 和自己生成的代码，容器基线不够硬，需求从「能跑」变成「敢跑」；同时 Firecracker 等底层已成熟多年，封装成 agent 友好产品的边际成本下降。[E10,E18]替代解释是「AI 基建的营销周期」——沙箱这个旧概念借 agent 重新包装。两个解释都成立：品类确实新，但底层技术是老的。

2 Top 12 全景

按三个隔离档选出 12 个方案（Docker Sandboxes 为闭源商业产品，无 star 数据，单列注明）。star 为 2026-09-30 gh api 认证读数。

2.1 重点项目

2.2 其余方案速览

star 为 2026-09-30 GitHub API（gh api 认证）实测读数 [E01–E04,E06–E12]；创建时间为仓库创建年月。

3 怎么选怎么配：先问「跑谁的代码」

选型的第一问不是「哪个 star 多」，是「沙箱里跑谁的代码」——威胁模型决定隔离档，隔离档决定候选池。

3.1 三条工程纪律

1. 降级路径必须存在。microVM 档的宿主可能不支持嵌套虚拟化（云上常见），编排层要能自动回落到 gVisor/容器档并明确告知用户——「隔离档位」是部署环境的函数，不是纯产品选择。[E06,E09,E11]
2. 文件与网络的出口策略比隔离本身更常出事。沙箱挡住了逃逸，挡不住 agent 把密钥发出去：出口白名单、凭据注入（而不是挂载）、MCP 策略（Docker Sandboxes 的组织级策略是正确方向）要一起设计。[E05,E18]
3. 会话持久化决定产品形态。毫秒级并发（OpenSandbox/CubeSandbox）适合无状态短任务；持久会话 + 文件系统保留（E2B、Docker Sandboxes 本地档）适合 coding agent 的长任务——先定任务形态再选运行时。[E01,E02,E03,E05]

4 方法、数据来源与局限性

4.1 方法

选样。用户提供 3 个起点（OpenSandbox、cubesandbox、Docker Sandboxes），逐一核实后按「三个隔离档各有代表」补充 9 个：E2B、Daytona、microsandbox、agent-infra/sandbox、agent-sandbox（K8s SIG）、gVisor、Firecracker、Kata Containers、Docker 容器（基线）。纳入标准：GitHub 可检索或官方文档可得、与「agent 执行不可信代码」直接相关、三档各有代表。

事实采集。star 数以 2026-09-30 gh api 认证读数为准（此前未认证 API 读数出现过不稳定，最终一律以认证读数覆盖）；Docker Sandboxes 的能力描述来自 docs.docker.com/ai/sandboxes 官方文档实测（sbx CLI、本地/云双环境、组织级策略）。12 条数据点均标注 [E01–E12]。

隔离分档与象限定位。三档划分与 Figure 2.2 象限是定性判断（依据官方架构文档），用于看格局。Figure 3.1 的性能画像为定性估计，未做基准测试。

4.2 局限性与替代解释

性能数字是定性画像。Figure 3.1 没有跑分支撑（Firecracker 的 ~125ms 是 AWS 官方口径，其余为机制推断）——两个方案相差 1 分不具有统计含义。真实选型前应以自己的工作负载实测冷启动与密度。

「爆发」的时间判断依赖仓库创建日期。品类成型说（12 个月内 4 个新项目）基于 GitHub API 创建时间，但「沙箱作为 agent 组件」的实践早于这些仓库（e2b 2023 年已在做）；我们论证的是「独立品类被命名和建仓」，不是「技术首次出现」。

license 风险提示。CubeSandbox 的 license 为自定义条款（NOASSERTION），严格说不属于 OSI 认证开源——本报告仍纳入（用户点名 + 12.8k star），但商用前需确认条款。

样本偏差。偏 GitHub 开源；闭源托管平台（Modal、Fly Machines、Cloudflare Containers 等）只在机制层面提及。单机 macOS 沙箱（sandbox-exec、Seatbelt 封装）与小众方案不在样本内。

时效。该赛道月度变化显著（样本中 4 个仓库创建于 2026 年内）。数据截至 2026-09-30。

数据速查表

12 个方案关键属性一页汇总。

star 为 2026-09-30 gh api 认证读数 [E01–E12]；Docker 容器与 Docker Sandboxes 无 star 数据（基线/闭源）。