训练会写代码、会用工具的 AI 智能体，强化学习（RL）的每一次 rollout 都要一个独立的沙箱（sandbox）：一个能装依赖、跑命令、读写文件的隔离环境。DeepSeek 2026 年 9 月发布的论文 DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale（arXiv:2609.22978）介绍了他们在生产中使用的 sandbox 平台。

先说结论。这篇论文最值得借鉴的是五点：

1. sandbox 申请的资源大多用不上：约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内，所以可以大幅超卖，但要用 CPU 核心调度保护对延迟敏感的任务。
2. 镜像不要整个拉取：一个 sandbox 实际只会读到镜像的 4%–13%，按需加载比全量拉取快得多。
3. 调度可以很简单：power-of-k 随机选节点，加上本地的「在途」记录，最终由节点自己决定接不接受。
4. RL 需要任务级操作：训练被抢占或结束时，整批暂停、恢复或结束一个任务的所有 sandbox。
5. 要防智能体作弊：论文记录了真实的 reward hacking 和越权事件，sandbox 需要专门防护。

下面逐项展开。我们的开源项目 OpenDsec 就是照着这篇论文实现的，文末说明它在哪些地方做了不同的选择。OpenDsec 与 DeepSeek 没有关联。

规模 ​

论文给出的生产数字：

最后一行常被忽略：sandbox 活得比一次部署久，所以升级节点时不能把它们杀掉。

一套 SDK，四种后端，不做抽象 ​

DSec 提供四种后端：函数调用（FnCall）、容器、microVM 和完整虚拟机。它们共用一套 SDK，但 SDK 不试图把后端抽象成同一个接口：调用方明确选择后端，每种后端有自己的参数。理由很实际：容器、microVM 和虚拟机在启动时间、隔离强度、能不能挂 GPU 上差别很大，统一的抽象只会隐藏这些差别。

调度：power-of-k 和节点的最终决定权 ​

放置 sandbox 用的是经典的 power-of-k choices（论文引用 Mitzenmacher）：从候选节点里随机取 k 个，选负载最低的。它不需要全局精确的状态，却能把负载分得很均匀。

两点细节决定了它在高并发下能不能用：

• 在途记录（in-flight overlay）：节点的负载是定期汇报的，两次汇报之间刚放上去的 sandbox 看不到。每个调度实例在选中节点时就把这次放置记下来，计算负载时叠加上去，避免一窝蜂打到同一个节点。
• 最终准入权在节点：调度只是尽力而为。节点收到请求时按自己当前的容量和内存压力再检查一次，不够就拒绝，调度换一个节点重试。

控制面的组件（API 服务、状态收集）都没有持久状态，重启后重新向节点轮询即可恢复。sandbox 的 id 里编码了它所在的节点，路由不用查表。

超卖和 CPU 核心调度 ​

论文统计约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内。按申请量分配就会浪费大量机器，所以 DSec 大幅超卖 CPU。

超卖的代价落在对延迟敏感的任务上。只把后台任务设成 SCHED_IDLE 不够：它只管同一个硬件线程上谁先跑，管不了同一物理核另一个超线程上的邻居抢执行单元和缓存。论文的测量是，50% 的干扰负载下，不保护时延迟增加 45.2%，SCHED_IDLE 最多改善 3.4%，加上 Linux 的 CPU 核心调度（core scheduling）后只增加 17.3%。

内存方面，论文同样做了共享和回收：暂停的 sandbox 把内存换出，相同的只读数据在 sandbox 之间共享。

镜像：分层构建，按需加载 ​

RL 任务的环境种类多、每种用得少，传统的「先把整个镜像拉到节点上」很浪费。DSec 的做法：

• 分层：环境由 base、workspace、toolkit 等独立版本化的层拼成，换一层不用重建整个镜像。
• 按需加载：镜像数据放在 DeepSeek 自己的分布式文件系统 3FS 上，sandbox 用到哪部分数据才读取哪部分。论文统计一个 sandbox 实际只读到镜像的 4%–13%。
• 效果：8,192 个容器的突发创建，按需加载用时 35 分钟，全量拉取超过 60 分钟。
• 构建和运行分开：构建环境的账号和跑任务的账号分离，跑任务的账号不能往别人会用到的镜像里写东西。

