jack/Chan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
354 Commits 9 Branches 1 Tag
9efbae6adeff997ccc176b60f5562761b6c36210
Commit Graph
10 Commits
Author SHA1 Message Date
jackandCursor 335d891478 生产与研究分家：实盘执行器独立成 live/ 子树，加 AWS 部署 
实盘要跑在 AWS（API key 绑了 IP 白名单），而信号在新加坡那台算。借这次
把生产从研究侧摘出来，四条具体代价里第一条已经咬过：

1. live_state.json 原先落在 research/out/，而那里 shadow_hb 会自动 rename
   归档、研究脚本会写、人也手工清过。那文件装的是 MAX_DAY_LOSS 累计与已
   处理信号键，被清掉不报错，只是两道闸静默失效。改到 LIVE_HOME。
2. 采集器十币清空 300~560ms 直接叠在信号到达执行器的延迟上。
3. 研究侧探针 OOM 过一次（14.9GB），当时若有仓位在场会连坐执行器。
4. 为读两个常量 import 研究侧 step43，把 numpy/pandas/pyarrow 拖进实盘
   进程。抽出 stdlib-only 的 live/exit_params.py，install.sh 加断言挡回归。

新增 live/ship_signals.py：AWS 侧 ssh tail 拉总线，每次重连从文件头重放
+ 按幂等键去重，断线期间的信号自愈；旧信号由 staleness 闸挡掉不补做。
带时钟倒流检测——两机时钟不同步会让那道闸静默放宽。

部署件：systemd 两单元（搬运挂了执行器仍管在场仓位的超时平仓）、
install.sh、dryrun.sh（验密钥/白名单/时钟/ssh/取整）、status.sh、README。

验证：live_exec 重构后端到端空跑，SOL 多头与 ADA 空头的止损/两级止盈/
数量取整逐项核对正确，isolated + post_only + reduceOnly 都在；搬运的去重、
重启不重复追加、脏数据跳过、断线重连重放均已测。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:03:03 +08:00
jackandCursor 360e4e1c41 自动化实盘执行器：信号总线 + 两个半仓分解 + 四条硬约束 
## 架构：影子发信号，实盘执行，两个进程

不让实盘自己算信号。前两个理由是资源与隔离（2 核上再来一份十币计算会把清空
从 247ms 推到 500ms+；实盘崩溃不该影响正在采的数据集），第三个最要紧：
**实盘交易的必须是影子测量的那一个信号**。各算一份会让两边悄悄分叉，之后就
没法把实盘实际成交和影子测的滑点曲线对照——而那个对照是整件事的目的。

总线用 append-only JSONL + fsync：崩溃安全，且「影子在跑、实盘没在跑」会表现
为信号在攒着，而不是静默丢弃。

## 出场结构精确分解成两个半仓

TripleBarrierConfig 只有单级止盈，装不下 3ATR 减半 + 8ATR 目标。但已核实
exit_model.py:151 的 runner_stops 是从**入场价**算的（ret = (entry-low)/a），
且 RUNNER_STOP == SL == 2.0，所以两半共用同一个不动的止损，可精确分解为：

    半仓 A  市价入场 · TP 3ATR · SL 2ATR · 48min
    半仓 B  市价入场 · TP 8ATR · SL 2ATR · 48min

止损先到则两半都在 -2ATR 出场；3ATR 先到则 A 出场、B 继续且止损仍在 2ATR。
与回测逐情形一致。assert_decomposable() 在启动时挡住 RUNNER_STOP != SL 的
改动，否则实盘会跑另一个收益结构且不报错。

## 硬约束是这个文件的重点

一笔止损只亏约 1 USDT，所以「亏损可控」对单笔成立。但三类故障的代价**不随
仓位缩小**，必须显式封住：失控下单（MAX_OPEN=3 / MAX_DAY=15）、亏损累积
（MAX_DAY_LOSS=20）、裸仓（重启对账）。状态落盘且原子替换——不落盘的话反复
重启就等于反复重置日上限，而失控下单恰好常伴随反复重启。

已验：幂等去重、并发上限、日开仓上限、日亏损上限、跨日归零且保留 done 键、
重启后计数不清零、状态文件损坏时不抛异常。

## 重启对账选择平掉而非接管

