实验记录：Qwen3-8B TB v0.1.x eval-as-train capacity probe (84h, 320 rollout, wandb fdhgc9j7) — Codex pass@1 upper bound 9.2%（vs run-3 OOD 5.6% / vs Qwen3-32B 15.5% / vs AfterQuery 17%）

[HansBug]

TL;DR

承 issue #4 run-3 主帖 与 issue #8 OOD eval，开了一个特殊配置的 capacity probe —— 把 TB v0.1.x eval set（86 task）直接当 train set 训 Qwen3-8B（"eval-as-train" overfit 探针）。launch 脚本：run_qwen3_8b_tboverfit.sh，仅在 run_qwen3_8b_experiment.sh 上 override ROLLOUT_PROMPT_DATA 为 tbench_test_convert/train.jsonl，算法侧 0 改动。

⚠️ 本 ckpt 不可提交 TB leaderboard / 不可作为 fair benchmark —— train/eval 同集 = 数据泄漏。本 run 的输出只能做 (1) capacity 上界探针，(2) reward landscape / 学习行为分析，(3) 后续 probing / distillation 的 ckpt 来源。

• W&B run：https://wandb.ai/hansbug/openclaw-terminal-rl/runs/fdhgc9j7
• runtime：~84h（2026-05-02 12:20 UTC → 2026-05-05 11:55 UTC，NFS 爆盘 ENOQUOTA forced stop，详见 §9）
• 训练量：320 rollout / 320 train step / 37,236 trial / 最后 ckpt = iter_0000311
• 核心结论：eval-as-train 给出 pass@1 ≈ 9.2% 的 upper bound，距同尺寸开源 setup 仍差 1.7-1.9×，距 frontier 闭源差 5-7×：

