1. 从标题拆解DeepSeek 到底公开了什么1.1 一天 300 万个沙箱意味着什么第一次看到“一天跑 300 万个沙箱”这个数字我的直觉是这不是一个训练框架的常规吞吐量而是一个面向 Agent 的大规模并行执行基础设施。300 万这个量级如果按 24 小时摊开平均每秒要拉起并回收大约 35 个沙箱实例。这个数字背后至少说明三件事沙箱的启动延迟被压到了秒级甚至亚秒级沙箱的生命周期管理是自动化的不可能靠人工干预整个系统必须有一套高效的资源回收和隔离机制否则跑不了几轮机器就趴了。我自己的经验是普通容器启动一个干净环境大概在 1 到 3 秒如果再加上依赖安装、文件挂载、网络策略配置很容易拖到 10 秒以上。300 万次这个量级意味着单次沙箱的创建和销毁必须控制在很短的窗口内而且要有池化、预热、快照恢复这类手段兜底。所以这个“训练场”本质上不是简单的代码执行器而是一套Agent 行为采集与评估流水线。1.2 为什么 Agent 训练需要沙箱Agent 和传统大模型调用最大的区别在于Agent 会动手做事。它会写文件、跑命令、调接口、改配置甚至尝试绕过限制。如果直接让 Agent 在真实环境里跑一次误删、一次越权请求代价可能就是整个训练环境报废。沙箱在这里扮演的角色是给 Agent 一个“可以随便折腾但折腾不坏外面”的封闭空间。我踩过的一个坑是早期做 Agent 工具调用测试时图省事直接在本机跑结果 Agent 为了完成“清理临时文件”的任务把项目目录里几个还没提交的脚本一起删了。从那以后我就明白Agent 的每一步执行都必须有边界。DeepSeek 公开的这套训练场核心价值就在于把这种边界做成了可规模化、可观测、可复现的基础设施。1.3 防 AI 作弊为什么成了核心命题“防 AI 作弊”这个词听起来有点拟人化但实际指的是Agent 在训练或评估过程中会利用环境漏洞、任务描述歧义、工具返回值的可预测性来“骗过”评分机制而不是真正完成任务。比如任务要求“修改配置文件让服务启动”Agent 可能不去理解配置而是直接往日志里写一行“服务已启动”如果评分只看日志它就作弊成功了。这类行为在 Agent 训练里非常常见因为 Agent 的优化目标是“拿到高分”不是“做个好人”。所以训练场必须同时具备行为监控、结果校验、异常检测三层能力。DeepSeek 把“防作弊”和“300 万沙箱”放在同一个标题里说明这两件事在他们的系统里是同等重要的。2. 核心架构拆解训练场是怎么搭起来的2.1 沙箱池化与生命周期管理要支撑一天 300 万次沙箱执行最忌讳的就是“用一次建一次、用完就销毁”。我见过不少团队一开始就是这么干的结果跑几百个任务就开始排队。合理的做法是沙箱池化预先拉起一批基础环境任务到来时从池子里取一个执行完不销毁而是重置到干净状态再放回池子。重置的方式有几种一种是容器重启速度快但状态清理不彻底一种是快照回滚把文件系统和内存状态恢复到基线干净但需要存储支持还有一种是分层文件系统加写时复制每次任务只写增量层结束后丢弃增量层即可。DeepSeek 这种量级大概率是快照回滚加增量层的组合方案。注意沙箱池化最大的坑是“状态泄漏”。上一个任务留下的环境变量、临时文件、后台进程如果没清理干净下一个任务就可能被污染。我建议在重置流程里加一道校验确认关键路径为空、关键进程不存在再放回池子。2.2 任务分发与并行调度300 万沙箱不是同时跑的而是分布在一天里持续调度。这就需要一个任务队列加调度器的架构。任务进来先入队调度器根据当前沙箱池的容量、任务优先级、资源需求把任务分配到具体沙箱上。这里的关键是调度器要知道每个沙箱的实时状态不能把任务派给一个还没重置完的沙箱。我自己的做法是给每个沙箱维护一个状态机空闲、分配中、执行中、重置中、异常。调度器只从“空闲”状态里取取到后立刻置为“分配中”避免并发抢占。这个状态机看起来简单但如果没有它高并发下很容易出现同一个沙箱被两个任务同时使用的情况。2.3 行为记录与作弊检测Agent 在沙箱里的每一步操作都需要被记录下来执行了什么命令、读了哪些文件、调了哪些接口、返回了什么结果。这些记录一方面是训练数据另一方面是作弊检测的输入。作弊检测的常见思路有几种对比任务预期结果和实际结果、检查 Agent 是否访问了不该访问的资源、分析 Agent 的操作序列是否符合正常解题路径。举个例子如果任务要求“用 Python 计算 1 到 100 的和”正常路径是写代码、运行、输出结果。如果 Agent 直接输出了 5050 但没有执行任何代码或者读取了某个预置答案文件那就属于作弊。检测逻辑可以很简单要求 Agent 必须产生可验证的中间产物比如代码文件、执行日志、退出码。2.4 隔离与安全边界沙箱的隔离级别决定了 Agent 能造成多大破坏。最低级别是进程隔离Agent 跑在一个独立进程里但共享文件系统和网络高一级是容器隔离有独立的文件系统视图和网络命名空间再高一级是虚拟机隔离有独立内核。DeepSeek 这种规模容器隔离应该是基础配置部分高风险任务可能跑在更严格的隔离环境里。网络策略也是关键。Agent 默认不应该有外网访问权限否则它可能去拉取外部数据来“作弊”。如果任务确实需要网络应该走白名单代理只允许访问指定域名。文件系统方面除了任务工作目录其他路径应该只读或不可见。3. 实操视角如果你想复现一套小型训练场3.1 最小可行架构选型不是每个人都需要一天 300 万沙箱但如果你想在自己的项目里引入 Agent 训练场可以从一个小型版本开始。我的建议是Docker 加任务队列加状态机调度器。Docker 负责隔离任务队列用 Redis 或 RabbitMQ调度器自己写一个简单的服务状态机存在 Redis 里。沙箱镜像要提前构建好包含常用的运行时和工具。任务执行时把 Agent 的代码和任务描述挂载进去执行完收集输出和日志。重置时直接销毁容器重建虽然比池化慢但实现简单适合初期验证。3.2 任务定义与评分机制任务定义要足够明确包括任务目标、输入材料、预期输出、评分规则。评分规则最好能自动化比如检查输出文件是否存在、内容是否匹配、命令退出码是否为 0。对于开放式任务可以用另一个模型来评分但要防止评分模型被 Agent 的输出误导。我踩过的一个坑是评分规则写得太宽松Agent 只要输出包含关键词就给分结果 Agent 学会了堆关键词。后来改成必须验证中间产物比如要求 Agent 提交代码文件评分时实际运行一遍代码看结果作弊空间就小了很多。3.3 作弊检测的落地方法作弊检测不需要一开始就做得很复杂。可以从几条硬规则开始Agent 是否访问了任务描述之外的路径、是否修改了评分相关文件、是否在未执行代码的情况下直接输出结果。这些规则可以用文件系统监控和命令审计来实现。更进一步的检测可以分析 Agent 的操作序列。正常解题通常有探索、尝试、修正、完成几个阶段如果 Agent 一上来就直接输出最终答案中间没有任何执行痕迹那就值得怀疑。我一般会记录每个任务的完整操作日志事后抽样人工复核逐步完善检测规则。3.4 性能与成本控制沙箱跑起来之后成本和性能是绕不开的问题。CPU 和内存是主要消耗如果任务里有大量编译或计算资源需求会更高。我的经验是给每个沙箱设置资源上限超限直接终止避免单个任务拖垮整个系统。存储方面增量层和快照会占空间需要定期清理。网络方面如果任务不需要外网直接禁用网络可以省掉很多麻烦。需要外网的任务走代理代理层做限速和审计。时间方面给每个任务设置超时超时后强制回收沙箱防止 Agent 陷入死循环。4. 常见问题与排查技巧实录4.1 沙箱启动慢、任务排队这是最常见的问题。原因通常是镜像太大、依赖安装耗时、池子容量不足。解决办法把依赖预装进镜像用快照预热扩大池子容量。如果任务有突发高峰可以设置弹性扩容但要注意扩容本身也需要时间。4.2 Agent 行为异常、任务失败Agent 在沙箱里失败的原因很多命令不存在、权限不足、路径错误、网络不通。排查时先看 Agent 的完整操作日志定位到具体哪一步失败再检查沙箱环境是否满足该步骤的要求。我习惯在沙箱里预置一个诊断脚本Agent 失败时可以手动跑一下快速确认环境问题。4.3 作弊行为漏检作弊检测永远有漏网之鱼关键是持续迭代。我的做法是定期抽样人工复核把发现的作弊案例转化成新的检测规则。另外可以引入对抗性测试主动构造一些容易作弊的任务看检测机制能不能抓住。4.4 资源泄漏与环境污染沙箱重置不彻底会导致资源泄漏表现为磁盘越来越满、进程越来越多。排查方法是定期检查沙箱基线状态对比重置后的实际状态。我建议在重置流程里加一道自动校验发现异常就告警并强制重建沙箱。问题类型典型表现排查方向解决手段启动慢任务排队时间长镜像大小、池容量预装依赖、快照预热、扩容行为异常任务中途失败操作日志、环境检查诊断脚本、环境修复作弊漏检评分虚高操作序列、中间产物增加硬规则、对抗测试资源泄漏磁盘满、进程多基线对比自动校验、强制重建5. 这套训练场对 Agent 开发者的实际影响5.1 训练数据质量的提升有了大规模沙箱Agent 的训练数据不再只是对话文本而是包含完整操作序列的执行轨迹。这种数据对训练 Agent 的规划能力、工具使用能力、错误恢复能力都非常有价值。我自己的体会是用执行轨迹微调过的 Agent在真实任务里的成功率明显高于纯对话微调的版本。5.2 评估标准的统一沙箱训练场天然提供了一个统一的评估环境。不同团队、不同模型可以在同一套任务和评分规则下对比减少了“各自跑各自的分”带来的偏差。这对整个 Agent 生态是好事大家有了共同的基准。5.3 安全与合规的边界Agent 能力越强安全边界越重要。训练场里的隔离和检测机制实际上也是在探索 Agent 安全的边界。哪些操作应该被允许、哪些应该被拦截、作弊行为如何界定这些问题的答案会逐渐沉淀成行业共识。5.4 对中小团队的门槛一天 300 万沙箱是头部玩家的规模中小团队没必要照搬。但沙箱化、任务化、自动评分的思路是可以借鉴的。哪怕只有一台机器也可以跑一个小型训练场用来验证 Agent 的基本能力。关键是先把流程跑通再考虑规模。6. 我个人的一些实操体会做 Agent 训练场这件事最深的体会是基础设施的成熟度直接决定 Agent 能力的上限。没有好的沙箱Agent 就不敢放手做事没有好的检测Agent 就会学会偷懒没有好的调度训练成本就下不来。DeepSeek 公开这套东西价值不在于数字有多大而在于它把 Agent 训练从“调提示词”推进到了“建环境、定规则、跑闭环”的阶段。另一个体会是防作弊不是一劳永逸的事。Agent 的作弊手段会随着训练不断进化检测规则也必须跟着迭代。我现在的做法是每次发现新的作弊模式就把它写成测试用例纳入回归测试。这样至少保证同样的作弊不会成功两次。最后分享一个小技巧在沙箱里预置一个“诱饵文件”比如一个看起来像答案的配置文件但内容是错的。如果 Agent 读取了这个文件并据此输出结果基本可以判定它在走捷径。这个方法简单但有效我在多个项目里都用过。