为 RL 设计的生命周期 ​

DSec 和 RL 训练框架是一起设计的：有状态的 rollout 执行在 sandbox 里，GPU 训练可以被抢占，两者分开。为此 sandbox 平台提供：

• 任务级操作：按任务暂停、恢复、结束全部 sandbox。训练被抢占时整批暂停，回来后整批恢复。
• 透明恢复：对一个已暂停的 sandbox 发起任何操作，平台先自动恢复它。
• 超时回收：显式结束，或者空闲超时后回收。
• 嵌套项目和有界委托：项目可以任意深度嵌套（例如 root/rl/job-42/agent-7），一个身份只能把自己有的权限再委托出去。

防作弊和越权 ​

论文记录了智能体在 sandbox 里的真实「越轨」行为，例如：无限输出写满存储、伪造请求发给 sandbox 内部的管理进程、读取管理进程的日志找答案、覆盖 /bin/bash、用文件系统的 ioctl 破坏元数据、扫描端口找镜像源。

DSec 的防护包括 AppArmor 限制，以及用 eBPF 实现的网络策略：出站默认拒绝，按规则放行。

云上溢出 ​

本地集群利用率超过 80% 时，DSec 把一部分容器任务放到云上。不是所有任务都能上云，只有镜像在一个去重后约 30 TB 的 EROFS 集合里的任务才行，这个集合覆盖了约 70% 的容器任务。

对自建 sandbox 平台的启示 ​

• 按实际用量而不是申请量规划容量，然后用核心调度保护延迟敏感的任务。
• 镜像体积不是瓶颈，读多少才是：先上按需加载，再优化存储。
• 简单的随机调度够用，前提是节点有最终准入权、调度实例记得自己刚放了什么。
• 从第一天起就设计任务级操作和暂停，RL 训练一定会被抢占。
• 把智能体当作不可信的程序：输出有上限、网络默认拒绝、评测和智能体分开。

OpenDsec：开源的实现，以及不同的选择 ​

OpenDsec 按论文的架构实现了 IAM、调度、状态收集、节点、SDK 和镜像库，并在两台 384 线程的裸金属节点上做了生产验证。下面几处我们做了不同的选择：

几个对照论文做的实测（项目的裸金属测试机，2 × AMD EPYC 9Y24）：

• CPU 核心调度：50% 干扰负载下，延迟增加从不保护时的 18.0% 降到 2.1%（SCHED_IDLE 加核心调度）；100% 干扰负载下从 81.0% 降到 10.0%。方向与论文一致。
• 密度：单台 384 线程的节点一次突发创建 5,120 个 microVM，用时 37 秒；两个节点一次突发创建 8,192 个容器，全部成功。
• 防作弊：论文列出的事件逐条对照处理，例如每条命令每路输出最多记录 64 MB，智能体会话用普通用户。

此外，OpenDsec 自带 fleet 服务，分批滚动升级和修改配置，运行中的 sandbox 不受影响。

还没做的：没有做按需加载与全量拉取的对比实验，GPU 还没有在真实硬件上测过。

常见问题 ​

DSec 是开源的吗？ ​

论文介绍的是 DeepSeek 内部的系统，没有附带代码。OpenDsec 不是 DeepSeek 的代码，而是我们按论文独立实现的开源项目（服务端 AGPL-3.0，SDK Apache-2.0），与 DeepSeek 没有关联。

DSec 用的是容器还是虚拟机？ ​

都有。DSec 提供函数调用、容器、microVM 和完整虚拟机四种后端，以容器为主力，由调用方按任务选择。

为什么 RL 训练需要专门的 sandbox 平台？ ​

RL 一个任务就可能同时要上万个 sandbox，每个都要装依赖、跑测试、存活几个小时，而且训练随时可能被抢占。通用的容器平台一般没有任务级暂停、大规模突发创建和防作弊这些能力。