崩溃重启后交易所可能还有仓位，而 executor 全没了，那些仓位没有任何止损在盯。
接管需要重建入场价/ATR/剩余半仓状态/已过根数，任一项猜错就让出场结构变成
另一个东西；平掉的代价只是一笔小额亏损，且行为确定。

## 已知风险：止损在机器人侧

Bitget 连接器只支持 LIMIT / LIMIT_MAKER / MARKET，无触发单。
PositionExecutor.control_stop_loss() 是本地盯价、触发时才发市价单，所以进程
一死仓位就是裸的。10x 下强平需逆向 10%（约 100 个 ATR），48 分钟内极不可能，
单次代价仍封在保证金内。下一步用 Bitget 服务端 TP/SL 计划单做兜底。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:52:03 +08:00
jackandCursor f716ddd149 推送带杠杆与保证金，名义额默认抬到 500 
杠杆只影响占用保证金，**不改**名义敞口、手续费、滑点、盈亏绝对值——费与滑点
都按名义额收。所以「用杠杆所以可以很小额」这个方向要说清：杠杆省的是本金
占用，不是成本。

它真正的用处是让「抬名义额」几乎免费，而抬名义额正好压掉步长取整。实测
取整到步长偶数倍后最差币的名义偏差：100U → 6.7%(SOL)、500U → 1.8%、
1000U → 0.6%。所以默认名义改 500、杠杆 10x，每笔占 50 USDT 保证金。

止损在 2 ATR ≈ 0.2%，而 10x 的强平约需逆向 10% = 100 个 ATR，差 50 倍。
这个止损紧到杠杆几乎不引入强平风险，所以这里没有「杠杆换风险」的取舍。
仍建议逐仓，让每笔最大损失被保证金封住。

推送里加上占用保证金与「触止损亏多少 USDT / 占保证金百分之几」，手工执行时
不必自己换算。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:44:39 +08:00
jackandCursor 97457b0518 过滤网信号推 Telegram，供手工小额实盘 
自动执行链一行都还没写（下单/持仓状态/跨重启持久化/对账/熔断），而过全部
滤网的信号只有约 5.3 笔/天——低到人手能接。先手工跑一批，就能在写自动化
**之前**拿到真实费率档、真实成交价、真实出场行为，让执行链的每个假设都有
实测对照，而不是写完再发现出场模型不对。

推送内容按手工执行需要给全：参考成交价（回测口径的次根开盘）、按 2/3/8 ATR
换算的绝对价位、下单数量、该币滑点预算，以及一句「偏离超过预算就不值得做」。
剩余半仓止损保持 2ATR 不移成本，这是回测参数，移了就不是同一个收益结构。

时效是这条路最大的风险，所以起点取 kline_ts 而不是信号产生时刻——参考价就是
在 kline_ts 那一刻存在的，从信号时刻起算会漏掉数据延迟加计算那 0.5~1.5s，而
那段不可压缩。超过 TG_STALE_S 直接标记已失效，不让人自己判断：宁可漏做，不
要在偏离预算之外入场。

三条防线：lag 退化时不推（与「停开新仓」同一条规则，不能只在自动化里执行）；
按 (币, K线时刻, 方向) 去重，避免补根或池重建重放导致开两次仓；无预算的币
（如 TRX）不推。推送任何失败只打日志，不连坐采集——已验假 token 下降级为
HTTP 401 日志而非抛异常。

凭据走 tg.env（已 gitignore），给了 tg.env.example 说明怎么拿 token 和 chat id。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:35:17 +08:00
jackandCursor f5f456c523 计算判定改看「清空全部币」，并挡掉空窗口 
判定原先比逐根的 queue_ms 与 inner_ms，结构上错了两处，十币下直接指反：

判据错。要紧的是一个收盘时刻清空所有币要多久，不是单币的 q 或 i。币同一秒
收盘，币数超 worker 数时后面的币串行等待，这笔代价不出现在任何单根的 q 或 i
里。现在按 kline_ts 聚合取各币最大 compute_ms，落到 clear_hist。

