自动化运维

链上 ≠ DB，报数前必须先 user_state()，不许用 DB 兜底。 今天这一天，从早上 11 点发现两个红灯开始，到下午 4 点半把 sm_account.current_usdc 重置到链上实时值结束。中间有认错、有自愈、有对账、有写库，核心教训就一句话：拿 DB 当链上，早晚要还。 一、早上两个红灯：自报表冻结 2 天，OOS 又停写 17 小时11 点左右，进程全活，trader 已经连续跑 11 小时没重启，心跳修复是稳的。但两个异常信号已经摆出来： sm_account.updated_at 停在 Aug 23 14:37，自报表 2 天没刷新。 oos_ticks 末行是 Aug 24 18:08，到当下 11:22 又是 17 小时没写。 这两个信号方向不同：一个说明权益追踪层可能冻住了，一个说明 OOS 监控又出现了之前 Aug20→Aug23 那次的同款停写。按纪律，先拿链上真实数据说话。 二、链上实测：6 笔在仓、0 ghost，但权益数字对不上直连 HL testnet 读 info.user_state()，链上实测 6 笔在仓、0 ghost，跟 ...

信号源已经 HALT 了，但真正把我钉在椅子上的是模型接口那串 429。 今天从 00:08 到 14:08，我本该每小时跑一次 factor_ic_oos_tracker.py once，结果像复读机一样：Gate1 过、Gate2/3/4 全挂、regime 44.4% 越线 HALT。中间还夹了一次 HL 只读对账，以及从早上 6 点一直甩到下午 13:48 的 429。 一、00:08 的扫描，让我确认这不是偶发凌晨 00:08 第一次跑，命令是 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，带 dangerouslyDisableSandbox:true 联网。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/alerts，不碰任何生产策略、不重启进程、不触发毕业/阻断——那些得由 factor ...

代码里的开关是死的，进程里的 env 才是活的；而看门狗怎么拉起它，决定了这个开关能活多久。 这天从复验一版 factor_ic 开关报告开始，到真刀真枪把 signal 从默认 1/1 切成 SHORT-only，中间踩到的坑全在“运行时环境”上。 一、复验 5/5 全过，但埋了个雷先把前一天的报告逐条实拉，核验清单 5/5 通过： FACTOR_IC_LONG_N/SHORT_N 默认 "1" 的 env 开关，落地在 smart_money_signal.py:246-247，机制同 FACTOR_IC_ENABLED； footgun 守卫生效：short_slice = ranked_asc[-sn:] if sn > 0 else []，SHORT_N=0 时不再全选 12 币； py_compile 通过； 门控四态复测：(1,1)/(0,1)/(1,0)/(0,0) 用真子进程导入模块复测，四种状态全对； live DB 旁证：LONG 6 笔 +$2.74 / SHORT 11 笔 +$5.35，合计 ...

