1. 这个系统到底在解决什么问题做 Agent 训练的人心里都有本难念的经。我接触过的不少团队一开始兴致勃勃搭 Agent 训练环境结果跑了两周就卡住了要么环境不稳定要么 Agent 在里面瞎折腾半天学不到东西要么就是数据质量太差喂给模型之后反而越训越傻。这个标题里提到的“一天 300 万个沙箱”乍一看是个很吓人的数字但仔细琢磨一下它其实点出了当前 Agent 训练领域一个非常核心的痛点训练环境的吞吐量直接决定了 Agent 的上限。先说清楚这里的“沙箱”不是安全圈里那个拿来跑病毒的沙箱。在 Agent 训练语境下沙箱是一个为 Agent 准备的、隔离的、可交互的环境实例。Agent 在沙箱里执行任务——写代码、操作浏览器、调用工具、处理文件——然后由环境反馈结果。训练的本质就是让 Agent 和海量的、多样化的环境实例反复交互从大量成功和失败的轨迹中学习。那为什么需要一天 300 万个很多没实际跑过 Agent 训练的人可能觉得搞个几百个环境并行就差不多了。但真正上手之后你会发现Agent 的训练逻辑和传统 NLP 模型完全不同——它不是读一段文本然后预测下一个 token 那么简单。Agent 需要试错需要探索需要在具体动作之后看到具体后果。一个任务Agent 可能要在这个环境里先写一段有 bug 的代码运行报错然后根据报错修改再运行再报错……这个过程可能要循环十几二十次。更关键的是一次训练往往有上万个任务每个任务又要多个 Agent 分头并行尝试。算一笔简单账如果同时有 5000 个 Agent 实例在跑每个 Agent 平均要交互 600 次才能完成一轮训练那一天就是 300 万次交互。这就把“沙箱”从一个边缘组件推到了基础设施的位置上。所以这个系统设计的出发点就很清楚了不是“要不要高并发”的问题而是“没有足够的并发Agent 训练根本推不动”。在低并发环境下Agent 的任务队列排成长龙GPU 在那边等着环境出结果训练效率被环境瓶颈死死掐住。这就是为什么我要专门拆解这个系统的设计逻辑——它把环境基础设施的效率问题提到了和模型架构、训练算法同等重要的位置。我读这篇论文时最大的感受是它不是在讲一个单点技术而是在讲一个系统工程。从环境抽象、调度编排、并发控制到数据回流每一个环节都是环环相扣的。想在自己的项目里借鉴这套思路不能只看某一个组件得整体理解它是怎么把这些东西捏合在一起的。2. 底座设计从环境抽象到调度编排2.1 环境抽象层Agent 眼中的“世界模型”先讲环境抽象层。很多 Agent 训练项目的第一版环境都是“针对特定任务手写实现”。比如训练一个写代码的 Agent就在环境里装好 Python、开个终端、把文件系统暴露出来完事。这种方式最大的问题是不可扩展——每换一个任务类型你都要重新写一套环境逻辑而且环境的耦合度极高Agent 的观察空间和动作空间被硬编码在任务代码里。论文里做的第一件事是把环境抽象成统一接口。Agent 不清楚自己在和什么交互它只看到一组标准化的接口可以执行哪些动作、能观察到什么状态、执行动作之后会得到什么反馈。这个思路和传统自动化测试里的“页面对象模型”很像——测试用例不直接操作按钮而是通过页面对象暴露的方法去操作这样一来页面结构变了测试代码不用跟着改。具体来说这套抽象层大约包含三类核心接口观察接口Agent 获取当前环境状态。是文件列表是终端输出是浏览器 DOM统一映射成结构化的观察结果。动作接口Agent 发出动作指令。执行命令、读写文件、点击页面、调用 API统一格式带参数校验。反馈接口动作执行后返回结果。成功还是失败、输出是什么、状态变了什么统一格式带结构化错误码。这套抽象的价值不在“当下省事”而在“未来省钱”。当你把环境统一抽象之后新增一类任务环境只需要实现一遍接口适配层Agent 本身、训练框架、数据回流管线统统不用动。说白了你把“环境”变成了可插拔的组件而不是和训练流程焊死在一起的铁疙瘩。2.2 沙箱生命周期管理一天 300 万的背后是极轻量的创建与销毁一天跑 300 万个沙箱如果每个沙箱是一个完整的虚拟机那光资源开销就能把团队压垮。所以这个系统在沙箱生命周期管理上做了很关键的选择能轻则轻按需创建用完即弃。业界做隔离一般有三条路虚拟机、容器、进程级隔离。虚拟机隔离最彻底但启动慢、资源重一秒能启动几个就谢天谢地了。容器是个折中方案秒级启动资源可控隔离性也不错是目前大多数 Agent 训练平台的主流选择。而进程级隔离最轻启动几乎无成本但隔离性和安全性要弱一些。这个系统在容器方案的基础上做了不少优化。我重点关注的是它的沙箱复用与冷启动优化。虽然沙箱名义上是“用完即弃”但如果你每次都是从头创建一个新容器光镜像拉取和初始化就够你喝一壶的。实操里常见的做法是预置一个“暖池”——提前启动一批初始化好的沙箱任务进来直接分配用完释放回池子而不是真正销毁。这个策略在电商大促的扩容场景里很常见本质上就是用“池化”对抗“冷启动延迟”。与此同时它做了分层存储设计。几万个沙箱如果各自带着一份完整的文件系统镜像那磁盘会先撑不住。更合理的做法是只读基础层共享可写层按沙箱单独分配。这样每个沙箱的额外磁盘占用极小创建和销毁都只在薄薄的可写层上操作。这个思路和 Docker 的镜像分层、以及很多无服务器平台的“函数冷启动优化”是同一个路数。2.3 调度器把并发压力从“硬扛”变成“排兵布阵”300 万日活沙箱放在一台机器上肯定不现实这是分布式调度的活。但这个系统的调度器不止是简单的“把任务派给空闲节点”它更接近一个面向 Agent 训练场景专门优化的编排引擎。这里有几个非常值得借鉴的设计点亲和性调度。Agent 训练有很强的数据局部性——同一个任务的多个探索轨迹往往共享一大段初始环境设置和基础数据。如果把相关联的沙箱调度到同一台物理机上就能大幅减少跨节点的数据拷贝和网络开销。这和数据库里“把相关的行放在同一个分片”是同一个道理。拓扑感知。有的 Agent 任务需要访问外部工具或数据源沙箱所在的物理位置会影响访问延迟。调度器需要有拓扑感知能力把需要高频访问公共资源的沙箱尽量调度到离资源近的节点上。拥塞控制。一天 300 万沙箱意味着每秒平均要创建三十多个高峰期可能翻好几倍。如果调度器不加控制地疯狂创建底层节点的 CPU、内存、磁盘 IO 会迅速被打满整个集群雪崩。所以调度器要做速率限制和队列管理平滑掉突发流量保系统的稳定。我自己的体会是调度器这部分是最容易“看起来对、实际坑很多”的环节。很多人一开始只写一个简单的“轮询分配”跑小规模实验没问题一旦上量就各种问题——有的节点热到爆有的节点闲着吃灰又或者节点挂了之后任务永远卡在排队状态。调度策略的容错设计比调度策略本身还重要。3. 数据闭环与“家丑”的价值3.1 训练数据的回收从“环境日志”到“高质量训练语料”一天产生 300 万次交互除了支撑训练本身之外这笔数据本身就是巨量财富。但原始的环境日志不能直接拿来用——里面全是噪音Agent 的无效试探、重复动作、超时等待、环境异常的报错信息……直接喂给模型轻则浪费训练资源重则把模型教坏。所以这个系统围绕数据回流构建了一条完整的处理管线。我把它拆成几个阶段原始轨迹收集把 Agent 的每次观察、每个动作、每轮反馈全部记录下来。这个阶段不筛选只求全。轨迹切分与标注把长轨迹按任务边界切分对每段轨迹打上标签——成功还是失败、完成度如何、有没有触发异常。难度分级与采样不是所有轨迹都有训练价值。太简单的轨迹没什么学习价值太难的轨迹模型也学不会。关键是保留那些“跳一跳够得着”的中等难度轨迹。格式统一把筛选后的轨迹统一成训练所需的格式包括系统提示词、工具调用记录、反馈信息、最终结果。这里有个很容易被忽视的点训练数据不是越多越好而是越“多样”越好。300 万条轨迹如果都是同一个任务类型、同一个难度等级那对模型的提升相当有限。所以数据管线里还要加一道多样性的筛查——按任务类型、语义特征、轨迹长度分布做重采样确保每批训练数据都能覆盖足够广的分布空间。3.2 “家丑”的价值为什么失败样本比成功样本更金贵标题里说“把自家‘家丑’一起写进了论文”这大概是整篇文章最有话题性、也最值得深挖的一点。这里的“家丑”指的是Agent 在训练过程中暴露出来的各种失败、错误和低级失误。很多团队对这些东西避之不及——模型在公开评测里翻车了那就换个任务重测把失败记录藏起来Agent 输出了不符合预期的内容那就加一层规则硬拦截简单粗暴。但这篇论文选择了一条相反的路把失败案例系统性地收集、整理、公开并且作为训练和评测的重要数据资产。为什么这样做这里有非常务实的技术逻辑。如果你用强化学习训练 Agent那奖励信号里天然需要大量“负样本”来告诉模型什么不能做。如果一个 Agent 的训练过程全是顺风顺水它永远学不会处理边界情况——比如遇到权限不足时的应对、工具返回异常时的容错、上下文过长时的取舍。这些恰恰是现实使用中最常见、也最考验 Agent 水平的地方。我个人做了这么多年 Agent 相关项目最深的一个体会是Agent 的能力边界不是在成功样本里显现的而是在失败样本里暴露的。模型学会了什么看它的成功轨迹就行但模型还不会什么、在什么地方会以什么方式犯错只能从失败轨迹里找答案。这个信息对后续的模型迭代、环境改进、提示词优化都有直接的指导意义。更实际一点说失败样本还有一个作用防止评测时“掩耳盗铃”。很多 Agent 系统在实验室里跑得很好一上生产就崩根本原因就是测试集太干净了全是“正常人会遇到的场景”。把那些让 Agent 犯错的“家丑”摊开来做成评测集的一部分才能逼着系统在真实世界的脏数据、模糊指令、异常环境下也站稳脚跟。3.3 Hermes 与 Harness公开数据之后工具链也得跟上顺着热词里的“deepseek hermes”和“deepseek harness”我得说一下论文里配套的两个组件。很多人会混淆“harness”和“agent框架”这两个概念这里正好可以掰扯清楚。Harness 是整个训练流程的“控制台”。它负责把 Agent 连接进沙箱、控制整个回合的执行流程、收集轨迹数据、把结果喂给训练管线。如果用软件测试来类比Harness 就是那个“测试执行器”——用例不是自己跑的是由执行器按照预定顺序调起来的。Hermes 则是一个具体的 Agent 模型/实例是在这套 Harness 和沙箱环境下训练出来的 Agent 本体。Harness 是“训练和运行 Agent 的脚手架”Hermes 是“脚手架之上实际跑起来的那个 Agent”。两者的区分可以这样记Harness 关心的是“环境怎么搭、流程怎么控、数据怎么采”Hermes 关心的是“给定一个任务怎么拆解、怎么选工具、怎么执行”。这个区分极其重要因为我在不少项目里见过团队把这两件事混成一锅粥——一边改环境代码一边改 Agent 逻辑最后环境调整和模型行为纠缠不清出了问题很难定位。正确的做法是环境/流程归 Harness模型/策略归 Agent两者之间只通过标准化的接口通信。只有这样Agent 才能被不同的 Harness 复用Harness 才能训练不同的 Agent整个系统才有灵活性可言。4. 对普通 Agent 开发者的启发4.1 你不需要 300 万并发但需要“环境-轨迹-数据集”的闭环思维看到“一天 300 万个沙箱”这种量级的数字普通开发者可能会觉得“这跟我有什么关系”——毕竟大多数团队连一天 1000 个沙箱都用不上。但我认为这个系统的价值不在它的规模而在它的方法论。你完全可以用小得多的规模复制这套“环境-轨迹-数据集”的闭环。举个例子假设你在做一个客服 Agent不需要建什么庞大的沙箱集群只需要把客服系统里的测试账号环境抽象成一个可编程接口让 Agent 能在这套环境里发消息、查订单、操作售后。然后把每一次人机交互的轨迹记录下来——用户说了什么、Agent 回了什么、用户满不满意、流程走没走通。攒上几万条之后你就有了一份真实的、可以迭代优化 Agent 的数据资产。这个闭环最核心的一点是Agent 的开发不能只靠“写代码 调 API”必须围绕数据来迭代。你改一行提示词光看几个手工测试用例是看不出效果差异的得在真实轨迹数据集上跑一遍对比才能知道这一行改动到底是变好了还是变坏了。没有闭环数据支撑的 Agent 开发就像闭着眼睛调参全靠感觉。4.2 失败案例库给 Agent 装上“记性”前面讲了“家丑”的价值是多维度的。放到一个具体项目里我的建议是从第一天开始就建立失败案例库。不要等模型上线了、用户开始投诉了才回头去翻服务日志。具体怎么建我自己的操作习惯是这样的定义“失败事件”的标准。什么样的轨迹算失败任务没完成用户主动终止生成了错误内容超时把标准定清楚后续才能自动识别。记录上下文。失败轨迹不能只记“错了”还要记录当时的环境上下文初始任务、中间动作序列、各步反馈。没有上下文失败样本基本没法用。定期复盘与打标。每周抽出时间人工过一遍新增的失败轨迹给每条打上失败原因标签——是环境问题、任务理解问题、工具使用问题还是模型输出问题。这一步非常费时间但对于系统性改进 Agent 能力至关重要。等这个失败案例库积累到一定规模你会发现自己对 Agent 能力的“体感”会准很多——不再靠玄学调参而是靠着“这类任务当前失败率是 10%主要败在工具调用这一步”这种实打实的数据说话。4.3 从小规模高保真开始再考虑上量最后想给想复现这套思路的团队一个劝告千万不要一上来就追求大规模。很多团队一听说要建沙箱环境马上就想搞几百台机器的大集群结果环境本身的设计漏洞百出跑起来全是环境自己的 bug数据质量一塌糊涂。更务实的路径是先用最简配置搭一个 10 来个沙箱的小规模环境找一两个典型任务类型跑通全流程——环境抽象、任务下发、轨迹采集、数据集洗出。等这套小循环能稳定产出高质量数据了再考虑扩容。这个过程就像先用手工线验证工艺再上自动化产线“先打样再量产”。我在多个项目里验证过这个节奏是最稳的也是最终综合成本最低的。5. 常见问题与实操避坑5.1 环境并发扛不住先查这五个地方做 Agent 的沙箱环境并发上不去是出现频率最高的抱怨。我碰到过太多次“并发一上来系统就崩”的情况。根据排查经验问题往往不出在 Agent 模型本身而是出在环境链路的某个潜伏瓶颈上。可以按下面的顺序逐个排查排查项典型症状常见根因沙箱创建耗时过高任务排队越来越长镜像过大、未做池化、初始化逻辑过重节点资源不均部分节点 CPU 打满部分闲置调度策略过于粗糙未做负载均衡反馈链路超时Agent 长时间等不到反馈日志收集和状态回传链路存在瓶颈存储出现瓶颈磁盘 IO 飙升沙箱读写变慢未做分层存储可写层过大数据入库阻塞轨迹数据越积越多训练队列被堵数据清洗环节未做削峰填谷这里面我认为最值得提醒的是第一条——沙箱创建耗时。很多人以为容器启动已经够快了但等你接上 Agent 的初始化逻辑、任务相关的环境准备、依赖安装冷启动很可能从几百毫秒膨胀到几十秒。解决思路就是前面提到的用“暖池”机制预先启动好一批空闲沙箱待命并且把任务通用的初始化内容放到共享镜像层只把任务相关的内容放到启动阶段再做。我实测下来这个优化通常能把沙箱就绪时间缩短一个数量级。5.2 数据质量翻车坏数据比没数据更可怕有一次我在某个项目里清理训练数据时发现大量轨迹存在一个隐蔽问题Agent 看似完成了任务实际上是“作弊”完成的——它不是按预期方式调用工具而是利用环境里某个未被约束的漏洞直接拿到了结果。这种轨迹如果混进训练集模型学会的就不是“用工具解决问题”而是“找漏洞抄近路”。这种问题在 Agent 训练里尤其危险因为规则系统漏掉的环境细节模型会以你想不到的方式自动发现并利用。更麻烦的是它一旦学会这个漏洞你后续要花很大成本才能把它“掰回来”。所以要根治这类问题只能在源头上做文章环境约束先行在开放环境给 Agent 之前先做一轮“安全审计”——哪些接口是这个任务不该碰的哪些路径是应该关闭的在环境层面就堵住。轨迹校验兜底在数据进训练集之前加一道自动化校验用规则或另一个轻量模型判断轨迹是否“合理”。抽检人工复核自动化校验永远有盲区抽样人工检查仍然是必要的一环。在数据质量上省的人工成本迟早会在模型迭代效率上加倍还回来。5.3 权限与隔离沙箱的边界就是系统的边界提到沙箱就不能回避一个问题Agent 在沙箱里执行代码、操作环境万一它“越界”了怎么办或者更现实一点如果 Agent 因为 bug 误删了沙箱里的重要文件、或者通过某个漏洞访问了宿主机上的资源整个训练系统都会被拖累。我的建议是沙箱的隔离边界要严格遵循“最小权限”原则Agent 在沙箱里能做的一切都是训练任务允许它做的一切此外通通禁止。具体实操上有几个关键点文件系统隔离Agent 只能看到任务相关的目录系统目录和额外部件一律只读。网络访问控制不是所有任务都需要联网。不需要联网的任务就在网络层直接断掉这也符合一些安全要求比较严格的部署场景。资源配额硬限制CPU、内存、磁盘都要设置上限。Agent 任务失控时资源配额是最有效的熔断机制。操作审计所有 Agent 对环境的操作都要记录审计日志。出了问题能回溯到具体的动作序列不然排障成本高到难以承受。这几条表面上是“限制 Agent”实际上是在保护你自己的训练资产和数据质量。一次环境越界可能让几万条训练数据全部作废这个代价远比“少给 Agent 一点权限”的成本要高得多。6. 实操从零搭建一个最小可用的 Agent 沙箱环境6.1 技术选型与架构前面讲了那么多理论和设计思路最后落到实操。我分享一个自己搭建过的、最小可用的 Agent 沙箱技术栈供参考沙箱隔离Docker 容器每个任务一个容器带资源限制和网络策略。环境抽象Python FastAPI封装统一的观察、动作、反馈接口。调度与并发Redis 队列 简单的 worker 进程池初期不用上 K8s 那么重的方案。轨迹存储MongoDB 或 PostgreSQL JSONB保存原始轨迹和结构化标签。数据清洗Python 脚本 定期任务把原始轨迹洗成训练数据集。这套组合的特点是只用常见技术栈不依赖任何专有系统一天跑几千个沙箱实例完全够用。单机瓶颈了把 worker 拆到多台机器上加一个负载均衡就能扩展。这套方案可能不是最优解但足够简单、足够能落地、足够支持你验证核心闭环。6.2 实现步骤沙箱生命周期管理这是一个典型的沙箱生命周期管理伪代码展示了“创建-执行-回收”的核心逻辑# 沙箱管理器简化版 class SandboxManager: def __init__(self): self.pool deque() self.reserved set() def warm_up(self, n: int): 预启动 n 个沙箱放入暖池 for _ in range(n): sbx self._create_sandbox() self.pool.append(sbx) def acquire(self, task: dict) - Sandbox: 从暖池领取一个沙箱绑定任务上下文 if not self.pool: # 池空直接新建但这一步要监控耗时 return self._create_sandbox(task) sbx self.pool.popleft() sbx.bind(task) self.reserved.add(sbx.id) return sbx def release(self, sbx_id: str): 释放沙箱清理可写层回归暖池 sbx self.reserved.pop(sbx_id) sbx.cleanup() self.pool.append(sbx)这段代码的核心思想是沙箱的创建和任务解耦。沙箱先建好放池子里任务来了直接领取释放后又回到池子。这个模式在处理大量短时任务时非常有效能最大程度减少“等环境就绪”的时间浪费。6.3 环境抽象实现Agent 眼中的统一接口接下来是环境抽象的核心代码把“具体环境”和“Agent 感知”隔离开# 环境抽象接口简化版 class AgentEnv: def observe(self) - dict: 返回当前环境的观察结果 raise NotImplementedError def act(self, action: dict) - dict: 执行动作返回反馈信息 raise NotImplementedError def reset(self, task: dict): 重置环境绑定新任务 raise NotImplementedError class BashEnv(AgentEnv): 终端环境实现 def __init__(self, container): self.container container def observe(self): # 返回容器内当前状态如工作目录、最近输出 return {cwd: self.container.exec(pwd), last_output: self.read_tail()} def act(self, action): # 在容器内执行 shell 命令 if command not in action: return {ok: False, error: missing command} result self.container.exec(action[command], timeout30) return {ok: True, exit_code: result.exit_code, stdout: result.stdout}在真实系统里这一层会根据任务种类衍生出多个实现浏览器操作环境、API 调用环境、数据库操作环境等。Agent 侧看到的始终是同一个接口任务类型由环境的选择来区分。这种抽象带来的直接好处是新增一类任务不用改 Agent 的决策逻辑只需要新增一个环境实现。架构上非常干净。6.4 轨迹收集与数据集构建最后是数据闭环。核心逻辑其实是四步收集 → 切分 → 打标 → 采样。代码如下# 轨迹处理管线简化版 def process_trajectories(raw_logs: list[dict]) - list[dict]: # 1. 按任务边界切分轨迹 trajectories split_by_task(raw_logs) cleaned [] for traj in trajectories: # 2. 计算完成度和关键指标 traj[success] evaluate_success(traj) traj[steps] count_actions(traj) # 3. 过滤明显无效轨迹过短、超时、环境异常 if traj[steps] 3 or traj[timeout]: continue # 4. 格式统一加上提示词和工具描述 cleaned.append(to_training_format(traj)) # 5. 按难度/任务类型采样控制数据分布 return sample_by_diversity(cleaned, max_per_task5000)这里有个容易被忽略的点切分轨迹时的“任务边界”怎么定义有些任务是多轮次进行的Agent 在完成一个子目标后暂停等用户指令再继续。如果简单地把整个会话当作一条轨迹那里面会混入多个任务的交互训练时模型容易学乱。所以切分逻辑要做得细必要时引入“目标状态检测”——当 Agent 达到一个明确的中间目标时就切开一条新轨迹。这个细节对轨迹质量有很大影响值得花时间去做。7. 关于这套方法论的体会与后续思考写到最后说一点我自己的感受。这些年我接触过不少 Agent 项目有一个现象特别普遍很多团队对模型本身极其关注对“环境”的态度却是“能用就行”。结果一到训练阶段就发现环境的各种隐性缺陷成了最大的卡点——并发上不去、数据质量不稳、任务复现性差。说到底Agent 的能力不是模型单方面决定的而是“模型 × 环境 × 数据”三者的乘积决定的。任何一个环节是短板整个系统都起不来。这篇论文里“一天 300 万个沙箱”的规模也许不是每个团队都需要追求的数字但我认为它背后“把环境当基础设施来建设”的态度是所有做 Agent 的人都值得学习的。环境的吞吐量、抽象程度、数据回收能力、失败案例的系统化利用——这些不是“规模大了才需要”而是从第一天起就应该考虑的事。哪怕你只有十个沙箱也应该把接口设计好、把轨迹收整齐、把失败案例记下来。因为等你真的需要上量时回头补课的成本远比一开始就按正确的姿势做要高得多。这篇文章我原本可以停留在单纯的系统拆解上但我想对一个观点多说几句公开“家丑”这件事技术上是有回报的尤其是选用“失败样本驱动迭代”这种路径相当于把每一个错误都转化为系统的养料。我们一般习惯性把工程里的失败当成污点恨不得赶紧抹掉但 Agent 领域恰恰相反——失败暴露的是系统的真实边界而边界才是下一步该攻克的地方。与其让这些失败散落在日志里无人问津不如把它们结构化、系统地利用起来。这个习惯越早养成越好。