核心 case · C16
公开OpenWAM60k首次全量回归
2100局完成；Score17.01，提交至完成2小时14分。
2026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。
人的最终 Review
待审尚无明确的最终评审意见。
本 case 的 token 总数
待关联这次要做到什么
先建立可追溯实跑数据，并比较历史及公开结果。 核权重/seed/54配置2100局与6300视频；历史只在真实可比范围对照
实际做到什么
过程交代资源等待、兼容修改、实际并发、有效进度和尾部；最终报告含逐能力/任务成绩、同权重25局配对、布局替补与独立审计。最终报告：https://qcnatfwzm13g.feishu.cn/docx/MHYedtYuiofWFWxovuRcg29DnNe
来源 1 ↗使用的 Skill
缺少实际使用及版本证据，待核对原执行。
Agent 初评
理解3/4 / 交付3/4 / 可靠3/4 / 协作3/4
这个 case 收到的反馈
正常选型/接口问题；未见完成后的明确质量评价
公开OpenWAM为何还要独立旧合批机制
统一接口不应导致每模型一套调度；本次缺口是通用B4拆批，保留原生预处理。
处理结果：已补兼容并实跑；后续权重复用。
下一步：暂无
另外我想确认一个点，旧合批工具怎么理解。为啥这个旧版 openWAM 还有自己的一套机制？我理解现在的 adapter 接入后其实就统一接口我们自由调动了才对，怎么这个公开 openWAM 接入似乎比一个我们给的新权重还麻烦？来源 1 ↗
下一步如何判断和改进
建议先核对下面的证据缺口，再补充人的最终 Review；已有结果在原验收范围内判断。
已读原话题与完整最终报告；本轮整理未重跑审计。相同权重不等于全部运行条件相同：单会话→合批、release/model revision均变；不能把−4pp归因于训练。原话题链接在原话题字段。
展开过程：运行范围、耗时、资源与返工
运行范围
seed0；54配置、2100有效局；Run v3-public-openwam60k-regression-full2100-s0-20261013。正式五类等权Score17.01/SR11.98%；253成功。6300视频/产物哈希审计通过；18替补布局、2次基础设施恢复。历史严格可配范围只有stack_bowls25局，不能宣布全任务回归通过。
关键时间与耗时
北京时间10月13日14:23要求试跑；14:51获准回收旧模型；14:59:32提交，14:59:43首worker，17:13:23终态，17:33报告送达。提交到终态2h13m52s；交办到报告约3h10m（消息分钟精度）；初始排队11s。准备/换模/许可等待含在交办总时长，不能全算推理耗时；累计GPU小时缺测。
资源使用
先查队列及推理服务，评测空闲但推理8–15卡驻留Ego-UMI；确认后换成8公开权重副本，配8评测卡，每卡4进程×最多8环境，推理B4/20ms。16:01快照32worker/244环境；尾部缩至2worker/16环境有任务组成原因。报告后仅有模型清理交接，未证实已释放。
返工与人工介入
公开旧封装共用动作缓存且8行请求未按B4拆分，补通用兼容；酒嘉年确认8×4×8并批准回收8旧副本，这是资源授权，不算Agent错误。其后质询“为何公开权重另有旧机制”，Agent纠正解释。13局基础设施故障在原Run恢复，18布局替补；没有报告者重跑整轮的证据。