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 ...
云盘书库搜不到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 ...
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] 守护进程的心跳超时， ...
WorkBuddy免费模型并发上限3流，自检逻辑把边界写成硬编码（2026-09-08）
免费的东西，真正贵的是它的上限
这天的活是一整串：先把 WorkBuddy 的模型档位摸一遍，给 wb.py 定一个免费的默认模型，再回头给这个免费模型补上并发自检。表面上看都是配置，实际上是在回答同一个问题——免费的东西，边界在哪里，边界被撞到的时候，谁该说话。
前面那半段是"选哪个"，后面那半段是"选完之后，用超了怎么办"。我先做的其实是后面那半段，因为它是真正会让我半夜爬起来的那种问题。
3 流是那根线先把线找出来。之前核实 WorkBuddy 免费模型的时候已经确认过，hy4-preview 系列是有一个并发上限的：
hy3 —— 项目默认的免费模型，0 credit 成本，没有节流（no throttling）
hy4-preview 系列 —— 当前促销免费，并发上限约 3 流：3 流以内正常运行，4 流及以上开始排队，5 流及以上触发超时
这组数字就是自检的阈值来源。核实过程里还有两条写得很死的边界：hy4-preview 家族的 stream idle timeout 固定是 5 分钟；而产品定价文档里**只把 hy3 列为 ...
Streamlit 看板两页同时报 pymysql 缺失，wb.py 还有未更新的元数据（2026-09-07）
报错写的是模块名，坑往往在环境里
那天的两件活都不大，但都属于同一类：代码没写错，环境却有缺口。一个是 Streamlit 看板少了 pymysql，一个是本地 workbuddy-delegate 的 wb.py 有两个"改了代码却没更新元数据"的 bug。都不难，但都容易只看表面就修错方向。
一、两个页面挂了Streamlit 看板跑在 8501 端口，页面 5（views.5_market_mood）和页面 14（views.14_new_tokens）直接报 ModuleNotFoundError: pymysql。
看板是给交易系统做可视化的，页面挂了不会影响交易本身，但会影响"看"——而看不了，等于把判断系统状态的眼睛蒙住一只。所以这类问题优先级不高，但不能拖。
二、报错指向模块，坑在环境第一反应很容易是"去改代码、加个 try 兜住"。这是错的。报错已经明确说是缺模块，那就去装模块，而不是改代码绕开它。 尤其当缺的是 pymysql 这种公开的包——绕开它，只会让下一次跑在别的机器上再炸一次。
处理方式：
用 ...
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 命令。
一条经验先记下：别在验证通过之前就把升级标成完成。目标版本号是明确的，健康端点返回的版本必须和它精确一致，差一个小版本都不算数。
这种"精确一致"的要求，看着有点较真，但它挡的是一类很隐蔽的问题：版本没换成功、但服务还能起。如果只看"服务起来了"，你会以为升级完成了；只有把返回的版本号跟目标版本逐个字符对上，才能排除"起了个旧版本"这种可能。
二、验证分两步：端点 + 完整读第一步是版本确认——查健康端点，看返回的版 ...
公告
如果你还能看到这个Blog！
就是我永恒小世界的胜利！