2 Commits

Include renames

Author	SHA1	Message	Date
jackandCursor	f11c6507b0	实盘执行改走 Bitget v2 REST，止损挂到服务端 ... 丢掉 Hummingbot 的 PositionExecutor。它的连接器只暴露 LIMIT / LIMIT_MAKER / MARKET，没有触发单，于是 control_stop_loss() 只能本地盯价、触发时才发市价单 ——**进程一死仓位就是裸的**。而交易所本身支持 place-order 带 presetStopLossPrice，下单时就把止损挂到服务端。绕过连接器不是图省事，是为了 消掉一整类故障。顺带 TripleBarrierConfig 只有单级止盈，装不下两级，自己写更短。 ## 三条出场腿各自挂在哪 止损 交易所侧（presetStopLossPrice，随入场单一起到）→ 进程死了仍在 止盈 交易所侧（post_only reduce-only 限价） → 进程死了仍在 超时 本进程，48 分钟到点市价平 所以进程死掉只会让持仓超过 48 根，不会变成裸仓，退化是良性的。 ## 止盈不能用 presetStopSurplusPrice 它触发后按市价执行，而成本模型里止盈是 maker——那 60% 的出场不吃滑点、按 maker 费率计（LEG_IS_TAKER）。用 preset 会让这部分变成 taker，预算就不成立。 所以止盈单独挂 post_only + reduceOnly 限价单。止损反过来必须市价：stop-limit 在急跌里可能不成交，损失远大于省下的费。 ## clientOid 是交易所级幂等，但要小心两个坑 信号键形如 SOL:1787904388411:+1，`:` 和 `+` 未必被接受，带过去直接拒单——而 拒单发生在入场腿上，等于这笔信号静默漏掉。 清洗时不能简单把非字母数字换成下划线：那样 `+1` 和 `-1` 都变成 `_1`，同一根上 的多空信号得到相同 oid，第二笔被当重复拒掉。方向显式编码为 L/S。 用 clientOid 而非只靠本地去重，是因为「已发出但没收到回复」这种情况本地判不了， 重试就会开两次仓。 ## 空跑要走完 open_position 第一版在 on_signal 里 `if dry: return`，结果数量取整、价位对齐 tick、请求体 构造全都没被验到。现在空跑走完整条路径，不下真单由 Bitget(dry=True) 负责。 实测两笔：SOL 多头 entry 106.706 / ATR 11bp → 止损 106.471、止盈 107.058 与 107.645；BTC 空头 → 止损在上方 79747.5、止盈在下方。半仓精确一半（SOL 2.3+2.3、 BTC 0.0031+0.0031）。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-28 16:07:28 +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