导读一个「Agent」会写文件、跑命令还会等模型回复。把这样的任务同时开到成千上万个先吃紧的可能不是模型而是承载每一步动作的执行环境。「DeepSeek Elastic ComputeDSec」讨论的正是这件事怎样为大规模训练和评估提供隔离、有状态的沙箱。论文作者报告的规模很大但那些数字是作者自报不是我的实测。想象一个编码任务Agent 先读取仓库修改文件再运行测试。测试失败它查看日志、改第二版然后重新执行。对话框里只显示几轮消息执行端却留下了文件、进程结果和下一步要用的上下文。现在把同一类任务交给大量 Agent 并行训练。每个任务都需要自己的工作区任务之间不能互相改文件模型思考时工作区又可能暂时没有动作。沙箱何时创建、何时保留、何时回收都会变成系统问题。我一直认为模型会调用工具只说明它具备推进任务的能力。任务能否稳定跑完还要看外部「Harness」如何管理状态、权限和成本。「DSec」值得看的地方就在模型之外的这一层。01 一个任务为什么需要一间自己的“工作室”先看最朴素的场景。让两个 Agent 分别修复同一份代码中的不同问题。如果它们共用工作目录甲刚改完的文件可能被乙覆盖乙运行测试时也可能读到甲尚未完成的修改。最后两边都说“完成”结果却无法归因。隔离执行环境解决的是这个边界问题每个任务在自己的空间里读写、运行和观察结果。对训练与评估尤其如此。评估要比较不同 Agent 的表现至少需要知道它们各自面对了什么环境、产生了什么结果。环境相互干扰结论就难以解释。「DSec」论文明确将目标放在大规模 Agent 训练和评估所需的隔离、有状态的执行环境上。这里的“有状态”也很关键。Agent 修改文件后再次运行命令需要看到刚才的修改如果每一步都从空白环境开始连续任务就会断裂。换句话说沙箱不只是防止任务越界的围栏还是保存任务现场的工作室。规模上来后系统要管理的是一批不断创建、暂停活动、继续运行和结束的工作室而不只是转发模型请求。02 Agent 等模型时环境在等什么一次 Agent 循环可以写成读取现场 → 请求模型决定下一步 → 执行工具动作 → 把结果交回模型。中间请求模型的时间里任务并没有结束。文件和执行结果仍要留着等下一轮动作接上。这带来一个直接的资源问题。如果沙箱始终占用与执行命令时一样的资源等待中的任务会挤占运行中的任务如果一等待就彻底销毁下轮动作又得重建现场。两种做法都可能让规模化变贵具体取舍则取决于任务形态和实现方式。我的工程判断是Agent 基础设施要区分“任务仍然存在”和“任务此刻正在消耗计算”。这不是说「DSec」采用了某一种具体的暂停算法给定材料不足以确认它的内部调度细节。这里讨论的是有状态任务在规模化时绕不开的设计问题。拿写代码作例子模型读完测试失败信息花一段时间规划修改。此时最重要的是保住代码和测试结果让下一步能接着做未必需要持续运行同等规模的计算资源。状态要延续资源占用却应按活动情况管理。03 中断之后恢复的究竟是什么长任务还会遇到中断。模型请求可能失败工具调用可能报错任务也可能需要重试。此时只保存聊天记录不够Agent 说“我已经改了配置”文件系统里究竟有没有那次修改才决定下一步能否安全继续。恢复首先要回答三个问题上一步动作执行了吗执行结果写进了哪里重新尝试会不会把同一动作做两遍例如一个 Agent 已经生成文件但在返回“成功”前连接中断。若系统直接重跑可能覆盖文件若直接跳过又可能漏掉必要的检查。这里不能把“有状态”简单理解成“永远不丢东西”。它说明执行环境能够承载连续任务具体的状态保存、故障恢复与重试语义仍需看论文和系统实现给出的证据。给定素材没有这些细节我不会替论文补一套机制。对产品团队而言这个区别很实用。设计 Agent 工作流时要明确哪些动作可以重试哪些动作需要先核对结果哪些动作必须交由更严格的权限流程处理。沙箱提供现场可靠交付还需要清楚的任务规则。04 四种执行形态为什么要放进同一个入口论文给出的另一个事实是「DSec」通过统一 SDK 接入「FnCall」、容器、「microVM」和完整「VM」。这四种形态说明Agent 的动作不会只有一种运行方式从函数调用到完整虚拟机任务需要的环境跨度很大。可以用需求来理解这种跨度。一个简单的函数动作和一个要安装依赖、写入文件、运行测试的编码任务对环境的要求显然不同。统一入口的价值是让上层工作流有机会用一致方式提交和管理任务而执行端仍能面对不同类型的环境。但“统一 SDK”不等于四种形态的隔离强度、启动成本和可用能力完全相同。给定事实也不足以推断「DSec」会怎样自动选择环境更不能据此替产品做性能排名。开发者真正该追问的是我的任务需要哪些系统能力允许什么权限任务状态要保留多久我看这类基础设施首先看接口是否让这些选择变得可管理。模型负责提出动作运行时负责让动作在合适的边界内执行。接口越统一边界越要说清楚否则“接入方便”可能掩盖任务之间的实际差异。05 38 万并发沙箱该怎么读这个数字论文作者报告其生产系统支持超过 38 万个并发沙箱、每秒创建超过 5000 个沙箱。这是理解系统目标的重要数字也必须标清来源它是作者报告不是 Henry 实测更不是独立验证结果。读这组数字时我更关心它指向的工程压力。并发沙箱数量考验大量任务同时存在时的管理能力创建速率考验新任务涌入时系统能否及时提供执行环境。两项指标回答的问题不同不能直接拿来推算单个 Agent 的任务完成速度。同样它们也不能单独证明业务效果。一个沙箱创建得快任务可能仍花大量时间等待模型、下载依赖或运行测试。一次评估能否稳定复现还取决于输入、环境状态、工具结果和失败处理。把基础设施吞吐量写成“Agent 已经规模化交付”中间跳过了太多环节。所以这篇不是一份上手评测。给定材料没有独立压测、可用性说明或价格信息。对准备选型的团队这组数字值得关注要算自己的 ROI还得带上任务时长、资源占用、失败重试和结果质量。06 产品团队应该先算哪笔账如果你的 Agent 只回答问题执行环境可能不是最先出现的瓶颈。一旦它要写文件、跑命令或在多个步骤之间保留现场沙箱就进入了产品成本和可靠性的核心。任务越多创建、等待、恢复和回收越难靠临时脚本解决。我会先把一个真实工作流画出来任务创建后做什么动作什么时候等待模型失败后从哪里继续结束时留下哪些结果。再标出每一步需要的权限和环境。这个方法不依赖「DSec」的具体实现却能帮团队判断自己是否真的需要大规模有状态沙箱。还有一条容易被忽略的边界隔离环境不能代替权限设计。我之前写《Agent越权权限边界该设在哪里》时关注的也是这个问题。Agent 能在沙箱里运行不代表它该访问的文件、网络和外部服务就可以无限放开这些边界仍要由产品明确规定。「DSec」给我的启发很直接Agent 规模化不是把模型请求数乘上去而是把每个任务的执行现场当作需要调度的对象。至于这套系统在不同业务中的效果如何仅凭目前给定的论文信息还不能下结论。结语Agent 写下一行代码之前需要一个能写入、能隔离、能在下一轮继续使用的地方。「DSec」把这个看似后台的问题推到台前。论文作者报告的规模值得研究产品能否受益仍要回到自己的任务生命周期、权限边界和成本账本。互动话题你的 Agent 工作流目前最容易卡在哪一步创建环境、等待模型、恢复中断还是控制工具权限如果觉得有价值欢迎「点赞」「在看」「转发」三连 ↓参考来源DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at ScalearXiv / Hacker News
