DeepSeek Agent训练揭秘：300万代码沙箱背后的自动化数据工厂

梁文锋署名DeepSeek公开的Agent训练方法真正值钱的部分其实不是模型参数量而是底下那个一天能撑300万代码沙箱的底座。我花了几天把公开资料啃完又在自己环境里复现了一部分流程这篇就把我对这套系统的理解掰开揉碎讲一遍。先说结论这套方案解决的根本问题不是“怎么把模型调聪明”而是“怎么低成本地给Agent构造一个可以无限试错、自动反馈、可并发的训练场”。数据、模型、算法这三样东西DeepSeek在这篇公开里把重心明显压在了“数据生产”和“反馈构造”上而这恰恰是多数团队最不重视、也最缺经验的地方。1. 先别急着聊模型Agent训练真正的瓶颈在“反馈回路”1.1 为什么强化学习在Agent身上失效了做过RLHF或者指令微调的人应该都有这个感受给一个聊天模型打分哪怕是让另一个大模型来当裁判效果都还算勉强可用。但到了Agent场景你让模型去操作代码仓库、调用工具、完成一个多步骤任务事情就彻底变了。最大的问题不是模型不会干活而是你没法拿到可靠的反馈信号。传统RLHF里的奖励模型本质上是在对“一段文本”做偏好判断但Agent的一次完整运行可能包含十几次工具调用、多次代码生成、反复报错重试。这时候你再让奖励模型对一个“运行轨迹”打分它根本分不清哪一步是真正导致失败的原因。DeepSeek这篇公开的出发点就在这里如果你不给Agent一个真实的环境去执行所有的推理和决策都停留在“抽象概率”层面那再怎么强化学习都是在沙地上盖楼。所以他们把答案压在了代码沙箱上让Agent在沙箱里真实执行代码、验证结果、拿到确定性反馈。1.2 所谓“底座”就是一套自动化的数据生产与评估系统我理解这套底座的核心链条是任务库产生题目 → 沙箱池并发执行Agent的尝试 → 奖励模型根据真实执行结果给出反馈 → 反馈回流做强化学习。逻辑上不复杂复杂的是工程。一天撑300万个沙箱意味着平均每秒要拉起接近35个沙箱实例。每个沙箱里跑的可能是一段Python脚本、一个Linux命令、一次数据库查询操作也可能是整个仓库级任务的编译测试。要做到这个规模沙箱的创建、销毁、复用、隔离全部得是高度自动化的流水线。这跟我们平时本地起个Docker容器完全是两个量级。我自己在复现小规模版本的时候单机同时开20个容器就已经开始焦虑了CPU争抢、镜像下载带宽、超时任务清理全是坑。DeepSeek这套系统能跑300万背后一定是把调度做得极其精细。1.3 这篇公开适合谁看我觉得有三类人最值得读正在做Agent产品、但训练数据靠人工标注或简单扒公开数据集的人你会发现自己缺一个“自动化数据工厂”准备在这套开源基础上做二次开发的算法工程师你需要先了解清楚数据生产环节的天花板在哪关心成本控制的团队负责人看完算力测算那部分会对“自建沙箱”和“租商业API”的差距有直观感受。2. 一天300万沙箱的数据工厂是怎么运转的2.1 整体LOOP起任务、跑沙箱、收反馈、给奖赏这套系统的核心循环可以概括成四步从任务池里取出任务实例每个实例都绑定一个沙箱环境Agent在沙箱里尝试完成任务期间可以读写文件、执行命令、运行代码沙箱里产生的结果包括报错信息、测试输出、最终产物被结构化地收集起来奖励模型和规则模型结合执行结果给出多维度反馈回流更新Agent。看起来像是强化学习的标准范式但关键差别在于环境反馈是真实、确定、可验证的。Agent写错了代码就是会报错写对了代码就是能通过测试。这种“环境即裁判”的属性让奖励信号的信噪比极高也让后面的强化学习变得扎实。我以前做过纯靠LLM打分的Agent训练那个体验真的是一言难尽。一个模型在任务里绕来绕去最后绕对了裁判模型可能说它是胡编一个模型快速放弃裁判模型可能反而觉得“知道适可而止”。环境反馈不存在这种价值观偏差它只有跑没跑通、对不对、快不快。2.2 三个阶段的训练流程公开内容里把Agent训练分成了三个阶段我按照自己的理解拆一下。第一个阶段是“收敛阶段”。这期间Agent在沙箱里做广泛的探索目的是让模型学会在真实环境里“活下去”——比如知道代码报错后要看报错信息、知道测试不通过时要重新读题而不是硬改。这个阶段产生的大量“尝试-失败-修正”轨迹本身就是无价的数据资产。第二个阶段是“蒸馏阶段”。把探索过程中表现最好的那些轨迹筛选出来用来做监督微调。这个阶段的意义在于把强模型探索出来的高质量行为模式尽可能高效地搬到目标模型身上。第三个阶段是“强化学习阶段”。在蒸馏之后继续用沙箱反馈做RL进一步巩固模型的推理能力和工具使用能力。这三个阶段的划分本身并不稀奇几乎所有的RL训练都遵循类似的节奏。稀奇的是他们每个阶段都能拿到300万沙箱级别的真实执行数据做支撑。数据量大到什么程度很多小团队做Agent训练训练集里的人工标注数据可能也就几千到几万条而这里一天的探索轨迹就是300万条起点。2.3 沙箱池的复用策略一天300万沙箱如果全部是“创建-使用-销毁”的一次性模式成本会爆炸。公开资料里提到系统对沙箱做了一定的池化处理。我的理解是相同的镜像环境会被预加载到一批常驻沙箱池里任务分配过来的时候直接在已有环境里执行。环境隔离用容器实现但容器的生命周期和任务的执行周期被解耦了。任务跑完不立刻销毁容器而是清理现场后给下一个任务复用。只有遇到严重污染或者环境损坏的情况才真的销毁重建。这个复用逻辑和我们做测试平台时处理浏览器实例的思路很像新建一个浏览器内核很贵所以用无头浏览器的实例池来跑跑完一个用例就清空状态给下一个。关键是任务之间要保证隔离否则上一个任务的残留变量和文件会污染下一个任务的执行结果。3. 架构拆解分配器、沙箱池、奖励模型怎么协同3.1 核心组件一览我把公开资料里涉及的关键组件整理成一个表方便对照理解组件职责我的理解任务分配器从任务池取任务分发给空闲沙箱类似消息队列的消费者模型但要做动态负载均衡沙箱池管理器维护常驻沙箱实例的生命周期关键指标是冷启动耗时和复用率代码沙箱提供隔离的可靠执行环境支持Python、Shell、仓库级任务等多种类型执行结果收集器汇总退出码、stdout、stderr、文件变化这部分的数据质量直接决定反馈质量奖励模型管道将执行结果转为奖励信号规则为主模型为辅两者结合数据回放缓冲区存储轨迹供蒸馏和RL使用需要海量存储和高吞吐读写这个架构里我最在意的其实是“执行结果收集器”。很多人做Agent训练只关心代码最终跑没跑通但实际上Agent的行为轨迹里藏着的中间信息——比如第一步怎么做、遇到第一个报错后怎么反应、在什么情况下选择换方案——对强化学习的价值可能比最终结果更大。3.2 奖励模型不是用LLM判分而是“持久化评估”公开内容里反复强调了“持久化评估”这个思路。我第一次看到这个词的时候愣了一下后来想明白了它指的是奖励模型必须基于持久化、可复验的评估结果来反馈。举个例子Agent在沙箱里写了一段排序代码奖励模型不能只看“看起来对”而要把真实的数据跑一遍看看排序结果对不对、复杂度有没有超预期。代码的对错、执行结果的正确性这些是可以用确定性测试来验证的不需要大模型来猜。这一点的意义被大多数人低估了。LLM作为裁判在很多场景下是不稳定的同一个答案换两次问法可能得到不同分数。而当奖励信号本身有噪声强化学习的效果就会大打折扣。DeepSeek这套系统通过“真实执行规则校验多维度反馈”的组合把应该由环境决定的反馈全部交还给环境只在那些确实需要语义理解的地方才动用模型。按照实操经验我建议所有做Agent训练的人都把这个原则刻在脑子里能验证的绝不靠猜能规则化的绝不模型化。这是提高奖励信噪比的最有效路径。3.3 代码沙箱为什么必须用真实环境而不是模拟有人会问为什么不直接用静态分析或者LLM自评来评判Agent的代码非要费劲跑沙箱这个问题我在做Agent评测的时候也纠结过。静态分析可以检查语法错误、风格问题但完全无法判断代码是否真的完成了任务逻辑LLM自评可以看“逻辑通不通”但对运行时的边界情况、并发问题、资源泄漏基本无能为力。只有真实环境能告诉你全部真相。跑测试用例时哪个assert失败了、处理大文件时内存爆了没有、网络请求超时没有这些信息只有在真实执行中才会浮现。更关键的是真实执行得到的反馈信号是客观的不管是从Vanilla RL还是从偏好优化的角度看客观的reward信号都是最有价值的。4. 算一笔账300万沙箱×一天硬件和成本大概是多少4.1 并发沙箱数量与实例规格300万是“一天”不等于“同时在线300万个”。要估算峰值并发得看每个沙箱任务的平均耗时。如果每个沙箱任务的执行耗时是两分钟那么单实例一天能跑720个任务。300万除以720约等于4167也就是说系统需要同时维持大概4000个沙箱实例的并发能力并且全天候满负荷运转。如果平均耗时降到30秒并发需求就要拉到16000个以上。这个并发量其实已经不是“能不能做到”的问题而是“成本扛不扛得住”的问题。4000个沙箱如果平均规格是2核4G内存同时跑满就需要8000核CPU、16TB内存。如果换成GPU实例成本会指数级上升。4.2 推理成本与训练成本测算Agent运行和推理是两笔开销。运行阶段Agent在沙箱里不断尝试每次尝试都可能调一次LLM推理。假设每个任务平均触发30次推理300万任务就是9000万次推理请求。就算每次请求只消耗几百个token总token消耗也是一个恐怖级别。训练阶段从这些轨迹里蒸馏和强化学习的算力开销取决于模型规模和训练轮数。公开资料给过一个对比自建这套系统单次任务的成本可以控制在商业Agent API的几十分之一以内。这个差距主要来自两点一是自建的推理成本远低于商业API的定价二是沙箱环境用池化复用边际成本被压得很低。我用小规模数据粗算过假设一个任务需要10次Agent推理、每次推理消耗2000 token那么一天300万任务就是600亿token。按照当前主流商业API的定价哪怕拿到批量折扣这也是一笔天价。而自建推理集群之后成本主要体现在电费和硬件折旧上能压两个数量级下来。4.3 存储与数据传输的隐性成本300万沙箱每天产生大量的执行日志、代码片段、中间文件这些数据不能随便丢。日志要留底做分析高质量的轨迹要长期保存用于后续训练。我粗略估计一天的原始执行日志至少是几十TB到上百TB的量级。这是我特别想提醒的一点很多团队评估成本的时候只算了算力没有算存储和带宽。当你的数据生产系统真正跑起来之后日志存储、对象存储、数据回放缓冲区的开销会逐渐浮出水面。建议在做预算的时候至少预留20%-30%给数据和传输不要到头来卡在这一环。5. 公开的细节里哪些值得直接抄作业5.1 代码准确性只是底线关键在“久经考验”公开内容里有一个表述让我印象深刻他们不只关心Agent能不能在这一次任务中写对代码更关心它在长期、多轮、多任务条件下是否可靠。用我的话说就是写对一次可能是运气一直写对才是能力。具体到奖励设计上我看到了几个可以借鉴的维度测试通过率确定性最高、权重最大的指标修改次数一次写对和改了十次才对过程分不同运行效率同样完成功能耗时越短的奖励越高自省质量报错之后是否采取合理策略而不是盲目重试。这里面的度要把握好。在早期阶段“能跑通”的优先级远高于“跑得快”。如果一开始就严格惩罚运行速度模型会变得非常保守不敢尝试复杂操作探索效率会急剧下降。建议分阶段调整权重探索期侧重成功率收敛期侧重效率和稳定性。5.2 Relabeling与反馈权重模型能力变化之后怎么办有一个工程细节我觉得非常有价值当新模型版本产出后过去那些由旧模型产出的轨迹怎么办直接扔掉太可惜但不做处理又未必符合新模型的风格。公开资料里提到对旧数据做重新标注。我理解这个过程是让新模型重新接触旧任务看旧轨迹在当前模型视角下是否仍然成立再根据新模型的反馈做权重调整。这相当于给数据做了一次“版本升级”让旧数据还能继续发挥作用。这个做法我强烈建议抄下来。大多数团队训练数据一版用完就丢其实很浪费。当你把“数据版本管理”纳入训练管线你会发现每次模型迭代都不需要从头生产数据老数据重标后依然可以用。5.3 场景覆盖面不能漏掉冷门但关键的工具沙箱任务不能只集中在热门的几个函数和库上面。如果大部分任务都集中在某几个主流框架模型的泛化能力会非常差遇到冷门但刚需的工具就束手无策。我知道有些团队为了解决这个问题会拿着用户反馈里遇到的真实问题去构造新任务让训练数据尽可能贴近线上的真实分布。虽然没有办法证实DeepSeek是否也这样做了但以我负责少量Agent训练的经验来说如果任务库里有一批长尾场景的数据最终模型的线上表现会有很明显的改善。6. 实操中最容易翻车的几个地方6.1 别把RLHF数据直接扔进Agent训练这是一个我踩过的坑也看到很多新团队在重复。RLHF里常用的“打分-排序”数据本质上是对静态文本做偏好排序和Agent的“执行-反馈”数据是不同的东西。混在一起用会引入大量噪声。正确的做法是数据按来源和结构分开存储Reward信号按类型分开计算。执行反馈必须来自沙箱运行结果人工标注和LLM评判只能作为辅助信号。6.2 资源规划要预留重试和超时Agent在沙箱里的行为不可控一个简单的任务可能因为模型陷入死循环而跑上半个小时。如果任务池和沙箱池的数量设置不当一个任务卡住后面整个队列都会堆积。建议配置三重保障一是每个任务设置硬性超时时间超时自动终止二是沙箱冰封检测定期检查每个实例的状态三是任务重试机制失败任务可以换实例重跑但要对重试次数做限制。不要嫌这些东西琐碎生产环境的稳定性全靠它们撑着。6.3 训练参数的节奏感训练刚开始时学习率可以稍高一些让模型快速适应环境后面的学习率要降下来。更重要的一个经验是反馈权重的调整节奏要跟着探索进度走前期多奖励尝试后期多奖励精准。这个节奏感没有公式可以参考完全靠实验数据说话建议每一次权重调整都留足对比观察的时间窗口不要频繁变动。6.4 警惕蹭“harness”热度的各种魔改包最近网上出现了不少“DeepSeek harness桌面版”、“DeepSeek Hermes网页版”之类的下载页和插件看上去好像和官方底座产品有关。但是在我查遍公开资料之后可以明确说DeepSeek并没有发布这类桌面软件或者第三方插件这些更多是利用关键词热度做的包装页面。很多下载包里塞了脚本和广告推广风险相当高。如果你冲着“底座”去研究请专注官方公开的技术内容代码层面的东西可以从实际数据和架构出发自己验证不要因为看到某个看起来很专业的“Hermes官网”就下载来用。这个提醒相信懂的人自然懂。7. 我的看法底座比模型本身更值钱把整篇的内容拉回来看我最深的感受是一套可靠的数据生产系统比一个临时的强模型更有复利价值。模型几个月就可以换新版本但数据生产管线一旦跑通就能持续地产出高质量训练数据并且随着系统运行时间的增加数据的丰富度和覆盖度也在累积。这就像一家工厂今天生产出再牛的产品也比不上工厂本身具备持续迭代的生产能力。在我看来梁文锋署名的这个公开内容最值得研究的地方不在于某个具体的模型效果数据而在于传递了一个清晰的信号在训练资源有限的情况下优先建设数据生产系统建设真实高效的反馈链路远比纠结一个模型结构改动来得重要。我还想分享一个个人体会这套系统真正难的地方不在算法而在工程。模型AI跑得转框架也不难搭难的是你每天都要面对几千个沙箱实例、几万个报错日志、几十种不同的环境依赖并且保证整个系统像工厂流水线一样稳定运转。如果你现在也在做Agent训练我建议先别急着追求大规模先用最小的沙箱闭环跑通把数据格式、反馈信噪比、任务调度这三个基本功练扎实再谈数量级。这是我在这条路上摸索下来最值钱的几句心里话。