链上权益重置与OOS停写17小时,根因是拿DB当链上兜底(2026-08-25)
链上 ≠ 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,跟 ...
模型接口连续返回429,OOS扫描门禁全挂并触发HALT(2026-08-24)
信号源已经 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 ...
同一晚四个异常叠加,样本外停写三天根因在调度器与全局变量缺失(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()(无顶层捕获)→ 整个脚本崩溃;
Gate1- ...
A1交易栈静默四十小时,罪魁是计划任务启动命令拉不起Python(2026-08-18)
今天的教训:进程僵死往往不是代码崩了,而是那条 start /MIN cmd /c 启动命令在无桌面的计划任务会话里根本拉不起 python。
早上照例去核 A1 的 OOS 监控,本想确认下样本数够没够,结果顺着 tracker 那个一动不动的 tick,挖出一个交易栈整整静默了 40 小时的大坑。下面按我当天的排查顺序记下来。
一、核 A1:tracker 数字没错,但 tick 冻结暴露异常先找到项目真实路径 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard,DB 都在。oos_ticks 从 08-17 的 5 行涨到了 20 行,说明自动化一直在跑。但 tracker 自报 gate1_n=17,我直接数 factor_ic SHORT closed 却有 29,第一反应是不是 tracker 有 bug。
按铁律「自报字段不可信,须逐笔重算」,我开始独立复算。结果跟 tracker 对不上:我数 OOS(closed≥08-10)是 18 笔 / maxDD 57.2% / p ...
策略毕业门槛冻结进PREREG,KILL触发7天和连续3tick升级落为硬规则(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。1h 正好卡在中间。同时补了一句"tr ...
策略研究流程固化,小仓升标准仓被自己的数据推翻(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 跟踪),不污染现有运行策略
R8:跨场代理研究必须验证 PnL / ...
hl_testnet.db 对账发现 25 天 SOL 空单与链上多单对不上(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, $80
ETH szi=0. ...
五个候选因子验证,只留下做空高动量一条腿(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 / D2 上涨限定 TOP3),笔数从 ...
低动量 LONG 两组回测全负之后,策略死路被写成规矩(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 上涨限定 TOP2
148
−25.82%
50.7% ...
动量跟随多头回测被 A/B 窗口数据直接拒绝(2026-08-12)
不调参,先攒满 ≥12 笔已平 A/B 确认期望符号——若正再加 regime 过滤,若负就重估而非优化。
今天一整天基本都在 factor_ic 上打转。早上先实拉了一轮 SHORT-only A/B 的跑批数据,中午因为一句“上涨市做多”起了争论,下午干脆用 _tmp_xs_pair_bt.py 同款框架把动量跟随多头回测跑了一遍。结果很干脆:这条路被数据拒绝了。
一、先拉现状:19:54 那轮实拉晚上 7 点 54 分,我把当前 factor_ic 的实盘状态完整拉了一遍。进程态没毛病:signal 75444 已经跑了 53.1 小时,SHORT-only 模式(LONG_N=0),watchdog 单实例在岗。全量 factor_ic 一共 29 笔,+$11.01,其中 LONG 腿 9 笔 +$2.92,SHORT 腿 20 笔 +$8.09。
但真正要看的是 A/B 窗口,也就是 SHORT-only 这段。53 小时里总共 4 笔信号,全是 SHORT,已经平仓 3 笔,没有 1 笔 LONG 漏单。这 3 笔已平的净盈亏是 - ...