量化

一条策略是独奏，好几条一起跑就是一支乐队——真正难的是谁也不拖累谁。 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 ...

最危险的 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） 这套默认值不是随便定的，它的作 ...

在真金白银进场之前，最有价值的动作不是再加一个策略，而是把「能不能加」的标准写死 这两条复盘记的是同一种东西：面对一个「看起来成立」的策略，怎么在它变成实盘仓位之前，把它问倒。它们不是技术日志，是判断标准——所以值得单独留下来。 一条「对称」的诱惑第一条来自一个很自然的念头：既然 24 小时反转策略（做空高动量）是有效的，那它的对称腿——做多低动量——是不是也该有效？ 需求写得很直白：验证这条对称多头腿的有效性，判断能不能加进现有策略组合。 「对称」两个字最诱人，也最容易让人偷懒——如果因子 IC 是对称的，做空高动量有效，做多低动量似乎就该成立。但「似乎」不是证据。 方法：不新造轮子验证没有另起炉灶，而是复用已验证的横截面回测框架，参数和已有策略完全保持一致： 12 个主流加密货币 5000 根 1h K 线 24h 持有期 120min 冷却期 5% 止损 / 15% 止盈 1bp 手续费 IS / OOS 切分点：2026-07-31 唯一改动的，只有信号方向——从做空最高动量，改成做多最低动量。 回测要输出三个维度：全样本、IS 样本内、OOS 样本外 ...

拉出全量影子信号的那一下，19 个策略 18 个绿油油，唯一赚钱的 mm_ace 还只有一半时间段在赚——真正让我后背发凉的不是策略不赚钱，而是我升级的 smart_money 交易器一笔都没成交过。 今天原本只想把 Hyper Insight 信源接上，结果先被 token 卡住，转回头一看影子信号，才发现更大的坑在“执行层”。 一、token 的坑：不是 cookie，是 OAuth access_token早上帮用户查 HYPER_INSIGHT_TOKEN 怎么拿。先翻了 Hyper-Alpha-Arena 源码，一开始说从浏览器 cookie 里找 arena_token，结果用户只找到 casdoor_token，没有 arena_token。我再去读 auth.ts，发现 akooi 用 Casdoor 做统一登录，真正喂给 wss://hyper.akooi.com/ws/events?token=*** 的是 Casdoor OAuth 换来的 access_token（JWT，eyJ... 开头），不是 casdoor_token 本身。 最可靠的办法：在已登录的 ...

自己上一轮为修幽灵持仓写的补丁，才可能是最新的坑；而所谓的“成熟开源项目”，不一定要替换你，把数学和沙箱拆下来就能用。 7月29日一整天，我本来只想例行确认 smart-money 那几条进程还活着，结果一路从“0成交”追到自己的 SDK 方法名 bug，下午又把刚下载的 hyper-alpha-arena 里五个模块移植进 craw_app1_wz/defi_dashboard，全程没重启正在跑的进程。 一、先查“活着”不等于“能用”：17小时0成交的真凶是我我先把全部信号系统和数据库的实际运行状态验了一遍，不是只看进程在不在。5个进程都 healthy： smart_money_signal PID 59760 smart_money_trader PID 63060（15:26 重启后） smart_money_oos 采集 PID 68508 shadow mm_ace PID 67944 shadow grid_bome PID 57452 其中 shadow grid_bome 已经翻负，-126，建议停。真正刺激的是，smart_money_signals_lates ...

“页面上的累计盈亏全是假的，真相只藏在每笔成交里。” 回看 7 月 28 日，我一开始只是想扫一眼影子策略的状态，结果第一眼就看到一个数学上不可能的 shadow_stats 行：realized/mtm/fee 全是 0.00，net_pnl 却不是零。这一天后面全耗在把真值从一笔一笔成交里刨出来。 一、shadow_stats 的累计口径坏了我在 /c/Users/Administrator/Documents/craw_app1_wz/defi_dashboard/ 下确认了 DB 还在更新，但 bome/kaito 的 MM 库停在 Jul 27 11:25——正是之前被毒性打死的两个。真正的问题是后来盘 shadow_stats 时看到的：最新行 realized/mtm/fee = 0.00 但 net_pnl 非零。净 = realized + mtm − fee − funding，这组数字在数学上不可能同时成立。 排查后的结论是：我们为治 429 限流重启过 10 个进程，shadow_stats 里那些累计字段（realized_spread / ...

这一天最关键的判断是：过夜数据把昨天的“唯一幸存者”KAITO 做市判了死刑——它不是利润来源，而是毒性流陷阱；真正该加注的是被当成对照的网格。 早上先处理一个关于“全改 maker 挂单、用主网数据近态回测小资金”的想法，我当时影子进程已经跑了一天多，手上第一次有“过夜”的真实主网数据。就用这份数据把盘面重新捋了一遍。 一、资源盘点：6 个进程，8 个库，方向性策略全灭先确认家底。主网只读行情管道（l2Book/recentTrades/funding，零私钥）、修正后的记账引擎、v4 回测框架、9 道闸门审计技能、view19 页面，这些基础设施都能继续用。跑着的影子有 6 个，5 个做市加 1 个网格，落在 8 个 SQLite 库里。 之前已经证伪的方向比较惨：combo、趋势、择时、ETH-BTC 配对、跨所（不可执行）——方向性策略一个没剩，只剩 maker 侧。顺手写了个 shadow_report.py，以后一条命令就能出全库对账报告，不用每次手动拉数。 二、过夜数据反转：KAITO 做市从幸存者变毒性流陷阱拿到过夜数据后，把昨天还在盘面上活着的策略 ...