MiniMax Agent RL 沙箱：智能体规模化训练先要解决执行环境

2026 年 3 月 18 日，腾讯云与 MiniMax 对外披露了一件在 agent 圈里被反复引用、却很少有人真正读懂的事：双方在 MiniMax 的 Agent 强化学习（Agent RL）训练里，跑通了一套「百万级吞吐、十万级并发」的沙箱执行环境。据腾讯云开发者社区随后于 3 月 20 日发布的技术文章，这套系统日峰值达到百万级规模，可以在瞬时拉起数万个执行环境，单一部署场景里涉及数千到上万种不同的容器镜像。需要先把边界说清楚：这些数字来自腾讯云与 MiniMax 的联合披露，属于厂商自我口径，没有第三方独立审计。本文引用时一律按「厂商披露」处理，不把它当作被验证过的行业基准，读者也宜带着同样的折扣去看。

这套系统到底在做什么，用一句话概括，就是给正在学习的模型提供一个可以真正「动手」的地方。据腾讯云的说明，agent 在训练中要自主完成一串迭代动作——读取代码、修改、运行、查看报错、再尝试一次；训练素材里包含来自 GitHub 的真实项目，比如 SWE-bench 那类 bug 修复任务。每一次这样的尝试，背后都对应一个沙箱被初始化、被使用、再被销毁的完整过程。模型每写一行代码、每跑一个程序，都需要一个隔离的环境把这行代码真正执行出来，再把执行结果（成功、失败、报错栈）喂回去，模型据此调整下一步。没有这个能「跑」的环境，整套学习的闭环就不成立。

规模从何而来，要把两组数字叠在一起看才明白。据 36Kr 3 月 18 日的报道，MiniMax 的每个 agent 训练任务「可能会 rollout 出数百条尝试路径，每条路径都需要一个独立的沙箱环境」；面向用户查询时，「每个 query 都要并发启动数百个沙箱来运行」。一个训练任务展开数百条路径，成千上万个任务同时在跑，乘出来自然就是十万级并发、百万级吞吐。据 36Kr 报道，腾讯云方面称这是「国内最大的训练沙箱系统之一」，规模「至少比同行高一个数量级」——这同样是厂商口径的相对表述，缺乏公开可比的同行数据，读者宜存疑。

真正值得记下的硬指标其实是启动速度。据同一报道，环境的拉起时间从几分钟压缩到「数百毫秒」，由此带来的 GPU 空转浪费下降了「一个数量级」。这个因果链条是理解后文的关键：agent RL 里最贵的资源是加速卡，而加速卡最怕的就是干等；如果每次拉起一个执行环境都要几分钟，昂贵的 GPU 就只能空转，等着环境准备好再继续算。启动越慢，闲置越多，规模化训练的账就越难算平。所以这个案例表面上是在秀吞吐，底层真正被解决的问题，是把「等环境」这件事从分钟压到毫秒。

业内谈 agent，习惯把注意力放在模型本身：参数量、激活比、benchmark 分数。MiniMax M2 系列确实值得谈——据 arXiv 论文与 MarkTechPost 报道，M2.7 是一个总参数 229.9B、每 token 激活 9.8B 的 MoE 模型，在 SWE-bench Pro 上得到约 56.2 分，在多语言与终端类基准上也有不错的成绩。但如果只盯着这些分数，就会错过这个案例真正的分水岭：让 M2 变强的那套强化学习，它的瓶颈其实不在模型架构，而在模型学习时脚下踩的那块地。

这里需要换一个视角来看训练本身。传统监督学习里，训练数据是静态的：一批标注好的文本，喂进去就行，数据本身不会「运行」，也不会给出动态反馈。Agent RL 完全是另一回事。据 MiniMax 官方与 arXiv 论文的描述，公司把内部大量真实任务和工作空间改造成了 RL 训练环境，规模达到数十万个；验证环节用「Agent-as-a-Verifier」，让 agent 在沙箱里把应用真正部署起来、用 Playwright 这类工具去交互、再按评分标准打分。也就是说，这里的「训练数据」本身就是一个个能被运行、能产生真实报错、能反馈结果的活环境，早已越过了静态文本的范畴。模型这时候做的，是在一个可执行的世界里反复试错，从每一次真实的运行结果中学习。

