Forever BLog

记录一次优化清单（2026-09-04）系统跑得动，不代表它没有一堆欠账 那天没有急着写新功能，而是做了一次系统深潜——把交易系统从上到下过了一遍，把"该修、但一直没修"的事一条条捞出来，收成一份优化队列。深潜的副产品，是几个早就该做的接通和改造。 一、先把清单本身立起来清单不是随手记的备忘，它得能当队列用。所以它的形态是一个结构化目录：optimization_todos，落在 1viking://resources/craw_app1_wz/queue/optimization_todos_1 它来自 2026-09-04 的一次系统深潜，用途写得很明确——作为交易系统改进任务的有序队列，按优先级排。 先有清单，再谈排期。 没有清单的时候，优化永远是"想起来才做"，而想起来的，往往是最不痛的那一条。 这件事看着像在整理文档，其实是先给自己立一个"可执行的容器"。一套系统跑久了，欠账是散着的：有的藏在某个脚本的注释里，有的只在某次事故的复盘里被提过一句，有的就是"知道有问题但没空管"。深潜的作用，就是 ...

记录一次夜里的异常（2026-08-23）一晚上三条"死因"，长得像同一个症状 有些夜里，你会以为在处理一个 bug，其实是四个。那天从 OOS 停写查起，查到最后发现：一条 3 天的数据空洞、一个设错位置的超时、一笔拖了 4.6 天才被硬止损的仓，还有一行缺了 global 的赋值。它们互不相干，却在同一晚一起发作。 一、停写三天的 OOS先看最表面的：factor_ic_oos.db.oos_ticks 从 08-20 18:08 之后就再没写入了，空了 3 天。 runtime_state 给出了另一半答案：next_run_at=None，last_run_at=1787220565（≈08-20 18:08）——调度器在那之后就没再排下一次运行。automation 配置本身还是 ACTIVE，状态显示正常，那只是假象。 代码侧的根因，是 compute_regime()（L177）里的 fetch_candles 没有任何 try/except： 沙箱/网络异常 → fetch_candles 抛异常 → 冒泡到 main()（无 ...

记录一次毕业门槛的落地（2026-08-17）一个策略能不能"毕业"，不该由它自己说了算 前几周 factor_ic 一直在攒样本，但"攒到什么时候算成、什么时候算废"，始终没被写成硬规则——靠人看、靠感觉判。这天我把这件事做完了：把门槛冻进 PREREG，再落一个每小时跑一次的跟踪器，让它替人盯着。 一、先把门槛冻死动手写码之前，第一件事是冻结。 PREREG 的三处关键约定——L73 / L75 / L104——逐条核验通过，完全冻结生效。§10 里原本还留着两处"未冻结项：7 天阈值、3 次 tick 阈值——实施阶段按实际数据决定"，这次一并回填成硬值： KILL 触发 = 7 天（一周复盘周期，够短能响应、够长不误杀） regime halt 升级 = 连续 ≥3 tick tracker tick = 1h（故 3 tick = 3h） tick 为什么定 1h，也写明了理由：5min 太密、OOS 没意义；6h 太慢、KILL 响应要等 18h。1 ...

记录一次研究框架的固化（2026-08-16）研究的成本不在跑一次回测，而在第五次重复研究同一个已经被否定的方向。 08-16 这天没有跑新策略，而是把"以后怎么研究新策略"这件事，固化成了文档。 起因是下午的一次毕业提议——想把唯一赚钱的那条策略从小仓升到标准仓。结果自己的数据把提议推翻了。于是那天明白：比定策略更急的，是先定"研究策略的流程"。 一张卡，8 条规矩那天落盘的第一份文件是 NEW_STRATEGY_RULES.md，8 条硬规则： R1：未填策略卡禁止写代码 R2：新策略必须先核对已 KILL 族边界，不在 KILL 表才能进入预注册 R3：预注册必须冻结 3 个独立 gate + 自动毕业 / halt 动作，主人不手动执行命令 R4：策略 KILL 后必须回写 KILL 族边界，避免重复踩坑 R5：预注册冻结后禁止调整阈值，调整必须重写预注册 R6：毕业 / 停止决策由智能体自动判断，主人保留否决权 R7：新策略必须资源隔离（独立预算、独立 watchdog、独立 OOS 跟踪），不污染现有运行策略 ...

记录一次单腿的确认（2026-08-15）数据库里说开着一笔空单，链上却是多单——那一刻要确认的，是这一条腿到底是不是真的。 08-15 例行对账时，发现 hl_testnet.db 里躺着一条很老的 OPEN 记录。对账这件事平时看起来很枯燥，但它偶尔会拽出一笔"幽灵仓"——数据库以为还开着的仓位，链上其实早就不存在了。 一条 25 天的 SOL 空单最先跳出来的是这一条： hl_testnet.db 有 1 个 OPEN 仓：SOL SHORT @ $77.246，开仓时间 2026-07-22，距今约 25 天。 25 天没动的仓位，本身就不正常。这极可能就是 07-30 那一波"半平仓" 遗留下来的——当时 BTC / ETH / SOL 处理过一轮，通过数据库看，只有 SOL 这一笔没清掉。 DB 和链上，一张一张对判断它是不是幽灵仓，做法只有一个：把数据库里的每一个 OPEN，和链上的实际仓位逐一对照。 DB OPEN（sm_positions） 链上真实 一致？ ETH LONG @1891.3 ...

