评测协议与模型选择

1. 指标定义

T4 不是普通的二分类 success。每条 episode 返回最终堆叠层数，评分只能取离散层数对应的分值：0 层、1 层、2 层或 3 层。若三条 fresh3 的总层数为 2，则 mean graded 是 2/9；这并不告诉我们具体是哪三条分别得到几层，除非保存逐 seed 终态。

因此报告至少要同时给出：

textseed 列表
每条 episode 的层数
0/1/2/3 层计数
完整三碗 success 数
mean graded
失败阶段（如果有可靠 trace）

2. 门禁分级

Gate A：数据和接口

• manifest、raw/processed 数量和 SHA；
• ACT loader、checkpoint、stats 和 deploy config 可加载；
• 三相机、action/state 维度、next-state 对齐通过；
• 代码包无软链接、危险路径和额外依赖。

Gate B：fresh3

只回答“这份候选有没有明显坏掉”。三条成功或高 mean graded 不是线上泛化证明。若 fresh3 未达到预设门槛，停止升级并先诊断。

Gate C：fresh10 / fresh20

要求固定 seed、相同 runner、相同 process topology。此阶段用于筛候选和发现 seed-specific failure，仍不等价于最终线上私有 100。

Gate D：完整公开 panel

只有完整、预先固定的 public panel 才可用于候选比较。不能在看过结果后修改 seed 文件或移除 setup failure。

Gate E：线上提交

线上服务的 private seeds 和 environment 是最终真值。提交前要冻结：checkpoint、stats、code root、deploy config、依赖版本、打包清单、时间和账号解锁状态。

3. 普通 runner、trace 和视频的边界

本次 clean50 trace 的 1/3, 5/9 不能覆盖普通 runner 的 0/3, 1/3，更不能覆盖线上 T4 25.3/100。

4. 失败阶段记录

不要只写 success=false。推荐按以下阶段归类：

textsetup_demo / reset
approach
grasp
lift
transport
lower
release
stabilize
final stacked-state check

但只有在保存了逐动作 trace、状态或可靠视频时才能归类。普通 runner 只有 aggregate graded 时，不应凭分数猜失败阶段。

5. 模型选择规则

1. 先保护一个代码包、stats、权重和评测证据都完整的候选。
2. 候选比较使用相同的官方 wrapper、seed 顺序和进程拓扑。
3. 先看完整三碗 success，再看 mean graded，再看层数分布和失败阶段。
4. loss 只作为训练健康信号，不单独决定提交。
5. clean50 诊断只决定下一项实验，不直接替代 exact550。
6. 任意 action alignment、数据采样、gripper loss、chunk、模型大小的变更必须单变量、独立 run name、独立 stats。
7. 训练集/专家 replay 成功不计入泛化 panel。
8. 如果后续候选低于 protected candidate，不能覆盖 protected 文件。

6. 线上结果与本地结果出现差异时

按以下顺序排查：

1. 确认上传的权重和本地候选 SHA 一致；
2. 确认 stats 是权重对应的同一份；
3. 确认线上使用的代码 root、deploy config 和本地 preflight 一致；
4. 确认没有额外 Python 依赖、软链接或绝对路径；
5. 确认公开/私有 seed 分布、任务初始状态和失败 setup 是否不同；
6. 确认 cold/persistent reset、planner warm-up、RNG 和 renderer 初始化差异；
7. 最后才讨论模型是否泛化不足。

本次线上 25.3 低于本地历史控制 fresh3 的 2/3，至少说明 public 3-seed 结果不够稳定；不能据此断言某一个单独原因已经被证明。