jack/Chan - Chan

374 Commits 9 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
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

Author

SHA1

Message

Date

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