sandbox 可以超卖多少？ ​

论文统计约 90% 的 sandbox 平均只用到申请 CPU 的 5% 以内。OpenDsec 默认把 CPU 超卖 8 倍，并用 CPU 核心调度保护对延迟敏感的 sandbox。具体比例取决于你的负载。

什么是 reward hacking，sandbox 怎么防？ ​

reward hacking 指智能体不解决问题，而是钻评测的空子拿奖励，比如读取评测日志里的答案、改掉系统命令。常见的防护是让智能体碰不到评测的东西：智能体和评测用不同的用户、限制输出、网络默认拒绝。

不训练模型，只想给 AI 智能体一个执行代码的 sandbox，有用吗？ ​

有用。论文里的超卖、按需加载和防越权对任何「运行不可信代码」的场景都适用。OpenDsec 也可以直接作为 AI 智能体的代码执行沙箱，并兼容 E2B SDK，见自建 E2B。

延伸阅读 ​

• 论文：arXiv:2609.22978
• OpenDsec 核心概念
• OpenDsec 与 E2B、Daytona、Modal 对比
• 快速开始：在一台 Linux 机器上装好 OpenDsec

OpenDsec 是 Kernflux 的开源项目，与 DeepSeek 没有关联。文中关于 DSec 的内容均来自上述论文。

E2B 是 AI 智能体最常用的代码执行沙箱（sandbox）之一：智能体生成的代码在一个隔离的 Firecracker microVM 里运行，不少智能体框架都支持 E2B。但 E2B 主要是托管云服务，代码和数据要发到 E2B 的云上。数据不能出域、网络离线、或者 sandbox 用量大到托管费用不划算时，就需要自建。

先说结论。自建 E2B 有两条路：

1. E2B 自己的开源运行时（e2b-dev/runtime，Apache-2.0）。可以在一台机器上自建（Embed）；部署到自己的云账号（BYOC）是企业版功能。
2. OpenDsec 的 E2B 网关。OpenDsec 是开源的 sandbox 平台，自带一个提供 E2B API 的网关。用 E2B SDK 写的代码不用改，设置三个环境变量就能跑在你自己的单机或集群上。

这篇文章一步步介绍第二条路：单机安装、用 E2B SDK 调用、搭 code interpreter、扩成集群，以及和 E2B 的差别。

第一步：单机安装 ​

需要一台 Linux x86_64 机器（在 Ubuntu 24.04 上验证过），有 systemd 和 cgroup v2。要用 microVM（和 E2B 一样的 Firecracker），还需要 /dev/kvm：裸金属，或者开启了嵌套虚拟化的云主机。

sudo -i                                    # 以下都用 root
apt update && apt install -y make git python3-venv
curl -fsSL https://go.dev/dl/go1.27.3.linux-amd64.tar.gz | tar -C /usr/local -xz
git clone https://github.com/kernflux/opendsec && cd opendsec
deploy/quickstart.sh

脚本会编译程序、下载 Firecracker 和 guest 内核，装好全部服务，其中包括 E2B 网关（端口 7400），并配好一个叫 base 的模板（Python 3.12）。在一台全新的 8 核虚拟机上全程约 11 分钟，大部分时间在编译。

第二步：用 E2B SDK 调用 ​

安装脚本写好的 /root/opendsec-ops/demo.env 里已经有 E2B SDK 需要的三个环境变量：

. /root/opendsec-ops/demo.env       # 设置 E2B_API_URL、E2B_SANDBOX_URL、E2B_API_KEY
python3 -m venv .venv && .venv/bin/pip install e2b

E2B_API_KEY 就是 OpenDsec 的 token。之后的代码和用 E2B 云服务时完全一样（用 .venv/bin/python 运行）：

from e2b import Sandbox

sbx = Sandbox.create()                          # 模板 "base"
print(sbx.commands.run("python3 -V").stdout)
sbx.files.write("/tmp/a.txt", "hello")
print(sbx.files.read("/tmp/a.txt"))
sbx.kill()

在别的机器上调用时，把三个变量里的地址换成这台机器的地址即可：