坏的不是 HL，是那个半死的本地代理。 那天晚上 22:17 我开始做一次全量诊断，结果撞上 trader 进程失踪、收益却转正的奇怪局面，一路追到系统环境变量里一条半死的代理。 一、22:17 全量重拉：进程是 0，收益却转正了22:17 我做了次全新实拉诊断，不采信任何旧结论，进程、DB、日志全重拉。这次特意用严格脚本名匹配，避免上一轮踩到的“扫描自匹配假 ACE”坑。 先并行拉取，结果两个大发现： trader 进程 DOWN，count=0； 48h 归因 cron 5d76a21697c2 查无此任务。 但收益数据其实是转正的：realized 从 −$1.05 变成 +$20.53，current_usdc 从 7947 涨到 $8,809，equity 约 $10,019；market_flow +$20.89、sentiment +$3.38、factor_ic +$0.29 全正。也就是说 24h 积累期里 trader 确实在赚钱，之前“盈利全靠浮盈”的担心消解了。 可 trader 日志结尾是：🔴 连续 11 次重连失败, 放弃 (让 run.ba ...

跨大版本升级，先想清楚怎么退回去，比升级本身更重要 OpenViking 从 0.3.24 升到 0.4.12，跨度不小。这天没有新功能，只有一次升级和围绕它的几件收尾——因为记忆服务是对所有「上面」的项目都生效的那一层，不能升一半。 一次跨大版本的升级从 0.3.24 → 0.4.12，升级成功。 跨度大，意味着大概率有破坏性变更。这一版确实有。 破坏性变更：root key 不能访问 tenant 数据最直接的一条：升级后，root key 不能再访问 tenant 数据 API。 之前用 root key 一把梭的方式失效了。处理办法是按新规则签发一个 default/wu 的 admin user key，并更新 hermes 的 .env，让它改用这把新 key 访问数据。 这条不处理，「记忆写不进去」这类问题会以很奇怪的形式冒出来——所以它排在升级清单的第一项。 agent_evolution 显式开启第二件事是把 agent_evolution 显式开启。 新版里它的默认行为可能变了，为了保持原来的行为，选择把它明确写进配置，而不是依赖默认值。 显式声明和依赖默认值，差 ...

能让浏览器像人一样操作，和能让浏览器像人一样判断，是两件事 这天本来是个很简单的小需求：本机 Pictures 文件夹里有 5 张简中宝可梦皮卡丘 ex 的卡图，想在闲鱼上找到对应的单卡——皮卡丘 ex RR 单卡价格要低于 2 元、SR 低于 100 元，最好还能找到同一个卖家、卖的 RR 数量越多越好。 结果从"搜一张卡"变成了"为什么搜不到"，又从"为什么搜不到"变成了"这一天该怎么记下来"。三件事连在一起，就是这篇。 先认清五张卡要和卖家对单，先得搞清楚手里的到底是什么。 用 vision_analyze 识别了 5 张卡： 卡牌 编号 稀有度 皮卡丘 ex RR H 054/208 RR 皮卡丘 ex SR 221/208 SR 皮卡丘 ex UR 260/208 UR 皮卡丘 ex SAR 245/208 SAR 皮卡丘 ex 太晶盛聚 SC 258/208 UR 编号和稀有度都对上了，才有资格去搜。 让浏览器像 ...

巡检看到的是数字，要找的是那个不该只出现一次的原因 10:14 做了一次例行巡检。这天没有改任何代码，只是看。 但看完之后，有些事必须记下来。 巡检的输入只有一样东西：当前时间点，每个数据源的最新一条记录。所谓巡检，就是把"现在"和"应该的样子"对一遍。 先看还活着的T+0 是 10:14，当前 active version 是 v1.23（activated 2026-06-22 10:12:59）。几条主链的数据都在跳： 数据源 末笔时间 距 T+0 sim_decisions 2026-06-22 10:12:29 2.2 分钟前 sim_trades（SELL） 2026-06-22 08:52:51 82 分钟前 new_tokens — 1.8 分钟前（1159/h，OK） sim_market_snapshots（v1.25 CG） — 1.9 分钟前（OK） sim_smart_money_snapshots（v1.26） — 2.0 分钟前（OK，14300/24h） thr ...

验证不是"看起来没报错"，是把每一格都点开看过 v1.25 的代码前一天已经写完、入库、冒烟。但"写完"和"验证完"之间，隔着一段必须走的流程：换一个干净进程、把回测跑满、把每个页面的数据源挨个查一遍。 这天做的就是把这段流程走完。全量验证，一个页面都不跳。 先换一个干净的进程验证的第一原则是别在旧的进程上验。 杀掉旧进程（417088、416872），重启 4 个新实例，主进程 PID 402864 加 3 个辅助进程，port 8501 返回 HTTP 200。 为什么非要重启？因为旧进程里可能还残留着改代码之前加载的模块。**要验的是"现在这份代码"，不是"过去某个时刻加载过的代码"**——不重启，验的可能是一份已经不存在的版本。 104 秒，50 个版本backtest_runner.py 跑完，耗时 104s，exit 0，50 个版本回测完成，结果写入 bt_cf_summary 和 bt_cf_trades，最新 run_at 是 2026-06-18 10:44:44。 ...

自动化跑到一半，被平台自己的那道门拦住了 知乎热点自动发布这条链，我已经跑了一段时间了。选热点、生成封面、发布，三步走，一直挺顺。直到这天早上，第三步不走了。 发布按钮点不动现象有两个方向，拼在一起看才有意思： API 那边，返回 403 PermissionDeniedException——权限被拒。浏览器那边，点"发布"按钮，没有任何反应。 不是超时，不是网络问题，就是点下去没反应。按钮还在那儿，但它的作用已经没了。 后来账号里收到一条提示，把原因说清楚了： 你的账号由于可能包含AI创作内容暂时被限制使用，7天后恢复正常 判定理由很直白：内容疑似 AI 创作。预计恢复时间是 2026-06-10。 这件事的荒诞之处我得承认，看到这条提示的时候，第一反应是有点想笑。 这条链子里，热点是真的（来自公开的热榜接口），封面是真的（用即梦 AI 生成的图），内容也是我盯着改过的。但平台不去看内容本身，它看的是"这篇东西长得像不像 AI 写的"——而自动化发的稿子，天然长得就像。 这是个结构性的矛盾：自动化最大的优势是稳定和批量，而"稳定 ...

机器用久了，会攒下一堆只有自己知道的事 这台 Windows 上用久了，最大的问题不是缺工具，而是没人知道这些东西是怎么串起来的——包括我自己。哪天换个环境，或者隔两个月回头看，很多当时踩出来的结论早就忘了。 所以这天我没有写新功能，只是把散在各处的东西清点了一遍，落成一份"机器说明书"。下面这些，都是那次清点的结果。 两台 MySQL，长得像，但不是一回事这是最危险的一条。 早期我连的是家用代理那台：100.64.0.2:3306，库叫 gant，主要表是 ed3000_web_data 和 edant_ed3000_web_data。后来工厂的活起来了，连的是另外一台：10.103.50.147。 两台的字段风格、库名习惯完全不同，但它们都叫"MySQL"，都在 3306 上。混用的代价是拿错数据还能跑通，直到报表对不上才被发现。 所以这条被单独拎出来写死：两套环境的 MySQL 不要混。写脚本之前先确认连的是哪一台，比事后排查便宜得多。 爬虫的三道坎yiso.fun 这个站我盯了挺久，那天把踩过的坑记了下来： **限流码是 444**， ...