Forever BLog

页面再顺、大屏再快，策略该不该上线还是得看那 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 ...

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

坏的不是 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 显式开启。 新版里它的默认行为可能变了，为了保持原来的行为，选择把它明确写进配置，而不是依赖默认值。 显式声明和依赖默认值，差 ...

最危险的 bug 不是仓太多，而是你算风险时偷偷用了不该用的分母。 这天从晚上一直忙到凌晨，起因很简单：把全部策略重新诊断一遍，不再信任何自报数字。结果发现账是错的、收益是噪声、现金缺口是平仓不返现的 bug、7 个仓位冻结是风控拿链上 $788 当分母误杀出来的。最后我把风控 equity 改回模拟账本，顺手把 trader 参数调保守，重启后 0.211x，才真算止血。 一、先拉进程和 DB，自报值全部作废我第一件事不是看总结表，而是直接实拉进程和 shadow_fills。8 个交易相关进程（ACE-main、ACE-neutral、trader、signal、watchdog、sim_loop、maincoin_paper、smart_money_oos）虽然有重复包装进程，但父子关系正常，ACE 进程数是 0，确实砍了。 真实收益重算下来，和“ACE-main +$962”差了两个数量级： ACE-main 名义成交量 $770,064，真实盈亏 +$22.31，效率 +0.29 bps。 trader 只有 +$0.75（已实现 +$5.30，浮亏 -$4.55）。 AC ...

一个以 _tmp_ 开头的脚本，最后成了所有因子验证用的一把尺子 07-31 那两条复盘里反复出现的「复用已验证的横截面回测框架」，说的就是这个脚本。到了 08-01，它的切分点从 07-31 挪到了 08-01——这意味着 07-31 之后的数据第一次成为真正的样本外。 它是干什么的_tmp_xs_pair_bt.py，一个横截面回测脚本，适用场景写得很清楚： 12 币加密货币池子的因子回测验证 支持动量、成交量、CVD 等多因子、多方向测试 「横截面」三个字是重点：它不是盯单个币的时间序列，而是在同一时刻把整个池子横向排开，比较币与币之间的相对强弱——高动量的做空、低动量的做多，都是在这个横向切片上定义的。 标准配置框架有一套固定进默认值里的配置： 项 值 K 线 5000 根 1h 主网 K 线（约 208 天） 持有期 24h 冷却期 120min 止损 / 止盈 5% / 15% 手续费 1bp IS / OOS 切分点 2026-08-01（07-31 之后为真 OOS） 这套默认值不是随便定的，它的作 ...