核心 case · C11
EgoStandard与UMI缓存异常子集补跑
同权重修复前后配对：UMI312局、Standard282局。
2026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。
人的最终 Review
待审尚无明确的最终评审意见。
本 case 的 token 总数
待关联这次要做到什么
修复纹理读取后，对两模型受影响布局配对判断变化。 两模型受影响布局严格配对，区分缓存变化与机器/版本混杂；整组总结
实际做到什么
UMI313局、312严格配对，Standard282局全配对；缓存读取告警为0；两报告均明确无净提升不证明无影响。
使用的 Skill
缺少实际使用及版本证据，待核对原执行。
Agent 初评
理解3/4 / 交付3/4 / 可靠3/4 / 协作2/4
这个 case 收到的反馈
有诊断追问与人的当时推断，非明确终态好评
缓存报错影响什么，需要同条件证据
人提出观察与试验假设；补跑没净提升不能证明无影响。原话中“看来不影响”保留为人的当时判断。
处理结果：两模型补跑及日志已交付，结论按配对与混杂边界收敛。
下一步：暂无
纹理缓存错误是什么东西？怎么理解？会影响我们结果的准确性吗？来源 1 ↗
解释一下我们现在的纹理缓存读取错误是个什么问题？它会影响我们的评测结果吗？但是看起来好像只有我们训练的几个 ego 开头的评测分数比较低，然后纹理缓存问题比较大？来源 1 ↗
哦，所以说我们现在证明的，就是说这个评测的低分不能归结于缓存。但是呢，这个缓存报错长期还存在，这个问题本身也需要确认，就是它到底是影响缓存命中和我们的执行效率，还是说真正对结果有影响？我觉得这个事可能是更值得去分析定位的。你能看一下这里这个缓存报错究竟会导致什么结果以及我们该怎么修复它呢？来源 1 ↗
有没有一个正常的环境 & 缺失缓存后环境效果图差异的展示？另外这个问题的影响面有多大？来源 1 ↗
感觉完全看不出区别，那可能结果就还好。但是我们能不能跑一些实验，拿正常的，完全一样的配置跟这种缓存出现问题的配置做一下对比，然后 验证一下两个成功率有没有差异，这样的话就比较直观的证明问题会不会比较严重。现在我们不是有一些缓存出问题的这种执行结果，然后我们先看一下有没有能完全对照上的正常结果来分析。然后如果没有的话，我们就跑几轮评测验证一下。来源 1 ↗
拿现在快跑完的200局来对比，跟缓存报错的那部分比较，成功率有明显的上升吗？来源 1 ↗
那看来这个 bug 不影响结果，但我们也没理由让报错继续留着，这个问题修复不出现了吧。还有其他类似这种 warning 级别的异常吗来源 1 ↗
下一步如何判断和改进
建议先核对下面的证据缺口，再补充人的最终 Review；已有结果在原验收范围内判断。
已读UMI/Standard配对报告；相机画面与环境改动是可比性边界。
展开过程：运行范围、耗时、资源与返工
运行范围
UMI313局，312严格配对；Standard282局全配对。前后布局对齐，纹理读取告警归零；无净提升不证明纹理无影响。
关键时间与耗时
整次交办总时长本批未完整核得，不以两条报告发布时间相减。
资源使用
沿已有评测选受影响布局补跑，避免全量重跑；不以修复后少报错推断吞吐改善。
返工与人工介入
预期补测不计返工；同话题后来C12改变非纹理环境导致95局9成功→0并回滚，单独保留负例。