于是执行环境从配角变成了主角。我更愿意把这套沙箱理解成 agent 训练的「风洞」——飞机能不能在真实气流里飞得稳，先要看它在风洞里被吹过多少种贴近真实的工况；同样，模型能学到多少真本事，取决于沙箱吹出来的这股「气流」，和真实生产环境到底有多像。这个比喻的要点在于它考验的是保真而非声势：气流跑得再快、场面铺得再大，只要吹出来的工况和真实飞行对不上，测出来的数据就是错的。执行环境就是这样一层——它自己不产出 benchmark 分数，也不出现在发布会的高光时刻，却决定了上面那套 RL 到底能不能跑起来、能跑到多大。

把这层执行环境的物理约束翻译成训练术语，就是四个词：吞吐、并发、隔离、保真。当十万个 agent 同时想动手，如果每个环境要几分钟才能拉起，昂贵的 GPU 就只能干等，并发根本堆不上去；如果隔离不够，一个 agent 的破坏行为会污染别的环境，训练信号就乱了；如果环境跑得和真实机器不像，agent 学到的就是假本事，一旦离开训练场就掉点。这四项能否同时达标，才是决定这套 RL 能不能跑、跑多大的先决条件。执行环境越贴近真实运行，它托起的 RL 才谈得上真正有效。

把这层执行环境做得又快又稳，靠的是一组具体的工程手段，而不是玄学。据腾讯云 3 月 20 日的技术文章，这套系统的核心思路是让环境「从预初始化状态实例化」，而不是每次都从零开始搭：通过「运行时快照」，沙箱可以毫秒级进入可执行状态；资源池采用常驻模式而非纯按需创建，配上一套统一的调度系统，负责环境的创建、分配与回收。镜像层面做去重，执行时按需加载，再辅以节点侧的数据复用，尽量减少重复读取。一句被反复引用的话概括了它的生命周期：「环境秒开、用完即删」。这八个字背后，是一整套把冷启动开销前置、把公共状态复用到极致的设计。

这套能力后来被产品化、开源化了。据 2026 年 4 月 23 日腾讯云的开源公告（经 PRNewswire 发布，并见于腾讯云开发者社区），底层的 Cube 沙箱以 Apache 2.0 协议全栈开源，并披露了五项指标：冷启动压缩到 60 毫秒以内（50 并发场景下平均 67 毫秒、P95 为 90 毫秒），而其称行业平均约为 150 毫秒；单实例内存开销低于 5MB；一台 96 核物理服务器可同时运行 2000 多个沙箱；平台级可突发调度 10 万以上实例，P99 延迟低于 200 毫秒；并提供百毫秒内的事件级快照与回滚。这些依然是厂商自测数据，尤其那个「行业平均 150 毫秒」的对照，公告里没有说明取样口径和对比对象，只能当作腾讯云的自我陈述看待，不宜直接拿去做横向比较。

值得单独点出的是安全隔离的做法，因为它直接关系到后面要讲的保真度。据开源公告，Cube 的架构基于 RustVMM 加 KVM，每个沙箱运行独立的 Guest OS 内核，再配合 eBPF 驱动的 CubeVS 做内核级网络隔离，目标是彻底规避容器逃逸。这是一个有讲究的技术选择：容器更轻，但共享宿主内核、隔离偏弱；虚拟机隔离强，但传统上更慢、更重，起一个虚拟机动辄几百毫秒到秒级。业界长期的经验是「更安全就更慢」，二者向来难以兼得。

Cube 想同时拿到两头的好处。据公告，它用 Rust 底层重写、CoW（写时复制）内存复用、reflink 磁盘共享等手段，把独立内核虚拟机的重量级开销硬压下来，试图在保住虚拟机级隔离的同时，把启动速度做到接近容器。对于一个要跑陌生代码、可能触发任意系统行为的 agent 训练场来说，隔离绝不只是一个安全合规的加分项，它本身就是环境保真度的一部分：只有隔离足够干净，模型在里面折腾出来的报错才是真报错，而不是被沙箱自身的资源限制或行为屏蔽污染出来的假象。执行环境既要快，也要真，这两件事在工程上是拧在一起的。

执行环境为什么必须「保真」，值得单独展开，因为这是本案例最容易被吞吐数字盖过的一点。Agent RL 的逻辑很简单：模型做一个动作，环境给一个真实反馈，模型据此调整。这个闭环能成立的前提，是环境的反馈足够贴近生产里的真实运行。如果沙箱为了跑得快、跑得多，砍掉了某些系统调用、简化了文件系统、屏蔽了真实的网络行为，那么 agent 最终学到的，只是如何在这个被简化的世界里拿高分，而没学会如何在一台真实机器上把活干成。保真度一旦打折，吞吐再高也只是在高效地生产错误的经验。