export E2B_API_URL=http://<网关>:7400
export E2B_SANDBOX_URL=http://<网关>:7400
export E2B_API_KEY=<你的 OpenDsec token>

JS/TS SDK 同样可用（需要 Node.js 22.19 以上）。

fork、快照和暂停 ​

在 microVM 上，fork、快照和暂停都连同内存保存，运行中的进程会延续下去：

from e2b import Sandbox

src = Sandbox.create(timeout=300)
src.files.write("/tmp/state", "v1")

forks = src.fork(count=2)                       # 运行中 sandbox 的两个副本
snap = src.create_snapshot()                    # 快照
again = Sandbox.create(snap.snapshot_id)        # 从快照创建

# 超时时暂停而不是结束；connect 时恢复
s = Sandbox.create(timeout=60, lifecycle={"on_timeout": "pause", "auto_resume": True})
s2 = Sandbox.connect(s.sandbox_id)

for x in [src, *forks, again, s2]:
    x.kill()

fork 适合智能体的树搜索，或者从一个装好依赖的环境展开大量 RL rollout。

第三步：搭 code interpreter ​

E2B 的 code interpreter（run_code，返回结果、图表和 pandas 表格）需要一个专门的模板。OpenDsec 用 E2B 开源的 code-interpreter 服务构建它：一个已经运行着该服务和 Python Jupyter 内核的 microVM 的内存快照，所以创建后立刻就能执行代码。

构建时 sandbox 要从网上安装软件包，所以机器需要能访问 apt 源和 PyPI。仍在 opendsec 目录下：

curl -fsSL https://codeload.github.com/e2b-dev/code-interpreter/tar.gz/refs/heads/main | tar -xz
. /root/opendsec-ops/env                        # 管理员 token：要往 root 项目发布镜像
.venv/bin/pip install ./sdk/python
.venv/bin/python deploy/e2b/build-code-interpreter.py code-interpreter-main/template

这会构建镜像 root/code-interpreter:v1。然后在 /root/opendsec-ops/opendsec.json 的 e2b.templates 里加一个模板：

"code-interpreter-v1": {"image": "root/code-interpreter:v1", "backend": "microvm", "cpu": 2, "memory_mb": 2048}

下发配置并重启：

export OPENDSEC_OPS=/root/opendsec-ops
deploy/prod/opendsecops push-config all && deploy/prod/opendsecops restart

之后调用方安装 e2b-code-interpreter 就能用：

from e2b_code_interpreter import Sandbox

sbx = Sandbox.create("code-interpreter-v1")
print(sbx.run_code("6 * 7").text)               # 42

速度 ​

2026-10-23 在项目的裸金属测试机（AMD EPYC 9Y24）上，经网关在 Firecracker microVM 上测得：

扩成集群 ​

单机够用就不用往下看。sandbox 多了以后，OpenDsec 可以扩成多机集群（部署文档），E2B 网关也随之扩成多个副本：

1. 在集群配置的 e2b 一节列出各网关的地址、sandbox 放进哪个项目，以及模板。
2. 给节点加上 fleet 角色 e2b=<序号>。
3. 前面放一个负载均衡：TCP 7400，健康检查用 HTTP 9467 /readyz。

网关自己不保存状态，每次调用都用调用方的 token 发给 OpenDsec，所以权限、配额和审计记录照常生效。

和 E2B 云服务的差别 ​

完整列表见 E2B 兼容，主要的几条：

做不到的选项会返回 400，而不是悄悄忽略，所以程序不会在没拿到所要设置的情况下运行。

选 E2B 自建还是 OpenDsec ​

• E2B 自建（Embed） 适合一台机器就够用、想用 E2B 自己代码的场景；部署到自己的云账号（BYOC）是 E2B 企业版的功能。
• OpenDsec 适合需要多机集群、离线部署、RL rollout 那样的大规模突发创建，或者除了 E2B SDK 还想用容器、QEMU 虚拟机和任务级暂停的场景。代价是 E2B 兼容还有上面列出的缺口，项目还是 0.x 版本。

