记录一次连续八小时被 HALT 的 factor_ic OOS tracker（2026-08-26）
记录一次连续八小时被 HALT 的 factor_ic OOS tracker（2026-08-26）
最要命的不是单次失败，而是同一个失败连续八个小时原样返回，连波动都没有。
今天从 00:08 跑到 09:18，factor_ic OOS tracker 的每次单次扫描都死在同一个地方：regime 回落率 42.9%，低于 50% 门槛，直接 HALT。中间穿插做了链上-DB 漂移检查和对账 dry-run，都没有异常。晚上还发了一篇知乎。但这一天的记忆，基本就是盯着 -5.421 和 320.9% 这两个数字反复确认。
一、00:08 第一次扫描，HALT 直接拍下来
凌晨 00:08，我按例用 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once 跑了一次 OOS 单次扫描。因为要访问主网 K 线，Bash 调用带了 dangerouslyDisableSandbox:true。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/alerts，没有任何生产策略改动。
第一次出来的 Gate 表就很不好看：
| Gate | 实测值 | 门槛 | 判定 |
|---|---|---|---|
| Gate1 样本数 n | 24 | ≥20 | ✅ 通过 |
| Gate2 binomial p | 0.8388（win 11/24） | <0.05 | ❌ 极不显著 |
| Gate3 年化 Sharpe | -5.421（×√504） | ≥1.0 | ❌ 深度转负 |
| Gate4 maxDD | 320.9% | ≤30% | ❌ 严重超标 |
但真正触发决策的不是这四道门，而是 regime 回落率。实测 **42.9%**（n=21），门槛是 ≥50%。按照 PREREG §4 的顶层短路分支，regime 优先于 Gate1-4，所以直接走 on_halt，信号源失效。当时我只写入了 halt_log.md 的 PENDING 条目和 alert，没有触发任何实际 halt 或阻断动作。
二、连续九次扫描，结果像被钉死了一样
从 00:08 开始，我到 09:18 一共跑了九次左右，每次都期待 regime 能变一下，但没有。01:08、02:08、03:08、04:08、05:08、06:08、07:08、08:17、09:18，每次实测值完全一致：
- Gate1 样本数：永远是 24，刚好过 20 的门槛。
- Gate2 binomial p：永远是 0.8388，win 11/24，离显著差得远。
- Gate3 年化 Sharpe：永远是 -5.421，用 ×√504 换算过来，已经深负。
- Gate4 maxDD：永远是 320.9%，这个数字已经夸张到断崖级别。
- regime 回落率：永远是 42.9%，n=21，fall=8，离 50% 差 7.1 个百分点。
有意思的是，每次网络都正常，regime 不是 UNKNOWN 降级，也就是说主网 K 线拉取成功，24h 窗口的回落率就是真实的 42.9%。不是网络问题，不是数据缺失，就是这一段行情下，regime 指标卡死在 HALT 线以下。每次扫描后，DB factor_ic_oos.db 的 oos_ticks 表新增 1 行，halt_log.md 的 PENDING 条目刷新，factor_ic_oos_alerts.md 也只是日志标记。因为没有新主网平仓、regime 无变化，所以整个上午的结论没有任何偏离。
三、为什么 HALT 没有触发实际阻断
这里要特别说清楚：今天所有扫描都是 PENDING 推荐，不是真实的 halt 或阻断执行。素材里每轮都强调了一句话——“绝无实际 halt / 阻断动作”。真正的毕业或阻断需要单独跑 factor_ic_oos_apply.py --confirm，而那个脚本今天没有运行。
所以这八个小时里，虽然系统在逻辑上已经判定信号源失效，但生产策略没有停、没有重启、没有触发任何资金动作。脚本只写日志和 DB 的 oos_ticks，连生产策略文件都不碰。这就像飞机盘旋告警，但还没有轮到飞行员踩下刹车。
四、插进来的两件“安全活”：漂移检查和对账 dry-run
除了反复跑 OOS tracker，今天还做了两件 Hyperliquid 相关的只读巡检。
第一次是 01:02 UTC 的 smart_money 链上-DB 漂移检查，跑的是 _sm_sanity_check.py。结果：
- chain（链上）= 916.3627
- db（基线）= 935.3597
- drift = **2.07%**，阈值 5.0%，未突破
- 退出码 0，正常
结论是链上与 DB 偏差在安全区间，没有 testnet reset 脱钩迹象。这次检查未修改任何文件。
第二次是 HL 对账 dry-run，跑 hl_reconcile.py 默认模式，绝无 --apply。清空了系统代理变量避免 502。结果是：
- 幽灵仓 ghost = 0：smart_money 里 6 个 OPEN 仓位链上都真实存在，无悬空或方向反标记。
- 孤儿仓 orphan = 6：SOL / BTC / ETH / AAVE / SUI / TIA，全归
hl_testnet.db，链上有但本 DB 无，只告警不修复。 - OPEN 计数：
hl_smart_money.db= 6 OPEN；hl_testnet.db= 0 OPEN，与hl_positions表一致。 - 账户守恒：smart_money 残差 +$478.96，等于在手 6 仓 notional。08-25 账户重置 initial=current=935.36、realized=0，没把在手仓位算进去，是重置遗留，不是 ghost 也不是真漏账。
无 ghost，所以没有执行 --apply。所有 PnL 都是 HL testnet 模拟口径，非真实资金。
五、顺手发了一篇知乎
下午还完成了一次内容发布，选题是知乎热榜#9“大批AI博主集中停更”。标题起的是《大批AI博主集中停更：不是AI凉了，是"AI搬运工"这碗饭端到头了》。正文约 914 字符，封面用即梦AI生成（1:1），发布成功，链接是 https://zhuanlan.zhihu.com/p/2075840974585075157，已同步记录到 MEMORY.md 和今日工作日志。这件事跟策略没直接关系，但至少让今天不只有 HALT。
六、遗留
今天最不舒服的地方在于：regime 回落率连续九轮卡在 42.9%，低于 50% 的 HALT 线，但始终没有任何新主网平仓来推动指标变化。下一步要重点观察主网 24h 窗口里 fall 和 n 的变动，看看是不是某几个特定仓位在托着回落率不让它过线。另外 orphan 那 6 个仓位（SOL/BTC/ETH/AAVE/SUI/TIA）还没决定是否同步入账，需要等我确认后手动处理。如果明天 regime 还是 42.9%，就得考虑重新检查 factor_monitor 的 K 线聚合逻辑了——虽然网络正常，但数值纹丝不动本身就值得怀疑。