记录一次被 429 卡了一上午的 OOS 扫描（2026-08-24）
记录一次被 429 卡了一上午的 OOS 扫描（2026-08-24）
信号源已经 HALT 了，但真正把我钉在椅子上的是模型接口那串 429。
今天从 00:08 到 14:08，我本该每小时跑一次 factor_ic_oos_tracker.py once，结果像复读机一样：Gate1 过、Gate2/3/4 全挂、regime 44.4% 越线 HALT。中间还夹了一次 HL 只读对账，以及从早上 6 点一直甩到下午 13:48 的 429。
一、00:08 的扫描，让我确认这不是偶发
凌晨 00:08 第一次跑，命令是 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，带 dangerouslyDisableSandbox:true 联网。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/alerts，不碰任何生产策略、不重启进程、不触发毕业/阻断——那些得由 factor_ic_oos_apply.py --confirm 单独执行。
跑出来的数字是这样：
| Gate | 实测值 | 阈值 | 判定 |
|---|---|---|---|
| Gate1 样本数 | 24 | ≥20 | ✅ 通过 |
| Gate2 binomial p | 0.8388（win 11/24） | <0.05 | ❌ 极不显著 |
| Gate3 年化 Sharpe | -5.421 | ≥1.0（×√504） | ❌ 严重转负 |
| Gate4 maxDD | 320.9% | ≤30% | ❌ 严重超标 |
| regime 回落率 | 44.4%（n=18） | ≥50% | ❌ HALT |
决策直接走 PREREG §4 的顶层短路：regime 回落率 <50% 优先于 Gate1-4，进 on_halt，信号源失效。 网络正常，主网 K 线取到 n=18 的真实样本，不是 UNKNOWN 降级。看到这组数我就知道，今天接下来的所有扫描都会是同一张脸。
二、每小时复读，数字一字不差
从 01:08 到 05:08，每次结果的确完全一致。本小时没有新增主网平仓或入场完成 24h 窗口，regime 稳定在 44.4%（n=18），Gate 指标一直 n=24、Sharpe=-5.421、maxDD=320.9%。这种“无变化”本身就有信息量：不是突然挂了，而是已经挂了很久，扫描只是每小时确认一遍。
02:08 那次我特意在记录里写清边界：只读 hl_smart_money.db 与 factor_monitor 主网 K 线，只写 factor_ic_oos.db 与 docs/strategy_research/_prereg 下的日志/alerts，没改任何生产策略文件。这算是给自己吃定心丸：HALT 归 HALT，环境是干净的。
三、顺手做了一次 HL 对账，没有 ghost
当天还跑了 Hyperliquid 只读对账，dry-run，没加 --apply。先按守恒口径复核：smart_money 用 initial + realized_pnl − open_notional ≈ current_usdc，testnet 同理，0 OPEN。结论如下：
- 无 ghost 仓位（0）：
hl_smart_money.db里 6 个 OPEN 仓位链上都还在，没有悬空或方向反。 - orphan 6 个：SOL/BTC/ETH/AAVE/SUI/TIA，全归
hl_testnet.db，较上次新增 AAVE。 - OPEN 计数：
hl_smart_money.db= 6 OPEN，hl_testnet.db= 0 OPEN；smart_money 从上一轮 5→6，是链上新开仓，不是异常。 - 账户守恒：smart_money 残差 +$0.89（已知历史偏移，无害）；testnet 残差 -$480.45，正好等于 6 个链上 orphan 的市值未入 DB，不是真漏账。
所以不需要 --apply，只告警不写库。 所有 PnL 都是 HL testnet 模拟口径。
四、上午的 429，才是真正的停机事故
从 06:08 之后再发起扫描，就一直撞同一句报错：
429 您的使用量已超出频率限制，将在 2026-08-24 13:48:12 UTC+8 重置，您也可以切换其他模型继续使用。
我试了好几次，不管发 factor_ic_oos_tracker.py once 还是对账指令，回复永远是一串 429，后面跟一个 request id（这里不贴）。这跟策略状态无关，纯粹是模型接口频率配额用完。OOS 扫描的 HALT 没让我停工，429 反而把整个自动化流程从早上 6 点断到下午 13:48 重置。
中间我还见缝插针地把一篇知乎热榜稿发出去了：标题《宇树机器人100米小组垫底：不是机器不行，是「人形」这个赛道太急了》，链接 https://zhuanlan.zhihu.com/p/2075115964773970241，正文约 706 字符。这算当天唯一一件跟量化无关但顺利交付的事。
五、14:08 恢复，结论没变
13:48 重置后，14:08 那次 once 扫描终于跑通，退出码 0。结果和上一窗口 06:08 完全一致：Gate1 n=24 通过；Gate2 p=0.8388；Gate3 Sharpe -5.421；Gate4 maxDD 320.9%；regime 44.4% HALT。网络正常，regime 取到 n=18 的真实主网 K 线，不是 UNKNOWN。
这一整天，策略侧没有新的坏消息，也没有新的好消息。坏消息都是那串 429 带来的。
六、遗留
factor_ic_oos.db和_prereg日志已经落盘，但on_halt只是标记，后续要不要手动干预factor_ic_oos_apply.py --confirm还没定。- HL 对账的 orphan 6 个仍只告警，尤其新增的 AAVE 要单独决定是否入库。
- 429 的根因是模型接口配额，13:48 重置后能跑通，但明天如果还按这个频率扫，得提前算好配额，或者换备用模型。
下一步：把每小时扫描的频次和模型配额对齐，别让 HALT 决策被 429 打断。