记录一次五个候选因子的验证（2026-08-14）一天跑完五个方向，最后只剩一条腿站着。 08-14 把手上所有候选方向一次性验证完：低动量做多、24h 动量跟随、量价因子新腿、factor_ic 最优形态、长周期反转。五个方向，五份报告。 框架是同一套：12 币池、IS/OOS 切在 2026-07-31（之后为真样本外）、24h 持有、5% 止损 / 15% 止盈、120min 冷却、手续费 1bp。 只换信号，不换尺子。 结论是：五个方向里，四个被否，只剩"做空高动量"这一条腿。 一份报告，一个拒绝理由那天先把"怎么算验证通过"定死了。评估分三条：回测配置一致性（权重 0.3）、结论数据支撑（0.4）、建议可执行性（0.3）。也就是说，一个方向的结论，光看全样本收益没用，必须有全样本 + 样本内 / 样本外多维度的支撑。 剩下的就是一份份看。 低动量做多：−29.63% 到 −54.01%四个配置（A 上涨限定 TOP1 / B 不限 regime TOP1 / D1 上涨限定 TOP2 ...

记录一次给策略立规矩（2026-08-13）找一条新腿的价值，不如记下一条"以后别再走"的死路。 08-13 跑完两组回测，屏幕上的收益几乎全是负的。那天做的不是继续找，而是把"以后不能再做什么"一条条写下来。 因为一次失败的验证，如果不落成规矩，下次还会用另一种形式再失败一遍。 两组被数据拒绝的腿先看当天跑出来的东西。两组的配置完全一致：12 币 / 5000 根 1h 主网 K 线（约 208 天）、24h 持有、120min 冷却、5% 止损 / 15% 止盈、手续费 1bp。行情门控用的是"12 币 24h 收益均值 > +2%"，样本内 / 样本外切分点沿用 2026-08-01（即 07-31 之后的真样本外）。 第一组：低动量做多（LONG 低动量反转） 配置 笔数 总收益 胜率 回撤 A 上涨限定 TOP1 74 −29.63% 50.0% 39.06% B 不限 regime TOP1 169 −36.63% 48.5% 55.79% D1 上涨限定 ...

记录一次多策略协作层的搭建（2026-08-07）一条策略是独奏，好几条一起跑就是一支乐队——真正难的是谁也不拖累谁。 08-07 做了一次全栈巡检。不是看单条策略赚不赚，而是看这些进程、这些策略拼在一起，作为一个"协作层"能不能稳。结论是：核心很稳，但辅助层里藏着一个真问题。 下面把那天理出来的东西记一遍。 六个逻辑进程先把家底摆出来。那天所有逻辑进程都在跑： 进程 端口 / 状态 trader 监听 66552，直连 HL，已连续运行 40 小时零 502 错误 sim_loop 模拟循环，本轮已修复并重启 mc_paper 本轮已修复并重启 signal 信号生成，本轮已修复并重启 watchdog 守护 oos 样本外监控 六个全活。但"全活"只是最低标准——真正要查的，是它们各自的输入输出有没有被污染。 三个辅助进程在吃死代理那天现场抓到一个 P1 级 的真问题。 sim_loop、mc_paper、signal 三个辅助进程，继承了一个已经死掉的系统代理 127.0.0.1:7890（C ...

记录一次策略的体检（2026-08-05）一条策略的体质，不是它今天赚了多少，是它亏的时候怎么亏。 08-05 白天做了一次修复。修完一处，按惯例要给场上的策略重新量一遍收益——把"修之前"和"修之后"分开看，否则修了等于没修。 这次体检的对象是两条在跑的策略：24 小时持有周期的反转策略 factor_ic，和看资金面的 market_flow。下面这份，是那天的体检记录。 修复之后，先把基线钉住修完一处代码，最危险的不是改错，是默认它就修好了。 所以每次修复之后我都要重做一遍收益体检。它有两个作用：一是确认修复本身没带来副作用，二是把新的 realized_pnl 固定下来，当作下一段比较的基线。 08-05 修复完成时，账户的 realized_pnl 停在 +$19.74。这个数字本身没有好坏，它只是一个起点——后面所有"修复后表现如何"的判断，都要拿它当尺子。这一点很关键：如果基线没钉住，后面看到的一切变化，都分不清是策略的功劳还是记账的噪声。 两条策略，两种体质体检不能把它们塞进一张表里比绝对值，因为两条策略的仓 ...

记录一次记忆服务的升级（2026-08-03）跨大版本升级，先想清楚怎么退回去，比升级本身更重要 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 显式开启。 新版里它的默认行为可能变了，为了保持原来的行为，选择把它明确写进配置 ...