单日300万沙盒训练Agent：大规模环境工程实践与架构解析

1. 从标题拆解300万单日沙盒到底在说什么第一次看到“单日 300 万沙盒养出一个 V4”这个说法我脑子里蹦出来的第一个念头是这得是多大的并发量。300 万这个数字放在任何系统里都不是小数目更何况是“沙盒”——意味着每一个都是独立隔离的运行环境不是简单的 API 调用。后来跟几个做 Agent 训练的朋友聊了聊又翻了一圈 DeepSeek 技术社区里的讨论才慢慢把这件事的全貌拼出来。简单说这是一套用大规模沙盒环境来训练 Agent 能力的工程实践。核心逻辑不复杂你想让一个模型学会在真实环境里干活光靠静态数据集是不够的得让它在一个可控的、可重复的、能快速重置的环境里反复试错。沙盒就是干这个的。但难点在于规模——单日 300 万个沙盒实例意味着从调度、隔离、状态管理到结果回收整条链路都得扛住极高的吞吐。这件事为什么值得聊因为大部分人在做 Agent 训练时卡的不是模型本身而是环境。你写一个 Agent 去操作浏览器、去调 API、去执行代码每一步都可能因为环境状态不一致而失败。沙盒解决了隔离问题但引入了一整套新的工程复杂度。DeepSeek 这套东西的价值在于它把“怎么把沙盒规模做到百万级”这件事的工程细节摊开了不管你用的是 DeepSeek 还是别的模型这套思路都能直接借鉴。适合谁看如果你正在搭 Agent 训练管线或者在做 Agent 产品的后端架构再或者你只是好奇“Agent 训练到底在训什么”这篇都能给你一些能直接抄作业的东西。我会尽量把每个环节的“为什么”讲清楚不只是告诉你“要这么做”而是告诉你“为什么不能那么做”。2. 沙盒训练的整体架构为什么不是简单堆机器2.1 沙盒的本质一个可重置的“平行世界”先把这个概念说透。沙盒在 Agent 训练里的角色类似于游戏里的“存档点”。Agent 在沙盒里做任何操作——点按钮、填表单、发请求、跑代码——都不会影响真实系统。做完一轮沙盒重置Agent 从干净状态重新开始。这样你才能让同一个 Agent 在同一个场景里反复练习直到它学会正确的操作序列。但“重置”这件事本身就有讲究。最简单的做法是每次开一个全新的容器跑完就销毁。问题是启动容器有开销如果每个沙盒生命周期只有几秒启动时间占比就会非常高。DeepSeek 的做法是维护一个沙盒池用过的沙盒不销毁而是做状态回滚。回滚比冷启动快得多尤其是当沙盒内部状态复杂的时候。注意状态回滚不是万能的。如果 Agent 在沙盒里写了文件、改了配置、装了依赖回滚就得把这些都还原。DeepSeek 的方案是分层文件系统加写时复制基础层只读所有修改落在可写层重置时直接丢弃可写层。这个思路和 Docker 的镜像分层是一样的但他们在上面加了一层更细粒度的状态快照。2.2 调度层300 万单日是怎么算出来的300 万单日拆到每秒大约是 35 个沙盒的创建或重置。这个数字看起来不算夸张但考虑到每个沙盒可能持续几十秒到几分钟实际并发运行的沙盒数量可能在几万到十几万之间。调度层要解决的核心问题是怎么在有限的物理资源上让这么多沙盒高效运转。DeepSeek 用的是两级调度。第一级是全局调度器负责把沙盒请求分配到不同的物理节点。第二级是节点内的本地调度器负责在单机上管理沙盒的生命周期。全局调度器不关心沙盒内部在跑什么只关心资源配额和亲和性——比如某个 Agent 的连续多轮操作最好落在同一个节点上避免跨节点通信开销。这里有个细节值得说他们用了“预热池”。不是等请求来了才创建沙盒而是提前创建一批空闲沙盒放在池子里。请求到达时直接从池子里取取完立刻补充。这样冷启动的延迟就被隐藏掉了。预热池的大小根据历史负载动态调整高峰期多预热低谷期少预热。2.3 隔离方案为什么不用传统虚拟机虚拟机隔离性最好但太重。启动一个 VM 动辄几秒到几十秒而且内存开销大。容器轻量但隔离性弱一些尤其是内核共享带来的安全问题。DeepSeek 的选择是介于两者之间——用轻量级虚拟化具体来说是基于 Rust 实现的用户态内核加硬件虚拟化支持。这个选择背后的逻辑是Agent 训练场景下沙盒里跑的东西是不可信的。Agent 可能会执行任意代码可能会尝试逃逸可能会消耗大量资源。你需要比容器更强的隔离但又不能接受虚拟机的开销。轻量级虚拟化在启动速度和隔离性之间取了一个平衡点启动可以做到毫秒级同时每个沙盒有独立的内核态。实操心得如果你自己在搭类似系统不一定非要上轻量级虚拟化。如果 Agent 只做 API 调用和简单文件操作容器加 seccomp 加 cgroup 就够了。但如果 Agent 要执行任意代码尤其是用户提交的代码那隔离级别必须往上提。我见过太多因为隔离不够导致沙盒之间互相干扰的案例排查起来非常痛苦。3. Agent 训练的核心环节沙盒里到底在训什么3.1 任务定义从“能跑”到“跑对”沙盒本身只是环境真正决定训练效果的是任务设计。DeepSeek 这套系统里每个沙盒加载一个任务定义任务定义包含初始状态、目标状态、可用操作集、成功判定条件。Agent 在沙盒里尝试各种操作序列系统记录每一步的结果最终根据是否达成目标给出奖励信号。任务定义的粒度很关键。太粗Agent 学不到细粒度的操作技巧太细任务数量爆炸训练效率低。DeepSeek 的做法是分层定义底层是原子操作比如“点击坐标 (x,y)”、“输入文本”、“发送 HTTP 请求”中层是组合操作比如“填写表单并提交”高层是完整任务比如“完成一次电商下单”。训练时从底层开始逐步往上。这里有个容易踩的坑任务的成功判定条件如果写得太严格Agent 会陷入“怎么做都不对”的困境学习信号稀疏训练效率极低。如果写得太宽松Agent 会学会“作弊”——用非预期的方式达成目标。DeepSeek 在判定条件里加了“操作合法性检查”比如不允许直接修改内存来改变状态必须通过合法操作接口。3.2 奖励设计稀疏奖励怎么破Agent 训练最头疼的问题之一就是稀疏奖励。一个任务可能几十步操作只有最后一步才知道对不对。中间步骤没有任何反馈Agent 根本不知道哪一步走错了。DeepSeek 用了两种手段来缓解这个问题。第一种是中间奖励。在任务定义里埋一些“检查点”Agent 到达检查点时给一个小奖励。比如“打开网页”是一个检查点“找到搜索框”是另一个“输入关键词”是第三个。这样奖励信号就密集多了。但检查点的设计需要领域知识不能随便埋否则 Agent 会学会“刷检查点”而不是真正完成任务。第二种是逆强化学习。用人类操作日志作为示范训练一个奖励模型来给 Agent 的每一步打分。这个奖励模型不需要很精确只要能区分“好操作”和“坏操作”就行。DeepSeek 的技术社区里有讨论提到他们用这个方法把训练效率提升了三倍以上。注意逆强化学习需要大量人类操作数据。如果你没有这个数据积累可以先从规则化的中间奖励开始。规则化奖励虽然粗糙但胜在可控不会引入奖励模型的偏差。3.3 并行训练怎么让几万个 Agent 同时学单日 300 万沙盒意味着同时可能有几万个 Agent 在并行训练。并行训练的核心挑战不是计算资源而是样本效率。如果每个 Agent 都从零开始学那大部分时间都浪费在重复探索上。DeepSeek 用了参数服务器加经验回放的架构。参数服务器负责维护全局模型参数每个 Agent 在本地沙盒里用当前参数跑一段算出梯度传回参数服务器。参数服务器聚合梯度更新参数再分发给各个 Agent。经验回放池存储所有 Agent 的操作序列和奖励训练时从池子里采样打破时间相关性。这里有个工程细节梯度传输的带宽可能成为瓶颈。几万个 Agent 同时传梯度网络压力很大。DeepSeek 用了梯度压缩把稀疏梯度用稀疏格式传输稠密梯度做量化。实测下来带宽占用降低了百分之七十以上而模型效果几乎没有损失。4. 实操复现从零搭一个迷你版沙盒训练系统4.1 环境准备与基础组件选型如果你不想一上来就搞几万个沙盒可以先从单机版开始。我自己的实验环境是 Ubuntu 22.0432 核 CPU128G 内存一块 RTX 4090。这个配置跑几百个并发沙盒没问题足够验证整套流程。基础组件我选了这几个容器运行时用 containerd比 Docker 轻量启动更快沙盒内部用 Python 的subprocess加resource模块做资源限制状态管理用 Redis 存沙盒元数据用本地文件系统存沙盒快照。模型侧我用的是 DeepSeek 的 API因为本地部署对显存要求太高API 调用更适合快速验证。# 安装 containerd sudo apt-get update sudo apt-get install -y containerd sudo systemctl start containerd sudo systemctl enable containerd # 安装 Python 依赖 pip install redis requests fastapi uvicorn4.2 沙盒生命周期管理创建、运行、重置沙盒的生命周期我分四个阶段创建、初始化、运行、重置。创建阶段从预热池取一个空闲沙盒如果没有就新建。初始化阶段加载任务定义设置初始状态。运行阶段执行 Agent 的操作序列记录每一步的结果。重置阶段回滚状态把沙盒放回预热池。import subprocess import os import shutil import redis class Sandbox: def __init__(self, sandbox_id, base_dir/tmp/sandboxes): self.sandbox_id sandbox_id self.base_dir base_dir self.work_dir os.path.join(base_dir, sandbox_id) self.redis redis.Redis(hostlocalhost, port6379, db0) def create(self): os.makedirs(self.work_dir, exist_okTrue) # 复制基础镜像到工作目录 shutil.copytree(/opt/sandbox_base, self.work_dir, dirs_exist_okTrue) self.redis.hset(fsandbox:{self.sandbox_id}, status, created) def reset(self): # 删除工作目录重新从基础镜像复制 shutil.rmtree(self.work_dir) shutil.copytree(/opt/sandbox_base, self.work_dir) self.redis.hset(fsandbox:{self.sandbox_id}, status, reset) def run_command(self, cmd, timeout30): try: result subprocess.run( cmd, shellTrue, cwdself.work_dir, capture_outputTrue, textTrue, timeouttimeout ) return { stdout: result.stdout, stderr: result.stderr, returncode: result.returncode } except subprocess.TimeoutExpired: return {error: timeout, returncode: -1}这个迷你版没有做真正的隔离只是用工作目录来模拟。生产环境里你需要把subprocess换成容器调用把工作目录换成容器内的文件系统。但核心逻辑是一样的创建、运行、重置。4.3 任务定义与奖励计算任务定义我用 JSON 来描述包含初始状态、目标状态、操作集、检查点。奖励计算分两部分中间奖励来自检查点最终奖励来自目标达成。import json class Task: def __init__(self, task_file): with open(task_file) as f: self.definition json.load(f) self.checkpoints_hit set() def get_initial_state(self): return self.definition[initial_state] def check_intermediate_reward(self, state): reward 0 for cp in self.definition[checkpoints]: if cp[id] not in self.checkpoints_hit: if cp[condition](state): reward cp[reward] self.checkpoints_hit.add(cp[id]) return reward def check_final_reward(self, state): if self.definition[goal_condition](state): return self.definition[goal_reward] return 0检查点的条件我用 Python 函数来写这样灵活。比如“搜索框可见”这个检查点条件就是检查当前页面 DOM 里有没有搜索框元素。目标条件就是“订单提交成功”之类的。实操心得检查点的奖励值不要设得太高否则 Agent 会为了刷检查点而忽略最终目标。我的经验是中间奖励总和不要超过最终奖励的百分之三十。另外检查点不要设得太密否则 Agent 会学会“按部就班”但不会灵活应变。4.4 并行调度与结果回收并行调度我用的是 Python 的concurrent.futures加一个简单的队列。每个沙盒跑完一轮后结果写入 Redis调度器从 Redis 读取结果决定下一步是重置沙盒还是销毁。from concurrent.futures import ThreadPoolExecutor, as_completed import uuid class SandboxPool: def __init__(self, size100): self.size size self.pool [] self.executor ThreadPoolExecutor(max_workerssize) def warm_up(self): for i in range(self.size): sb Sandbox(str(uuid.uuid4())) sb.create() self.pool.append(sb) def run_task(self, task, agent): sb self.pool.pop() try: state task.get_initial_state() total_reward 0 for step in range(task.definition[max_steps]): action agent.act(state) result sb.run_command(action[command]) state self.update_state(state, result) total_reward task.check_intermediate_reward(state) if task.check_final_reward(state) 0: total_reward task.check_final_reward(state) break return total_reward finally: sb.reset() self.pool.append(sb)这个调度器很简单但已经能跑通整个流程。生产环境里你需要考虑负载均衡、故障转移、优先级调度等。但作为验证这个够用了。5. 常见问题与排查技巧实录5.1 沙盒启动慢从秒级到毫秒级的优化路径我最初用 Docker 跑沙盒启动一个容器要 1 到 2 秒。几百个并发的时候光启动就花了十几分钟。后来换成 containerd 加预热池启动时间降到 50 毫秒以内。关键优化点有三个一是用预热池隐藏冷启动二是用写时复制减少文件系统开销三是用轻量级运行时替代完整容器。如果你也在做类似优化建议先测一下启动时间的分布。很多时候瓶颈不在容器运行时本身而在镜像拉取或者网络配置。我遇到过因为 DNS 解析慢导致启动延迟的情况后来把 DNS 缓存加上就好了。5.2 Agent 卡死超时与资源限制的平衡Agent 在沙盒里跑飞是常有的事。可能是死循环可能是等待一个永远不会出现的元素可能是发了一个永远不返回的请求。如果不加限制一个卡死的 Agent 会占着沙盒不放拖垮整个系统。我的做法是三层限制第一层是操作超时每个命令最多跑 30 秒第二层是任务超时每个任务最多跑 5 分钟第三层是资源限制每个沙盒最多用 1 核 CPU 和 2G 内存。超过任何一层限制沙盒强制重置任务标记为失败。注意超时时间不要设得太短。有些任务确实需要较长时间比如等待页面加载或者等待异步操作完成。我一开始把操作超时设成 5 秒结果大量正常操作被误杀。后来调到 30 秒误杀率降到百分之一以下。5.3 状态污染为什么重置不干净状态污染是沙盒系统里最隐蔽的问题。表现是 Agent 在某个沙盒里跑得好好的换一个沙盒就各种奇怪错误。排查半天发现是上一个任务留下的文件或者配置没清理干净。DeepSeek 的方案是分层文件系统基础层只读所有修改在可写层。重置时直接丢弃可写层理论上不会有污染。但实际实现里如果 Agent 修改了基础层的内容或者写了共享内存污染还是可能发生。我的做法是在重置后加一个校验步骤检查关键文件的状态是否和初始状态一致。不一致就强制重建沙盒。5.4 常见问题速查表问题现象可能原因排查方法解决方案沙盒启动超时镜像拉取慢或资源不足检查节点资源使用率和镜像仓库延迟增加预热池大小使用本地镜像缓存Agent 操作无响应命令死循环或等待超时查看沙盒内进程状态和网络连接设置操作超时强制重置沙盒任务成功率骤降状态污染或奖励函数错误对比成功和失败任务的沙盒状态加强重置校验检查奖励计算逻辑梯度传输带宽打满并发数过高或梯度未压缩监控网络带宽和梯度大小启用梯度压缩降低并发数沙盒之间互相干扰隔离级别不够检查是否有共享资源被修改提升隔离级别使用独立内核6. 从这套系统里能学到什么6.1 工程思维规模上去了问题就变了单日 300 万沙盒这个量级很多在小规模下不是问题的问题会变成大问题。比如日志几百个沙盒的时候你随便写文件就行几万个沙盒的时候日志写入本身就成了瓶颈。DeepSeek 的做法是异步日志加采样只记录关键事件普通操作只记计数不记详情。再比如监控小规模下你人工看就行大规模下必须自动化。他们的监控系统会实时统计沙盒创建成功率、任务完成率、平均步数等指标一旦偏离基线就自动告警。这套东西不是一开始就有的是随着规模增长逐步补上的。6.2 Agent 训练的本质环境比模型更重要聊了这么多工程细节最后回到一个根本问题Agent 训练到底在训什么。我的体会是模型本身的能力固然重要但环境的质量往往决定训练的上限。一个设计良好的沙盒环境能让一个中等能力的模型学会复杂的操作序列。一个设计糟糕的环境再强的模型也学不出东西。DeepSeek 这套系统的价值不在于它用了多先进的技术而在于它把环境工程做到了极致。从沙盒隔离到任务定义从奖励设计到并行调度每个环节都有大量细节需要打磨。这些细节不会出现在论文里但它们是实际系统能跑起来的关键。如果你正在做 Agent 相关的工作我的建议是先把环境搭好再考虑模型。环境搭好了模型可以慢慢换。环境没搭好换什么模型都白搭。这个顺序不能反。