更多对比见 OpenDsec 与 E2B、Daytona、Modal 对比。

常见问题 ​

E2B 可以自建吗？ ​

可以。E2B 的运行时是开源的（Apache-2.0），可以在一台机器上自建；部署到自己的云账号是企业版功能。另一种方式是用 OpenDsec 的 E2B 网关，在自己的单机或集群上提供 E2B SDK 调用的 API。

用 OpenDsec 需要改 E2B 的代码吗？ ​

不需要。设置 E2B_API_URL、E2B_SANDBOX_URL 和 E2B_API_KEY 三个环境变量，把 SDK 指向网关即可。用到网关不支持的功能（例如目录监听）时会返回明确的错误。

支持 E2B 的 code interpreter 吗？ ​

支持，用 deploy/e2b/build-code-interpreter.py 构建模板后即可使用 run_code，包括结果、日志、错误、图表和 pandas 表格。目前只支持 Python 内核。

没有 KVM 的云主机能用吗？ ​

能。没有 /dev/kvm 时安装脚本只装容器，E2B 网关的 base 模板也用容器后端。这时 fork 和快照只保留文件系统，code interpreter 模板需要 microVM。

能完全离线部署吗？ ​

能。OpenDsec 提供离线安装包（deploy/offline），我们在不能上网的虚拟机上验证过安装和使用 E2B SDK，见安装。

自建要花多少钱？ ​

OpenDsec 是免费的开源软件（服务端 AGPL-3.0，SDK Apache-2.0），只需要你自己的机器。

延伸阅读 ​

• E2B 兼容：支持的功能和差别
• 快速开始
• 多机集群部署
• 解读 DeepSeek DSec 论文：OpenDsec 的设计来源

OpenDsec 与 E2B 没有关联，只是实现了 E2B SDK 调用的 API。文中关于 E2B 的情况来自它的文档和代码仓库，核对日期 2026-10-25。

OpenDsec 的自动测试一直在我们自己的开发机和生产集群上跑，全部通过。但开发机上什么都装好了，生产集群也是一步步调出来的。新用户拿到的是一台全新的机器和一份 README。所以开源之前，我们换成新用户的视角，在全新的 Ubuntu 24.04 虚拟机上，按文档把用户可能用到的每个功能走了一遍。

测了什么 ​

两个严重问题 ​

新版 Ubuntu 内核上，microVM 恢复全部失败。 Ubuntu 24.04 当前的 6.8.0-147 内核会杀掉用 CLONE_INTO_CGROUP 放进一个「执行过 cgroup.kill」的 cgroup 的进程。OpenDsec 暂停 microVM 时会结束 VM 进程，恢复时在原来的 cgroup 里启动新进程，于是每次恢复都失败。我们的生产机器内核旧一些，所以一直没碰到；一旦升级内核就会出现。现在结束进程改成先冻结 cgroup 再逐个发送 SIGKILL，不再用 cgroup.kill，并加了一个在受影响内核上会失败的回归测试。

管控节点重启时，少量调用报 unknown edge。 watcher 重启后，要等计算节点重新登记（最多 10 秒）才知道它们；这段时间里 apiserver 会把这些节点当成不存在。压测中硬重启一台管控节点，3,911 次调用里有 3 次失败。现在 watcher 启动时先从其他副本拿到已知节点，apiserver 也会把暂时看不到的节点保留 2 分钟。同样的硬重启，修复后 0 失败。

其他问题 ​

剩下 20 个大多是新用户第一次就会碰到的：

• 安装：新机器上没有 make，安装脚本编译到一半才报错；新 Ubuntu 上缺 python3-venv，README 里的 Python 步骤失败；全新的云镜像没有软件包索引，要先 apt update。
• 命令行：opendsecctl exec 丢了参数里的引号，python3 -c '...' 会出错；--help 不能用；批量创建不打印新建的 ID；导入一个不存在的本地文件时，会去 Docker Hub 下载。
• E2B：单机安装没有 E2B 网关；在默认禁止外网的集群上，E2B sandbox 连不了外网，而 E2B 默认是允许的。
• 运维：opendsecops restart 漏掉了 E2B 网关；磁盘告警用固定阈值，200 GB 以下的机器全都会报；Kubernetes 上 apiserver 没有权限写镜像库。
• 性能：我们推荐的 NFS 4.1 不支持找稀疏文件的空洞，跨节点从内存快照创建要读完整个内存文件，用时 141 秒；换成 4.2 后是 62 秒。文档已改成 4.2，store-check 遇到 4.1 会提醒。

