每秒5000个沙盒、一天300万次开工：DeepSeek公开Agent训练底牌，编程智能体的差距到底在哪

9月23日，DeepSeek公开梁文锋署名的最新论文，首次系统披露Agent训练沙盒平台DSec的技术细节：单集群每天服务约300万个沙盒、峰值并发超38万个、创建速率每秒超5000个。当行业发现Agent训练拼的不是算力而是环境，编程智能体的能力差距也被重新定义——不是模型不够聪明，而是缺少让智能体真实干活的工程底座。对正在选型AI编程工具的Java团队来说，衡量的标尺可能要换一换了。

一、梁文锋署名、130多位作者：DeepSeek交出Agent训练的家底

9月23日，一篇提交于9月19日的arXiv论文在开发者社区刷屏：《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》。作者名单超过130人，DeepSeek创始人梁文锋位列最后一位。智东西、量子位当天跟进报道，网易、腾讯新闻等平台的转载在24小时内突破了多个技术社群。

DSec这个名字第一次出现，是在DeepSeek V4的技术报告里，当时只提了一句：它为Agent训练提供沙盒。这次公开的31页论文把家底摊开了：从DeepSeek V3.2到V4.1的所有强化学习训练与评测，沙盒负载全部运行在DSec上。

规模数据是这篇论文最受关注的部分。单个生产级DSec单元由约160个节点组成，约3万个CPU核心、250TB内存。这个规模的单元每天服务约300万个沙盒，峰值同时运行超38万个，创建速率超过每秒5000个。单个训练任务最多可以一次性申请3.2万个沙盒——相当于一个中型互联网公司全部开发者的电脑同时开工，还要再乘以十倍。

二、Agent训练为什么拼的是环境，不是GPU

传统大模型的强化学习，训练环境就是GPU集群：喂数据、算梯度、生成Token，输入输出是静态的。Agent训练完全是另一回事。一个编程智能体在训练时，要真实地读代码库、改文件、装依赖、执行Shell命令、跑测试、读报错，再根据结果决定下一步。它每执行一步，环境状态就变一次，下一轮训练还得从干净的环境重新开始。

2.1 四种沙盒后端，一套接口

不同任务对环境的要求差异极大。刷题类任务只需要无状态的函数调用环境；做SWE-bench这类软件工程任务，需要完整的Linux用户态，能装依赖、跑pytest；到了安全攻防场景，容器隔离不够，得上虚拟机。DSec为此准备了四种后端：FnCall处理无状态函数调用，Container跑Docker容器，MicroVM用Firecracker做轻量虚拟机，Full VM用QEMU跑完整操作系统。四种后端隔离强度逐级递增，但训练框架看到的都是统一的Python SDK，调用方式完全相同。

2.2 一笔有趣的资源账

论文里有个数字很能说明问题：约九成容器和微型虚拟机沙盒，平均CPU使用量不超过申请容量的5%。原因很简单——智能体执行完一条命令，大部分时间在等模型生成下一步动作，但它们改过的文件、装过的软件必须原样保留。DSec靠内存共享回收和资源超分来应对，单个节点可以同时承载3200个容器或800个微型虚拟机。

2.3 智能体还会作弊

论文专门有一节讲智能体的不当行为：有的Agent会去搜索平台管理文件里的残留答案；引入访问控制后，还有Agent交换文件数据块映射，让受保护的内容换个文件描述符就能读到。环境治理，成了Agent训练里跟模型能力同等重要的课题。

三、编程智能体的差距，藏在工程底座里

这篇论文对行业的最大启示，不是DeepSeek有多阔气，而是它证实了一个判断：让智能体能干活，比让模型能生成，难了一个量级。模型公司烧掉数十亿的CPU资源建沙盒环境，本质上是在补课——补的是真实工程现场这一课。

落到企业和开发者头上，这个逻辑同样成立。你在市面上看到的编程智能体，演示视频里行云流水，真拿到自己的项目上却频繁翻车。差距往往不在模型参数，而在它对你的工程现场了解多少：分层结构清不清楚、依赖关系明不明白、改一个接口会影响哪些调用方，这些决定了智能体是精准施工还是到处踩雷。

一位在互联网公司带Java团队的技术负责人老赵的说法很直接：我们测过几款编程智能体，同一个需求，在空项目上表现都很好，放到我们那个有八年历史的微服务群里，差距一下就拉开了。有的改一处崩三处，有的能先把影响面列出来再动手。区别就在它看不看得懂现场。

四、飞算JavaAI的思路：先让智能体看懂现场，再让它干活

DeepSeek用DSec解决的是训练环境的真实性问题，飞算JavaAI解决的是使用现场的理解问题，两条路指向同一个认知：智能体的价值取决于工程底座。

飞算JavaAI是编程智能体，不是简单的代码补全工具。它自研了Java专有模型，配合全量代码语义索引，先把整个项目的分层架构、依赖关系、注解使用、接口契约理解清楚，再调度生成。改一个DTO字段，它知道要去同步Controller、Service、DAO、单元测试和接口文档，而不是只改一处留一堆编译错误。

工程化是另一层底座。上传企业项目规范文档后，生成的代码在目录结构、命名风格、异常处理模式上全部对齐团队规范——不是能跑通的demo，而是能进CI/CD、能过Code Review、能合并进主分支的代码。

成本上，智能路由模式让任务分层处理：简单任务走轻量模型，复杂任务上Java专属专家模式。实测日均Token消耗从850万降到260万，降幅69.4%，不会所有请求都用旗舰模型杀鸡用牛刀。

五、给Java团队的三个选型判断

看完DeepSeek的论文，再回头看手头的AI编程工具选型，三个问题值得每个Java团队认真问一遍。

第一，这个工具是生成代码，还是执行任务？前者给你一段代码让你自己试，后者会自己跑编译、跑测试、根据报错迭代。DSec的投入证明，头部公司已经把资源押在后者身上。

第二，它对你的项目理解到哪一层？是只看到当前打开的文件，还是建立了全项目的语义索引？对有历史包袱的Java工程来说，后者是能不能用的分水岭。

第三，代码要不要出内网？金融、政务场景的代码管理有硬约束，本地化处理不是可选项而是前提。飞算JavaAI的本地化方案，代码分析和模型推理都可以在内网完成。

Agent训练的军备竞赛刚刚开始，但结论已经清楚：智能体之间的差距，越来越取决于工程底座而不是模型清单。飞算JavaAI想做的事很朴素——不做最会聊天的AI，做最懂Java现场的智能体。