这也解释了 Cube 为什么要费力去支持异构环境。据 4 月的开源公告与相关报道，MiniMax 在 Agentic RL 训练中并发运行的是「数十万个异构沙箱」，镜像覆盖 Linux、Windows、Android 三类系统，平台可在分钟级调度这个量级的实例。异构不是为了炫技：真实世界的软件跑在不同操作系统上，路径规则、权限模型、运行时行为各不相同。一个 agent 若只在单一干净的 Linux 容器里学过，一旦面对 Windows 的反斜杠路径或 Android 的沙箱运行时，就很可能掉链子。环境覆盖的广度，直接决定了训练出来的能力最终能迁移到多宽的真实场景里去。

保真的另一面是可回退。据开源公告，Cube 提供百毫秒内的事件级快照，支持在任意状态存档、回滚与快速 fork。放在 RL 语境里，这几乎是一件必需品：一个 agent 的动作可能把环境搞坏、搞进死角，甚至触发不可逆的破坏，训练系统需要一个「撤销键」，能把环境迅速拨回某个干净的检查点再继续，而不是每次都从头重建一个新环境。这里快照同时扮演两个角色——它是性能手段，因为 fork 一个已经初始化好的状态，比冷启动一个全新环境要快得多；它也是保真手段，因为面对 agent 那些不可预测的行为，只有能随时回滚，训练才能在「让 agent 自由试错」和「不让环境彻底失控」之间取得平衡。

把这几件事收拢起来看：广度上的异构覆盖，时间上的可回退能力，加上前面讲的干净隔离，共同定义了「这座风洞吹出来的气流有多接近真实」。而这恰恰是吞吐、并发这类数字本身回答不了的问题。一套沙箱可以在所有速度指标上都很出色，却在保真度上悄悄失分，而失分的代价，要等到 agent 部署进真实环境、开始掉点的时候才会暴露出来。所以评估执行环境时，速度只是入口，保真才是那道真正难的题。

把 Cube 的来路交代清楚，有助于判断这套能力到底有多可信、多可复用。据腾讯云 4 月的开源说明，Cube 沙箱并不是为了 agent 从零发明出来的，它脱胎于腾讯云自己的 Serverless 基础设施——那套系统据称已经承接了「百亿级调用」，并长期支撑腾讯元宝这类「亿级用户」的产品。也就是说，是先有了大规模、长时间的线上生产验证，才有今天被搬去当 agent 训练场底座的这套东西。这和「为了一场发布会现造一个 demo」是两码事，也是这个案例相对扎实、值得多看一眼的地方：底层调度、隔离、资源复用这些能力，是在真实高压流量里磨出来的。

开源本身也改变了这件事的性质。据公告，Cube 原生兼容 E2B 与 OpenAI 的 SDK 接口标准，宣称 agent 应用「无需改动业务代码，只需更改一个环境变量」，就能从 Manus、OpenAI Agents SDK 这类海外方案迁移过来。这一步的含义远不止「省事」：它把执行环境这一层，从各家自建的黑盒，往一个有公共接口、可替换实现的方向去推。E2B 在海外已经把「agent 沙箱即服务」做成了一个明确的产品品类，腾讯云选择兼容它的接口标准而不是另立一套，等于承认这一层正在标准化。而接口的标准化，往往正是某样东西从「各家自研的私有组件」变成「行业共用的基础设施」的信号。

不过开源与兼容也带来了新的评估负担，这一点必须讲透。接口一致，绝不代表实现等价：同一段 agent 代码，跑在 E2B、跑在 Cube、跑在自建容器上，它们的隔离强度、启动延迟、系统调用的完整程度都可能不一样，而这些差异恰恰会反过来影响 RL 训练的保真度。对采用方来说，「能一行环境变量切过来」当然是实打实的便利，但切过来之后，仍然要自己动手去验证一件事：这个新环境喂给模型的反馈，和你真正的生产环境到底有多像。接口的统一大幅降低了迁移成本，却一点也没有免除保真度上的尽调。便利和可信，是要分开评估的两件事。

从治理与运营的角度看，这套沙箱把几件原本分散的事情，收拢成了一个必须一起考虑的问题：运行时、权限、成本、安全隔离，这四样谁都不能单独达标，缺一个整套就立不住。据前述披露，环境「用完即删」既是性能设计，也是安全与合规设计——一个跑完就被销毁的隔离内核，天然减少了残留状态、数据泄漏和横向移动的攻击面。CubeVS 的内核级网络隔离，处理的则是「agent 在沙箱里发起了不该发的网络请求」这一类风险。这些都不属于模型能力的范畴，而是运行环境本身的治理问题，靠把模型练得更聪明并解决不了。

