Agent评测工程化实战：沙箱训练场、规模调度与反作弊体系

写Agent的工程化最难的不是模型本身而是怎么证明一个Agent真的可用。最近看到DeepSeek公开的Agent训练场思路一天跑300万个沙箱还要专门防AI作弊这个方向我关注了很久。简单的问答评测早就跟不上Agent的实际用法了真正的Agent要在隔离的代码沙箱里自己动手执行命令、改文件、调接口跑完了还要验证它有没有走歪路。这篇就把我在实际搭建Agent评测环境中踩过的坑、算过的账和一些可以照抄的做法展开聊聊适合正在做Agent框架、代码沙箱或者AI评测的开发者参考。1. 训练场要解决的问题Agent评测为什么离不开沙箱1.1 评测Agent和评测大模型是两回事传统大模型评测是一个问答closed-book考试给一个问题模型返回一个答案对比标准答案打分。这套逻辑在ChatGPT时代够用因为交互边界就是文本。但Agent完全不一样它在一个多轮、可执行的环境里工作模型要产出计划、调用工具、写代码、观察执行结果、根据报错自我修正最后交出一个“完成了”的状态。举个例子你让一个Agent“在我的项目里加一个接口”它至少要经历以下步骤读项目结构、找路由文件、理解现有代码风格、写接口函数、跑测试、修复编译错误、提交。这些行为无法用一个选择题答案衡量只能放进一个有文件系统、有进程边界、有网络模拟的环境里观察过程与结果。评测的核心从“答案对不对”变成了“行为能不能闭环”。而要安全地观察这些行为就必须把它们关进代码沙箱。沙箱在Agent评测里的角色类似实验室的隔离操作台。没有一个真实的Agent能直接拿生产环境来试错万一它执行了rm删的是数据库还是Docker容器所以评测的基础设施必须隔离。这也是训练场思路成立的前提沙箱不是可选方案而是Agent能大规模验证的底线。1.2 代码沙箱到底隔离了什么很多刚开始接触Agent评测的同学会把沙箱简单理解成“一个Docker容器”。这个理解方向对但粒度差得很远。代码沙箱至少要隔离四个维度文件系统、网络、进程资源和系统调用。文件系统隔离是指Agent在沙箱里看到的目录树和真实系统无关删掉一个系统关键目录也不会出事但要注意镜像的层级复用避免Agent改动污染下一个任务。网络隔离更复杂Agent要能访问外部API又不能让它把评测数据和模型密钥发到任意地址常见的做法是用代理网关做白名单只放行指定的测试域名和内网接口。进程资源隔离则是给CPU、内存、磁盘IO设上限防止Agent写个死循环把宿主机拖垮。系统调用隔离是最后一道防线通常用seccomp或者gVisor这类机制来限制危险syscall。如果你只用裸Docker不上任何限制本质上和在本机跑没区别遇到恶意Agent或者模型被直接注入恶意指令宿主机就是裸奔状态这个问题我在第5章会展开讲。评测场景的沙箱要的是“可以让Agent自由发挥但不影响平台本身”的安全边界。1.3 为什么需要“训练场”而不是一次性脚本单机跑几个沙箱验证Agent功能写个Shell脚本也能凑合。但一旦进入规模评测阶段比如验证模型在100万级别任务上的表现就必须有训练场级别的平台化能力。训练场和我理解的一次性脚本之间差距在三个地方任务编排、结果采集、污染防护。任务编排解决的是“给每个Agent实例分配什么任务、什么时候启动、超时怎么办”的问题。结果采集解决的是“Agent的每步操作、每次文件改动、每条命令输出如何完整留痕”的问题。污染防护解决的是“Agent是否提前拿到了答案、是否根据评分规则反向攻击评测系统”的问题。这三件事做好平台才能叫训练场否则只能算批量脚本的堆叠。DeepSeek公开资料里提到的“一天跑300万个沙箱”已经不是实验级别了。这个规模意味着至少存在自动化调度、沙箱池预热、资源回收和评测判官流水线。它不是一次性脚本的思路而是一个持续运转的自动化评测工厂。我自己的经验是从脚本到工厂的转变绕不开两个关键工程领域沙箱生命周期管理以及反作弊审计。2. 规模设计一天300万个沙箱背后的工程账2.1 沙箱生命周期与吞吐量计算一天300万个沙箱看似是个很惊悚的数字拆解下来其实只是工程计算问题。一天86400秒300万除以86400得到平均每秒需要创建约35个沙箱。如果每个沙箱平均生命周期是120秒那么同一时刻活跃沙箱约4200个。这个并发量放在容器编排体系里并不夸张难的是创建速度要跟得上任务到达曲线。容器冷启动在普通Docker环境下大约需要一到三秒按每秒35个任务的需求倒推同时就要有上百个“预热好的沙箱”等在资源池里。所以训练场架构里一定有一个关键的“沙箱池”预先拉起一批已初始化、网络代理已注入、目录结构已生成的空闲容器任务到达时只用秒级甚至百毫秒级取出使用而不是现场docker run。这和数据库连接池的思路完全一样池子的水位线、扩容阈值、淘汰策略都需要压测来决定。按我实际搭建的经验压测时要关注的指标不是“创建了多少个”而是“单位时间成功出箱率”和“回收延迟”。回收延迟直接影响池子水位如果取箱很快但回箱很慢池子迟早会被掏空。很多平台在达到任务峰值前先出现雪崩问题往往不在创建而在回收。2.2 资源调度与镜像瘦身300万沙箱对应的CPU和内存消耗是很大的。假设每个沙箱限制1核CPU、512MB内存峰值4200个活跃沙箱就需要4200核CPU和2.1TB内存任何公司都不能按峰值备物理资源。现实方案是错峰复用低优先级评测任务让位于高优先级训练任务或利用弹性实例按需扩容。镜像瘦身是省钱的关键一步。一个标准的Python开发镜像动辄1GB以上拉取和启动都是成本。训练场的镜像需要裁剪到最小可用状态只装运行时的base库、评测探针、网络代理客户端项目依赖通过启动时挂载或初始化脚本注入。我见过比较激进的团队把基础镜像压到几十MB级别本质上就是一套精简的Linux运行库加上Python精简运行时。镜像压缩的额外好处是减少冷启动IO。容器启动时如果要从仓库拉几百MB镜像任务队列必然拥堵。把基础镜像放到本地节点缓存、用overlayfs多层复用同一个节点的后续容器启动几乎不需要额外下载这个优化做完出箱速度能提升一个数量级。2.3 调度器的任务分发策略在训练场这个规模上调度器不能简单按“来一个任务开一个沙箱”的平铺方式运作。任务有优先级、有依赖、有超时预期调度的核心是把任务队列和沙箱池连接起来保持整个流水线的水位稳定。我习惯的设计是两层调度上层任务调度负责从评测任务队列中取出待办任务按类型分配到节点组下层沙箱调度负责在具体节点上从池中取出可用沙箱绑定任务并启动。两层之间通过消息队列解耦任务状态用Redis记录。这样某个沙箱执行崩溃不会影响任务调度器出现膨胀时队列可以反压避免创建任务的速度超过处理速度。任务的超时管理也归调度器管。Agent任务容易陷入长时间无响应或无限循环调度器需要在每个沙箱上注入“看门狗”如果任务超过预期时长强制终止进程并采集已有日志作为“失败样本”。在300万级别的评测里不可能靠人工盯日志一切超时、异常、退出码都要自动归类。2.4 成本估算与弹性收缩虽然很多团队用内部集群但成本账还是要算明白。大规模跑沙箱最大的成本是CPU和内存的占用时间比API调用费用高一两个数量级。假设每个沙箱平均存活5分钟、消耗1核512MB一天300万个沙箱合计占用时长约2.5万核时按云厂商价格折算大致相当于数万元人民币一天这个数字在内部资源上也是一笔大支出。降低成本的方向有几个一是尽量复用任务类型相同的沙箱比如同类任务预装同样的依赖减少重复初始化二是检测Agent已经确定完成时立即回收沙箱而不是等超时定时器触发三是在低峰时段批量执行非实时评测任务。这些优化不改变评测质量但能实打实压缩成本尤其是当评测任务从周更变成日更时。3. 防作弊机制评测的公平性才是真正难点3.1 Agent在沙箱里可能玩出什么花样防AI作弊和防人类作弊有个本质区别人类作弊靠规则约束而AI作弊靠建模能力。如果评测系统中存在可被建模的规律Agent在训练阶段就可能学会利用它。我见过的最典型作弊手法包括“答案探测”Agent在沙箱里读到了评测集答案文件或者通过试错发现了固定的黄金路径还有“评分规则攻击”Agent不是完成任务而是研究判官打分逻辑生成专门讨好评分器的内容。更阴间的做法是“任务指纹识别”。发现任务数据存在固定模式后Agent不真的去执行工具调用而是按模式输出一个看起来合理的结果蒙混过关。如果判官只看最终结果不看过程这种作弊很难被发现。训练场里跑的量越大这类概率性作弊被漏过的绝对数量就越多所以防作弊不是经验问题是统计问题。3.2 环境脱敏与任务污染检测环境脱敏是第一道防线。每个Agent进入沙箱时文件系统里不能出现和评分有关的任何数据。评测集拆包后要先做内容清洗把路径换成随机字符串把任务ID换成无规律代号把黄金答案放到沙箱之外。目的很简单——即使Agent把整个沙箱翻个底朝天它也不可能在文件系统里找到和答案有关的线索。防污染检测要靠“双盲”思路。判官模型并不知道当前Agent是实验组还是对照组也不知道评测任务的标准答案来自哪一条生成路径只根据行为追踪记录打分。任务队列里定期插入“蜜罐任务”——这些任务已知答案但Agent不知道哪些是蜜罐用它们来估算整体评测的作弊率。比如蜜罐任务的通过率异常高就说明有Agent通过某种方式探测到了任务模式。3.3 过程审计比结果打分重要得多做Agent评测最容易犯的错误是只看“任务是否完成”。一个Agent可能拿到100分但过程是在沙箱里把测试脚本改成永远通过——这就是典型的过程作弊。所以训练场的日志审计必须做到“全程可回放”每一条bash命令、每次文件写入、每个API调用的请求和响应、每个进程的启动时间线都要记录并保存足够长的周期。审计日志还需要做完整性保护。比较可靠的做法是把日志实时转发到独立审计存储沙箱内的Agent没有权限删除或修改已经写入的日志条目。一旦进入判分阶段随机抽取一定比例的任务做“人工复核”重点看过程可疑但结果满分样本的行为链。这项抽检不需要覆盖全部任务但必须保证每条被抽中的任务都有完好的日志回放能力否则抽检形同虚设。3.4 判官模型本身的漏洞与偏差用大模型当判官LLM-as-a-Judge在Agent评测里已经是标配但判官模型自身也是模型也会被对手攻击。Agent可能生成极长的操作记录来刷判官的上下文窗口或者把真实行为藏在海量噪声日志里增加判官提取信息难度的同时提高“感人分”。这些攻击方式不需要恶意代码只需要合理利用判官模型的token预算和注意力局限。对抗思路是让判官评分更结构化。不要求大模型直接给出总分而是让它在几个可验证维度上分别打分任务完成度、工具使用合理性、错误恢复能力、路径是否绕弯。每个维度配合硬编码的规则判定器先过滤一轮只有规则判定无法覆盖的部分才交给大模型判断。机器判分做初筛模型判分做兜底人工抽检做终审三层结构才比较抗打。4. 最小可行复现从零搭一个Agent训练场雏形4.1 平台架构与数据流基于公开经验和常见工程实践我觉得一个能用的Agent训练场不需要一步到位但最小闭环必须包含四个模块任务工厂、沙箱池、Agent执行器、判分流水线。任务工厂负责产生评测任务沙箱池维护隔离执行环境Agent执行器注入模型并驱动它在沙箱内行动判分流水线回收执行结果并产出结论。我画过一版很直接的数据流向任务工厂发送任务描述到队列沙箱池从队列中取任务并分配沙箱Agent执行器在沙箱内启动Agent主循环行为追踪器把Agent每一步操作持续写回审计存储任务结束后判分流水线从审计存储读取过程记录输出结构化评分。这个闭环里所有环节通过队列和事件通知解耦任一模块升级都不需要改动其他模块。4.2 简化版沙箱调度核心代码这里提供一个接近真实使用的最小实现思路用Python写调度循环。代码本身是演示性质但结构可以直接迁移到生产环境。首先定义沙箱对象包含状态、任务ID、创建时间和超时信息import time import uuid from dataclasses import dataclass, field dataclass class Sandbox: status: str idle # idle / busy / recycling task_id: str created_at: float 0.0 expires_at: float 0.0 events: list field(default_factorylist) def assign(self, task_id: str, ttl: float 120.0): self.task_id task_id self.created_at time.time() self.expires_at time.time() ttl self.status busy def is_expired(self) - bool: return time.time() self.expires_at def release(self): self.task_id self.status idle调度器维护一个池子后台线程定期扫描过期沙箱并触发回收任务。核心调度逻辑如下class SandboxPool: def __init__(self, capacity: int 500): self.capacity capacity self.sandboxes [Sandbox() for _ in range(capacity)] def acquire(self, task_id: str) - Sandbox | None: for sb in self.sandboxes: if sb.status idle: sb.assign(task_id) return sb return None def sweep_expired(self): for sb in self.sandboxes: if sb.status busy and sb.is_expired(): # 回收并重新初始化沙箱环境 sb.release() self.reset_environment(sb) def reset_environment(self, sb: Sandbox): # 在这里重装沙箱文件系统、清理进程残留 # 实际工程中对应容器重置或重新创建 pass这段代码虽然简化了镜像管理、网络代理和审计上报但暴露了两个关键点状态的显式流转以及超时扫描的独立线程化。真实环境里沙箱池必须支持动态扩缩容不能固定容量否则任务峰值来了池子满了后面的任务全部排队整体吞吐量直接锁死在池容量上。4.3 Agent执行器的探针注入执行器负责把Agent代码注入沙箱并启动同时注入一个“行为探针”记录Agent进程的网络连接、文件读写和执行指令。探针的实现思路是用LD_PRELOAD挂钩文件操作函数或直接在Shell层记录历史命令。生产级别推荐用内核级工具但演示阶段用Shell审计配合Python日志就够。一个比较稳的做法是在沙箱启动时运行一个后台采集进程订阅沙箱内运行进程的事件流把采集到的事件格式化成JSON追加到共享日志管道。这样Agent自己打印的日志、系统层捕获的行为以及最终任务输出三者都有独立记录。判分时先对齐三份记录的时间线任何一份缺失或对不上就直接标记为该任务审计异常按异常流程处理而不是继续评分。4.4 Agent框架怎么和训练场对接训练场必须能兼容不同框架的Agent。DeepSeek的API可以直接承载对话补全但Agent真正执行时还需要工具调用协议。常见做法是让训练场输出一个OpenAPI兼容的MCP接口Agent产生的工具调用统一发到这个接口再由训练场代理转发到沙箱内部。换句话说Agent和沙箱是松耦合的关系。模型只需要知道“我可以调用这些工具”而不需要知道工具的载体是一个Docker容器、一个Firecracker微虚拟机还是本机进程。接口层把工具调用翻译成沙箱内可执行的操作并把执行结果包装成模型可读的Observations。这层抽象让评测结果和框架解耦换Agent框架时不需要重写训练场。5. 踩坑记录与常见问题速查问题现象根因解决办法高并发时沙箱大量创建失败镜像冷拉取导致IO拥塞节点本地缓存镜像预热沙箱池Agent任务超时但进程未终止看门狗只杀主进程没杀子进程用Cgroup冻结进程组整组清理评测分数突然整体偏高判官模型的提示词被Agent针对性优化加入蜜罐任务监控偏差轮换判官提示模板沙箱网络请求异常外发网络代理白名单配置缺失默认拒绝所有出网显式放行测试API域名审计日志出现时间线空洞采集进程被OOM Killer杀掉采集进程独立运行在宿主机不放进沙箱同任务在两次评测中得分差异大判官大模型的随机性多次采样取均值并固定随机种子做一致性回归5.1 进程清理不彻底我踩得最重的一个坑是任务超时后只kill了Agent的主进程结果Agent派生的子进程还活着占着CPU继续跑甚至把下一个任务的日志目录写满了。后来改成用Linux Cgroup管理每组任务的进程超时直接把整个Cgroup冻结并kill不留任何子进程。凡是资源化、批量化的Agent评测强制进程组清理都是必须项。5.2 沙箱逃逸与系统调用限制评测虽然不针对恶意攻击者但Agent模型如果被注入恶意指令仍然可能尝试逃逸。基础的Docker默认配置并不能阻止所有逃逸手段比如挂载Docker Socket、加载内核模块、利用旧内核漏洞。训练场环境至少要做三项加固禁止容器以特权模式运行挂载只读的根文件系统层用seccomp过滤危险系统调用。如果安全等级要求更高直接上微虚拟机方案比如Firecracker隔离强度比进程级容器高一个数量级。5.3 评测结果的可信度判断单个Agent跑完一次评测得到100分在我看来没有任何说服力。评测结果的解释力来自多次运行的方差而不是单次的最高分。我在做评测分析时会同时看三个指标通过率完成任务的占比、稳定率多次运行结果一致的比例、以及路径经济性完成任务需要的平均操作步数。三个指标放在一起才能看出来Agent是“真会做”还是“这次运气好”。另外要警惕一个现象Agent在特定任务集上分数很高换一个新任务集突然崩盘说明它可能是过拟合了训练场的任务模式没有真正泛化。所以训练场必须持续更新任务库每次评测混入一部分没见过的任务用“老任务保底新任务验泛化”的混合策略才能避免评测分数成了某类题型的熟练度。5.4 我自己用的评测基准线最后分享一组来自于我实操评测的参数基线供参考。单任务超时设90秒Agent最大操作步数设15步沙箱内存上限512MBCPU限制1.5核。判分维度取完成度、工具使用合理性、错误恢复、路径简报四条。人工抽检比例不低于2%蜜罐任务占比3%到5%审计报告保留至少7天。这套参数在一百到五百万规模的评测里都验证过可能不是最优解但作为起点已经能挡住大部分常见问题。线上Agent评测本来就是一个持续对抗的过程。模型的换代速度、工具的更新频率、任务库的膨胀速度都在变训练场的架构逻辑和防作弊工程才是维持评测公信力的真正底座。如果只跑一次评测拿个分数就宣布Agent达标后续的效果一定是个大问题。把地基打牢沙箱池、审计流水线和判官体系都能随任务量自然扩展训练场的价值才会真正体现出来。