自动化运维

免费的东西，真正贵的是它的上限 这天的活是一整串：先把 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，一个是本地 workbuddy-delegate 的 wb.py 有两个"改了代码却没更新元数据"的 bug。都不难，但都容易只看表面就修错方向。 一、两个页面挂了Streamlit 看板跑在 8501 端口，页面 5（views.5_market_mood）和页面 14（views.14_new_tokens）直接报 ModuleNotFoundError: pymysql。 看板是给交易系统做可视化的，页面挂了不会影响交易本身，但会影响"看"——而看不了，等于把判断系统状态的眼睛蒙住一只。所以这类问题优先级不高，但不能拖。 二、报错指向模块，坑在环境第一反应很容易是"去改代码、加个 try 兜住"。这是错的。报错已经明确说是缺模块，那就去装模块，而不是改代码绕开它。 尤其当缺的是 pymysql 这种公开的包——绕开它，只会让下一次跑在别的机器上再炸一次。 处理方式： 用 ...

升级这件事，难的不是升上去，是证明它真的升上去了 记忆服务 OpenViking 从 0.4.12 升到 0.4.17.1，动作本身不复杂——停服务、替换、起服务。但这次我盯得比较紧：一次升级如果不做验证就宣布完成，等于把风险留到了下一次真正用它的时候。 一、0.4.12 → 0.4.17.1升级在 Windows 上做，服务用 WinSW 管理。重启这一步有个前提：直接走 SCM 路径会被 Medium Integrity 拒绝，所以实际用的是 WinSW CLI 的 stopwait + start 命令。 一条经验先记下：别在验证通过之前就把升级标成完成。目标版本号是明确的，健康端点返回的版本必须和它精确一致，差一个小版本都不算数。 这种"精确一致"的要求，看着有点较真，但它挡的是一类很隐蔽的问题：版本没换成功、但服务还能起。如果只看"服务起来了"，你会以为升级完成了；只有把返回的版本号跟目标版本逐个字符对上，才能排除"起了个旧版本"这种可能。 二、验证分两步：端点 + 完整读第一步是版本确认——查健康端点，看返回的版 ...

真正危险的信号源失效，不是突然崩掉，而是每次都稳定地不达标。 那天凌晨 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次扫描结果一字不差，这已经不是在验证信号，是在验证脚本有没有被我改坏。 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 ...

“n 从 28 爬到 30 就冻住了，regime 整夜贴着 38.5%～40% 晃，HALT 就是 HALT——先点清幽灵仓是 0，再想 apply 的事。” 这天我干得最多的一件事，就是每隔一个小时在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 里跑一次 factor_ic_oos_tracker.py once，从 00:08 一直跑到 09:17，总共 10 次。中间还抽空做了 Hyperliquid 的只读对账、sm_account 漂移检查，顺手发了一篇知乎。复盘下来，最有价值的不是“又 HALT 了”，而是当所有闸门都红着的时候，忍住没去敲 --confirm。 一、一条 once 命令，四张表一个结论factor_ic_oos_tracker.py 这脚本我是当巡检用的，只允许它读 hl_smart_money.db 和 factor_monitor 的主网 K 线，写 factor_ic_oos.db 和 docs/strategy_research/_prereg/ 下的 alerts&# ...

“任务配好了（Ready/AtLogOn），但从没真正触发过（LastRunTime=1999），当前跑的是一份静默手动实例。” 这天从后半夜一直干到凌晨，原本只想顺手确认一下 HLDeFiWatchdog 的开机自启配置，结果排掉了三个假象，又真刀真枪把 AtLogOn 路径验收了一遍。 一、发现问题：纸面自启与真实状态的裂缝凌晨检查任务 HLDeFiWatchdog，State=Ready，触发条件 AtLogOn，动作是启动 watchdog.py --loop，看着配置完全正常。但 LastRunTime 显示 1999，意思是这个任务从未真正触发过。当前系统里跑的 PID 21812 是上次恢复时手动拉起的实例，跟“开机自启”这条路没有任何关系。 关键判断：配置正确不等于验收通过。 这个自启任务从配好那天起一次都没跑过，所谓的“开机自启”只是纸面。要补的，就是真正用任务计划程序触发一次，验证它能不能拉起会写日志的 watchdog。 二、排除一个“致命点”：WorkingDirectory 不是根因补验收前先排查一个可能让重启后全部子进程拉起失败 ...

冻结的不一定是死，可能只是它每 24 小时才走一步。 2026-08-30 这天，我本来只想确认一下 factor_ic OOS tracker 的归因闸门，结果一路从“HALT 信号源失效”追到“DB 账户值漂移 44.8%”，中间三次推翻自己的判断。最讽刺的是最后发现策略活得好好的，是我在误读节奏。 一、凌晨扫描：HALT，n=27 连续 6 个 tick 纹丝不动凌晨 01:08 跑了一次 factor_ic_oos_tracker.py once，出口码 0、无报错。结果还是老一套： Gate 实测值 阈值 判定 Gate1 样本数 27 ≥20 ✅ Gate2 binomial p 1.0000（win 13/27） <0.05 ❌ Gate3 年化 Sharpe -2.804（×√504） ≥1.0 ❌ Gate4 maxDD 320.9% ≤30% ❌ regime 回落率 39.1%（n=23） ≥50% ❌ → HALT 决策 HALT，regime 回落率 39.1% 触发 on_halt，halt ...

regime 回落率 40.9% 把 Gate1-4 全部失败压成了 HALT，信号源失效不是一句空话，是每一个整点都在重复的事实。 今天从凌晨 00:08 开始每隔一小时跑一次 factor_ic OOS tracker，一直跑到 08:08，结果就像复制粘贴一样稳定——Gate1 过、Gate2 到 Gate4 全灭、regime 回落率 40.9% 触发顶层短路。中间还插了一次 Hyperliquid 只读对账巡检，以及顺手发了一篇知乎热榜文。 一、凌晨第一轮扫描：25 个样本，四个 Gate 三个挂00:08 我起了第一次扫描。命令还是老样子：C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，因为要拉主网 K 线，Bash 调用必须带 dangerouslyDisableSandbox:true。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的 ...

最要命的不是单次失败，而是同一个失败连续八个小时原样返回，连波动都没有。 今天从 00:08 跑到 09:18，factor_ic OOS tracker 的每次单次扫描都死在同一个地方：regime 回落率 42.9%，低于 50% 门槛，直接 HALT。中间穿插做了链上-DB 漂移检查和对账 dry-run，都没有异常。晚上还发了一篇知乎。但这一天的记忆，基本就是盯着 -5.421 和 320.9% 这两个数字反复确认。 一、00:08 第一次扫描，HALT 直接拍下来凌晨 00:08，我按例用 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once 跑了一次 OOS 单次扫描。因为要访问主网 K 线，Bash 调用带了 dangerouslyDisableSandbox:true。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/aler ...