出路错。「排队为主 → 加核」只在还有空闲核时成立。worker 已等于核数时加
worker 不增吞吐，只把等待从 queue 挪到 inner。十币实测正是如此：inner 被
争抢从 144 抬到 192ms 反超 queue 135ms，于是判定落到「量级已低、无需优化」
——而此时最后一个币已在 1376ms。现在币数超核数就直接指向增量路径。

顺带修一个瞬时故障：WS 重连瞬间 feed 的 deque 可能为空，空窗口放行会让
worker 抛「DataFrame for 1m is empty」，白占一个计算槽（币数超核数时会推迟
后面所有币），而报错文本还会让人以为是缺历史数据。加 MIN_BARS 守卫。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 05:19:14 +08:00
jackandCursor ef2a85dd8c 币池可配，实测十币的排队代价；标出漂移的 tick 地板 
加 --syms（start.sh 传 SYMS），默认仍是三币。TRX 不进十币池：实盘口径 208 天
只有 5 笔，ATR 门控几乎全刷掉。

十币实测（对比三币）：

  queue_ms        2 → 169ms（P90 519ms，每刻最大排队中位 533ms）
  inner_ms      144 → 196ms（CPU 争抢也拖慢了纯计算）
  lag_signal_ms 621 → 958ms；同一收盘时刻最后算完的币中位 1376ms

排队从可忽略变成主项，与「10 币 × 196ms ÷ 2 核 ≈ 640ms 突发」吻合。这也是
之前「加核没用」那个结论唯一会翻转的场景：CPU 占用率只有约 3%，问题纯粹是
所有币同一秒收盘的突发，加核压的是并行度而非单币耗时。

但 800ms 哨兵不受影响——它喂的是 t_data − kline_ts（数据腿），十币下逐币
154~532ms 全在线内。加币不碰那道闸。

另外发现一个会被静默误读的东西：ADA/AVAX/DOGE/LINK/LTC 的漂移中位精确等于
半个 tick 且在四个延迟点上完全相同。那不是漂移，是中价的最小变动量——ADA 半
tick 就有 2.34bp。拿这个数去比预算会误判某币不可做。shadow_report 加了
tick_floor() 标注；方向上安全（真实漂移只会更小，这些是上界）。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:50:09 +08:00
jackandCursor 6c843639d5 影子路径开 lean 模式，实测完整链路 1410 → 683ms 
拉到新引擎后在服务器侧直接实测，没有沿用 3.4 倍那个换算——那是在旧代码上量的。

先做等价性验证。不能直接引用 step46 的对拍结论：它固化的是 bsp_list 那条链的
哈希，而影子路径走 find_fast_bsp3 + build_htf_zones + htf_fx_timeline +
attach_htf_context，两条链读的东西不一样。所以新建 verify_lean_parity.py 在
这条路径上逐根对拍 compute() 的每个返回字段。

其中一个坑：随机取窗口测不到信号分支。信号密度约 1/2000 根，头 12 个窗口命中
0 个，「一致」只覆盖了早退路径。改成一半窗口对齐到已知信号根，命中率才上来。
最终 180 窗口 / 两模式各 90 命中 / 零分歧。

生产实测（inner_ms，容器内同口径）：

  compute_ms      646 → 132ms   4.89x
  inner_ms        612 → 128ms   4.80x
  lag_signal_ms  1410 → 683ms   完整链路，落回 800ms 线内

比 3.4 倍更好，因为是引擎 ~3.5x 叠 lean ~1.35x。

两点判读上的订正：

- lag_data_ms 那 576→490ms 是噪声，不要记在引擎账上。均值 721±36 vs
  740±127，重叠；而且引擎本来就影响不到交易所与网络那一段。
- 仍有 44% 的根超 800ms，但尾部现在完全由数据腿主导（lag_data P90 1482ms
  vs compute P90 237ms）。计算既不是瓶颈也不是尾部主因了，继续压计算换不到
  尾部改善。800ms 那道闸取的是最近 30 根的中位数，683ms 已满足。

start.sh 加 SHADOW_LEAN（默认 1），设 0 可退回 full 复量两模式差异。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:24:08 +08:00
jackandCursor 54792fe015 把 compute_ms 拆成排队与纯计算，据此否掉换机器这个方向 
compute_ms 一直是「提交进程池到拿到结果」的墙钟时间，排队和纯计算混在一个
数里，所以「加核有没有用」只能靠猜——这也是原先打算在 AWS 开第二台比 CPU
的依据。

