背景描述
【AISBench】【精度测评】Terminal-Bench 2 容器化终端任务统一接入与可复现评测闭环建设
需求背景 ：Terminal-Bench 2 （terminal-bench-2）在容器化终端环境 中评测 Agent 完成真实工作流（安全修复、数据处理、系统调试、模型训练等）。样本由 环境镜像 + 任务指令 + 验证脚本 定义；评测需在资源与超时约束下运行容器并以测试脚本判定成败。AISBench 虽有任务注册与落盘能力，但缺少 TB2 类“容器内操作 + 测试判定”的统一接入，导致口径不统一、交付成本高、审计不完整。
需求描述 ：在 AISBench 中新增 TB2 标准接入与评测，覆盖“任务发现/加载 → 容器环境编排 → Agent 执行 → 验证脚本判定 → 指标汇总 → 样本审计”。
任务形态参考 ：仓库内 terminal-bench-2/* 每任务含 instruction.md、task.toml、tests/test.sh / tests/test_outputs.py、environment/ 或外部 docker_image；验证常写入 /logs/verifier/reward.txt/logs/verifier/ctrf.json
验收标准 ：
固定子集可在 AISBench 统一入口下完成执行与判定，产出结构化结果与样本级审计。
判定口径：以任务 tests/test.shreward （/logs/verifier/reward.txt）为最终通过/失败依据；保留 CTRF （ctrf.json）用于复盘。
运行可复现：任务版本、镜像 tag、资源与超时、路径可追溯。
方案设计
整体设计思路
TB2 的“样本”为任务目录 。AISBench 需将目录元数据标准化为统一结构，再交给容器编排与 Agent 执行器；评测器只认 verifier 产物 ，避免自行 reinterpret 测试结果。
sequenceDiagram
participant AIS as AISBench
participant Task as 任务目录
participant C as 容器
participant A as Agent执行
participant V as tests或test.sh
participant L as 或logs或verifier
AIS->>Task: 发现与加载task.toml
AIS->>C: 启动docker_image或构建Dockerfile
C->>A: Agent在容器内执行
A->>V: 完成任务动作
V->>L: 写入reward与ctrf
L->>AIS: 收集判定与日志
AIS->>AIS: 汇总指标与审计
Loading
方案范围：Terminal-Bench 2 数据集接入与测评能力建设
任务发现与字段标准化（需求拆分项汇总：任务加载）
task_id / task_path；instruction（instruction.md）。环境：docker_image 或 environment/Dockerfile；cpus、memory、storage、build_timeout_sec。
超时：agent_timeout_sec、verifier_timeout_sec。
验证：verifier_script（默认 tests/test.sh）；产物 /logs/verifier/reward.txt、/logs/verifier/ctrf.json。
元数据：difficulty、category、tags、作者等（task.toml 的 [metadata]、[agent]、[verifier]、[environment]）。
容器执行与编排（需求拆分项汇总：容器编排）
启动方式：拉取 docker_image 或从 Dockerfile 构建。
挂载：任务工作目录、结果路径、/logs 可收集
Agent 输出协议：任务要求的关键产物路径（如 /app/results.txt）在文档与校验中明确。
资源与隔离：task.toml 限制与并发隔离策略（避免任务间污染、日志覆盖）。
评测判定（需求拆分项汇总：reward/CTRF 判定）
最终以 /logs/verifier/reward.txt 数值（0/1）为准 。保留 ctrf.json 作为测试级审计（失败用例、栈、耗时）。
超时/环境失败分类：镜像拉取失败、容器启动失败、依赖安装失败等，错误信息可观测。
指标与审计（需求拆分项汇总：汇总与审计落盘）
汇总：pass rate （可选加权/分层）。
分组：按 category、difficulty、tags。
样本级：task_id、判定、reward/CTRF 路径、关键日志路径、失败类型（timeout / env_error / verifier_error 等）。
最小验收集与复现（需求拆分项汇总：验收集与复现约束）
固定子集策略（排序取前 N 或固定 seed）；固定镜像 tag 与仓库 commit；固定资源与超时；并发与隔离策略。
建议验收集覆盖多个 category（如 security、model-training、data-processing）。
外部参考 ：TB2 官方可用 Harbor（harbor run --dataset terminal-bench@2.0 ...）；AISBench 侧须保证行为、判定口径、审计产物 清晰一致。
影响范围
强依赖 Linux + Docker ；任务脚本可能在容器内安装依赖（如 uv、pytest），需文档化典型镜像体积与构建时间。
使用说明
前置 ：Docker 可用；磁盘与内存满足最差任务配置；Agent 执行器需支持在容器内非交互或伪终端运行（按所选 Agent 集成方式）。配置 ：任务子集列表或筛选规则、镜像拉取策略、资源上限、超时、并发数、日志宿主机落盘根目录。判定 ：禁止绕过 test.sh 自行判定 pass/fail；除非文档明确“调试模式”且不计入正式评测。复现 ：每次运行记录任务仓库 commit 、镜像 digest 、AISBench 版本。
测试设计
单元测试
task.toml 解析与各字段默认值；缺失必填字段报错。reward 解析：mock reward.txt 为 0/1 与非数字异常。
集成测试
固定最小子集：全链路 infer（或 mock Agent）+ verifier；收集 reward 与 ctrf。
失败注入：镜像不存在、超时，验证失败类型与审计字段。
端到端 / 复现
同输入同配置多次运行判定一致；差异可通过日志解释。
依赖缺失时用户文档中的修复指引可验证（检查清单）。
需求拆分验收点
任务加载、编排约定、reward/CTRF 判定、汇总审计、最小验收集（见内部需求拆分）。
背景描述
【AISBench】【精度测评】Terminal-Bench 2 容器化终端任务统一接入与可复现评测闭环建设
需求背景：Terminal-Bench 2（
terminal-bench-2）在容器化终端环境中评测 Agent 完成真实工作流（安全修复、数据处理、系统调试、模型训练等）。样本由 环境镜像 + 任务指令 + 验证脚本 定义；评测需在资源与超时约束下运行容器并以测试脚本判定成败。AISBench 虽有任务注册与落盘能力，但缺少 TB2 类“容器内操作 + 测试判定”的统一接入，导致口径不统一、交付成本高、审计不完整。需求描述：在 AISBench 中新增 TB2 标准接入与评测，覆盖“任务发现/加载 → 容器环境编排 → Agent 执行 → 验证脚本判定 → 指标汇总 → 样本审计”。
任务形态参考：仓库内
terminal-bench-2/*每任务含instruction.md、task.toml、tests/test.sh/tests/test_outputs.py、environment/或外部docker_image；验证常写入/logs/verifier/reward.txt与/logs/verifier/ctrf.json。验收标准：
tests/test.sh产出的 reward（/logs/verifier/reward.txt）为最终通过/失败依据；保留 CTRF（ctrf.json）用于复盘。方案设计
整体设计思路
TB2 的“样本”为任务目录。AISBench 需将目录元数据标准化为统一结构，再交给容器编排与 Agent 执行器；评测器只认 verifier 产物，避免自行 reinterpret 测试结果。
方案范围：Terminal-Bench 2 数据集接入与测评能力建设
任务发现与字段标准化（需求拆分项汇总：任务加载）
task_id/task_path；instruction（instruction.md）。docker_image或environment/Dockerfile；cpus、memory、storage、build_timeout_sec。agent_timeout_sec、verifier_timeout_sec。verifier_script（默认tests/test.sh）；产物/logs/verifier/reward.txt、/logs/verifier/ctrf.json。difficulty、category、tags、作者等（task.toml的[metadata]、[agent]、[verifier]、[environment]）。容器执行与编排（需求拆分项汇总：容器编排）
docker_image或从 Dockerfile 构建。/logs可收集；保证 verifier 可写。/app/results.txt）在文档与校验中明确。task.toml限制与并发隔离策略（避免任务间污染、日志覆盖）。评测判定（需求拆分项汇总：reward/CTRF 判定）
/logs/verifier/reward.txt数值（0/1）为准。ctrf.json作为测试级审计（失败用例、栈、耗时）。指标与审计（需求拆分项汇总：汇总与审计落盘）
category、difficulty、tags。task_id、判定、reward/CTRF 路径、关键日志路径、失败类型（timeout / env_error / verifier_error 等）。最小验收集与复现（需求拆分项汇总：验收集与复现约束）
category（如 security、model-training、data-processing）。外部参考：TB2 官方可用 Harbor（
harbor run --dataset terminal-bench@2.0 ...）；AISBench 侧须保证行为、判定口径、审计产物清晰一致。影响范围
uv、pytest），需文档化典型镜像体积与构建时间。使用说明
test.sh自行判定 pass/fail；除非文档明确“调试模式”且不计入正式评测。测试设计
单元测试
task.toml解析与各字段默认值；缺失必填字段报错。reward.txt为 0/1 与非数字异常。集成测试
端到端 / 复现
需求拆分验收点