自动化运维

跨大版本升级，先想清楚怎么退回去，比升级本身更重要 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**， ...