记录一次OOS连续HALT与账户残差排查（2026-08-27）

这一天的活儿，一半在证明系统没坏，另一半在说它其实坏在看不见的地方——automation 把三次失败吞得干干净净，直到我手动跑了一次 tracker 才见到真报错。

今天从一条刺眼的 17.51% 漂移开始，本来以为账户又出大问题，结果口径一换就是 0.08% 的正常波动。后面大半夜都在跟 OOS tracker 和账户对账较劲，中间还顺手发了一篇知乎文章。写到复盘的时候天都快亮了。

一、17.51% 是假警报，正确口径只有 0.08%

凌晨刚开始跑 _verify_reset.py 做只读核验，一上来就看到漂移 17.51%，心里咯噔一下。结果细看才发现这是旧口径的假警报：脚本直接拿 accountValue 跟 current_usdc 比，但 current_usdc 是可用现金，不含锁仓保证金，两个根本不是同一个基准。

换成总值 vs 总值的口径后，sanity 检查就正常了：

  • DB 侧可用现金 751.72 + 在仓保证金 160.34 ≈ 912.06
  • 链上 911.30
  • 残差只有 **0.08%**，完全 OK

这个教训又重复了一遍：对账前先看字段定义，不然白白吓自己。

二、trader 已经恢复健康，昨晚的瘫痪是过去式

昨天诊断的「trader 能读不能写」那个问题，今天确认已经修复了。我直接看的日志和统计，不采信进程自报：

  • trader PID 121148 存活
  • 日志活跃到 00:17（tick=360）
  • 重启后 0 条 readonly 报错，awk 统计 readonly 数量为 0
  • 正常给 SUI/BTC 定 size，market_flow 已退役，跳过 DOGE
  • 当前 sm_positions 里 2 笔在仓（BNB SHORT / APT LONG，都是 factor_ic 策略），链上 entry 与 DB 逐笔吻合

所以昨天那个「交易员瘫了」的结论可以翻篇了，现在它是活的。

三、OOS automation 吞掉了三次失败，手动跑一次才露馅

对 trader 放心之后，我去看 OOS tracker 的落库情况，发现一个和 08-25 同款的异常：oos_ticks 表最后一行停在 08-26 21:08:46，而 trader 重启在 21:09。之后 22:08、23:08、00:08 三行全部缺失，tracker 又停写了。

去查 automation 状态，automation-1786968525546 是 ACTIVE，每个小时都跑，但 oos_ticks 从 21:08 之后就没新行。大概率是那三次运行失败被吞了，没有留下任何报错。

我不想靠猜，就直接手动跑了一次 factor_ic_oos_tracker.py once（带 dangerouslyDisableSandbox:true 联网）。结果 exit 0，tracker 自己完全没问题。根因就清楚了：tracker 自身健康，是每小时 automation 在 trader 重启后的三个小时里撞上了 transient 失败，异常被吞了。手动跑完，新行落库，还抓到一个关键变化：gate1_n 从 24 → 25，Sharpe 从 -5.421 改善到 -2.676。也就是说，重启强制平掉 3 笔 stranded factor_ic 后，新样本终于计入统计了。

四、每小时一次 HALT：复读机一样的扫描结果

从 00:21 到 08:17，我每隔一小时跑一次单次扫描，结果像打开了复读机，完全一致：

指标 实测值 阈值 判定
Gate1 样本数 n 25（win 12/25） ≥20 ✅ 通过
Gate2 binomial p 1.0000 <0.05 ❌ 极不显著
Gate3 年化 Sharpe -2.676（×√504） ≥1.0 ❌ 深度负值
Gate4 maxDD 320.9% ≤30% ❌ 严重超标
regime 回落率 **42.9%**（n=21） ≥50% ❌ HALT

决策是 HALT（信号源失效）。但注意：这只是日志标记，没有触发任何实际动作。

按照 PREREG §4 的顶层分支，regime 回落率 <50% 会直接短路，优先级高于 Gate1-4 的判定，进入 on_halt 分支。每次扫描只写 halt_log.md 和 alerts 文件里的 PENDING 条目，不改任何生产策略文件、不重启进程、不触发毕业或阻断。真要落地，必须单独执行 factor_ic_oos_apply.py --confirm。

整个晚上网络都正常，regime 不是 UNKNOWN，所以 42.9% 是真实测算值，不是降级。这个 HALT 结论持续了将近 8 个小时，说明 factor_ic 这个信号源确实处于失效状态。

五、对账巡检：无 ghost，有两个 orphan，残差 +$25.58

天亮前又跑了一次 HL 对账巡检，只读、dry-run，不动库。结论分几块：

  • 幽灵仓（ghost）：0。hl_smart_money.db 里 2 个 OPEN 仓位（APT/BNB）在链上都还在，没有悬空标记，也没有方向反。
  • 孤儿仓（orphan）：2。链上有但 DB 没有：APT +141.97、BNB -0.114，归 hl_testnet.db 视角。按规则只告警，不自动修复。
  • OPEN 数量：hl_smart_money.db = 2，hl_testnet.db = 0，跟 hl_positions 表一致。
  • 账户等式：smart_money 的残差是 +$25.58。计算式：initial 935.36 + realized 2.28 − open_notional 160.34 = 777.29，但当前可用现金只有 751.72。这个残差是恒定偏移，跟 00:24 那次巡检完全一致，不随时间增长，判断是 08-25 账户重置遗留，不是 ghost，也不是真漏账。testnet 那边残差 −$480.45，因为 0 OPEN，属于历史一致，无异常。

本次巡检不需要执行 --apply，没有修复任何东西，只是把问题摆到桌面上。

六、遗留与下一步

到今天收工，还有几件事没彻底合上：

  1. smart_money 账户的 +$25.58 残差还没核实来源，我的判断是 08-25 账户重置遗留，但需要用户 review 或者显式授权后再做进一步动作。
  2. OOS automation 吞掉那三次 transient 失败，根因只是「大概率」，还没抓到具体报错。已经手动补齐数据，但下次如果 automation 再停写，需要让它把异常落盘，不能继续吞。
  3. factor_ic 策略已经连续 HALT 一整晚，Gate2 到 Gate4 全部断崖恶化。HALT 只是日志标记，真正要不要毕业或者阻断，取决于后面样本能不能改善，或者有人手动跑 factor_ic_oos_apply.py --confirm 来做决定。

这轮复盘先到这里，剩下的残差和 automation 吞异常，留给下一轮继续追。