https://arxiv.org/html/2609.22978v1 看看这篇论文

回复 Erfan： 这篇是 DeepSeek 的 DSec：面向大规模 Agent 训练的沙箱基础设施。核心不是“让 Agent 更会思考”的新算法，而是：怎样让几十万个 Agent 同时操作真实环境，还能控制成本、保留状态、不把系统搞坏。 从抓到的摘要和架构部分看，最值得关注的是下面几个点。 一、Agent 训练不只是 GPU 跑模型 比如训练 Agent 修复代码，它需要反复读取仓库、修改文件、安装依赖、运行测试。这些操作都需要实际执行环境，而不是只生成一段文字。 难点在于：模型思考时，环境的 CPU 可能闲着，但修改过的文件、启动的服务、占用的内存还得保留。 所以，“大量在线环境”不等于“大量持续满负载计算”。DSec 就是针对这种有状态、间歇执行的负载来设计的。 二、没有一种沙箱能包打天下 它用统一 SDK 接入四类后端，但没有假装它们完全一样： FnCall：短小、无状态的代码执行，利用预创建环境减少启动开销。 容器：仓库级代码任务、一般工具调用，启动快、部署密度高。 microVM：需要更强隔离的任务。 完整虚拟机：Android、图形界面等需要完整系统能力的任务。 一个值得注意的细节：它的容器和 FnCall 实际跑在 QEMU/libvirt 虚拟机内，不是直接把不可信代码的容器放在裸机上。 三、优化重点不是“再包一层 Docker” 首先是环境分层。基础环境、任务工作区、工具层独立版本化，避免一点变化就把整个环境重新制作一遍。 其次是按需加载。镜像放在分布式文件系统 3FS 中，用到哪些数据再读取，而不是每次启动先把整个镜像拉完。论文报告的消融结果中，全量预拉取让完成时间变为约 1.7 倍，按需加载减少了 57% 的累计磁盘写入。 最后是高密度资源管理。利用 Agent 等待模型时的空闲窗口，结合内存共享、回收和 CPU 调度，让更多沙箱共存。但 CPU 闲置不代表内存也能直接释放，这是这里真正棘手的地方。 四、它把沙箱生命周期接进了训练流程 GPU 训练被抢占或中断时，不能让 Agent 已经执行到一半的环境跟着丢失。 论文强调将有状态的 rollout 执行与可被抢占的 GPU 训练解耦，并协调状态保留和闲置资源回收。这里 rollout 就是 Agent 从接到任务到执行结束的一段交互过程。 另外，环境本身也不可信：Agent 可能破坏文件、耗尽资源，或者钻评分机制的空子。隔离和访问控制不仅保护机器，也关系到训练反馈是否可信；不过这不等于已经彻底解决奖励作弊。 五、规模数字怎么理解 作者报告，单个部署单元约有 160 台 CPU 节点、3 万核、250 TB 内存；日服务约 300 万个沙箱，峰值并发约 38 万，创建速率超过每秒 5000 个。 这些是论文报告的生产规模，不是 38 万个任务同时满负载计算，也不能直接换算成模型能力提升。 我的判断：这篇的价值在于展示“Agent 训练的瓶颈如何从模型计算扩展到环境供给”。模型之外，镜像分发、状态管理、资源调度和隔离，都成了训练系统的核心部分。它更适合当作 Agent Infra 的系统论文看，而不是多 Agent 协作策略或新训练算法论文。