假 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 ...
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 ...
130秒规律暴露心跳守卫误判，交易worker反复重连（2026-09-10）
最危险的不是进程死了，而是它还活着，却已经很久没说过一句话
这天前后处理了几件看起来不相干的事：换掉一个 VLM 模型、给一个本地转发进程补 timeout、修交易 worker 的心跳、核正一份自动判定、读一份策略审计。等它们在记录里排到一起才发现，说的其实是同一件事——每一个长期运行的环节，都得持续向系统证明自己还活着。一旦它不再说话，系统不会立刻崩，它只会安静地做出一个错误的判断。
下面按当天实际处理的顺序记。
从一条 130 秒的规律开始监控里最先扎眼的是这个数：交易 worker 每隔约 130 秒就重连一次，节律几乎不抖。
反复核过之后，这个 130 秒不是巧合——它刚好等于连接守卫的超时阈值 + 平均一次重连所需的耗时。也就是说，重连不是网络断了，是被守卫"误判"成断了：它等了太久没等到该有的时间戳刷新，就按超时处理，断线，重连，然后 130 秒后再来一遍。日志里这种由"陈旧"引发的心跳超时，一次会话里数到了 3885 次。
顺着 _last_success_ts 往下挖连接守卫的判定本身很简单：当 _last_success_t ...
smart_money_trader 几千次心跳超时，每 130 秒重连暴露 120 秒阈值问题（2026-09-09）
心跳超时说的从来不是"连接断了"，而是"没人告诉它还活着"
smart_money_trader 的日志里堆着几千次心跳超时。表面看是网络不稳，但一台机器如果真烂到每两分钟断一次，它早该被停掉了——交易进程却一直在跑，仓位也没乱。所以这次不猜，先把它拆开看。
这一天的活，从头到尾只有一件事：把"到底是谁在超时"查清楚。 修不修得好是第二步。
先看清风暴的形状先把原始日志预解析了一遍，而不是凭印象判断。
reconnect_preanalysis.json 记录的这场风暴，时间跨度是 2026-08-18T22:00:00 到 2026-09-05T13:57:21。进程侧的 _HEARTBEAT_TIMEOUT 是 120.0 秒，stall_profile.jsonl 里的分析确认了一件事：重连的节奏大约是 每 130 秒一次——正好对上"超时阈值 + 重连周期"。
预解析里还埋着一个更早的坑。第一次统计出来的心跳数是 4355，但这个数字是错的：它把 470 次 [SIGNAL] 守护进程的心跳超时， ...
OOS tracker 多轮扫描中 A2 样本冻结在 16，Hyperliquid 对账确认零幽灵仓（2026-09-06）
“在量化系统里，一整天零翻转、零幽灵仓，就是最好的巡检结果。”
今天从 00:55 的 A2 扫描开始，到上午的 Hyperliquid 对账结束，我基本都在做重复但必要的检查：两套 tracker 并行跑，一条短腿 HALT，一条长腿攒样本，最后再确认链上账本没有幽灵仓位。
一、A2 长腿：样本连续冻结在 16凌晨 00:55–00:56，A2 OOS tracker 第 28 次执行，命令是 factor_ic_oos_tracker_a2.py once，走 anaconda python，带 dangerouslyDisableSandbox:true 访问主网 K 线。这一轮结果非常干净：
Gate1 样本数：16，但 A2 阈值是 ≥30，所以直接 ❌；
Gate2 binomial p：1.0000（win 8/16），完全不显著；
Gate3 年化 Sharpe：-5.080，远低于 1.0；
Gate4 maxDD：412.4%，严重超限；
regime 上升率：75.0%（n=16），≥50% ✅ OK。
决策是 NO_ACTION——reg ...
factor_ic OOS tracker 连续第82次HALT，37%回落率背后是信号源稳定不达标（2026-09-03）
真正危险的信号源失效，不是突然崩掉，而是每次都稳定地不达标。
那天凌晨 1 点刚过，我照例让自动化去跑 factor_ic OOS tracker。到早上 8 点 15 分，屏幕显示“第 82 次”，结果还是那一串熟悉的数字：regime 回落率 37.0%，HALT。一晚上什么都没变，但这恰恰是最值得记录的地方。
一、第 74 次到第 82 次，全部 HALT凌晨 01:08，第 75 次扫描 summary 先发过来：Gate1 样本数 31，通过；Gate2 binomial p 0.7201（win 14/31），不通过；Gate3 年化 Sharpe −2.732，不通过；Gate4 maxDD 320.9%，不通过；regime 回落率 37.0%（n=27），阈值 50%，触发 HALT。
命令是 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，Bash 里带 dangerouslyDisableSandbox:true 才能访问主网 K 线。脚本只读 hl_smart ...
连扫24轮全是HALT的factor_ic，排查重点是脚本是否被改坏（2026-09-02）
连续24次扫描结果一字不差，这已经不是在验证信号，是在验证脚本有没有被我改坏。
9月2日这天是从凌晨一路干到快中午的杂活日：云盘书库清掉18本README类文件，factor_ic OOS tracker从第15轮扫到第24轮全是同一条HALT，HL模拟盘对账确认没有ghost仓位，smart_money漂移检查只有0.16%，顺手还发了一篇知乎热榜文。
一、先把云盘书库里的“README”清出去改四个文件，删十八本“书”
白天最先处理的是云盘同步链路里的书库污染。之前同步时把云盘根目录下的 LICENSE、README、sitemap 这类文件全当书入库了。这次在 config.py 里新增了 CLUTTER_KEYWORDS，包含 license/copyright/readme/sitemap/usage/notice 等关键词，再加一个 is_clutter_name(name) 判断函数；lib/downloader.py 下载过滤时加 not is_clutter_name(...)，lib/ebook_scanner.py ...
公告
如果你还能看到这个Blog！
就是我永恒小世界的胜利！