0. 文档用途与 Schema 版本
本文档把 SWE-bench eval 管线里所有分析指标做成一张可导航的表，每项标注：字段路径、中文含义、聚合方式、对齐到 plan.md 的哪张图/哪个实验、已知缺陷。
v0.2 (
taco-swe-v0.2)：由src/analysis/build_trajectory.py在每个 task 完成时落盘到*_trajectory.json。正在跑的 eval 产出的就是这个版本。v0.3 (
taco-swe-v0.3)：post-hoc 升级，由src/analysis/rebuild_v03.py从 v0.2 升级得到*_trajectory_v03.json。修正 v0.2 的规则假阴性（validation_after_edit、other_bash细分）+ 加 semantic-equivalent / per-phase latency /reward_eval_share。聚合层：
.claude/skills/trajectory-analyzer/analyze.py。所有 v0.3 新字段在聚合时即可从 v0.2 原始字段重算，不必等 rebuild_v03。
1. 数据来源（每 task 产物）
Schema 顶层：{schema_version, instance_id, data_id, task, rollout, token_usage_total, steps, outcome, derived}。下面的字段路径都省略这一层前缀。
2. 指标分类
2.1 规模与结果（Scale & Outcomes）
2.2 Latency 分解 → 图 1
plan.md §4.3 图 1：SWE trajectory latency decomposition。目标是把"这个 rollout 为什么慢"拆成 LLM decode / tool exec / reward eval / queue 四块，证明 tool 尾 ≠ LLM 尾。
Trajectory-level（每任务一行）
Step-level
聚合产出：每个 step 的 llm_latency_s / tool_latency_s 汇总。
v0.3 新增
latency_by_phase— 按 phase 分桶（localization/patch/verification/env_setup/inspect等）分别给 LLM/tool 的 P50/P95/total。图 1 的真正 motif：patch-phase 的 LLM P50 是 localization 的 3.3×（n=199 实测 4.85s vs 1.48s）。reward_eval_share=reward_eval_s / wallclock_s，每任务一个 ratio，用于判断"慢 trajectory 里有多少锅是 sandbox 的，不是 agent 的"。实测 P95=65.6%。
判定（judgment.experiment_1_long_tail）
2.3 Phase 结构 → 图 2
plan.md §4.2–4.3 图 2：phase transition graph（localization → patch → test 的 motif）。
v0.2 phase 标签
来自 classify_phase，src/analysis/build_trajectory.py:410：
localization / other_bash / patch / edit_bash / inspect / test / submit / early_surrender
字段表
v0.2 的 bug
VERB_TEST = {pytest, tox, unittest, nosetests, make, ...} 不含 python，导致 python -m pytest、python manage.py test、python reproduce.py 全部被 first_test_step 漏掉，进而 validation_after_edit 恒为 False。
v0.3 修复
rules_v03.is_validation_command 拓宽匹配：
test runner 裸词：
pytest/tox/unittest/nosetests/jest/rspec/mvn test/gradle test/npm test/go test/cargo testpython -m pytest|unittest|nose|toxpython <path>/manage.py test|runtests.py|run_tests.pypython <path>/reproduce*|repro*|test_*.py|*_test.py|tests/*.pymake check|test
新字段：
derived.phase_summary.validation_after_edit_v03— 拓宽后的判定derived.phase_summary.validation_commands_v03— 命中的原始命令（供 spot-check）
n=199 实测：97.5% 任务实际跑了验证，192 条被 v0.2 漏报。
v0.3 other_bash 细分
rules_v03.reclassify_bash_intent：v0.2 把 33% 步数塞进 other_bash，图 2 motif 会糊。v0.3 拆成：
n=199 实测：原 33% other_bash → verification 15.5% + env_setup 15.5% + exploration 0.6% + truly_other 0.5%。
工作流闭环判定（judgment.workflow_health）
原先因 validation_after_edit bug 一直报 ❌ broken，修正后应为 ✅ healthy。
2.4 Outcome overlap（hunk 行级）→ 实验 2 / 图 3 / 图 4
plan.md 实验 2：失败轨迹里有多少 salvageable signal。
文件级（v0.1 保留，语义粗）
Hunk 行级（v0.2 新增，用于 C4 salvage 主论证）
v0.3 新增
derived.failure_analysis.semantic_equivalent_patch—resolved=True AND hunk_line_jaccard_overall < 0.1。强先验：测试通过但没碰 gold 行 = 语义等价实现（或 gold 过拟合）。n=199 实测：18.8% 的 resolved 任务属于这批，不剔除会严重污染"hunk recall 作为 resolve 代理"的论证。
判定
judgment.experiment_2_salvage：
salvageable = near_miss + useful_patch_attempt + useful_localization≥ 50% → ✅ / 25–50% → ⚠️ / < 25% → ❌
judgment.near_miss_sharpness：near_miss 的 hunk recall 分布
≥50% 命中 recall ≥ 0.5 → ✅ sharp
≥50% recall=0 → ⚠️ misleading（文件选对但行错，需要再切
near_miss_line_matchvsfile_only_match）
2.5 Tool Capability
判定（judgment.tool_capability）
2.6 Thinking-lite → 图 5
plan.md §1.5：不要直接吃 raw thinking，但用轻量 thinking 特征预测 resolve。
v0.1 布尔（保留但已弃用聚合）
v0.2 连续（主力）
图 5 readiness 判定
任一布尔饱和或死 → ⚠️，必须用连续 density/ngram 维度。
Schema 缺口提醒（schema_gaps 自动 surface）
uncertainty_expressed布尔饱和 > 90% → 弃用聚合，只用 densityrepeated_reasoning_steps（sha1 exact）死 → 用reasoning_ngram_max_pair替代
2.7 Stratification → 图 6
plan.md §4.3 图 6：confound-controlled analysis。关键：不分层 → difficulty 和 repo 会偷换长度信号。
聚合产出（stratification）
by_difficulty[]：每桶{n, resolved, resolved_rate, resolved_rate_ci95, insufficient_n}by_repo[]：同上v0.3 保护：n < 5 的桶不输出 rate，标
insufficient_n: true，避免"1/1=100%"或"0/1=0%"的误导
新增 by_loop_presence：按 loop_segments 是否为空分 {with_loop, without_loop}，对比 resolved_rate / hunk_recall_mean / wallclock_s_mean。
图 6 readiness
≥2 difficulty 桶有 n≥20 → ✅
2.8 Correlation → 实验 3
plan.md 实验 3：length-only scheduling 是否够用（Heddle/SortedRL 假设）。反驳路线：长度相关弱，过程特征相关强。
Marginal（correlations_with_resolved，Pearson 与 resolved）
v0.3 新增 partial corr（控 difficulty）
correlations_partial_difficulty：
by_bucket：每个 difficulty 桶（n≥10）内的 Pearsonpooled_weighted：n 加权平均用途：marginal corr 里 length ↔ resolved 的 -0.32 看着中等，partial corr 若接近 0 就说明 length 只是 difficulty 代理。n=199 实测 partial -0.30，几乎不变 → length 信号是真的。
判定 judgment.experiment_3_scorer
2.9 AReaL-only 字段（当前 null）
→ 对应 plan.md §5.1 Target 2（stale risk）、Target 3（learning utility）、§6.3 AReaL async control。
3. 判定阈值（analyze.py::_judge 权威）
实验 1（tool vs LLM 长尾）
tool_P95/P50 ≥ 5× AND ≥ 2×·LLM_P95/P50 → ✅ strong
tool_P95/P50 ≥ 3× OR ≥ LLM_P95/P50 → ⚠️ mixed
否则 → ❌ weak实验 2（salvage 率）
salvageable = (near_miss + useful_patch_attempt + useful_localization) / n
≥ 50% → ✅ strong
25–50% → ⚠️ mixed
< 25% → ❌ weak实验 3（length-only 不够）
|corr(num_steps, resolved)| < 0.2 且 corr ≤ 0.05 → ✅ strong
0.05 < corr < 0.3 → ⚠️ mixed
corr ≥ 0.3 → ❌ weak ← plan 立论失败图 readiness
workflow_health
validation_after_edit 率 < 10% 且 context_before_edit 率 < 30% → ❌ broken
validation_after_edit 率 < 30% 或 context_before_edit 率 < 50% → ⚠️ weak
其余 → ✅ healthy4. v0.3 Roadmap
5. 用法速查
# 实时分析（任何时候都可以跑，对正在跑的 eval 零干扰）
python .claude/skills/trajectory-analyzer/analyze.py \
--workdir <path> --out agg.json --per-task-out per_task.jsonl
# Eval 跑完后升级到 v0.3（增量模式，跑多少次都安全，默认 skip 已有）
./run_eval.sh rebuild_v03
# 或显式指定目录
python -m src.analysis.rebuild_v03 --workdir <path>
# 想重写已有 v03 文件（改了规则后）
python -m src.analysis.rebuild_v03 --workdir <path> --overwrite6. 主要结论指向（n=199 quick read）
实验 1：⚠️ mixed（tool P95/P50 ≈ LLM P95/P50，per-phase 拆分后 patch-phase LLM 是 localization 3.3×）
实验 2：⚠️ mixed（30%+ salvageable，hunk-recall 在 near_miss 上 ✅ sharp）
实验 3：⚠️ mixed（length 相关 -0.30，partial corr 确认真信号）
workflow_health：修正 v0.2 bug 后 → ✅ healthy（97.5% 任务跑验证）
6 张图：1/2/3/4/6 均 ✅ ready；图 5 需要只用连续 density 维度