Hyperliquid 链上余额与数据库漂移两个数量级，A2 扫描同步排查（2026-10-07）
链上余额 7.2042，库里躺着 13203.71，漂移 183178.86%，这不是阈值超了，是基线已经飞出去两个数量级。
今天原本只想做几个只读检查，结果第一条命令就直接把红色告警拍在脸上。后面又跑了一次 A2 OOS tracker，还顺手确认了一篇知乎文章的发布回执。
一、20:05，_sm_sanity_check.py 直接甩出 ALERT当时我在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 里跑一条 sanity check，命令是 C:/ProgramData/anaconda3/python.exe -u _sm_sanity_check.py，Bash 调用必须带 dangerouslyDisableSandbox:true，因为脚本要访问 HL testnet 外网。
脚本 stdout 打印了 ALERT，退出码 1。关键数字如下：
指标
数值
链上余额 chain
7.2042
DB 总值 (cur+open_margin=80.14)
13203.7100 ...
A2 样本连续二十多轮停在 n=19，maxDD 格式化缺陷同现（2026-09-30）
样本冻结本身不是风险，真正的风险是把 stdout 里的 427.8% 当成写库真值。
2026-09-30 这天，我原本想给 Hyperliquid 的链上-DB 漂移巡检收个尾，结果先被 429 队列挡了一下，又去发了篇 10 月 1 日生效的房贷贴息热榜文；等回到 factor_ic OOS 扫描时，A2 侧样本已经连续二十多轮卡在 n=19，还顺手确认了一个 maxDD 的格式化 bug。
一、早上的 HL 对账巡检，被 429 拦了一下按计划，我先在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 下跑 Hyperliquid smart_money 账户的链上-DB 漂移检查，脚本是 _sm_sanity_check.py，只读，不加任何 --apply。结果对话里先冒出来一串 429 queue.full.title 和 429 queue.waiting.title，脚本的完整 stdout 一直没拿到。后面我又补了一条只读对账巡检，跑 hl_reconcile.py（默认 dry-ru ...
A1 判 HALT 与 A2 判 NO_ACTION 在同套 factor_ic 下并存，关键在阈值门差异（2026-09-29）
A1 判 HALT，A2 判 NO_ACTION，同一天、同一套 factor_ic，结论完全相反——但并不是谁错了，而是它俩卡的门完全不一样。
2026-09-29 这天，从凌晨 00:40 到早上 05:56，我基本住在 factor_ic OOS tracker 的扫描输出里。两个 arm 轮流跑，中间还插了一次 Hyperliquid 的只读对账。最后没毕业、没阻断，但有几个数字和判断值得记下来，尤其是那个 stdout 的 maxDD 百分号 bug 和 A2 样本池六轮一动不动。
一、A2 那边：n=19 冻结六轮，NO_ACTION 一路到底A2 的扫描从凌晨 00:40 的第 75 轮开始，我在终端里守着看它输出表。Gate1 样本数 19，阈值是 ≥30（A2 更严），直接 ❌；Gate2 binomial p 0.6476（win 8/19，胜率 42.1%），远大于 0.05，❌；Gate3 年化 Sharpe −7.477，❌；Gate4 maxDD 写库是 4.2782，按真实值 ≤30% 是 ✅，但 stdout 打印 427.8%，后面 ...
Hyperliquid testnet 只读巡检与策略归因，代理变量清空防 502（2026-09-28）
只读不写是今天所有操作的第一原则，而样本量不足时，不出结论就是最正确的结论。
今天在 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 做了三件只读的事：HL testnet 对账巡检、策略级归因分析、factor_ic OOS tracker 双轨扫描。一整天下来，没动一行策略代码、没重启任何进程、没写一次生产库。以下按时间顺序复盘。
一、HL testnet 只读对账巡检上午先跑 hl_reconcile.py，默认 dry-run，不加任何写参数。启动前必须先把系统代理变量清空，否则容易 502：
123456set HTTPS_PROXY=""set HTTP_PROXY=""set http_proxy=""set https_proxy=""set ALL_PROXY=""set all_proxy=""
然后执行：
1C:\ProgramData\anaconda3\python. ...
假 PnL 追踪到链上未知仓位，smart-money 保证金被占死（2026-09-22）
真正让 trader 停摆的不是某个策略赚不到钱，而是链上有一批它自己根本不知道的仓位，正死死占着保证金。 今天这份复盘，本质上是把 09-11 那笔 -$98.57 的 orphan_reconcile 假损失给翻了个底朝天——最后发现我们之前一直在跟自己的影子打架。
一、早上先查盘面：11 天没开新仓今天 09:58 我启动诊断的时候，第一反应是“别又是策略逻辑写挂了”。psutil 里能看到的一串进程全是 ALIVE：smart_money_trader 10s 主循环在 tick=140，smart_money_signal 每 15s 左右写一次日志，watchdog 09:54:36 刚跑完一轮，streamlit_dashboard 端口 8501 返回 HTTP 200。看起来系统全活。
再看 sm_account 表，09:47:40 的快照写着 current_usdc=10045.98，realized_pnl=+51.19，W/L=58/57。单看这个账面，trader 就是“没在交易”，不是死了。
但 ...
HL smart_money 漂移353%撞上OOS样本冻结16，A2静默动作暴露风险（2026-09-21）
基线不重置，漂移 353% 就是迟早的事；样本连续 68 轮冻结在 16，A2 的 NO_ACTION 只是看起来无害。
今天从一条 HL smart_money 的 ALERT 开始，到下午 A1 tracker 甩出一个 429 收尾。中间还跑了一轮对账、查了个开机弹窗、顺手发了一篇知乎热榜稿。
一、HL smart_money 漂移检查：353.43%，还是那条 legacy 基线上午按计划跑 _sm_sanity_check.py，根目录脚本已经不在，只有 wb_runs/archive/ 里的归档副本。直接用 C:/ProgramData/anaconda3/python.exe -u 跑归档副本，输出一行 ALERT：
chain：$2,215.57
db_total：$10,045.98（含未平保证金）
drift：353.43%，阈值 5.0%
退出码 1
DB 总值还悬在 legacy 名义基线 ~$10,046，链上真实余额只有 ~$2,216，差约 4.5 倍。和 09-05 起连续 8 次 ALERT 是同一个根因：testnet 重置后 sm_accoun ...
127 笔平仓记录复盘确认 SL 放宽为负优化并已回退（2026-09-20）
“67% 的 5% 止损触发不是假摔，是真崩盘。”
今天下午把 Hyperliquid testnet 上这几个月攒下的平仓记录拉出来做了一次完整回放回测，原本以为只是例行核对一下参数，结果直接推翻了自己上周对 factor_ic 止损的一个调整。先打开今天生成的那份 TLDR 文件，路径还挂在 default/resources/craw_app1_wz/backtest-comprehensive-2026-09-20/Comprehensive_Backtest_-_2026-09-20/TLDR_10more_86032086_1.md 下面，光看摘要就意识到问题不小。
一、背景：127 笔平仓，5 个策略一起回放这次回测的样本是数据库 hl_smart_money.db 里 127 条已平仓记录，时间跨度从 2026-07-30 到 2026-09-10，全部是 HL testnet 的模拟单。覆盖 5 个策略：factor_ic、sentiment、token、market_flow、smart_money。回放工具用的是 ...
Hyperliquid 链上余额漂移 3750% 触发第 7 次报警，并核查双轨 OOS 扫描（2026-09-15）
今天最关键的判断：所有自动化和巡检都坚持“只读不写”，否则一次 --apply 就可能把 testnet 重置后的烂基线写进正式库。
从早到晚，我基本没写任何库，却把 Hyperliquid 链上账本、对账脚本、知乎发文、factor_ic OOS tracker 全部过了一遍。几件事表面互不相关，内里都在验证同一件事：脚本告诉你的“正常”和“异常”，到底能不能信。
一、smart_money 漂移检查：第 7 次 ALERT，同一个病根上午先跑 Hyperliquid smart_money 账户的链上-DB 漂移检查。命令很直接：
cd "C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard" && C:/ProgramData/anaconda3/python.exe -u _sm_sanity_check.py
结果一出来就是红色：
chain（链上真实余额）：260.9216
db_total（DB 净值 + 未平保证金）：10045.9839
drift：3750.19 ...
MES报表WORKER_NUM口径反了，工位利用率被除成零（2026-09-14）
不要急着改前端，先拿 SQL 把 572 万行逐行比对钉死——老表的 WORKER_NUM 就是真实人数，上一版却按 ×10 把它除成了 0。
2026-09-14 这天挺满。上午刚把 Hyperliquid testnet 的 drift 3341.32% 告警挂出去，下午就被叫去修一个 MES 报表：工位利用率、出勤时间、有效工时，显示得全不对。表面看是前端渲染有问题，实际一查，口径从根上就反了。
一、问题现象：所有指标都长得不对劲接下活的时候，用户给的是 100.64.0.2:3306 上 m3_ai_data 库的 work_load_0521 表，里面有示例数据。前端报表展出来的工位利用率、出勤时间、有效工时，没一个看着合理。当时我没急着动逻辑，先让脚本把表的概况拉出来。
这一拉就发现问题不小：
AREA 一共 14 个，前端只认 5 个；
MAIN_AREA 分布是 TST1 约 450 万行、TST2 约 77 万行、TST3/TST4 各约 22 万行；
WORKER_NUM 的值是 '0'~'7'，看着像真实人数，但我们上一 ...
Hyperliquid sm_account 链上-DB 漂移3502.97%又是基线脱钩问题（2026-09-13）
数据新鲜不代表没脱钩，drift 3502.97% 说明链上权益和 DB 基线已经差了约 36 倍，先确认是不是预期回撤，再决定重置。
9 月 13 号晚上我又盯上了 craw_app1_wz 项目里的 Hyperliquid smart_money 账户，担心 testnet 重置再把 sm_account 的基线和链上搞脱钩，于是让助手跑了一次只读检查。结果直接触发 ALERT，而且漂移幅度远超阈值，又是一次典型的 reset 脱钩。
一、为什么跑这次检查这个 sm_account 基线脱钩已经不是第一次出现了。之前 09-05、09-06、09-08、09-11 都出现过类似模式：DB 里的基线没跟着链上权益更新，testnet 一重置，两边就错开一大截。所以当天我特意安排了一次例行防脱钩检查，目的就是看基线有没有再次和链上脱开。
检查脚本是 _sm_sanity_check.py，放在项目目录 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 下面。我让助手必须用 Bash 工具执行，并且打开 danger ...
公告
如果你还能看到这个Blog！
就是我永恒小世界的胜利！