Daily Report — 2026-09-24
Daily Overview
- 工作内容： 工作涉及为资源管理实现复杂的架构变更 (TokenMonitor)，完善 robotics 控制规则 (I-166)，对训练失败进行深度诊断分析 (RoboMemory)，以及在 MIHD 和 Minecraft 服务器环境中进行系统维护与优化。
- 工作方式： 通过结合本地命令测试、远程评估运行、自动化数据处理/视频分析、代码探测以及使用基于 Web 的工具进行成本效益计算来开展活动。
- 影响： 这些工作通过更好的资源调度（减少 CPU spike）提高了系统稳定性，通过 prerequisite latching 增强了 robotics policy 的准确性，为“为什么 low loss 无法确保成功”提供了关键的诊断见解，并恢复了测试套件的完整性。
今日工作涵盖了多样化的活动，包括为 robotics 实现 prerequisite latching 规则，开发用于资源优化的 serial refresh 架构，诊断 robotic tasks 中的训练 loss 差异，以及解决 MIHD 仓库中的测试回归问题。
Tasks
Architecture & Strategy
- ❌ I-166 (Prerequisite rule implementation & closed-loop re-runs) — 使用新的 prerequisite rule (PRE_K=3) 为 framesamp（所有 14 个 tasks）和 seg_sum（受影响的 tasks）完成 closed-loop runs，以防止过早的 memory marks。
- 🔄 Serial Refresh Implementation (S1-S10) — 一个多阶段工作流，旨在消除 refresh 浪费，实现 FIFO compute gate，在 samples 之间冻结数值，并部署新的 single-owner scheduler。
- ✅ Implement I-164 (Per-task loss evaluation) — 开发一个工作流，按 task 和 phase 重新计算 flow-matching loss，以诊断特定的失败原因。
- ✅ Plan Budget Estimation (I-074) — 实现基于“已花费金额除以利用率百分比”来估算 plan 的美元预算的逻辑，包括针对每个 model 的准确度以及 Codex 的历史 backfilling。
- 🔄 Implement I-163 (Context evaluation) — 实现新的 context window 变体 (1/3/5 frames) 以及用于 Gemini 评估的结构化 segmentation summaries。
- 🔄 Draft SPEC-2 for trainable parameter counting — 创建一个规范，以自动化统计各种 fusion modules 和 references 中的 trainable parameters 及 total parameters。
Implementation & Fixes
- 🔄 Full-scale I-163 execution — 等待人类对规模的决策 (a: 5 tasks/10 eps vs b: 4 tasks/5 eps)。
- ✅ Fix golden fusion-gen dual-write mismatch — 更新 tests/test_golden_fusion_gen.py，以反映在 commit eb3f29d 中引入的有意的 gt/gt_labels dual-write。
- ✅ Analyze failure videos — 查看 StopCube 和 InsertPeg 的失败视频，以识别行为模式。
- ✅ Minecraft server resource optimization — 分析当前 m8a.xlarge 实例的 CPU/RAM 使用情况，并评估更便宜的迁移选项 (r6a.large, t3a.large 等)。
- ✅ Command usage testing — 反复调用 /usage 命令以检查稳定性或特定的输出模式。
Problems & Solutions
Critical Issues
1. ButtonUnmask tasks 中的 early memory marks 导致 policy 跳过 subgoals。
Solution: 在 writer_probe/gemini_v2_env 中添加了一个 ‘prerequisite_done’ latch，要求在视觉/物理感知到第一步之后，必须连续获得 3 个 ‘done’ 信号才能启用 marks。
2. StopCube 具有 low training loss 但 low success rate。
Solution: 重新计算了 phase-specific loss 并分析了 error distribution，发现 loss 被 ‘waiting’ phases 主导，从而忽略了关键且持续时间短的 ‘pressing’ timing error。
3. 一次性刷新所有数据导致 CPU spikes 和 UI stuttering。
Solution: 设计了一个 scheduler，将独立的 jobs (archiving, pricing, budgeting) 均匀分布在 refresh interval 中，并使用单一的 atomic publish。
4. Duke LiteLLM proxy 的 API quota exceeded。
Solution: 等待用户重置 quota 或注入新 key。
5. 由于固定的 ±20% error margin，初始的 budget estimation 太不精确。
Solution: 实现了一种“基于 stretch”的校准方法，利用一个 model 占主导地位的离散 segments 来计算每个百分点点的真实成本。
6. InsertPeg 失败模式不明确。
Solution: 分析了 loss 和视频，确定这是一个 contact-precision 问题，而不是 memory 或 learning 问题。
7. Codex limit estimation 缺乏新安装环境的历史数据。
Solution: 构建了一个专门的 log parser，直接从现有的 Codex session JSONL 文件中 backfill plan budget 数据。
General Issues
8. Golden test ’test_golden_fusion_gen.py’ 因输出数组的 assertion mismatch 而失败（预期仅为 ‘gt’，而 pipeline 现在写入 ‘gt’ 和 ‘gt_labels’）。
Solution: 通过 git log (eb3f29d) 确认 dual-write 是为了统一 schemas 的有意架构决策；更新了测试以断言两个 keys 并验证它们的相等性。
9. Minecraft server 在新的 r6a.large 实例上进行 player chunk generation 时出现 lag (TPS drop)。
Solution: 确定原因是高负载 chunk generation 期间只有一个 physical core (2 hyperthreads) 的限制；建议减少 view distance 或使用 pre-generation tools。
10. AI 尝试使用 shell redirection/piping，这被 system guard 拦截。
Solution: 切换到使用 Edit tool 来写入文件，并移除了 bash 命令中的 redirection，以符合安全约束。
11. 在长时间运行的 remote tasks 期间出现间歇性 tunnel failure。
Solution: 集成了自动 tunnel reconnection 逻辑，并通过 remote sleep/ssh 监控 session health。
Human vs AI Approaches
Strategic Level
Loss as a metric for success
| Role | Approach |
|---|---|
| Human | 质疑为什么 low loss 不会转化为 high success rates。 |
| AI | 计算了 loss concentration (top 5% share) 和 phase-specific statistics，以证明平均 loss 掩盖了关键的 timing errors。 |
Difference Analysis: 人类提供了关键的直觉/问题（为什么存在这种差异），而 AI 提供了数学推导和诊断框架。
Refresh Scheduling
| Role | Approach |
|---|---|
| Human | N/A |
| AI | 提出了各种 scheduling fixes 和 individual job optimizations。 |
Difference Analysis: 人类规定了核心架构需求：任务必须分散在 interval 中以防止 spikes，且 UI 只有在计算出的数据准备就绪时才进行 refresh，在此期间显示 cached values。
Budget Estimation Methodology
| Role | Approach |
|---|---|
| Human | N/A |
| AI | 最初提出了一种简单的 spend/utilization ratio，并带有静态的 ±20% error margin。 |
Implementation Level
Codebase debugging (Stale assertions)
| Role | Approach |
|---|---|
| Human | 提供了失败的初始 context，并指出了导致 drift 的特定 commit (eb3f29d)。 |
| AI | 系统地探测 codebase 以寻找被初始 crash 掩盖的“隐藏”失败，并在第 432 行发现了第二个 stale assertion。 |
Difference Analysis: AI 通过循环运行单个 test functions 的能力，使其能够发现用户尚未察觉的错误。
Decision on PickHighlight truth
| Role | Approach |
|---|---|
| Human | N/A |
| AI | 实现与 80k ckpt 一致的 prerequisite rule（在按钮按下前不要绘制）。 |
Difference Analysis: 用户需要确认这是否与 9/23 的新 truth definition 冲突。
AI Limitations
Critical Limitations
- AI 未能考虑到不同 models 对 total limit 的影响速率不同（例如 cache hits vs. full input），导致早期估算不精确。
General Limitations
- AI 最初在处理由 environment guard 强制执行的 shell command syntax 约束（redirection/piping）时遇到困难。
- 由于 repository security guards（保护 ‘git commit’ 动词），AI 无法直接执行 git commit，需要人类执行最终命令。
Learnings
Key Learnings
- 在成功取决于单一、短暂且关键动作窗口（例如 StopCube timing）的长程任务中，Average loss 可能会产生误导。
- 通过单个 model 使用的 ‘stretches’ 来计算 budget，提供了一种能够适应 provider 变化的自我修正准确性机制。
- training loss 与 success rate 之间的 Rank correlation 可能很低 (-0.51)，尤其是在 ’easy’ 阶段稀释了 loss 时。
Practical Learnings
- 对于 Minecraft servers，相比于原始的 vCPU 数量，CPU core count（physical cores vs hyperthreads）和 single-core speed 对于 chunk generation 期间的稳定性更为关键。
- 当脚本在某一行失败时，同一脚本中后续的其他 assertions 也可能是 stale 的；必须手动探测单个 test functions 以确保完全覆盖。
Conversation Summaries
Claude Code Environment
✅ Repetitive /usage command testing 用户连续多次执行 /usage command，以观察系统行为和 command response 的一致性。
RoboMemory
✅ Diagnostic analysis of StopCube and InsertPeg 分析了失败视频并重新计算了 phase-specific losses。发现 StopCube 失败是因为视觉 ‘badge’ 信号相对于所需动作时机的更新太晚。InsertPeg 被确定为精度问题。
TokenMonitor
🔍 Serial Refresh Architecture Design 21:52:42.000 | claude_code 用户请求转向 ‘serial refresh’ 模型以防止 CPU spikes。启动了一个复杂的多阶段 workflow 以实现：1. 实现 timeouts，2. 每小时归档一次数据，3. 实现一个 FIFO compute gate，以及 4. 创建一个新的 master scheduler (refresh.rs)。该 workflow 目前正在执行 S9 和 S10 阶段。
✅ Plan Budget Estimation Implementation 04:35:20.677 | claude_code 用户请求一项功能，用于显示 AI plans 的预估 USD budgets。AI 实现了一个通过 usage/utilization ratios 计算 budget 的系统，为 Claude/Kimi 添加了 historical archive，并从本地 logs 中回填了 Codex 数据。测试已通过，UI 已更新为带有紧凑、感知单位的 budget labels。
MIHD
🔍 Parameter Counting SPEC 起草了一份详细的技术规范 (SPEC-2)，用于统计 NCL 的可训练参数、ablation studies 以及诸如 QueST 和 STAIG original 等外部引用。
✅ Fix golden fusion-gen dual-write 调查了 test_golden_fusion_gen.py 中的失败原因。确定 commit eb3f29d 为 ‘gt’ 和 ‘gt_labels’ 引入了刻意的 dual-write。更新了 test suite 以预期这两个 keys，确保所有 14 个 golden tests 通过。
Minecraft Server
✅ Cost and Performance Analysis 分析了 AWS instance 的使用情况和定价。确定与当前的 m8a.xlarge 相比，迁移到 r6a.large (16GB) 或 r8a.large (16GB) 能在成本和稳定性之间提供更好的平衡。