每一项都写在 CHANGELOG 里。

没测到的 ​

真实 GPU、ARM 机器、多节点 Kubernetes，以及 Ubuntu 24.04 以外的发行版。如果你在这些环境上用 OpenDsec，遇到问题请提 issue。

体会 ​

开发机上的全量测试证明的是「代码在我们的机器上是对的」，证明不了「用户照着文档能用起来」。两个严重问题都和环境有关：一个是更新的内核，一个是生产集群里不会出现的重启时机。在全新的机器上按文档走一遍，能发现开发机上永远发现不了的问题。

今天我们把 OpenDsec 的代码公开在 GitHub 上。它是一套给强化学习训练和会执行代码的智能体用的 sandbox 基础设施：在你自己的机器上，成批地创建、暂停、复制和销毁隔离的执行环境。

为什么做它 ​

智能体的强化学习训练要同时跑成千上万个 rollout，每个 rollout 都要一个能装依赖、跑测试、访问网络的隔离环境。训练会被抢占，环境要能整批暂停；同一个状态要试多种走法，环境要能连同内存一起复制。

DeepSeek 在论文 DeepSeek Elastic Compute (DSec) 里详细描述了他们为此建的系统。OpenDsec 照这篇论文实现：无状态的 apiserver、带多级项目和配额的 IAM、汇总调度状态的 watcher、power-of-k 调度和节点上的最终准入，以及分层镜像、默认拒绝的网络策略和按任务暂停。论文没有说明的地方由我们自己决定，仓库里的 SPEC 逐条标注了哪些来自论文、哪些是我们的选择。

OpenDsec 是独立项目，与 DeepSeek 没有关系，也不包含其代码。

它能做什么 ​

• 快：Firecracker microVM 冷启动约 0.1 秒，从内存快照创建约 55 毫秒，暂停后恢复约 50 毫秒。
• fork：fork(count=N) 连同内存复制一个正在运行的 VM，源 VM 只停顿约 10 毫秒。同一节点上的副本共享内存页，64 个副本并发恢复约 0.2 秒。
• 规模：单个 384 线程的节点一次突发创建 5120 个 microVM，用时 37 秒。
• 兼容 E2B：按 E2B SDK 写的程序换三个环境变量就能跑在你自己的机器上，E2B 官方 Python 和 JS SDK 的验收检查全部通过。
• 能运维：组件之间 mTLS，IAM 用 Raft 多副本；fleet 分批滚动升级，失败自动回退；支持离线安装。升级任何组件都不影响运行中的 sandbox。

这些数字都是在我们自己的裸金属机器上测的，测量方法写在 SPEC 里。

试一试 ​

一台装了 Ubuntu 24.04 的 Linux 机器，约 10 分钟：

sudo -i
apt update && apt install -y make git python3-venv
curl -fsSL https://go.dev/dl/go1.27.3.linux-amd64.tar.gz | tar -C /usr/local -xz
git clone https://github.com/kernflux/opendsec && cd opendsec
deploy/quickstart.sh

详细步骤见快速开始，多机集群和离线安装见部署方式。

许可 ​

服务端是 AGPL-3.0；Python SDK、Go 客户端和 API 定义是 Apache-2.0，调用 OpenDsec 的程序不受 AGPL 约束。闭源修改、作为服务对外提供而不公开修改，或者需要企业版的单点登录和审计导出，可以申请商业授权。

接下来 ​

当前是 0.x 版本，1.0 之前接口可能调整。还没有验证过的有：Ubuntu 24.04 以外的发行版、真实 GPU、多节点 Kubernetes。欢迎在 GitHub 上提 issue 和 PR。