AI Agent 代码执行沙箱选型决策树

调研时间：2026-06-22 | 隔离层级：L0–L4 全覆盖 输入：威胁模型、延迟要求、是否自托管、是否有 KVM、并行数

一句话定位

一棵可执行的决策树——给定你的场景约束，走完 5 个判断节点，最终落到一个具体的隔离方案上。

Coding Agent 沙箱对照见 Coding Agent 沙箱对照 各方案技术细节见 行业全景 和 赛道深度分析 [已有]

日常类比

选沙箱像选银行保险柜：你要先回答几个问题——存的是现金还是文件？需要经常取用还是长期存放？要防小偷还是防核弹？预算多少？每个答案都会缩小你的选择范围，最终指向一种保险柜类型。类比边界：保险柜是静态的，沙箱是动态执行环境——代码会跑、会创建文件、会发网络请求，安全威胁也是动态演进的。

决策树（mermaid）

graph TD
    START["你的 Agent 需要执行<br>不可信代码吗？"]

    START -->|"否——只读分析/无代码执行"| NOEXEC["不需要沙箱<br>使用 API 调用即可"]

    START -->|"是"| Q1{"多租户？<br>（不同用户的代码<br>在同一台机器上执行）"}

    Q1 -->|"否——单用户自用"| Q2{"延迟敏感？<br>（交互式 Agent，<br>用户等待每一步）"}

    Q1 -->|"是——多租户/代码即服务"| Q3{"有 KVM 支持？"}

    Q2 -->|"是——需要 <50ms 响应"| OS["L2: OS Sandbox<br><b>Codex 路线</b><br>bwrap/Seatbelt/seccomp<br>启动 <10ms"]

    Q2 -->|"否——批量/异步执行"| Q3

    Q3 -->|"是"| Q4{"需要自托管？"}

    Q3 -->|"否（Mac/VPS/嵌套虚拟化不支持）"| Q5{"需要强隔离？"}

    Q4 -->|"是——数据不出境/合规要求"| Q6{"需要 E2B SDK 兼容？"}
    Q4 -->|"否——接受云端托管"| E2B["L3: E2B 云服务<br>Firecracker + API<br>启动 ~150ms<br>零运维"]

    Q5 -->|"是——不可接受共享内核"| GVISOR["L1: gVisor<br>用户态内核 Sentry<br>无需 KVM<br>syscall 兼容风险"]

    Q5 -->|"否——OS 级隔离够用"| OS

    Q6 -->|"是"| CUBE["L4: CubeSandbox<br>自托管 microVM<br>60ms + <5MB<br>E2B SDK 兼容"]
    Q6 -->|"否"| Q7{"需要 OCI/K8s 集成？"}

    Q7 -->|"是"| KATA["L4: Kata Containers<br>轻量 VM + OCI<br>200ms + 10-30MB"]
    Q7 -->|"否"| CUBE

    style NOEXEC fill:#f5f5f5,stroke:#999
    style OS fill:#e3f2fd,stroke:#1976d2
    style E2B fill:#e8f5e9,stroke:#388e3c
    style GVISOR fill:#fff3e0,stroke:#f57c00
    style CUBE fill:#fce4ec,stroke:#c62828
    style KATA fill:#f3e5f5,stroke:#7b1fa2

决策节点详解

节点 1：多租户？

判断标准：不同用户（或不同 Agent）的代码是否在同一台物理机上执行。

如果是多租户，共享内核的方案（OS sandbox、Docker namespace）存在内核 exploit 跨租户攻击的风险。Linux 内核每年有数十个 CVE，其中部分可用于容器逃逸。此时必须走 L4（microVM）或 L1（gVisor 用户态内核）路线。

详见 技术挑战 #1: 冷启动与隔离强度的矛盾 [已有]

节点 2：延迟敏感？

判断标准：用户是否在等待每一步执行结果（交互式 Agent），还是后台批量执行。

交互式场景下，<10ms 的 OS sandbox（Codex 路线）带来的体验是”瞬间执行”。60ms 的 microVM（CubeSandbox）在单次执行中感知不到差异，但在连续 100 次命令的 pipeline 中累积到 6 秒 vs 1 秒。如果可以接受 microVM 的延迟，优先选更强的隔离。

节点 3：有 KVM 支持？

判断标准：ls /dev/kvm 是否存在。

没有 KVM 的环境：macOS（全系列）、大部分 VPS/虚拟机（嵌套虚拟化未开启）、WSL 1。这些环境下所有基于 KVM 的方案（Firecracker/CubeSandbox/Kata）都无法运行。选择 gVisor（不需要 KVM）或 OS sandbox。

节点 4：需要自托管？

判断标准：数据是否可以离开你的网络（合规、隐私、成本）。

E2B 是云服务——代码在 AWS/GCP 的 Firecracker 实例上执行。如果你的场景要求数据不出境（金融/医疗/政府）或者需要控制成本（不按 API 调用计费），必须选自托管方案。

节点 5/6：E2B SDK 兼容？OCI/K8s 集成？

E2B SDK 兼容：如果你的 Agent 框架已经用了 E2B SDK（from e2b import Sandbox），CubeSandbox 可以零改动切换。

OCI/K8s 集成：如果你在 Kubernetes 集群里运行 workload，需要 OCI runtime 接口，Kata Containers 是唯一的 CNCF 毕业项目。

叶子节点速查

典型场景映射

场景 A：个人开发者用 Claude Code 写代码

• 多租户？否
• 延迟敏感？是
• → L0-L2：Claude Code 自带的 Permission + 用户确认够用

场景 B：SaaS 产品让用户上传代码在线执行

• 多租户？是
• 有 KVM？是（云服务器）
• 自托管？否
• → L3：E2B 云服务

场景 C：企业内部 Agent 平台，数据不出境

• 多租户？是
• 有 KVM？是（自有服务器）
• 自托管？是
• E2B SDK 兼容？是（已有 Agent 用 E2B SDK）
• → L4：CubeSandbox

场景 D：在 K8s 集群中跑 Agent 工作负载

• 多租户？是
• 有 KVM？是
• 自托管？是
• E2B SDK？否
• OCI/K8s？是
• → L4：Kata Containers

场景 E：Mac 上需要比 Docker 更强的隔离

• 多租户？否
• 延迟？否
• 有 KVM？否
• 需要强隔离？是
• → L1：gVisor（runsc）

场景 F：RL 训练需要大量并行沙箱 + 快照回滚

• 多租户？是（Agent 生成大量试错代码）
• 有 KVM？是
• 自托管？是
• E2B SDK？是
• → L4：CubeSandbox（CubeCoW 快照 + 高密度并行）

决策维度权重参考

不同角色对决策维度的权重不同：

证据等级