代码评测的沙箱是怎么搭的？每一步都讲透

模型生成的代码不能直接在自己的电脑上点运行，沙箱就是给这些代码准备的隔离考场：让代码在受控环境里跑起来、判出对错，同时保证主系统毫发无伤。AI 大模型的代码能力评测，成色如何全看这套沙箱搭得稳不稳。

为什么必须隔离执行

模型写出的代码是不可信输入，和陌生网友发来的附件一个性质。它可能死循环把机器拖垮，可能疯狂读写文件，可能联网乱发请求，甚至删除目录。评测又恰恰需要真实执行才能判分——只看代码长得对不对，永远测不出真实水平。所以唯一稳妥的方案是隔离：给每段代码一个一次性的、资源受限的、无敏感数据的小环境，跑完即销毁。隔离并非为了防模型使坏，重在给不可预测的行为兜底。

沙箱内部的执行链路

一条完整链路五步走。第一步起容器：为每次评测开一个全新容器，文件系统只放本题材料，网络默认关闭。第二步装配：写入模型生成的代码与测试用例，设定运行语言与版本。第三步执行：启动进程，同时套上资源上限——CPU 时间、内存、进程数、可写磁盘各设阈值，超限即杀。第四步收集：抓取输出、退出码、运行时长。第五步销毁：容器整体丢弃，不留任何残留。进来的是一段代码加一组用例，出去的是结构化的运行报告，DeepSeek 与扣子的代码评测实践都遵循类似的隔离执行思路。

五步里每一步都有一处必须钉死的设置。

用例和超时怎么定

用例决定判分质量。基础用例覆盖题面给定的样例，边界用例卡空输入、极值、异常格式，随机用例用程序批量生成防止硬编码蒙混。判分等级也由用例撑起：全过满分、部分通过按组给分。超时设置要有梯度：普通题给几秒，搜索类、大量输入的题放宽到十几秒，但必须有上限，因为死循环是常态而非意外。超时值本身要写进评测配置并保持稳定，改一次超时，历史成绩就不与可复现的要求兼容了。

沙箱搭建检查单

• 每次评测用全新容器，网络默认关闭
• CPU、内存、时长设资源上限并记录在配置里
• 用例分基础、边界、随机三组
• 运行报告与原始输出留档备查

跑完之后的整理动作

沙箱跑完只是拿到原始数据，后续三件事决定这份数据有没有用。判分归档：用例结果汇总成分数，归因到「编译失败、超时、答案错误」等类别，便于分析短板在哪。结果复核：抽样核对判分脚本，特别是超时边缘的运行，防止误杀。数据回流：把高频失败模式整理成新用例，反哺题库。代码评测得出的分数如何与其他维度合看，可参考数学答案判分的口径设计，结合大海捞针的成绩拼出完整能力画像；代码评测若扩展到多步任务执行，环境搭建思路可参照Agent 评测的环境，题库长期维护的原则则与安全评测的题库相通，都要持续更新、防止过时。

沙箱方案选型上也有梯度。轻量场景用受限子进程加资源限额就够，启动快、开销小；正规评测用容器隔离，兼顾速度与安全；涉密代码或高价值环境上虚拟机，隔离最彻底但拖慢节奏。无论选哪档，日志与监控都不可省：进程级日志帮你判断超时发生在哪一步，资源曲线帮你区分「算法慢」和「实现笨」。沙箱是纯工程活，没有玄学，把每次故障都沉淀成一条新的限制规则，环境会越跑越稳。

代码评测沙箱快问快答三则

• 沙箱一定要用容器吗？：容器是主流方案，虚拟机更重但隔离更彻底，小型评测用受限子进程加资源限制也可以起步。
• 断网会不会影响正常题目？：绝大多数算法题不需要网络，确需联网数据的题目应把数据预先装进容器，而不是开放外网。
• 同一道题跑多次结果不同怎么办？：先查时间依赖与随机数种子，把不确定性钉死后仍不稳的，属于题目本身有毛病，回炉改题。