排障

链上 ≠ 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 ...

一晚上三条"死因"，长得像同一个症状 有些夜里，你会以为在处理一个 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- ...

今天的教训：进程僵死往往不是代码崩了，而是那条 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&#x ...

不调参，先攒满 ≥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 笔已平的净盈亏是 - ...

页面再顺、大屏再快，策略该不该上线还是得看那 0/12 已平交易——结论是：还不能。 今天这一天的活很杂，上午接着搞 factor_ic 的 A/B 看板，下午被工厂大屏的前端问题打断，晚上又拉了一轮策略数据，结论反而比白天改的代码更重要。 一、先把 factor_ic 的回测结论摁在桌上上午有人问 factor_ic 的回测结果怎么样、当前运行情况怎么样。我第一反应就是当前运行必须实拉，不能凭记忆，尤其要确认 SHORT-only A/B 切了 17 小时后有没有 LONG 漏进来。回测结果是历史事实，可以看落盘记录，但运行状态必须实时。 实拉核验后，回测结果本身是清楚的：12 币全池、5000 根 1h K 线约 208 天，无前视。全样本 338 笔，**总收益 -16.5%，单笔均值 -0.053%，胜率 49.4%**。拆开看：LONG 腿 169 笔 **-38.1%**，SHORT 腿 169 笔 **+34.9%**。这个对比已经很说明问题了。 但更让人警觉的是别人给过来的判断——方向对、核心 caveat 对，却有 5 处实质错误，其中 ...

代码里的开关是死的，进程里的 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，合计 ...

"管道不是没接，是接了但死了8天没人发现"——这句话比任务描述里写的严重得多，也决定了这天所有动作的优先级。 翻开 factor_ic.db 一看，心里就咯噔一下。任务描述说管道没接，可实际查下来根本不是没接，是接了但早死了。后面还冒出一个 Streamlit 报错，根因居然是本地的 watchdog.py 把第三方包给遮蔽了——两件事串在同一天，都是典型到不能再典型的坑。 一、factor_engine：硬编码死代理断粮8天先看数据库。factor_ic.db 最后成功写入停在 07-31，08-01 到 08-06 的日志全是 502 和连接重置。翻代码找病灶，死因是 127.0.0.1:7890 这个硬编码死代理——和 08-07 那批 ProxyError 是同一个病根。更要命的是，没有任何调度器在跑它，所以断了 8 天完全没人发现。 factor_ic 表里 MIN run_iso=2026-07-30，MAX 之前卡在 07-31，这次补齐到 1596 行。断粮这 8 天，IC 管道等于完全没供数，而下游因子实验还在傻等。 二、修三件事，逐条实拉才点头第 ...

实拉核验是唯一能对抗“快照过时”的东西，但这一天我自己也差点被自己的扫描脚本骗过去。 昨天 08-07 的诊断列了六条待办，今天全部收尾核验。结果 5 真 1 漏报，还揪出一个伪造的二次拉起，中间两次反转，最后靠逐行代码和实拉日志才把状态钉死。 一、先说结论：5 真 1 漏报，白名单直接 fail-closed今天第一件事是核对昨天诊断的落地情况。我原以为 market_flow 退役后没有拦截日志，结果在日志里翻到了实锤 [FILTER] SUI market_flow 已退役，这条我之前说“无日志”是错的。对账也没问题：10000 −7.32 −3190.09 = 6802.59，和现金 6801.70 的差额 $0.89 正好是累计 fee。 但最要命的是漏了一笔新开仓。重启后新开仓不是 1 笔，而是 3 笔：22:57 SOL sentiment $350、06:59 TIA factor_ic $80、**07:34 TRUMP LONG $350，strategy=token**。查代码发现 token 是 signal 侧真实产出的新类型，在 smart_mon ...

一条策略是独奏，好几条一起跑就是一支乐队——真正难的是谁也不拖累谁。 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（Clash 已经死了）。结果是：cryptopani ...