单日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.04，32 核 CPU，128G 内存，一块 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 uvicorn

4.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(host='localhost', port=6379, db=0) def create(self): os.makedirs(self.work_dir, exist_ok=True) # 复制基础镜像到工作目录 shutil.copytree("/opt/sandbox_base", self.work_dir, dirs_exist_ok=True) self.redis.hset(f"sandbox:{self.sandbox_id}", "status", "created") def reset(self): # 删除工作目录，重新从基础镜像复制 shutil.rmtree(self.work_dir) shutil.copytree("/opt/sandbox_base", self.work_dir) self.redis.hset(f"sandbox:{self.sandbox_id}", "status", "reset") def run_command(self, cmd, timeout=30): try: result = subprocess.run( cmd, shell=True, cwd=self.work_dir, capture_output=True, text=True, timeout=timeout ) 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, size=100): self.size = size self.pool = [] self.executor = ThreadPoolExecutor(max_workers=size) 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 常见问题速查表

6. 从这套系统里能学到什么

6.1 工程思维：规模上去了，问题就变了

单日 300 万沙盒这个量级，很多在小规模下不是问题的问题会变成大问题。比如日志，几百个沙盒的时候你随便写文件就行，几万个沙盒的时候日志写入本身就成了瓶颈。DeepSeek 的做法是异步日志加采样，只记录关键事件，普通操作只记计数不记详情。

再比如监控，小规模下你人工看就行，大规模下必须自动化。他们的监控系统会实时统计沙盒创建成功率、任务完成率、平均步数等指标，一旦偏离基线就自动告警。这套东西不是一开始就有的，是随着规模增长逐步补上的。

6.2 Agent 训练的本质：环境比模型更重要

聊了这么多工程细节，最后回到一个根本问题：Agent 训练到底在训什么。我的体会是，模型本身的能力固然重要，但环境的质量往往决定训练的上限。一个设计良好的沙盒环境，能让一个中等能力的模型学会复杂的操作序列。一个设计糟糕的环境，再强的模型也学不出东西。

DeepSeek 这套系统的价值，不在于它用了多先进的技术，而在于它把环境工程做到了极致。从沙盒隔离到任务定义，从奖励设计到并行调度，每个环节都有大量细节需要打磨。这些细节不会出现在论文里，但它们是实际系统能跑起来的关键。

如果你正在做 Agent 相关的工作，我的建议是先把环境搭好，再考虑模型。环境搭好了，模型可以慢慢换。环境没搭好，换什么模型都白搭。这个顺序不能反。