worker 内部自己计时，连同父进程传入的提交时刻一起回传，拆出 queue_ms 与
inner_ms。实测中位 3ms / 695ms：2 个 worker 跑 3 个币并不排队，因为三个币的
收盘消息错峰到达。瓶颈全在单线程，加核压不到。

顺带把 README 里的内存数据从臆测的 1.5GB 改成实测 410MiB，并注明跨站点比
CPU 收益有限。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 03:02:06 +08:00
jackandCursor 95f2b614a2 延迟瓶颈实测为本机 CPU 而非机房位置，跨站对比主指标改为 compute_ms 
用户指出本机选新加坡是因为 Bitget 机房在新加坡。查证下来 ws.bitget.com 解析
到的是 CloudFront（dxotqhr62n6z4.cloudfront.net），落在新加坡 AS16509
（Amazon），即连的是 AWS 的 CDN 边缘而非 Bitget 自有机房。

腾讯云 ap-singapore（AS132203）到该边缘实测：ICMP 往返 2.1ms、TCP 握手
3.3ms、TLS 完成 9.0ms、首字节 87.8ms。首字节减 TLS 那约 79ms 是 CloudFront
回源开销，与我们的位置无关。

延迟构成（33 根样本）：数据到达中位 506ms、信号计算中位 646ms、合计 1315ms。
随机房位置变化的只有那 2ms 往返，占总延迟 0.15%。而 646ms 的信号计算是每根
在 2000 根 1m 加 800 根 5m 上重建缠论结构，本机 2 核、2 个计算进程，三币同时
收盘时第三个还要排队——这才是有改善空间的一项。

因此：
- 新增 deploy/netprobe.sh，把网络那一段单独量出来并入运行元数据。用到达
  延迟去比两个机房等于用公斤秤称克，必须把可变的那段拿出来单独看。
- compare_sites.py 主指标改为 compute_ms，lag_data_ms 降为自检项（两站应当
  接近；若差很多，先怀疑时钟而非网络）。元数据表加 nproc/cpu_model/往返。
- README 改写：第二台机器该测 CPU 规格而非地理位置，WORKERS 按核数减一给，
  币数多于 worker 数时排队时间直接计入 compute_ms。

另修正站点标签：本机是腾讯云而非 Hetzner，sg-hetzner → sg-tencent，标错的
33 行数据已清掉重采。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:51:51 +08:00
jackandCursor 631d97e493 加跨地部署脚本与站点对比，数据全表加 site 列 
目的是在第二台机器（AWS）上跑一套完全相同的采集，看不同地理位置的数据差异。
滑点里最大的一项是延迟漂移，而延迟含网络传输，所以机房选址是可优化参数。

数据侧两处必需改动：

- 全部输出加 site 列（三张 CSV 加 gzip 里的盘口与成交流）。没有这一列，两台
  机器的数据合起来就分不清来源。为免四处 writerow 漏加一处产生静默空值，
  改在 _SiteWriter 里统一注入。
- start.sh 在时钟未同步或偏移超 10ms 时**拒绝启动**。所有延迟数字都是
  「本地时钟 − 交易所 K 线收盘」，时钟偏 50ms 就全部同向偏 50ms，且不报错，
  只会让跨地对比得出一个干净且完全错误的结论。

deploy/ 下四个文件：setup.sh（docker + chrony + 拉镜像）、start.sh（校验时钟、
写运行元数据、起容器）、status.sh（健康速查）、README。运行元数据记 git commit、
镜像摘要、时钟偏移——两地数据对不上时，这三项任一不同都足以解释差异。

compare_sites.py 做配对对比：只取各站都有的 K 线（不取交集可能在比不同时段，
而延迟对市场活跃度敏感），并报配对差的符号占比而非两个中位数相减。已用注入
120ms 的合成数据验证能精确还原。另有一条自检：同一固定延迟点上两站漂移应当
相同——漂移是市场性质，若也差很多则先查时钟与时段对齐。

status.sh 里按列名取字段下标而非写死数字：加 site 列时字段整体右移过一次，
写死 $8 会静默变成读 lag_signal_ms 而非 lag_data_ms。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:39:47 +08:00