成本这一面尤其容易被忽视，却是规模化真正的约束。据 36Kr 报道，启动时间从分钟级降到数百毫秒，直接把 GPU 空转浪费压下了一个数量级——在 agent RL 里，最烧钱的一环，就是等沙箱准备好的这段时间里闲置的加速卡。单实例低于 5MB 的内存开销、单机 2000 多个沙箱的密度，指向的其实是同一件事：只有当每一个执行环境都足够便宜、足够快，十万级并发才在经济账上真正成立。执行环境如果又贵又慢，规模就先卡在成本这道坎上，根本轮不到去谈更复杂的训练设计。把执行环境的单位成本压到足够低，是规模化的隐形前提。

这里要克制地下一个判断，而不是喊口号。可以说的是：在这个案例里，决定 RL 规模上限的，是执行环境的吞吐、并发、隔离与保真这四项能否同时达标；触发条件恰恰是「同时」这两个字——四项里任何一项拖了后腿，整套训练要么根本跑不到那个量级，要么勉强跑到了、但学出来的东西不可靠。同样要说清楚的是：本案例支持不了「沙箱决定一切」或者「有了好沙箱就赢了」这样的结论——模型架构、数据质量、奖励函数设计同样在起决定性作用，这些本案例都没法归因。它真正支持的只有一条：执行环境是这一代 agent 训练里，一个被长期低估、如今被抬到基础设施位置的先决条件。是必要条件，不是充分条件，这个分寸要拿捏住。

现在诚实地盘一下账：这些披露出来的数字，到底能证明什么，又不能证明什么。能证明的是工程可行性——腾讯云与 MiniMax 至少在他们自己的测试与训练环境里，把百万级吞吐、十万级并发、60 毫秒冷启动这一组指标真的跑了出来，并且把底层开源了，让外界可以去读代码、跑复现，而不是只能信一份 PPT。开源这一步实质性地提高了可信度：Apache 2.0 的 Cube 沙箱是可下载、可复现的，这一点比任何自测数字都更有说服力，也是本案例值得被认真对待的根据。

不能证明的，有三层，得一层层说清楚。第一层，所有性能数字都是厂商自测口径，没有第三方审计；「行业平均 150 毫秒」「比同行高一个数量级」这类相对表述，公告里都没有给出公开的对照方法和对比对象，只能当作腾讯云的自我陈述，不能拿去当行业定论。第二层，也是更关键的一层：百万级吞吐、十万级并发这类指标达标，并不等于训练保真度高。沙箱能秒开、能并发十万，只说明它「跑得快、跑得多」，完全说明不了它「跑得真」——一个被过度简化以换取速度的环境，是有可能既满足全部吞吐指标、又让 agent 学到一堆在真实机器上根本不成立的技巧的。速度指标和保真度指标，测的是两件不同的事。

第三层，这套系统服务的是 MiniMax 的训练侧，而公开材料里几乎没有把「用了这套沙箱」直接归因到某个 benchmark 涨了多少分。M2.7 的 SWE-bench Pro 56.2 分是模型的综合结果，里面有架构的贡献、有数据的贡献、有奖励设计的贡献，没有办法干净地拆出「沙箱单独贡献了几分」。所以正确的读法是：把这组数字看成「执行环境这一层已经具备工业化能力」的证据，而不是「MiniMax 因此变强了多少」的证据。前者有据可查、可复现，后者需要更细的消融实验，而这类实验目前并不在公开记录里。对读者最有用的一条纪律因此也很朴素：遇到任何一套沙箱方案，先问它的吞吐，更要追问它的保真——而这两个问题的答案，往往不会写在同一份材料里。

作为对照，值得看看一条方向相反的路线，以免把「大而快的托管沙箱」误当成唯一正解。学术界今年出现了往反方向使劲的尝试：据 arXiv 上一篇题为 SWE-MiniSandbox 的工作，研究者探索的是「无容器」（container-free）的强化学习环境，试图绕开为每一个 RL 任务都起停一整套完整沙箱所带来的重量级开销，用更轻的方式去构造软件工程 agent 的训练环境。这条路线下的赌注，和腾讯云正好相反：与其把沙箱做得又快又强、再靠工程去支撑海量并发，不如从设计之初就尽量少依赖沙箱。