对照	TB v0.1.x pass@1	vs 本 run
Claude 4.5 Sonnet (Apex2) [闭源 frontier]	0.645	7.0×
Claude Opus 4.1 (Droid) [闭源 frontier]	0.588	6.4×
GPT-5 (Droid) [闭源 frontier]	0.525	5.7×
MiniMax-M2 230B (iFlow CLI) [开源 large]	0.420	4.6×
GLM-4.5 355B (Terminus 1) [开源 large]	0.399	4.3×
Qwen3-Coder-480B (iFlow CLI) [开源 large]	0.390	4.2×
Qwen3-32B + TerminalAgent [4× 同 family]	0.155	1.7×
gpt-5-nano (Terminus 2)	0.122	1.3×
codex-mini-latest (Codex CLI)	0.113	1.2×
本 run tboverfit eval-as-train upper bound	0.092	1.0×
Qwen3-235B-A22B (Terminus 1)	0.066	0.7×
run-3 iter215 OOD peak (issue #8)	0.056	0.6×
DeepSeek-R1 (Terminus 1)	0.057	0.6×
Qwen3-8B base (Terminus 2)	0.020	0.2×

• vs run-3 同 8B 模型 OOD eval：tboverfit 9.2% / iter215 OOD 5.6% = 1.65×，eval-as-train 确实给出更高 upper bound（消除 OOD gap）

• vs 同 family Qwen3-32B + TerminalAgent: 0.155 / 0.092 = 1.7×。同 base family 把模型放大 4 倍 + 换 better agent harness 已经把 8B 的 eval-as-train 上界拉爆

• vs AfterQuery GPT-OSS-20B (SFT+RL fine-tune)：在 TB Core 2.0（更难）上达到 0.170。同尺寸量级（8B vs 21B）、同样开源、同样 Apache-2.0，但他们走 SFT cold-start + RL 流程 + 专门的 agent-tuning，做到 17%，比我们 9.2% 高 1.85×。说明 8B-21B 这个尺寸档对 TB 是有空间的，问题不是 capacity bound 而是 setup

• 训练侧基础设施健康但 reward 中后期变稀：grad_norm mean 0.564、kl_loss mean 0.089、response_len 50w 在 [87, 283]、pg_clipfrac 全 0、无 mode-collapse；但 terminal/non_trainable_ratio 前 225 step 平均 3.4%（与 run-3 < 3% 同档），rollout 250-299 这一窗内升到 22.65% 并出现 7 次 single-step > 0.5 的 spike（详见 §8）。reward 分布 53.5% trial 全 0 / 41.3% partial / 5.1% strict success，GRPO 优势估计信噪比低（详见 §7）

• Per-task 拆解：320 rollout × 86 task 中，只有 19/86 task 曾经 strict-solved，其中 6 个 task（swe-bench-fsspec / broken-python / fix-permissions / fibonacci-server / hello-world / vim-terminal-task）pass rate ≥ 40%（broken-python 仅 1 trial 置信度低，有效高频是 5 个）；67/86 task 整 84h 训练 0 strict success。"9.2%" 不是模型在 86 task 上均匀解决了 9.2%，而是集中 overfitting 在 ~5 个简单 task 上、再加少量 partial credit

• 保留 ckpt（清理 3.5 TB 后）：iter_0000007 / 0000103 / 0000199 / 0000303 / 0000311，共 5 个 × ~104 GB = 515 GB

---

1 实验设计：为什么要做 eval-as-train？

issue #4 run-3 在 1376-task seta_env 上跑出 0.517 mean accuracy（train-side），但 issue #8 在 TB v0.1.x 66-task harbor 子集上做 OOD eval 时只有 iter215 peak 0.056 / iter279 0.025。这中间存在两条不可分辨的可能：

1. 数据分布不匹配（OOD gap）：seta_env 训练分布 ≠ TB v0.1.x 评测分布
2. 模型容量上限（capacity bound）：Qwen3-8B 在 TB v0.1.x 上的天花板就这么高

要区分这两条，最干净的实验是把 TB v0.1.x 自己当训练集：消除数据分布差，只剩"模型能不能学会"的问题。本次 probe 的产出：

• ✅ eval-as-train 把 pass@1 从 OOD 5.6% 推到 9.2%，差 +3.6 pp：OOD gap 是真实存在的，但不是 run-3 涨不动的全部原因
• ✅ 9.2% 仍远低于同尺寸开源 setup（AfterQuery 17.0% on TB 2.0）和同 family 大模型（Qwen3-32B 15.5% on v0.1.x）：capacity 上界存在，但远比我们这套 setup 能逼近的更高
• ✅ 集中 overfitting 而非分散学习：19/86 任务才有 strict pass，剩 67 个全程没解开 → eval-as-train 也救不了 hard task

这个 probe 的"失败"姿态本身就是信息：8B base + GRPO outcome-only + 默认 Terminus 2 scaffolding + 无 SFT warmup 这套组合在 TB v0.1.x 这个难度上 不够。

---

2 启动配置（与 run-3 仅差 1 个环境变量）

完整 wrapper：run_qwen3_8b_tboverfit.sh

#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &>/dev/null && pwd)"
export ROLLOUT_PROMPT_DATA="${SCRIPT_DIR}/dataset/tbench_test_convert/train.jsonl"  # ← 唯一区别
export SAVE_CKPT="${SCRIPT_DIR}/ckpt/qwen3-8b-tboverfit"
export WANDB_GROUP="qwen3-8b-tboverfit-probe"
exec "${SCRIPT_DIR}/run_qwen3_8b_experiment.sh"

tbench_test_convert/train.jsonl 是 TB v0.1.x 86 个 task 转换后的 prompt-only jsonl（task 描述 + Dockerfile 路径）。

配置一致性

配置项	run-3 (issue #4)	tboverfit-probe (本 run)
模型	Qwen3-8B base	Qwen3-8B base（同 ckpt）
algorithm	GRPO outcome-only (dense pass-rate reward)	同
rollout_batch	16 prompt × 8 sample = 128 traj	同
lr	1e-6 const	同
kl_loss_coef	0.01 (k3)	同
save_interval	8 round	同
num_rollout target	2000	同
训练数据	seta_env 1376 task	TB v0.1.x 86 task（eval-as-train）
pool 配置	1024 lease (issue #3)	同
Agent	Terminus 2 默认	同
SFT warmup	无	无

算法侧 / agent 侧 / 环境侧 0 改动，只换 ROLLOUT_PROMPT_DATA 一个变量。注意 没有用 SFT warmup（vs AfterQuery 走 SFT-then-RL 流程），也没改 Terminus 2 默认 scaffolding（vs leaderboard top 用 Apex2 / TerminalAgent / Codex CLI 这种 agent-side 优化的版本）。

---

3 主指标：Codex pass@1 trajectory

3.1 metric 定义（与 issue #8 §1.5 完全一致）

按 Codex 论文 (Chen et al. 2021) §2.1 公式：每 task 计算 $c_i / n_i$（success trial / total trial），dataset-level pass@1 = $\frac{1}{|\text{tasks}|} \sum_i c_i / n_i$。

本次：

• n_i = 该 task 在 320 rollout 中被采样到的总 trial 数（mean ~430，因为 86 task × 128 trial / round, 但每 task 不一定每 round 都被采到）
• c_i = 这些 trial 里 accuracy >= 0.99 的 strict success 数
• denominator = 86（即使日志中只观察到 85 task 有 trial，分母仍按完整 86 算 → 1 个 task 全 0）

3.2 trajectory（50-rollout sliding window）

锚点	rollout	Codex pass@1
Start (50w 第一个有效点)	49	2.49%
Peak	318	9.27% ⭐
Final	319	9.23%
All-time micro-avg (sum c / sum n)	—	5.12%
Tasks-ever-solved (pass@∞)	—	19/86 = 22.09%

关键观察：

1. 0 → 320 rollout 学到 +6.78 pp pass@1（2.49% → 9.27%）。绝对涨幅是真实的，但分母小、绝对水平低
2. 训练 50 → 250 rollout 这 200 个 rollout 里 pass@1 在 [4%, 6%] 横盘，rollout 250 后才再涨到 9%。说明 GRPO 在前 200 rollout 主要靠 partial credit 累积，strict success (pass-rate=1) 很难突破
3. vs run-3 iter215 OOD peak 5.6%：tboverfit final 9.2% 高 +3.6 pp ≈ 1.65×，eval-as-train 设置确实把 OOD gap 消掉了一些
4. vs Qwen3-32B + TerminalAgent 15.5%：差 -6.3 pp ≈ 1.7×。4× 模型 + better agent harness 已经压过我们 eval-as-train 的上界

---

4 vs run-3：同坐标系下的 trajectory 对照

直接对比 wandb canonical 字段 terminal/accuracy（rollout-level mean of per-trial accuracy ∈ [0, 1]，run-3 issue #4 §3.1 用的就是这个）。

Run	训练数据	start (50w)	peak (50w)	final (50w)	rollout 数
run-3 (issue #4)	seta_env 1376 task	0.318	0.528 ⭐	0.517	284
tboverfit (本 run)	TB v0.1.x 86 task (eval-as-train)	0.174	0.360	0.355	318
gap	—	-0.144	-0.168	-0.162	—

关键发现 — eval-as-train 下 train-side accuracy 显著低于 run-3 的 OOD-evaluable train-side：

• 起点低 0.14：tboverfit 起点 0.17 vs run-3 起点 0.32 = TB task 难度本身高于 seta_env，模型从 base 出发就要克服更难的分布
• 峰值低 0.17：run-3 在 seta_env 上 hit 0.53，tboverfit 在 TB v0.1.x 上即使 eval-as-train 也只到 0.36
• 末值低 0.16：差距没有缩小

这意味着：

Eval-as-train 不能"自动地"让 train-side accuracy 飙升。直觉上，把答案集喂回去训练应该 trivially 飙到 90%+，但实际上 partial credit + 多步 task + GRPO 优势估计的高方差导致模型很难把"知道答案"转化为"能稳定输出 successful trajectory"。

run-3 在 1376 task 大池子上学习曲线更平滑、峰值更高，是因为：

1. task 数大 → reward 梯度估计方差小、GRPO 优势更稳
2. task 难度梯度 → 简单 task 给信号、难 task 不影响整体（curriculum 自带）
3. task 多样性 → 不容易 overfit 到几个单一 pattern

而 tboverfit 的 86 task 池子里大部分是 evaluation-grade hard task，模型很快被 dominate 在少数几个能解的 task 上（详见 §6 per-task 拆解）。

---

5 vs Leaderboard：tboverfit 9.2% 在 TB v0.1.x 上的真实位置

数据来源：issue #8 §2.4-§2.5 调研 + tbench.ai 官方 v0.1.x leaderboard。

5.1 同 base family（Qwen3）梯度

模型 + agent	TB v0.1.x pass@1	倍率 vs base 0.020	倍率 vs tboverfit 0.092
Qwen3-Coder-480B (iFlow CLI) [agent 优化]	0.390	19.5×	4.2×
Qwen3-Coder-480B (Orchestrator)	0.197	9.85×	2.1×
Qwen3-32B + TerminalAgent	0.155	7.75×	1.7×
Qwen3-235B-A22B (Terminus 1)	0.066	3.3×	0.72×
本 run tboverfit (eval-as-train)	0.092	4.6×	1.0×
run-3 iter215 OOD (8B + RL)	0.056	2.8×	0.61×
Qwen3-8B base (Terminus 2)	0.020	1.0×	0.22×

核心 takeaway：

1. eval-as-train 8B (本 run) 0.092 > OOD 8B + RL run-3 0.056 > base 8B 0.020：8B 模型上 RL 给了 2.8×，eval-as-train 又给了 1.6×，绝对值从 0.02 → 0.06 → 0.09，每步都是真实的，但每步幅度都不大
2. 8B (eval-as-train) 0.092 vs 32B + TerminalAgent 0.155：4× 模型 + better agent harness 比 8B + eval-as-train 多 +6.3 pp。说明 agent scaffolding + 模型大小 在这个尺度上比 eval-as-train + 8B + 默认 scaffolding 更有效
3. 8B (eval-as-train) 0.092 vs Qwen3-235B 0.066：29× 模型 + 默认 Terminus 1 scaffolding 反而比我们低！ 这就是 issue 实验记录：Qwen3-8B run-3 (msp60ius) Phase 1 OOD 跑分 — base+4 ckpt × 66 task × 3 attempts (terminus-2 + harbor + sglang) — iter215 OOD 峰 vs iter279 回落 #8 §2.5.4 takeaway 实验记录：terminal-rl Qwen3-8B run-3 (60h, 565 step, wandb msp60ius) — accuracy 0.32→0.52，无 mode-collapse + 6 类 dataset 卡顿 #4 写的"RL 提升 magnitude 在小模型上很显著"——但前提是 RL 真的在做有效 fine-tuning（同尺寸 vanilla 235B 不带 RL 也只有 0.066）

5.2 跨尺寸对照（TB Core 2.0 上 <100B 模型，issue #8 §2.5.1）

模型 + agent	TB 2.0 pass@1	base	路线
AfterQuery-GPT-OSS-20B (SFT+RL fine-tune)	0.170	GPT-OSS-20B (21B/3.6B MoE)	✅ 专门 agentic SFT cold-start + RL
GPT-5-Nano (Codex CLI)	0.115	unsure (闭源)	✅ Codex 路线
GPT-OSS-20B (vanilla, Mini-SWE-Agent)	0.034	21B/3.6B MoE	默认

AfterQuery 的对照特别有教育意义：

• base 类型相近（GPT-OSS-20B 21B vs Qwen3-8B 8B，规模差 2.6×）
• 同样开源 / 同样 Apache-2.0 系
• 他们用 SFT cold-start (从公开 dataset) + RL on real-world tasks 的路线 → 0.170 (TB 2.0)
• 我们 直接 RL on eval-as-train，无 SFT → 0.092 (v0.1.x，但实际等价)

差距 ~1.85× 主要不是模型容量差距（21B vs 8B 容量差不会到 1.85×），而是训练流程：SFT warmup + 专门的 agent-tuning。这是 AfterQuery 公开 blog 主打的方法论。

5.3 vs Frontier（top-tier 闭源）

模型 + agent	TB v0.1.x pass@1	倍率 vs tboverfit
Claude 4.5 Sonnet (Apex2)	0.645	7.0×
Claude Opus 4.1 (Droid)	0.588	6.4×
GPT-5 (Droid)	0.525	5.7×
Claude Sonnet 4.5 (Terminus 2)	0.510	5.5×

frontier 用大量参数 + 专门 agent SFT/RL + 业界最强 agent scaffolding（Apex2 / Droid 都是各家自研），把 v0.1.x 推到 60%+。0.092 vs 0.645 = 7× 差距是开源 8B + minimal post-train + 默认 scaffolding 与他们的全部综合差距，无法分解为单一因子。

---

6 Per-task 拆解：86 task 中 19 个被学过、6 个被高质量学过、67 个一次都没解开

把 320 rollout × 86 task 总共 ~37,200 trial 按 task 聚合（log-parse 抽样，约 9% 因 timeout 没采到 evaluation 行），统计每 task 的 strict pass rate（accuracy >= 0.99）：

6.1 高 pass rate（≥ 40%）— 6 task

Task	strict success / total trials	strict pass rate	类型
swe-bench-fsspec	467 / 467	100.0%	SWE patch-style，可能有捷径解（详见 §6.5）
broken-python	1 / 1	100.0%	单 trial，置信度低
fix-permissions	371 / 400	92.8%	单步 chmod，简单
fibonacci-server	210 / 378	55.6%	flask 单 endpoint，trivial
hello-world	216 / 478	45.2%	写文件
vim-terminal-task	197 / 480	41.0%	vim 命令固定 pattern

6.2 中 pass rate（10-40%）— 3 task

Task	strict success / total trials	strict pass rate
qemu-startup	183 / 478	38.3%
recover-obfuscated-files	121 / 409	29.6%
get-bitcoin-nodes	63 / 458	13.8%

6.3 低 pass rate（< 10%）— 10 task

prove-plus-comm 2.4% / heterogeneous-dates 1.5% / csv-to-parquet 1.4% / chem-property-targeting 0.8% / sqlite-with-gcov 0.5% 等 — 偶发 strict success

6.4 NEVER strict-solved — 67 / 86 task

包括但不限于：

• 全部 swe-bench-astropy-* / swe-bench-django 等 SWE patch task（部分 partial credit > 0.86 但永远不到 1.0 — 模型能改对部分 test 但碰不到完整 patch）
• tmux-advanced-workflow / decommissioning-service-with-sensitive-data（多步、需要安全意识）
• build-linux-kernel-qemu / blind-maze-explorer-5x5（多步规划）
• incompatible-python-fasttext.* / nginx-request-logging（环境配置）
• chess-best-move / cartpole-rl-training（需要算法 reasoning）

6.5 关键观察

1. 84h 训练把 strict pass 集中在 6 个简单 task 上（swe-bench-fsspec 100% 是异常 outlier，broken-python 仅 1 trial 置信度低；剩下 4 个是 trivial single-step task）
2. partial credit 普遍但碰不到 1.0：很多 task 的 mean reward > 0.5（swe-bench-astropy-1 mean 0.867、swe-bench-astropy-2 mean 0.889）但 strict success 0 —— 模型能拿大部分 partial reward 但碰不到最后一关
3. eval-as-train 没有"广度学习" —— 既没有学到 86 task 的代表性子集，也没有从简单 task 推广到难 task。集中 overfit 而非泛化
4. swe-bench-fsspec 100% pass 值得单独排查：极有可能是 task 的 verifier 给了过于宽松的 reward signal（或者 task 本身有 trivial 解），不应该被解读为模型真正解决了 SWE 修 bug 任务

---

7 Reward sparsity：为什么"训练侧健康"≠"在学习"

37,236 个 trial 的 per-trial accuracy 分布：

区间	数量	占比
accuracy < 0.05（基本完全失败）	19,933	53.5%
accuracy ∈ [0.05, 0.99)（partial credit）	15,396	41.4%
accuracy >= 0.99（strict success）	1,907	5.1%

reward signal 主要由 partial credit 主导（41.4%）。这看起来是好事 —— 模型在很多 task 上能拿到部分分数，但实际上对 GRPO 的影响是混合的：

7.1 GRPO advantage 分布的高方差

GRPO (outcome-only) 把 raw_reward 标准化成 advantage：$A_i = \frac{r_i - \mu}{\sigma + \epsilon}$，其中 $\mu, \sigma$ 是 batch 内（128 trial）的均值和标准差。当：

• 53.5% 的 trial r=0、5.1% r=1、剩 41.4% 散布在 (0, 1)
• batch 内 $\mu \approx 0.05$（micro-avg）
• $\sigma$ 在 [0.2, 0.4] 量级

advantage 的信噪比是这样的：失败 trial 拿到 -0.1 ～ -0.2 的微弱 negative，partial trial 拿到 +0.5 ～ +1.5 的中等 positive，strict success 拿到 +1.5 ～ +2.0 的强 positive。问题在于 partial credit 的"几乎成功"和"完全成功"的 advantage 差距不大，而 outcome-only RL 真正想优化的是后者。

7.2 这与 issue #2 / run-3 的对比

• issue Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2 mode-collapse: response_len → 7 / non_trainable_ratio → 0.92。原因是 batch 内 r 全 0 / 全 1 → advantage 全 0 → 没有梯度
• run-3 没塌陷因为 1376 task 大池子里总有一些拿到 r=1 的 task，advantage 分布合理
• 本 run 处于"不塌陷但也学不动"的中间状态：reward 信号不全 0（partial credit 占 41.4%），但真正驱动学习的 r=1 trial 只占 5.1%，且高度集中在 6 个 task 上 → GRPO 等于在反复优化"做对那几个简单 task"，对其他 80 个 task 没有有效梯度

7.3 训练侧"健康"的精确含义

指标	值	健康定义	真实含义
grad_norm mean	0.564	不爆炸（>50）/ 不消失（<0.05）	gradient 在动
kl_loss mean	0.089	不漂太远 ref（>0.5）	policy 没被拉走
non_trainable_ratio	<0.05	不全 0 reward	大部分 batch 有信号
response_len 50w	[87, 283]	不退化（<30）	不是 mode-collapse
entropy_loss	0.04-0.08	稳定	探索 ok

全绿 = 训练 setup 没崩、policy 在合理范围内动。但**"在动" ≠ "在学到 86 task 的分布"**：

• ❌ 没有体现学到的"task 多样性"：5 个 task 主导，不是 healthy distribution learning
• ❌ 没有体现"OOD 泛化"：本来就是 eval-as-train，本质上不需要泛化
• ❌ 没有体现"hard task 学习"：67/86 task strict success = 0
• ✅ 体现了 setup 稳定：可以跑 84h 不崩

→ 不能因为训练侧曲线漂亮就认为"模型已经学到上限"。"训练侧健康"只意味着 infrastructure 工作正常，与 policy 收敛到了什么 distribution 是两件事。

---

8 全程 Dashboard（run-1/2/3 同款 9 张图，数据源：wandb fdhgc9j7）

8.1 总览（00_dashboard.png）

3×3 grid，按 issue #1 / #2 / #4 dashboard 同款格式：8 个 metric 子图（每个含 per-rollout raw + 50w 滑窗均值 + 100w 滑窗均值 + 阈值线）+ 右下角 summary 文本。数据全部来自 wandb run fdhgc9j7 的 canonical metrics（不是 log parse 估算）。

8.2 Per-50-rollout bucket（与 issue #4 §3.1 同口径，wandb 数据）

bucket	terminal/accuracy	terminal/reward_mean	terminal/non_trainable_ratio	rollout/response_lengths
rollout 0-49	0.174	-0.653	3.41%	151.2
50-99	0.222	-0.556	5.50%	182.9
100-149	0.249	-0.502	3.20%	197.8
150-199	0.281	-0.438	5.33%	193.4
200-249	0.318	-0.363	7.49%	260.1
250-299	0.355	-0.291	22.65% ⚠️	264.3
300-319	0.349	-0.301	7.91%	261.7

对比 issue #4 §3.1 run-3 同口径表：run-3 50w terminal/accuracy 由 0.318 → 0.522（涨 +0.20），non_trainable_ratio 全程 0.017-0.028（< 3%）。本 run terminal/accuracy 由 0.174 → 0.355（涨 +0.18，绝对水平低 0.17）；non_trainable_ratio 前 200 rollout 平均 4.4%（与 run-3 < 3% 同档），rollout 250-299 这段出现集中 degradation 升到 22.65%，第一次 single-step > 0.5 出现在 wandb step 433。Pre-step-225 mean 3.36%（≈ run-3 水位），post-step-225 mean 8.68% 含 7 个 > 0.5 的 spike（详见 §8.3 子图 07 + §8.4）。

8.3 单指标分图（4×2 table）

01 — terminal/accuracy	02 — terminal/reward_mean
50w start=0.174 → peak=0.360 → final=0.355；gap vs run-3 0.522 = -0.16。涨幅曲线和 run-3 同形状但抬高不起来	50w 范围 [-0.91, +0.13]，全程为负但单调上升；vs run-3 后期 +0.05 还差 0.1+
03 — rollout/raw_reward	04 — train/grad_norm
raw_reward 单 trial post-discount，整 320 rollout 50w 从未稳定为正	范围 [0.000, 2.069]，mean 0.564，全程在 [0.05, 50] 健康区间，仅 step 318 半空 anomaly 触底
05 — train/kl_loss	06 — train/entropy_loss
范围 [0.000, 0.237]，mean 0.089，从未踩 0.5 阈值	稳定 0.04–0.08，无 entropy collapse
07 — terminal/non_trainable_ratio ⚠️	08 — rollout/response_lengths
mean 7.93% / pre-step-225 mean 3.36% (≈ run-3 水位) / post-step-225 mean 8.68% ⚠️。第一次 > 0.5 在 step 433；总共 7/320 步 > 0.5 = 间歇性"组内全相同 reward"导致该 batch 无 advantage 信号	50w 范围 [87, 283]，从未跌破 30，无 mode-collapse。早期 ~150、后期 ~260 token

8.4 训练侧定性结论

Infrastructure 全程健康（grad_norm / kl_loss / entropy / response_len 全部不踩阈值），non_trainable_ratio 前 225 step 与 run-3 持平 (3.4% ≈ run-3 < 3%)、后 95 step 升到 8.7% 并出现间歇性 100% spike。policy 没崩，只是 reward 信号在中后期变得越来越稀疏（partial credit 主导，strict success (pass-rate=1) 少且集中在 5 个 task）→ §3 看到的 pass@1 在 [4%, 9%] 区间晃荡 + §6 看到的"5 task overfit 而非 86 task 广度学习"，是这个 reward sparsity 的直接表现。

---

9 Forced Stop：NFS ENOQUOTA（教训保留 + ckpt 清理）

9.1 时间线

UTC 时间	事件
2026-05-02 12:20	训练启动
2026-05-05 11:55:42	step 319 完成训练，开始写 iter_0000319 ckpt
2026-05-05 11:55:57	最后一行 RolloutManager log（rollout 320 进行到 56/128）
2026-05-05 11:57:18	filesystem_async.py:326 - Local process 0 encountered an error: [Errno 122] Disk quota exceeded
2026-05-05 11:57+	8 个 Megatron rank 全部 exit，GPU 显存 70 GB → 0 MiB，pool 容器还活着但训练已死
2026-05-05 12:22	用户首次发现训练 stale（30min stall 检测触发）
2026-05-06 02:13	清理 35 个中间 ckpt + 损坏的 iter_0000319 → 释放 3.5 TB

9.2 根因

• save_interval=8，从 iter_0000007 开始 → 共 40 个 ckpt
• 每个 ~104 GB → 40 × 104 ≈ 4.0 TB
• NFS quota 25 TB（共享）→ 写到 iter_0000319 时 ENOQUOTA
• iter_0000319 只写出 38 GB（vs 正常 104 GB）→ 损坏，已删除

9.3 后续防护建议

1. launch 脚本默认 --save-interval 24（单 8B run 控制在 ~15 ckpt 内）
2. 加 --ckpt-keep-last 5 滚动删除（待确认 slime arg）
3. NFS quota 监控加到 pre-flight 检查（启动训练前 df -h 警告）

9.4 Pool 侧 84h+ 0 fatal

整 84h，sudo docker logs openclaw_pool_server 中 500 Internal | Too many open | address pools 偶发但无 fatal。pool 配置（1024 lease）与 issue #3 / #4 完全一致。

---

10 结论 + 后续 Actions

10.1 Takeaway

1. eval-as-train 给出 8B+RL 的 upper bound ≈ 9.2% Codex pass@1（standard 定义，详见 §3）。这是消除 OOD gap 后的天花板。vs run-3 iter215 OOD peak 5.6% = +3.6 pp / 1.65×，OOD gap 是真实存在的但不是全部
2. terminal/accuracy (canonical wandb metric) 50w：tboverfit 0.174 → 0.360 → 0.355 vs run-3 0.318 → 0.528 → 0.517 = gap 0.16-0.17。同坐标下，eval-as-train 的 train-side accuracy 反而显著低于 run-3 的 OOD-evaluable train-side
3. 9.2% 的内部结构是"集中 overfit 6 个简单 task"，不是"广度学习"：19/86 task 学过，6 个 pass rate ≥ 40%（含 1 个置信度低的 1-trial outlier），67 个一次没解开
4. 8B + 默认 setup 与 SOTA 的差距来自 (1) base 模型大小、(2) agent scaffolding、(3) SFT warmup、(4) 训练数据 + RL 流程。eval-as-train 只 address 了 (4) 中的 data 部分，不能解决其他三项
5. 训练侧 infrastructure 健康 ≠ 训练有效：grad_norm / kl_loss / entropy / response_len 全程不踩阈值；但 non_trainable_ratio 前 225 step mean 3.4%（≈ run-3 < 3% 同档），rollout 250-299 这一段升到 22.65%、整后 95 step mean 8.7% 含 7 个 single-step > 0.5 的 spike。reward signal 53.5% 全 0、41.3% partial、5.1% strict success（且高度集中），GRPO advantage 估计信噪比低
6. vs 同尺寸/同档位开源对照：AfterQuery GPT-OSS-20B (SFT+RL) 在 TB Core 2.0 达到 0.170，Qwen3-32B + TerminalAgent 在 v0.1.x 达到 0.155。本 run 9.2% 距这两个标杆都有 1.7-1.85×，说明 capacity 真位置在 0.15-0.20 附近，不是 0.09
7. 本 run 的 ckpt 不可作为 TB 提交（污染），但可作为：(a) 同 base 不同训练流程的对照样本，(b) 后续 SFT-then-RL 流程的 ablation baseline，(c) reward shaping 实验的 baseline

10.2 后续 actions（issue #6 roadmap 已部分覆盖）

• 强 prerequisite：launch 脚本加 --save-interval 24 --ckpt-keep-last 5
• 方向 1：SFT cold-start：参考 AfterQuery 路线，先用公开 agent trajectory dataset SFT，再 RL on TB-related domain
• 方向 2：Agent scaffolding：用 TerminalAgent / 自研 prompt-stack 替换 Terminus 2 默认，看 0.092 → 多少
• 方向 3：reward shaping：除 outcome 外加 step-level reward（per-tool-call / per-test-pass），看能否突破 partial credit 41.4% 的 plateau
• 方向 4：模型放大：Qwen3-14B / 32B 上重跑同 setup，看 capacity bound 真位置在哪
• 方向 5：reward verifier 排查：swe-bench-fsspec 100% pass 异常，排查 verifier 是否有捷径

10.3 保留的 ckpt 路径

/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/ckpt/qwen3-8b-tboverfit/
├── iter_0000007/   # 起点（Phase 1 中）
├── iter_0000103/   # Phase 3 末（pass@1 plateau 中）
├── iter_0000199/   # Phase 4 慢回升中
├── iter_0000303/   # Phase 5 第二平台早期
├── iter_0000311/   # 最后健康 ckpt（Phase 5 apex 附近）
└── latest_checkpointed_iteration.txt → 311

每个 ~104 GB，共 515 GB。iter_0000319 因 ENOQUOTA 写到一半（38GB），已删除。

[HansBug]

Per-task 三档拆解 — 区分 "reward 完全冷死" vs "partial 卡 last-mile" vs "ever strict-solved"

0. 起因

issue 主帖 §6 把 86 个 task 粗糙二分成 "19 ever strict-solved" + "67 never strict-solved"。这个二分误导性很强：那 67 个 task 里只有 33 个是 reward 完全卡 0（GRPO 真没法学），剩 34 个其实 reward signal 很丰满（partial credit 拿到 0.5+）只是碰不到 acc=1.0 阈值。这两类 task 的"模型能不能学会"性质完全不同。

本 comment 所有 reward / 测试逻辑都直接引用 dataset/tbench_test/<task>/tests/test_outputs.py 和 run-tests.sh 的实际代码，不做推测。

1. 总览：3 档 / 6 档分布

档位	数量	占比	内涵
A. Truly cold（mean reward < 0.05，0 strict）	33	38.4%	320 rollout × ~430 trial = ~14k 次采样里没拿到任何 partial reward。GRPO 8 sample group 全部 reward=0 → standardize 后 advantage = 0 → 零梯度，永远不动
B. Partial credit 但 never strict（0.05 ≤ mean < 0.99，0 strict）	33	38.4%	12 个 partial cold (0.05-0.30) + 21 个 partial warm (0.30-0.99)。模型有部分能力但碰不到完整 success，最高的 swe-bench-astropy-2 mean=0.889 但 strict=0
C. Ever strict-solved（≥1 trial acc=1.0）	19	22.1%	6 high (≥40%) + 3 mid (10-40%) + 10 low (<10%)
Unobserved	1	1.2%	日志采样未踩到

关键 reframe：86 task = 38% 真冷 + 38% 部分能力 + 22% 学过 + 1% 未观察。"没学会"的 67 个不是均质的"卡死"，而是一半冷死、一半 "差一口气"。

---

2. Category A — Truly cold (33 task / 38.4%)：reward 完全卡 0，GRPO 真没法学

2.1 完整冷死任务清单（mean reward = 0.0000，14k+ trial 没拿到任何 partial）

polyglot-rust-c · git-workflow-hack · sqlite-db-truncate · play-zork · modernize-fortran-build · gpt2-codegolf · create-bucket · eval-mteb · new-encrypt-command · run-pdp11-code · build-initramfs-qemu · swe-bench-langcodes · count-dataset-tokens · polyglot-c-py · build-tcc-qemu · qemu-alpine-ssh · fix-git · git-multibranch · simple-web-scraper · super-benchmark-upet · oom · eval-mteb.hard · chess-best-move · security-vulhub-minio · build-linux-kernel-qemu

加 8 个 mean ∈ (0, 0.05)：download-youtube / grid-pattern-transform / blind-maze-explorer-algorithm.* / hf-model-inference / jupyter-notebook-server / raman-fitting.easy

2.2 三个具体例子（test 代码 + 模型 trajectory + 为什么 reward = 0）

例 A1：chess-best-move（mean=0.0000, n=425, strict=0）

Test 代码 tests/test_outputs.py：

def test_move_correct():
    move = open("/app/move.txt").read().strip().split()
    assert sorted(move) == sorted(["g2g4", "e2e4"]), "File is wrong"

唯一 1 个 test，3 个隐含要求：

1. 文件 /app/move.txt 存在且可读
2. 内容 .split() 后排序 == sorted(["g2g4", "e2e4"])
3. 即必须同时输出 g2g4 和 e2e4 两个 move（这是 chess_bard.png 状态下的双 mate-in-one），少 1 个就 fail

Canonical solution（issue 已确认）：用 stockfish + python-chess 解析 PNG → 检测白方棋子位置 → 算 best move。需要图像处理 + 国际象棋引擎，8B 模型完全不带视觉 + 没装 stockfish，纯瞎猜。

模型实际 trajectory（log 抽样）：

[user]: The file chess_bard.png has an image of a chess board. ... Write the best move
        for white to play to /app/move.txt in the form [src][dst] ...

[assistant]:
<tool_call>{"command": "mkdir -p /app", ...}</tool_call>
<tool_call>{"command": "convert chess_bard.png chess_bard.ppm", ...}</tool_call>
<tool_call>{"command": "ldcc -c chess_bard.ppm", ...}</tool_call>           ← 编了不存在的命令
<tool_call>{"command": "python3 -c 'import chess; print(chess.Move.from_uci(\"e2e4\"))'", ...}</tool_call>
<tool_call>{"command": "echo 'e2e4' > /app/move.txt", ...}</tool_call>
<|im_end|>

reward = 0.0 because：写到 /app/move.txt 的内容是 "e2e4"，.split() 后是 ["e2e4"]，与 sorted(["g2g4", "e2e4"]) 不等 → assert fails → 1 test 0 pass = 0/1 = 0.0。

全部 425 trial 都是这种"瞎猜单 move"模式。8 个 sample 都是 0 reward → 整 group advantage = 0 → 这个 task 在 84h 训练中贡献 0 梯度。

例 A2：build-linux-kernel-qemu（mean=0.0000, n=421, strict=0）

Test 代码（核心片段）：

def test_expect():
    open("init.sh", "w").write(init)         # init = busybox initramfs build script
    os.popen("bash init.sh").read()          # build initramfs
    open("a.exp", "w").write(expect)         # expect script booting qemu
    actual_output = os.popen("expect -f a.exp").read()
    expected_output = "Hello, this is a custom kernel"
    assert expected_output in actual_output

expect 脚本会 spawn qemu，跑：

spawn qemu-system-x86_64 -kernel ./linux-6.9/arch/x86/boot/bzImage \
                          -initrd ramfs/initramfs.cpio.gz -append "console=ttyS0" -nographic
expect "localhost login: " ; send "root\r"
expect "# " ; send "dmesg | grep Hello\r"
expect "# " ; send "poweroff\r"

唯一 1 test，3 个硬要求：

1. linux-6.9/arch/x86/boot/bzImage 存在 → kernel 必须从源码编译完
2. linux-6.9/usr/gen_init_cpio 存在 → kernel build 中间产物可用
3. dmesg 输出包含 "Hello, this is a custom kernel" → 必须改 init/main.c 加 printk(KERN_INFO ...)

Canonical solution：30+ 分钟 build：wget linux-6.9.tar.xz → 改 init/main.c 加 printk → make defconfig → enable TTY/SERIAL → make -j$(nproc)。

模型实际 trajectory：

[user]: Build linux kernel linux-6.9 from source. ... add
        printk(KERN_INFO "Hello, this is a custom kernel"); to start_kernel.

[assistant]:
<tool_call>{"command": "git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git",
            "timeout": 20}</tool_call>
<|im_end|>

reward = 0.0 because：(1) git clone linux kernel ~3GB，timeout=20s 不可能完成；(2) 模型 1 个 turn 就 <|im_end|> 放弃；(3) bzImage 不存在 → expect 脚本中 spawn qemu-system-x86_64 -kernel ./linux-6.9/arch/x86/boot/bzImage 直接 fail → "Hello, this is a custom kernel" 不在 output 中 → assert fails。

例 A3：polyglot-rust-c（mean=0.0000, n=411, strict=0）

Test 代码：

def test_fibonacci_polyglot():
    # Test with N = 42
    os.popen("rustc /app/main.c.rs -o /app/main").read()
    out1 = os.popen("/app/main 42").read().strip()
    os.popen("gcc /app/main.c.rs -o /app/cmain").read()
    out2 = os.popen("/app/cmain 42").read().strip()
    assert out1 == "267914296" and out2 == "267914296"

    # Test with N = 10
    out3 = os.popen("/app/main 10").read().strip()
    out4 = os.popen("/app/cmain 10").read().strip()
    assert out3 == "55" and out4 == "55"

    # Test with N = 0
    out5 = os.popen("/app/main 0").read().strip()
    out6 = os.popen("/app/cmain 0").read().strip()
    assert out5 == "0" and out6 == "0"

唯一 1 test，6 个 assert（3 N 值 × 2 编译器）。pytest 是 binary：1 fail = test fail = 0 reward。

Canonical solution：根据 task author 的 solution.sh 是 # UNKNOWN —— 这是 task 作者标的 hard 题，没有公开 reference solution。需要利用 /*...*/ C 块注释 vs Rust 块属性的 token-level 重叠技巧。

模型实际 trajectory：

[assistant 写到 /app/main.c.rs]:
use std::env;

fn main() {
    let args: Vec<String> = env::args().collect();
    if args.len() < 2 { println!("Usage: {} N", args[0]); return; }
    let n: usize = args[1].parse().unwrap();
    let mut a = 0; let mut b = 1;
    for _ in 0..n { let temp = a; a = b; b = temp + b; }
    println!("{}", a);
}

// This file is a polyglot, compatible with both Rust and C compilers.

reward = 0.0 because：这是纯 Rust 代码 + 自我安慰的注释。rustc 编译 OK 输出对（267914296），但 gcc /app/main.c.rs 立即 syntax error（C 不认 use std::env;、fn、let mut、Vec<String>），/app/cmain 二进制不存在，os.popen("/app/cmain 42").read() 返回空字符串 → out2 == "267914296" fail。

2.3 共同失败模式

这 33 个 task 的失败可分为 4 类，全部表现为 8 sample group 全 reward=0 → group advantage=0 → 0 梯度：

1. 需视觉/二进制理解：chess-best-move（chess_bard.png）、grid-pattern-transform、blind-maze-explorer.*。8B 不带 vision，瞎猜
2. 需重型构建/编译（timeout 不够）：build-linux-kernel-qemu（kernel build 30+ 分钟 vs timeout 20-360s）、build-initramfs-qemu / build-tcc-qemu / qemu-alpine-ssh
3. 需特殊 CS 知识：polyglot-rust-c / polyglot-c-py（compiler-level 双语 trick）/ oom（memory exploit）/ play-zork（Z-machine bytecode）
4. 多步 + 状态依赖 + 模型早停：git-workflow-hack / sqlite-db-truncate / git-multibranch。模型 1-3 turn 就 <|im_end|>

→ 这 33 个对 8B + 默认 Terminus 2 scaffolding + 360s timeout 是 capacity 之外，eval-as-train 也救不了。

---

3. Category B — Partial credit 但 never strict (33 task / 38.4%)：模型 知道该干啥 但 碰不到阈值

3.1 范围

• partial cold (0.05 ≤ mean < 0.30)：12 task — fix-pandas-version (0.293) / pytorch-model-cli.hard (0.280) / processing-pipeline (0.238) / form-filling (0.199) / nginx-request-logging (0.193) / pytorch-model-cli (0.172) / train-fasttext (0.139) / raman-fitting (0.123) / pytorch-model-cli.easy (0.107) / intrusion-detection (0.100) / solana-data (0.065) / path-tracing-reverse (0.234)
• partial warm (0.30 ≤ mean < 0.99)：21 task — top: swe-bench-astropy-2 (0.889) / swe-bench-astropy-1 (0.867) / tmux-advanced-workflow (0.774) / decommissioning-service-with-sensitive-data (0.678) / incompatible-python-fasttext.base_with_hint (0.667) / extract-safely (0.625) ...

3.2 三个具体例子

例 B1：swe-bench-astropy-2（mean=0.889, n=472, strict=0）— 最接近 strict 但永远碰不到

Test 代码（关键：tests/test_outputs.py 是空的 pass，真测在 run-tests.sh）：

# run-tests.sh 主体
cat > /app/test_patch.diff << 'EOF'
diff --git a/astropy/io/ascii/tests/test_qdp.py b/astropy/io/ascii/tests/test_qdp.py
@@ -43,7 +43,18 @@ def test_get_tables_from_qdp_file(tmp_path):
-def test_roundtrip(tmp_path):
+def lowercase_header(value):
+    """Make every non-comment line lower case."""
+    ...
+@pytest.mark.parametrize("lowercase", [False, True])
+def test_roundtrip(tmp_path, lowercase):
     example_qdp = """ ... """
+    if lowercase:
+        example_qdp = lowercase_header(example_qdp)
EOF
patch --fuzz=5 -p1 -i /app/test_patch.diff
pip install numpy==1.23.4
python -m pip install -e .[test] --verbose
pytest -rA -v astropy/io/ascii/tests/test_qdp.py

关键 mechanism：

• pytest test_qdp.py 跑该文件全部 test。test_qdp.py 在 astropy commit 7269fa3e 上有 8 个原始 test
• patch 只把 test_roundtrip 改成 @pytest.mark.parametrize("lowercase", [False, True])，把 1 个 test 拆成 2 个变体（test_roundtrip[False] + test_roundtrip[True]）
• 总 test 数 = 8 - 1 + 2 = 9
• accuracy 计算 = pytest 通过的 test 数 / 总 test 数

Canonical solution (solution.sh)：

# 2-line patch to astropy/io/ascii/qdp.py
-    _line_type_re = re.compile(_type_re)
+    _line_type_re = re.compile(_type_re, re.IGNORECASE)
...
-                if v == "NO":
+                if v.upper() == "NO":

为什么模型不动也能拿 0.889：

• test_roundtrip[False] —— 大写 QDP 命令，原始代码就 work，PASS
• 其他 7 个原始 test 不依赖大小写敏感性（test_get_tables_from_qdp_file / 等），全 PASS
• 唯一 fail 的是新加的 test_roundtrip[True]：lowercase_header() 把 example_qdp 转小写，原代码 re.compile(_type_re) 不带 re.IGNORECASE → "read serr 1 2" 匹配不上 _command_re → ValueError → fail

→ 8 / 9 = 0.8889，模型不需要做任何事情，只要不破坏现有代码就拿 88.9%

模型实际 trajectory：

[user]: ascii.qdp Table format assumes QDP commands are upper case. ...
[assistant]:
<tool_call>{"command": "python", "timeout": 20}</tool_call>
<|im_end|>

模型只 python 启动了 REPL 然后 timeout，啥也没改。reward = 0.7778 (= 2 × 0.8889 - 1，per-trial accuracy=0.8889、score=0.7778 与 mean 一致)。

例 B2：tmux-advanced-workflow（mean=0.774, n=463, strict=0）

Test 代码 tests/test_outputs.py，5 个 test：

def test_tmux_installed():
    result = subprocess.run(["which", "tmux"], capture_output=True, text=True)
    assert result.returncode == 0

def test_project_structure():
    assert os.path.exists("/app/project")
    assert os.path.exists("/app/project/src")
    assert os.path.exists("/app/project/data")
    assert os.path.exists("/app/project/logs")
    assert os.path.exists("/app/project/src/process_data.py")
    assert os.path.exists("/app/project/src/monitor.py")
    assert os.path.exists("/app/project/data/input.csv")

def test_scripts_executable():
    assert os.access("/app/project/src/process_data.py", os.X_OK)
    assert os.access("/app/project/src/monitor.py", os.X_OK)

def test_bug_fixed():
    output_file = "/app/project/data/test_output.csv"
    result = subprocess.run(["python", "/app/project/src/process_data.py",
                              "/app/project/data/input.csv", output_file], ...)
    assert result.returncode == 0
    assert os.path.exists(output_file)
    lines = open(output_file).readlines()
    assert len(lines) == 9, f"Expected 9 processed lines, got {len(lines)}"
    for line in lines:
        assert line.count("\n") == 1   # 没修 strip() bug 时，会有 double newline
        # ... + 各种 parts assert

def test_logs_generated():
    assert os.path.exists("/app/project/logs/process.log")
    assert "Starting processing" in log_content
    assert "Completed processing" in log_content

Test 1-3 在容器初始状态就过（Dockerfile pre-installs tmux, 创建目录结构, chmod +x scripts）→ 模型啥都不动也 3/5 PASS。

Test 4 (test_bug_fixed)：process_data.py 有 strip() bug → 输出 double newlines → len(lines) == 9 fail（实际 ~10 因为 split 错）→ FAIL。

Test 5 (test_logs_generated)：只要曾经跑过 process_data.py，logs/process.log 就有 "Starting processing" + "Completed processing"。模型在 trajectory 里跑过 process_data.py → PASS。

→ 4 / 5 = 0.8 ≈ task mean 0.774。

模型实际 trajectory：

[assistant]:
<tool_call>{"command": "tmux send-keys -t workflow:2 'vim /app/project/src/process_data.py' C-m"}</tool_call>
<tool_call>{"command": "tmux send-keys -t workflow:1 'python /app/project/src/process_data.py /app/project/data/input.csv /app/project/data/output.csv' C-m"}</tool_call>
<tool_call>{"command": "tmux send-keys -t workflow:1 'less /app/project/data/output.csv' C-m"}</tool_call>
<|im_end|>

模型用 vim 打开了文件但没真改 strip() bug，然后跑了 process_data.py（用 buggy 版本）→ test_bug_fixed FAIL，剩 4 个 PASS。reward = 0.8。

例 B3：incompatible-python-fasttext.base_with_hint（mean=0.667, n=480, strict=0）

Test 代码：

import fasttext
import numpy as np
import shutil, os

model = fasttext.load_model("/app/model.bin")    # ← 模块顶层加载，失败则全 fail

def test_predict_raises_no_error():
    try:
        model.predict("This is a test sequence")
    except Exception as e:
        raise AssertionError(f"Model inference failed: {e}")

def test_correct_output():
    labels, probabilities = model.predict([
        "This is a test sequence",
        "This is another test sequence",
        "This is yet another test sequence",
    ])
    labels = [label[0] for label in labels]
    GT_LABELS = ["__label__3", "__label__3", "__label__2"]
    GT_PROBS = np.array([0.7821925282478333, 0.6626591682434082, 0.5143404006958008])
    assert labels == GT_LABELS
    assert all(np.abs(np.array(probabilities) - GT_PROBS) < 1e-4)

def test_site_packages_not_overly_changed():
    ORIG_SIZE = shutil.disk_usage("/mnt/cache_dir/").used
    cur_size = shutil.disk_usage("/usr/local/lib/python3.13/site-packages/").used
    assert np.abs(cur_size - ORIG_SIZE) < ORIG_SIZE * 0.5

Dockerfile 已经 pip install fasttext，下载好 model.bin，并把 site-packages snapshot 到 /mnt/cache_dir/。3 个 test 含义：

1. predict 不能 crash
2. predict 输出特定 label 和 probability（精确到 1e-4）
3. 模型不能乱 pip install（site-packages 大小变化 < 50%）

为什么模型 pip show fasttext 一步拿 0.667：

• Test 1 (test_predict_raises_no_error)：fasttext 已装，model.bin 已下载，predict 不会 crash → PASS
• Test 2 (test_correct_output)：原始 fasttext 有 bug 导致输出错（task 设定）→ FAIL
• Test 3 (test_site_packages_not_overly_changed)：模型只 pip show，没装新东西 → PASS

→ 2 / 3 = 0.6667 = task mean 一致。

模型实际 trajectory：

[assistant]:
<tool_call>{"command": "python3 -m pip show fasttext", "timeout": 20}</tool_call>
<|im_end|>

模型啥都没改，纯靠"不破坏现状"拿 2/3。

3.3 共同模式（基于 3 个 case 的 test 代码分析）

这 33 个 task 的特征：

1. 多 test 设计的 verifier，partial credit 自然出现（pytest 跑 N 个 test，accuracy = passed / total）
2. 模型不动 = 拿"基础 / 状态检查"那部分 test（test_tmux_installed / test_project_structure / test_predict_raises_no_error / test_site_packages_unchanged）
3. 真正测 task 描述要求的那些 test 是少数（往往 1-2 个），且这些是 hard 的
4. GRPO 看不出 "做对那 1 个 hard test" 与 "啥都不做拿 4/5" 的 advantage 差距：
   • 啥不做 → 0.80（4/5）
   • 改 bug 改一半 → 可能 break 其他 test → 0.40
   • 改 bug 改对 → 1.00（5/5）
   • 期望 reward 上 [0.40, 1.00] 的 risky path < [0.80, 0.80] 的稳态 → policy 学会 "stay safe"

→ eval-as-train 在 Cat B 上没意义：模型早就靠"装死也能拿 partial credit"收敛了。

---

4. Category C — Ever strict-solved (19 task / 22.1%)：模型确实学会了

4.1 范围

Bucket	n	含义	代表 task (含 strict pass rate)
strict_high (≥40%)	6	高频学会	swe-bench-fsspec 100.0% / broken-python 100.0% (n=1) / fix-permissions 92.8% / fibonacci-server 55.6% / hello-world 45.2% / vim-terminal-task 41.0%
strict_mid (10-40%)	3	中频	qemu-startup 38.3% / recover-obfuscated-files 29.6% / get-bitcoin-nodes 13.8%
strict_low (<10%)	10	偶发命中	reshard-c4-data 7.4% / prove-plus-comm 2.4% / ...

4.2 三个具体例子

例 C1：hello-world（rate=45.2%, mean=0.458）— 最简单的 baseline

Test 代码：

def test_hello_file_exists():
    hello_path = Path("/app/hello.txt")
    assert hello_path.exists()

def test_hello_file_content():
    hello_path = Path("/app/hello.txt")
    assert hello_path.read_text() == "Hello, world!\n"

Canonical solution (solution.sh)：echo "Hello, world!" > hello.txt（依赖 Dockerfile WORKDIR=/app，Dockerfile FROM python-3-13 t-bench base 预设了）。

为什么 strict pass 只有 45.2%：

模型实际 trajectory（log 里抽的样本，正好是 fail）：

[user]: Create a file called hello.txt in the current directory.
        Write "Hello, world!" to it. Make sure it ends in a newline.
        Don't make any other files or folders.

[assistant]:
<tool_call>{"name": "shell_write_content_to_file",
            "arguments": {"content": "Hello, world!\n", "file_path": "hello.txt"}}</tool_call>
<|im_end|>

reward = 0.0 for this trial：why？trajectory 看起来对，但 accuracy=0。

可能原因（log 显示 reward=0 但 trajectory 内容看似 correct）：

1. shell_write_content_to_file 工具的 file_path: "hello.txt" 是 相对路径。如果工具的 WORKDIR 不是 /app（而是 /），会写到 /hello.txt，test 检查 /app/hello.txt 失败
2. 模型常出错的变体：写 "Hello, World!"（大写 W）/ 没换行 / 多写了其他文件（虽然 test 没显式检查"无其他文件"，但 task 描述要求）

→ 45.2% strict pass 表明 45% 概率 WORKDIR 对 / 内容对，55% 不对。即使 task 描述只 1 行，8B 也搞砸 55% trial。这是 Cat C 中最简单 task 的 baseline。

例 C2：fix-permissions（rate=92.8%, mean=0.927）

Test 代码：

def test_script_permissions():
    script_path = "./process_data.sh"
    assert os.path.exists(script_path)                                # assert 1
    file_stat = os.stat(script_path)
    assert bool(file_stat.st_mode & stat.S_IXUSR)                     # assert 2: u+x bit
    result = subprocess.run([script_path], capture_output=True, text=True)
    assert result.returncode == 0                                     # assert 3
    assert "Data processed successfully!" in result.stdout            # assert 4

Dockerfile 关键状态：

COPY process_data.sh .              # host 权限 664 (rw-rw-r--)
RUN chmod -x process_data.sh        # 移除 +x（实际 no-op，本来就没有）→ 容器内 644 = rw-r--r--

process_data.sh 内容：

#!/bin/bash
echo "Data processed successfully!"

为什么需要 chmod +x：assert 2 检查 S_IXUSR (user execute bit)，初始 644 没有 → 必 fail。assert 3 调用 subprocess.run([script_path], ...)，如果没 +x，OSError: Permission denied → returncode != 0 → fail。

Canonical fix：chmod +x process_data.sh（一行）。

模型实际 trajectory（log 抽样，该 trial 居然 reward=1.0）：

[user]: A script called 'process_data.sh' in the current directory won't run.
        Figure out what's wrong and fix it ...

[assistant]:
<tool_call>{"command": "ls -l process_data.sh", "timeout": 20}</tool_call>
<|im_end|>

这个 trial 的 reward=1.0 是 anomaly——模型只 ls -l，没 chmod，理论上 4 个 assert 应该 fail 后 3 个。但 log 明确显示 accuracy=1.0。可能原因：

• slime sample logging 与 reward 计算不同步：First rollout sample 可能 log 第 1 个 sample 的 prompt/response，但 reward 字段是 group 内某个 sample（也许是其他 sample 真做了 chmod）的结果
• 或 verifier 实际宽松：例如 t-bench harness 在 trial 结束前替模型自动 chmod？需查 harness 源码

→ 单独 flag 这个 task 做 verifier audit。无论如何，平均 92.8% strict 表明多数 trial 模型确实做了 chmod。

例 C3：swe-bench-fsspec（rate=100.0%, n=475/475）— 可疑异常

Test 代码 (tests/test_outputs.py 是 pass，真测在 run-tests.sh)：

# run-tests.sh
cat > /app/test_patch.diff << 'EOF'
diff --git a/fsspec/implementations/tests/test_dirfs.py
+@pytest.mark.asyncio
+async def test_open_async(mocker, adirfs):
+    adirfs.fs.open_async = mocker.AsyncMock()
+    assert (
+        await adirfs.open_async("file", *ARGS, **KWARGS)
+        == adirfs.fs.open_async.return_value
+    )
+    adirfs.fs.open_async.assert_called_once_with(f"{PATH}/file", *ARGS, **KWARGS)
EOF
patch --fuzz=5 -p1 -i /app/test_patch.diff
python -m pip install -e .[test]
pytest -rA -v fsspec/implementations/tests/test_dirfs.py

Canonical solution (solution.sh)：在 fsspec/implementations/dirfs.py 加 12 行：

async def open_async(self, path, *args, **kwargs):
    return await self.fs.open_async(self._join(path), *args, **kwargs)

关键 question：为什么 475/475 = 100% strict pass，而模型大多数 trial 不做任何修改？

机制分析（基于 fsspec @ commit b842cf4 源码）：

• DirFileSystem 继承 AbstractAsyncFileSystem (via AbstractFileSystem)
• AbstractAsyncFileSystem 有 __getattr__ 通过 _async_method mechanism 自动把未定义的 async method 委派给底层 self.fs
• 新加的 test_open_async 用 mocker.AsyncMock() mock adirfs.fs.open_async：
  • await adirfs.open_async("file", *ARGS, **KWARGS) 通过 __getattr__ 调用到 adirfs.fs.open_async("file", *ARGS, **KWARGS)（没有 path prefix！）
  • 返回值断言 == adirfs.fs.open_async.return_value → PASS
  • 但 assert_called_once_with(f"{PATH}/file", *ARGS, **KWARGS) 期望 "PATH/file" 而模型不动时实际调用是 "file" → 应该 FAIL

但 100% pass 表明这个新测试在不打 patch 时也通过，说明：

1. 要么 _async_method 机制确实自动 prefix 了 path（DirFileSystem 早就 partial-implement 了）
2. 要么 mocker.AsyncMock 的 assert_called_once_with 在这个特定 fsspec 版本/pytest-asyncio 配置下行为异常

结论：swe-bench-fsspec 的新 test 不能区分"打了 patch"和"没打 patch"，verifier 实际上对所有模型行为都返回 strict pass。这是 task 设计层面的 verifier shortcut，不是模型真学会了。给定 100.0% 命中率（475/475 0 例外），不可能是模型真做对。

→ 这个 task 在主帖 §6.5 已 flag 为"单独排查 verifier"。是整 86 task 中最严重的 metric 污染源：贡献了 ~1/86 = 1.16% 的 Codex pass@1，去掉这个 task 重算 → 9.27% → 8.11%。

4.3 共同模式（基于 3 个 case 的 test 代码分析）

19 个 strict-solved task 的特征：

1. 结构简单 + 单步（hello-world / fix-permissions / vim-terminal-task / fibonacci-server）→ 模型能稳定输出 1-2 个 tool call 拿 strict pass
2. Verifier shortcut 异常（swe-bench-fsspec 100% 无法用模型行为解释 / fix-permissions 92.8% 单 trial 异常）→ 真实 strict pass 率可能比表面上低
3. GRPO 在这些 task 上正反馈：sample 8 个 → 1-2 个 strict success → batch advantage 强正 → policy 进一步强化 pattern → pass rate 提升

→ 9.2% Codex pass@1 主要由 5 个高频 task + swe-bench-fsspec 异常贡献。去掉 fsspec 异常后，"真实"上界约 8%。

---

5. 全 86 task per-task mean reward 分布（一图看完）

颜色编码：🔴 truly cold / 🟠 partial cold / 🟡 partial warm / 🟢 strict_low/mid/high。可清楚看到：

• 左侧 6 个深绿：模型真学会的 high-pass task（含 swe-bench-fsspec 100% 异常）
• 中间一大片黄/橙：Cat B partial warm/cold（模型有部分能力但卡 last-mile），值得做 reward shaping 实验
• 右侧 33 个红：Cat A 完全冷死，需要 SFT warmup / agent scaffolding / 模型放大才能给 reward 信号

---

6. 对 issue #10 主帖结论的精确化

主帖原说法	精确化（基于 test 代码 ground truth）
"67/86 task 整 84h 训练 0 strict success"	67 = 33 truly cold + 34 partial-no-strict。前者无法学（无梯度），后者有部分能力但卡 verifier 设计上的 hard test
"9.2% pass@1 集中 overfit 在 5 task"	准确。5 高频（fix-permissions / fibonacci / hello-world / vim-terminal / qemu-startup）+ swe-bench-fsspec 100% 异常贡献了大部分。去掉 fsspec verifier 异常 → 真实 ~8.1%
"训练侧 healthy ≠ 在学"	精确化：训练侧实际只在 ~22% (Cat C) + ~38% (Cat B) = 60% task 上有有效梯度，剩 38% (Cat A) 完全沉默
"capacity bound 真位置在 0.15-0.20"	针对当前 setup。如果 SFT warmup 解 Cat A 一部分 + reward shaping 解 Cat B 一部分，8B 真上限可能更高

---

7. 后续 actions（已加到 issue #10 §10.2）

• 方向 1（解 Cat A 33 task）：SFT cold-start，让 8B 至少能在 git/qemu/build/视觉类 task 拿到 partial credit
• 方向 3（解 Cat B 33 task）：reward shaping 加 step-level / per-test-pass，让 last-mile 阈值不再是悬崖
• 方向 5（排查 Cat C verifier shortcut）：单独审计 swe-bench-fsspec / fix-permissions 等高 strict pass task 的 verifier，确认真实 pass rate
• 方向 6（新增）：curriculum learning — 先训 Cat C / Cat B 的简单 partial，逐步上 Cat A。当前 86 task 平均混训对 8B 的 GRPO 不友好（67% 的 group 都是 hard task → 全 0 reward → 0 梯度）

[HansBug]

Per-task reward std 分析 — TB v0.1.x 作为 RL 训练集合不合适的硬证据

0. 起因 + 方法

上个 comment（#issuecomment-4384811814）从 mean reward 拆出 3 档（cold / partial / strict）。但 mean 看不出模型行为是否影响 reward —— 这才是 GRPO 是否能学的关键。本 comment 加一个维度：per-task reward 在整 84h 训练里的 standard deviation。

核心 metric：std_trial = 同一个 task 跨整 84h 训练所有 trial 的 reward 标准差（基于 Welford 在线方差公式）。

• std_trial = 0：所有 trial reward 完全相同 → 模型行为对 verifier outcome 0 影响（无论模型怎么动，verifier 都给同一个 reward）→ GRPO 8-sample group 内 advantage 数学上必为 0 → 该 task 84h 训练贡献 0 梯度
• std_trial < 0.05：变异极小 → GRPO advantage 信号被 batch 标准化噪声淹没
• std_trial >= 0.20：变异大 → 模型 8 个 sample 真有差异 → GRPO 能算出有意义的 advantage → 真正可学

数据来源（可追溯）：

• tboverfit per-trial reward：/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/logs/training_8b_tboverfit.log（grep task=<NAME>.*Evaluation completed reward=），共 37,108 trial × 85 task
• run-3 per-trial reward：/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/logs/training_8b.log，共 35,429 trial × 1367 task
• 整体指标：wandb run fdhgc9j7 (tboverfit) + wandb run msp60ius (run-3)
• Test 代码：/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/dataset/tbench_test/<task>/tests/test_outputs.py + run-tests.sh

全部 numeric claim 都在 2026-05-06 03:30 UTC 重新解析 log 后核对，与 wandb canonical 一致。

---

1. tboverfit 的 reward std 分布 — 36.5% task std=0

std bucket	task 数	占比	含义
EXACTLY 0	31	36.5%	整 84h 训练所有 trial reward 完全相同，policy 完全不影响 outcome
(0, 0.05)	6	7.1%	接近 0，零星异常但 GRPO 实际信号几乎为 0
[0.05, 0.10)	9	10.6%	弱信号
[0.10, 0.20)	22	25.9%	中等信号
[0.20, 0.30)	9	10.6%	强信号
[0.30, 0.40)	5	5.9%	强信号
[0.40, 0.55)	3	3.5%	极强信号（hello-world 0.4956 / qemu-startup 0.4866 / vim-terminal-task 0.4348）

出处：log parse 全部 85 个 observed task，求 std_trial 后按上述 bucket 分组。85 = 31 + 6 + 9 + 22 + 9 + 5 + 3 ✓。

31 / 85 = 36.5% task 的 std 是绝对 0。这意味着 84h × 320 rollout 训练里，这 31 个 task 每一个 trial 的 reward 都一模一样。GRPO 在这些 task 上严格 0 梯度。

---

2. Per-task scatter (mean × std)：一图看 8 类 task 性质

X 轴 = per-task mean reward；Y 轴 = per-task std；每点 = 1 task。横向 std=0 一字排开的红/棕带就是"policy 完全无关"的 31 个 task。

8 类 task 拆解（基于 (mean, std, strict) 三元组）：

类别	n	颜色	mean	std	strict	性质
truly_cold_flat	25	深红	0.000	0.000	0%	永远 reward=0，全军覆没
truly_cold_noisy	8	红	<0.05	0.001-0.05	0%	偶发 partial 但 mean 接近 0
partial_stuck_flat	4	棕	0.5-0.89	0.000	0%	永远拿同一个 partial reward，policy 不影响
partial_cold	12	橙	0.05-0.30	>0	0%	弱 partial credit
partial_warm	17	黄	0.30-0.99	>0	0%	强 partial credit 但碰不到 strict
strict_low	10	浅绿	varies	varies	0-10%	偶发 strict 命中
strict_mid	3	中绿	varies	varies	10-40%	中频 strict
strict_high	6	深绿	varies	varies	40%+	高频 strict

出处：log parse + (mean, std, strict) 三元组分类，25+8+4+12+17+10+3+6 = 85 ✓。

关键发现：4 个 partial_stuck_flat task 是新维度暴露的："verifier 一直给同一个 partial reward 但 policy 完全无效"。完整列表（按 mean 降序）：

Task	mean	n	std_trial	解释（test 代码 + 出处）
swe-bench-astropy-2	0.8889	472	0.0000	pytest 跑 9 个 test，模型不动 → 始终 8 PASS / 1 FAIL（新加的 lowercase 变体）= 8/9。详见 上 comment §3.2 例 B1 + run-tests.sh
swe-bench-astropy-1	0.8667	468	0.0000	类似 astropy-2，pytest test_qdp.py 中某个 hard test 永远 fail。0.8667 = 13/15 estimate
incompatible-python-fasttext.base_with_hint	0.6667	480	0.0000	3 test 中 2 PASS（无 install + import 不 crash）/ 1 FAIL（要求修 fasttext 源码）= 2/3。详见 上 comment §3.2 例 B3 + tests/test_outputs.py
cron-broken-network	0.5000	249	0.0000	2 test 中 1 PASS / 1 FAIL，模型不动也是这个结果（tests/）

31 std=0 task 的拆解（出处：log parse 三元组分类）：

• 25 truly_cold_flat（mean=0, std=0, strict=0）
• 4 partial_stuck_flat（mean>0, std=0, strict=0，上表列出全部）
• 2 strict-but-flat（mean>0, std=0, strict>0）：
  • swe-bench-fsspec：n=467, mean=0.9925, std=0.0000, strict=100%（verifier shortcut，详见 上 comment §4.2 例 C3）
  • broken-python：n=1, mean=1.0, std=0（trivially，仅 1 trial）

这 31 个 task 在 84h 训练中给 GRPO 的有效梯度严格为 0（GRPO 数学：$A_i = (r_i - \mu_{group}) / (\sigma_{group} + \epsilon)$，当 $\sigma_{group} = 0$ 时 $A_i = 0$ 对全 group 8 sample 成立）。占 ~36% 的 group 容量但贡献 0 学习信号 —— 训练算力的 36% 是浪费的。

---

3. Per-rollout reward 轨迹：8 个 task 直观对照

按 std 从低到高选了 8 个代表 task，每个画 320 rollout 的 reward mean（20-rollout 平滑窗）。全部 per-50-rollout bucket 数据来自 log parse（grep task=<NAME>.*Evaluation completed reward=，按 rollout 编号分桶后求 mean / strict pass 率）：

Group 1 — std=0 task：完美水平线（policy 完全无关）

Task	std	mean	50-rollout bucket trajectory
chess-best-move	0.0000	0.000	全 7 桶 mean=0.000 / strict=0% / fail=100%（完美水平线）
cron-broken-network	0.0000	0.500	全 7 桶 mean=0.500 / strict=0% / fail=0%（验证：2 test 1 PASS 1 FAIL deterministic）
swe-bench-astropy-2	0.0000	0.889	全 7 桶 mean=0.889 / strict=0% / fail=0%（pytest 始终 8/9）
swe-bench-fsspec	0.0000	0.9925	全 7 桶 mean=0.9925 / strict=100% / fail=0%（注：从未 hit r=1.0，每 trial 都是恰好 0.9925，verifier shortcut + 单测有 1 个不重要的 fail，详见 上 comment §4.2 例 C3）

Group 2 — std>0 task：4 个 task 都是真上升 ⭐（不是震荡，不是 plateau）

hello-world (std=0.4956, mean=0.458, strict 45.2%)：

Bucket	strict%	fail%	mean
0-49	0%	100%	0.000
50-99	0%	100%	0.000
100-149	0%	100%	0.000
150-199	47.2% ⭐	44.4%	0.514
200-249	97.5%	2.5%	0.975
250-299	100.0%	0%	1.000
300-318	100.0%	0%	1.000

→ 教科书 phase transition learning。前 150 rollout 0% strict，rollout ~150 突然学会，rollout 200+ 锁死 100%。std=0.50 是这种 bimodal 分布（前半全 0、后半全 1）的标准差，不是震荡。

vim-terminal-task (std=0.4348, mean=0.623, strict 41.7%)：

Bucket	strict%	mean
0-49	0%	0.000
50-99	2.8%	0.125
100-149	15.0%	0.585
150-199	59.7%	0.886
200-249	62.5%	0.918
250-299	83.3%	0.964
300-318	93.8%	0.988

→ 更平滑的 monotonic learning。0% → 94% strict pass over 320 rollout。

fibonacci-server (std=0.3438, mean=0.764, strict 55.6%)：

Bucket	strict%	mean
0-49	18.7%	0.367
50-99	48.4%	0.796
100-149	58.7%	0.815
150-199	70.2%	0.921
200-249	64.7%	0.850
250-299	74.1%	0.907
300-318	96.2%	0.987

→ 起点已经 19% strict（task trivial），早期快速爬到 70%，最终 96.2%。

blind-maze-explorer-5x5 (std=0.2356, mean=0.334, strict 0%)：

Bucket	strict%	fail%	mean
0-49	0%	96.9%	0.016
50-99	0%	83.3%	0.083
100-149	0%	32.5%	0.338
150-199	0%	6.9%	0.465
200-249	0%	4.1%	0.480
250-299	0%	0%	0.500
300-318	0%	0%	0.500

→ 从未 hit strict=1.0，但 mean 从 0.016 monotonic 爬到 0.500（最终所有 trial 都拿到 partial=0.5）。看起来是 verifier 对 maze task 设了一个 partial reward = 0.5 cap 的 case，模型学会了拿这个 partial 但碰不到完整解。

修订定性结论

8 个 plotted task 中 4 个是真正学了（hello-world / vim-terminal-task / fibonacci-server / blind-maze-explorer-5x5），轨迹都是 monotonic 上升，不是震荡也不是 plateau。剩 4 个完全水平线（policy 无关）。这些是"std>0 时 GRPO 信号有用"的具体证据。整 86 task 中有 17 个 task 满足 std≥0.20 即"强 GRPO 信号"档（出处 §1 表格），plot 里抽的是其中 4 个。

重要纠正：早期版本本节误描述 hello-world 为"全程震荡没有上升趋势"，实际数据是 phase transition 0→1.0。该错误来自把 std=0.50 误读为"对/错随机震荡"，未注意 0→1 的 bimodal 时间结构。已修正。

---

4. vs seta_env (run-3 训练数据) — 决定性证据

把 run-3 训练 log 也按同样方法解析：1367 个 observed seta_env task × 平均 26 trial = 35,429 trial 总（出处：相同的 task=...Evaluation completed reward= regex；run-3 task 数远多 → per-task 采样数少）。

4.1 std 分布对照

std bucket	TB v0.1.x (本 run, n=85)	seta_env (run-3, n=1367)	差距
EXACTLY 0（无 GRPO 信号）	36.5% (31)	14.7% (201)	2.5× 多
(0, 0.05)	7.1% (6)	0.3% (4)	24×
总 std<0.05（无效信号）	43.5% (37)	15.0% (205)	2.9× 多
[0.05, 0.20)	36.5% (31)	32.6% (446)	~
[0.20, 0.40)	16.5% (14)	46.0% (629)	seta_env 2.8× 多
[0.40+]	3.5% (3)	6.4% (87)	seta_env 1.8× 多
总 std≥0.20（强 GRPO 信号）	20.0% (17)	52.4% (716)	seta_env 2.6× 多

结论：

• TB v0.1.x 43.5% task 给 GRPO 提供"无效"信号（std<0.05），seta_env 仅 15.0%
• seta_env 52.4% task 给 GRPO 提供"强"信号（std≥0.20），TB v0.1.x 仅 20.0%
• seta_env 的 reward landscape 比 TB v0.1.x 适合 RL 训练 ~2.6 倍

4.2 Scatter 对照

左图（TB v0.1.x）：明显的底部红线（std=0 一字排开）+ partial-stuck-flat 群在 (mean=0.5-0.9, std=0)。

右图（seta_env）：点云散开覆盖整个 (mean, std) 平面，std=0 任务比例小很多，且这些 std=0 任务里有相当一部分是 mean=1.0（task 太简单一直 strict pass）—— 这种"确定性成功"的 task 数量上 OK，因为 GRPO 在这些上不需要学但也没浪费容量。run-3 log 中 std=0 mean=1.0 的 task 有 100+（出处：log parse mean=1.0 std=0）。

而 TB v0.1.x 的 std=0 task 里只有 broken-python (n=1, trivial) + swe-bench-fsspec (mean=0.9925, verifier shortcut，从未 hit r=1.0) 在 mean≥0.99 区间，其他都是 mean<0.05 完全冷死或 mean 0.5-0.89 的 verifier-determined partial。seta_env 的"无信号 task"是已学会的，TB v0.1.x 的"无信号 task"是学不动的。

4.3 wandb canonical 整体指标对照

wandb metric	run-3 (seta_env)	tboverfit (TB v0.1.x)	解读
terminal/accuracy mean	0.464	0.271	TB v0.1.x 整体难 1.7×
terminal/accuracy peak	0.711	0.566	TB peak 也低
terminal/non_trainable_ratio mean	2.07%	7.93%	TB 3.8× 高
terminal/non_trainable_ratio max	0.144	1.000	TB 出现整 batch 全死 spike，run-3 从未
terminal/reward_mean mean	-0.072	-0.458	TB 整体 reward 显著更低
terminal/reward_max mean	0.996	0.898	TB 即使 batch 内最高 sample 也常 < 1
terminal/reward_min mean	-1.000	-1.000	都常出现 r=-1（fail）

run-3 各项 RL 训练健康指标都显著优于 tboverfit，差距在 1.5-4× 之间。

---

5. TB v0.1.x 性质判定 — 它就是 eval set，不适合 RL training

5.1 设计层面

TB v0.1.x = terminal-bench-core==0.1.1 的 86 task，是 tbench.ai 公开 leaderboard 的评测基准。设计目标：

1. Difficulty calibration：所有 task 都做了 expert/junior time estimate（task.yaml 里），分 easy / medium / hard 三档。hard task 占比远高于"训练用数据集"应有的水平
2. Verifier strictness：用 pytest 强约束，verifier 只看最终状态（不看中间过程），这对 outcome-only RL 友好但对 partial credit shaping 不友好
3. Canonical solution 复杂度：很多 task（chess-best-move / build-linux-kernel-qemu / polyglot-rust-c）的 solution.sh 是几十行复杂逻辑或干脆 # UNKNOWN，远超 8B 模型能从 base 状态学出的能力

5.2 Reward landscape 层面（基于本 comment §1-4 数据）

维度	训练集合理特征	TB v0.1.x 实际
std=0 占比	<10%	36.5% ❌
std<0.05 占比	<20%	43.5% ❌
高 std (≥0.20) 占比	>40%	20.0% ❌
non_trainable_ratio	<5%	7.93%（且 spike 100%）❌
任务大小（多样性）	>500 task	86 ❌
reward_mean	接近 0（中性区可学）	-0.46 ❌

TB v0.1.x 在 6 / 6 维度都不达"训练用数据集"标准。

5.3 与 seta_env 对比层面

seta_env（1376 task，run-3 train data）虽然不是公开 leaderboard 数据集，但内禀属性更适合 RL training：

属性	seta_env	TB v0.1.x
数据规模	1376 task	86 task（16× 小）
std=0 占比	14.7%	36.5%（2.5× 高）
std≥0.20 占比	52.4%	20.0%（2.6× 低）
non_trainable mean	2.07%	7.93%（3.8× 高）
terminal/accuracy mean	0.464	0.271（1.7× 低）
设计目标	RL training（推断）	public eval benchmark

→ seta_env 是设计给 RL training 用的（task 数量大、难度梯度好、reward signal 多样）；TB v0.1.x 是设计给评测用的（小、严、用 expert solution 验收）。

5.4 GRPO 算力分配的硬数学

每个 rollout = 16 prompt × 8 sample = 128 trial。GRPO 在每 group（8 个 sample）内做 advantage 标准化：$A_i = (r_i - \mu) / (\sigma + \epsilon)$。

• 对于 std=0 group：$\sigma = 0 \Rightarrow A_i = 0 \Rightarrow$ 该 group 对梯度贡献 = 0
• TB v0.1.x 36.5% task 的 std=0 → 假设均匀采样，每 rollout 的 16 个 prompt 中平均 5.8 个落在 std=0 task → 5.8 / 16 = 36% 的 batch 容量 0 梯度

这数学解释了：

• 为什么 84h 训练 terminal/accuracy 从 0.174 涨到 0.355（涨幅 +0.181，run-3 0.318→0.517 涨幅 +0.199 但起点高）—— TB v0.1.x 仅 ~56% 算力实际产生 GRPO 梯度（100% - 43.5% std<0.05）
• 为什么 non_trainable_ratio 在 wandb 上看到的是 7.93% mean（这是 trial-level 的，对应 group-level ~36% 的话需要满足"group 内 8 sample 的 task 不一定全是 std=0 task"。实际上 group 内 8 sample 都是同一 prompt 多次采样，所以 group-level non_trainable 直接就是该 prompt task 是否 std=0）

5.5 结论

TB v0.1.x 不适合作为 RL 训练集合。它是 evaluation benchmark，应该且只应该当 OOD eval set 用。

为什么不适合（按硬度排序）：

1. 数据规模太小（86 task vs 推荐 1000+）：每 task 在 320 rollout × 128 trial / 86 task ≈ 477 trial。少量 task overfit 后 GRPO 一直在反复优化同样的 5-6 个 simple task。

2. 36.5% task 完全无 GRPO 信号：这 31 个 task 占 36% 算力但 0 贡献。换 seta_env 仅 14.7% 浪费。

3. 4 个 partial-stuck-flat task 是 verifier 设计陷阱（出处：§2 表，list 完整）：swe-bench-astropy-2 / swe-bench-astropy-1 / incompatible-python-fasttext.base_with_hint / cron-broken-network 这种"啥都不做就拿 0.5-0.89" 的 task 训练时reward landscape 鼓励模型不动，这是 RL 的反优化方向。

4. GRPO standardization 在 std≥0.20 task 上才有信号：TB v0.1.x 仅 20% task 满足，剩余 80% group 信号噪比 < 1。

5. 整 reward landscape 是 eval-grade hard：accuracy mean 0.27（vs seta_env 0.46），起点离 GRPO 收敛区间太远。

正确的实验流程：用 seta_env（或类似设计的 large training-grade dataset）做 RL training → 用 TB v0.1.x / TB Core 2.0 做 OOD eval。本 run 把 eval set 当 train set 跑出 9.2% Codex pass@1 的"上界"是被 reward landscape 限制后的产物，不是 capacity bound（详见 issue 主帖 §10.1 takeaway #1）。

---

6. 后续 actions（补充到主帖 §10.2）

• 方向 7（新增）：扩 seta_env 风格的 train data（target ≥ 1500 task，std≥0.20 占比 ≥ 50%），不再用 TB v0.1.x 训练
• 方向 8（新增）：在 GRPO 训练前预过滤 —— 删掉 std=0 task 节省算力（针对小 train set 场景）
• 方向 9（新增）：审计 TB v0.1.x 中 4 个 "partial-stuck-flat" task 的 verifier 设计（swe-bench-astropy-2 / swe-bench-astropy-1 / incompatible-python-fasttext.base_with_hint / cron-broken-network，详见 §2 表）—— 这些 task 的 partial credit 设计鼓励"装死"，对 RL 是 anti-pattern