【免费下载链接】termgrade-environments
TermGrade Environments（termgrade-environments）是一个包含 1,004 个可执行 Linux 终端任务的基准评测仓库。每个任务由一个 Docker 容器、一份指令说明和一套 pytest 验证器组成，并在离线（无网络）环境下由 6 个主流模型实测了通过率。本文是一份面向新手与终端智能体（terminal agent）开发者的完整指南，手把手教你从零编写一个任务，并让它顺利通过oracle_verified离线评分验证。
🧭 先搞懂 TermGrade Environments 的评分哲学
在动手之前，你需要理解三条铁律，它们决定了任务能否进入正式发布集：
| 铁律 | 含义 | 对写任务的人的要求 |
|---|---|---|
| 离线评分 | 评分容器以--network none运行，测试文件在评分时才注入 | 解题与测试过程全程不能联网 |
| 测试文件不进镜像 | 智能体看不到自己将被什么标准评分 | tests/只由宿主侧在评分时拷入 |
| oracle_verified | 参考解答solution/solve.sh必须在构建出的镜像中通过自己的测试 | 你的参考解必须真实可跑，且与测试逐条对齐 |
oracle_verified的含义见 README.md：参考解答在构建出的镜像内离线跑通自己的验证器，才算通过；无法确认的任务会被打上标记。在 tasks.jsonl 中，每个任务一行，包含task、checksum、gradable、split和oracle_verified字段——这就是你最终要争取的绿灯：
{"task": "task_12292_4fd005", "checksum": "ea4dc4...", "gradable": true, "split": "unseen", "oracle_verified": true}📌 仓库官方数据：66,165 个候选任务目录中只有 1,004 个（1.5%）通过了这道"参考解自证"筛选。标准不低，但标准完全透明。
📁 一个标准任务的目录结构
每个任务目录都遵循同一套布局。以 environments/task_00002_aa2b6f/ 为例：
environments/task_XXXXX_xxxxxx/ ├── instruction.md # 给智能体看的任务说明（唯一可见信息） ├── task.toml # 元数据：类别、难度、镜像名、网络模式 ├── environment/ │ ├── Dockerfile # 任务镜像（FROM dsbase-venv312:local） │ └── setup.sh # 构建期初始化：布置场景、写测试文件 ├── tests/ │ ├── test.sh # 评分入口：跑 pytest 并写 reward.txt │ └── test_outputs.py # pytest 用例（评分时才注入容器） └── solution/ └── solve.sh # 参考解答（oracle_verified 的被验证对象）- 任务说明写法参考：instruction.md（本例要求实现一个日志时间范围过滤工具
/app/querylog，明确列出了输入契约、输出契约和必须同时满足的边界情况） - 元数据参考：task.toml（
category、difficulty、docker_image、network_mode = "no-network"）
🚀 第一步：构建基础镜像（只需一次）
所有任务镜像都FROM dsbase-venv312:local，而每个tests/test.sh调用的/opt/verifier_venv/bin/pytest就烤在这个基础镜像里。因此写任务前的第一个命令是构建基础镜像：
docker build -t dsbase-venv312:local base_image/基础镜像 base_image/Dockerfile 的关键设计值得理解：
- 基于
python:3.12.13-bookworm，预装 pytest、numpy、常用核心工具（grep、sed、jq等） - 用 uv 创建独立虚拟环境
/opt/verifier_venv，固定pytest==8.4.1+pytest-json-ctrf==0.3.5 - 验证器环境与系统 Python 隔离：智能体无论怎么折腾系统环境，评分器都能离线工作——这正是
--network none评分可行的根基
✍️ 第二步：编写 environment/ 让任务"可进入"
任务镜像由两个文件组成，参考 environment/Dockerfile 与 environment/setup.sh：
- Dockerfile只做三件事：
FROM dsbase-venv312:local并设置WORKDIR /app- 执行
setup.sh布置场景（例如 setup.sh 里写入了包含非法 UTF-8 字节、坏日期等陷阱的样例日志） - 末尾清除
/tests/*.py、/solution/*和临时脚本，确保镜像内不留任何测试代码
- setup.sh负责生成任务"现场"：占位脚本、输入数据文件、依赖安装。注意它是构建期执行的，网络可用；但你的任务设计不能依赖运行期联网，因为评分时容器是断网的
一个细节：Dockerfile 还会烤入tmux和asciinema。这是为 Terminus-2 / Harbor 脚手架准备的，缺失会导致 no-network 试验直接失败（"Failed to install tmux from source"）。如果你的镜像会跑在 Harbor 下，保留这两行。
🧪 第三步：编写 tests/ 评分器
评分入口 tests/test.sh 是固定的标准件，核心只有 4 行逻辑：
mkdir -p /logs/verifier cd / /opt/verifier_venv/bin/pytest --ctrf /logs/verifier/ctrf.json /tests/test_outputs.py -rA > /logs/verifier/pytest.out 2>&1 rc=$? if [ $rc -eq 0 ]; then echo 1 > /logs/verifier/reward.txt; else echo 0 > /logs/verifier/reward.txt; fi exit 0也就是说：pytest 全绿 →reward.txt写入 1。你真正要写的是 tests/test_outputs.py，写测试时有三条实践：
- 测"可观察结果"，不测实现：通过
subprocess调用被测产物、断言 stdout / 退出码 / 文件内容（本例测试逐个覆盖边界：START==STOP无输出、时区偏移、跨午夜日期进位等） - 每个断言都要能在断网环境跑通：不要假设能 pip install、能访问外网服务
- 测试数据由 setup.sh 在构建期生成，评分时随
tests/一起注入的只有测试代码本身——若测试需要数据文件，确保这些数据在setup.sh阶段就已写入镜像
🛠️ 第四步：编写 solution/solve.sh（oracle 的本体）
参考 solution/solve.sh：它用cat > /app/querylog << 'PYEOF'的方式生成一个完整可运行的工具，覆盖 instruction.md 中的每一条契约。
写参考解的要点：
- 逐条对照
instruction.md的边界情况清单逐条实现，参考解必须"满分"，而不是"大致能跑" - 只用镜像内已存在的工具与库；需要额外 Python 包时，在
setup.sh里离线预装或走基础镜像已装内容 - 参考解本身就是评分基线：它通不过的地方，你的任务就是坏的
✅ 第五步：复刻 oracle_verified 离线评分流程
最后一步，在本地完整复刻官方评分流程。以下命令序列来自 README.md 的 Quick start，把$T换成你的任务目录即可：
T=environments/task_XXXXX_xxxxxx docker build -t mytask:local $T/environment c=$(docker run -d --network none mytask:local sleep 600) docker exec $c sh -c 'mkdir -p /tests /logs/verifier' docker cp $T/tests/. $c:/tests/ docker cp $T/solution/solve.sh $c:/solve.sh docker exec $c sh -c 'cd /app && bash /solve.sh' docker cp $T/tests/. $c:/tests/ # 恢复 pristine 测试，与官方评分一致 docker exec $c sh -c 'bash /tests/test.sh' docker exec $c cat /logs/verifier/reward.txt # 期望输出: 1 docker rm -f $c⚠️ 最容易踩的三个坑：
- 忘了
--network none：本地跑通了不代表离线跑通，你的任务可能在评分时因隐式联网而挂掉 - 忘了第二次拷贝 tests/：参考解答可能改写或删除测试文件，官方评分会用宿主侧的干净副本恢复后再跑
test.sh，你必须以同样方式验证 - reward.txt 不是 1 时只看 pytest 输出不够：
test.sh永远exit 0，成败只看/logs/verifier/reward.txt，排障请打开/logs/verifier/pytest.out
🔍 收尾：核对元数据与发布字段
全部通过后，把任务登记进索引与元数据：
- tasks.jsonl：每任务一行，
oracle_verified: true即你在上面流程中的绿灯 - labels.jsonl：每（任务，模型）一行，记录
pass_rate、band、n_counted、k——发布集里 6 个模型共 6,024 条实测标签都在这里 - run_config.yaml：官方评分的模型配置（scaffold 为 terminus-2 via Harbor、离线评分、各模型的
k次采样与 reasoning 开关），可作为你自评时的对照基线 - task_source.jsonl：以 JSONL 形式内联存放全部任务的指令、测试、参考解与 Dockerfile，方便不克隆目录树也能审阅单个任务
🎯 总结：一份任务通过 oracle_verified 的最小清单
| # | 检查项 | 不满足的后果 |
|---|---|---|
| 1 | 基础镜像dsbase-venv312:local已构建 | pytest 找不到，评分必挂 |
| 2 | setup.sh在构建期准备好全部输入数据 | 离线评分时无数据可用 |
| 3 | 镜像内不含任何测试文件 | 违反"评分标准对智能体不可见"原则 |
| 4 | test.sh使用/opt/verifier_venv/bin/pytest并写reward.txt | 评分器读不到结果 |
| 5 | 参考解在--network none容器中通过自己的全部测试 | oracle_verified无法为 true |
只要按"写指令 → 布置环境 → 写测试 → 写参考解 → 离线自证"的顺序推进，并用 README 中的命令序列做最终验收，你的终端任务就能像仓库里的 1,004 个任务一样，稳稳拿到oracle_verified: true的发布资格。
【免费下载链接】termgrade-environments
相关推荐
Nomad 插件系统开发指南：如何从零编写你的第一个自定义任务驱动
Nomad 插件系统开发指南：如何从零编写你的第一个自定义任务驱动 Nomad 是一个易用、灵活且高性能的工作负载编排器，支持部署微服务、批处理、容器化与非容器
任务调度云原生运维后端TermGrade Environments run_config.yaml 完整配置指南：reasoning 标志与 max_tokens 背后的两个评分陷阱
TermGrade Environments run_config.yaml 完整配置指南：reasoning 标志与 max_tokens 背后的两个评分陷阱
SDXL Inpainting 0.1 快速上手：10行Python代码完成你的第一次AI图像局部重绘
SDXL Inpainting 0.1 快速上手：10行Python代码完成你的第一次AI图像局部重绘 SDXL Inpainting 0.1 是 Stabil
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