两条路线的分歧，恰好照出了执行环境这一层的核心张力：保真与成本、隔离与速度，本来就是一组需要反复权衡的矛盾，没有免费的答案。腾讯云 Cube 走的是「重隔离加极致优化」的路——用独立 Guest OS 内核保住保真和安全，再用 Rust 重写、运行时快照、内存复用这些手段，把重量级方案的速度硬生生压下来。无容器路线走的则是「轻量优先」——先把沙箱开销砍掉，代价是隔离和保真度得靠别的机制另想办法补回来。哪一条更好，不取决于谁的口号更响，而取决于训练目标本身：如果目标任务高度依赖真实的系统行为，比如要跑陌生二进制、触发系统调用、跨操作系统运行，那么重隔离带来的保真优势就值回它的成本；如果任务本身可以在一个受控的轻量环境里被充分表达，那么无容器的省法显然更划算。

这个对照的价值，在于提醒一件容易被忽略的事：沙箱越重未必越好，越轻也未必越好，关键是要和被训练的能力对齐。这里有一个很现实的反面教材：如果一支团队为了刷吞吐指标，把环境越做越轻、越做越假，最后很可能出现 agent 在训练场里门门满分、一到真实环境就明显掉点的局面——这恰恰说明它优化错了目标，把手段（吞吐好看）当成了目的。执行环境这一层的成熟，从来都不是单一维度上的军备竞赛，它考验的是保真度、成本、隔离这三者之间持续不断的校准。看懂这一点，才不会被任何一个孤零零的吞吐或并发数字带偏。

对东南亚的 AI 公司和企业 IT 团队来说，这个案例真正能迁移的东西，是它把一条评估轴摆到了台面上：决定一套执行环境价值的，首先是保真——它把 agent 的动作跑得有多真，而不是把吞吐跑得有多快、多满。跑得快、跑得多是入场券，跑得真才是分水岭。顺着这条轴，可以照着做的有三条。第一，把执行环境当成一等公民来选型，别把它当成训练或部署环节的附属品——在评估任何一套 agent 方案时，把沙箱的启动延迟、并发上限、隔离强度、系统覆盖度这几项列进硬指标，和模型分数并排放在一起考量。第二，优先考虑那些有公共接口、可迁移、最好是开源的执行层：Cube 兼容 E2B 与 OpenAI 的 SDK、以 Apache 2.0 开源，这意味着区域内团队不必从零自建就能起步，也不至于被单一云厂商锁死。第三，把保真度尽调正式写进采用流程：迁移一套沙箱可能只需要改一个环境变量，但迁移之后，务必用自己的真实任务去验证一遍，确认新环境喂回来的反馈没有失真。

预期也要设得克制一些。东南亚绝大多数团队，短期内并不需要十万级并发的训练沙箱——那是模型公司的量级，硬去对标既不现实也不必要。对区域内团队真正普遍相关的，是生产侧的 agent 运行时：怎么让一个 agent 安全地跑代码、调用工具、访问数据，同时把权限、成本和隔离这三件事管住。这一层的成熟度，比再多刷几个模型 benchmark，更能决定 agentic AI 到底能不能在本地落地。真正值得抄走的，是「用保真度而非吞吐数字来判断一套执行环境」这套眼光，它的绝对规模反倒是次要的。

最后给一个该盯的反向信号，用它来给上面这套判断上一道刹车。如果未来一段时间里出现这样的情形——某个团队的沙箱在吞吐、并发、冷启动这些指标上都很出色，甚至开源可查，但用它训练出来的 agent，一到真实生产环境就明显掉点，或者在独立的、贴近真实运行的评测里，表现远远逊于它的沙箱指标所暗示的水平——那就是一个明确的证伪信号：它说明这一层的竞争已经跑偏了，大家在拼命优化「跑得快」，却把「跑得真」丢在了一边，用百万级吞吐、十万级并发这些自测数字盖住了保真度上的失分。触发这个信号的条件，是「沙箱自测指标与 agent 真实环境表现出现系统性的背离」——用回前面那个比喻：一座训练风洞真正的标尺，是它吹出来的工况和 agent 要去的真实赛道有多贴合，气流吹得多快、多满只是次一级的问题；一旦自测指标和真实表现开始背离，就说明这座风洞在测一股假气流。看到它，就应当把「执行环境是先决条件」及时收窄成「保真的执行环境才是先决条件」，并对任何只秀吞吐、闭口不谈保真的方案保持警惕。反过来，只要迁移到真实环境之后能力基本守得住，这套把保真放在吞吐之前的执行层判断标准，对东南亚玩家就仍然值得认真去抄。