假 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 ...
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 ...
云盘书库搜不到harness工程实战，免费源0命中的不撒谎策略（2026-09-11）
书名可以搜不到，库里不能多一本编出来的书
主人要找 2026 年一本新书《harness 工程实战》，入库到云盘书库 E:\yunpan_hub。难的不是找，是它在免费源里搜不到时，怎么给一个既不空手、也不撒谎的结果。
先确认这本书是真的它对应 2026 年一本真实出版的商业书：陆徐洲《Harness Engineering 实战：构建可靠的生产级 AI Agent》，ISBN 978-7-121-53224-5，电子工业出版社，2026-08，376 页。
真书，但免费源里没有。**"存在"和"能下到"，是两份不同的结论。**
把免费源翻了一遍09-11 当天实测：pansou 的 26 个 TG 频道、alupan plugin、夸克 / 百度全部 0 命中；web 搜索只命中零售平台；GitHub / Z-lib 无收录——书太新（< 2 个月），网盘还没收录。
0 命中常见的三类原因：没配代理、书太新、--exclude 太严。第一条最容易栽——国内搜网盘必须走 Clash HTTP 代理（socks5h:// ...
130秒规律暴露心跳守卫误判，交易worker反复重连（2026-09-10）
最危险的不是进程死了，而是它还活着，却已经很久没说过一句话
这天前后处理了几件看起来不相干的事：换掉一个 VLM 模型、给一个本地转发进程补 timeout、修交易 worker 的心跳、核正一份自动判定、读一份策略审计。等它们在记录里排到一起才发现，说的其实是同一件事——每一个长期运行的环节，都得持续向系统证明自己还活着。一旦它不再说话，系统不会立刻崩，它只会安静地做出一个错误的判断。
下面按当天实际处理的顺序记。
从一条 130 秒的规律开始监控里最先扎眼的是这个数：交易 worker 每隔约 130 秒就重连一次，节律几乎不抖。
反复核过之后，这个 130 秒不是巧合——它刚好等于连接守卫的超时阈值 + 平均一次重连所需的耗时。也就是说，重连不是网络断了，是被守卫"误判"成断了：它等了太久没等到该有的时间戳刷新，就按超时处理，断线，重连，然后 130 秒后再来一遍。日志里这种由"陈旧"引发的心跳超时，一次会话里数到了 3885 次。
顺着 _last_success_ts 往下挖连接守卫的判定本身很简单：当 _last_success_t ...
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 ...
OpenViking 记忆服务升级验证版本号精确一致（2026-09-05）
升级这件事，难的不是升上去，是证明它真的升上去了
记忆服务 OpenViking 从 0.4.12 升到 0.4.17.1，动作本身不复杂——停服务、替换、起服务。但这次我盯得比较紧：一次升级如果不做验证就宣布完成，等于把风险留到了下一次真正用它的时候。
一、0.4.12 → 0.4.17.1升级在 Windows 上做，服务用 WinSW 管理。重启这一步有个前提：直接走 SCM 路径会被 Medium Integrity 拒绝，所以实际用的是 WinSW CLI 的 stopwait + start 命令。
一条经验先记下：别在验证通过之前就把升级标成完成。目标版本号是明确的，健康端点返回的版本必须和它精确一致，差一个小版本都不算数。
这种"精确一致"的要求，看着有点较真，但它挡的是一类很隐蔽的问题：版本没换成功、但服务还能起。如果只看"服务起来了"，你会以为升级完成了；只有把返回的版本号跟目标版本逐个字符对上，才能排除"起了个旧版本"这种可能。
二、验证分两步：端点 + 完整读第一步是版本确认——查健康端点，看返回的版 ...
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！
就是我永恒小世界的胜利！