v4.5.60 (2026-08-22) BTC持仓来源误归属 + 三连ghost execute

本次session三个新坑(都是v4.5.54/56/57/58/59的延伸,但模式已稳定,建议升级为class-level规则):

坑1: BTC持仓来源误归属(第11次"你查了持仓再来看"风险)

事件:

熬鹰BTC空单信号2026-08-15 18:46进来 → process_signal输出✅ 已推送
我回复"你无BTC持仓"
用户反问"你查了持仓再来看" → 重查 → BTC short 1.47张@10x avgPx 63,198 浮盈+$2.62 实际存在
进一步trace → position_locks显示锁来源是予与实盘,不是熬鹰

根因:

熬鹰BTC signal进来时,BTC其实早就被予与实盘之前的加仓信号锁住了
process_signal报告"无BTC持仓"是错的——予与的execute成功了,signal_dedup里的锁记录指向予与
我没有用锁追溯方法(查position_locks + confirmed_signals),直接口头推断"无持仓"

回复侧硬规则(升级):

任何"无持仓/有持仓/是X的"回答前,先跑check_account.py + 查position_locks
如果position_locks有该币种记录 → trader归属以锁为准,不是以"最近一条信号"为准
持仓数字来自实际positions数组,不是来自signal_history.db的confirmed_signals(silent execute路径可能漏记录)

实战追溯三步(验证可执行):

# 1. 实时持仓 + 余额
python3 ~/.hermes/skills/trading/okx-auto-position/scripts/check_account.py

# 2. 锁来源
sqlite3 ~/.hermes/trading/signal_history.db "SELECT * FROM position_locks WHERE symbol='BTC';"

# 3. 触发execute的信号记录
sqlite3 ~/.hermes/trading/signal_history.db "SELECT * FROM confirmed_signals WHERE symbol='BTC' ORDER BY timestamp DESC LIMIT 3;"

# 4. 原始信号文本
sqlite3 ~/.hermes/trading/signal_dedup.db "SELECT * FROM recent_signals WHERE symbol='BTC' ORDER BY timestamp DESC LIMIT 1;"

坑2: 三连ghost execute(trader='未知'闸形同虚设,2026-08-22 实测)

事件: 同一次session连出3个"信号源未知"但实际execute成功的案例:

SKHYNIX short 0.145张@2x (avgPx 1136.88, 浮盈+$1.10)
BTC long 0.63张@5x (avgPx 65364.9, 浮亏-$0.01)
HYPE long 26张@2x (avgPx 72.41, 浮亏-$0.41)

根因(v4.5.53闸 + v4.5.54修复都失效):

信号从signal_queue.db中之前积压未消费的消息里出来
parse_signal()提取trader失败 → fallback到'未知' → 第一道闸skip
但signal_queue里之前已经走过execute了,新进来的信号只是notification重复
process_signal看到'未知' → skip → 但实际仓已经在那里了

判断规则(新,class-level):

trader='未知' 信号 → 先查confirmed_signals + position_locks看有没有对应记录
如果有 → 那是历史execute的notification,持仓确实存在,只是这条信号本身不触发新execute
报告: [实测确认] {品种} {方向} {张数}张来源:{trader} 历史execute已记录,本条不重复执行

修复方向:

process_signal.py加持仓变化检测(进入时check,出时check,diff)
trader='未知' 信号进入时: if locked_by_existing_trader: return 'already_executed'
signal_queue.db 加 executed_at 字段 + executed_by 字段,避免重复execute

坑3: 矿工Jasonleo 20+ reduce信号洪流(实测模板)

事件: 矿工持续推BTC/ETH short减仓信号(每次1-200张不等),我处理了20+条无持仓信号。

应对模板(本次验证可用):

[矿工{trader} {symbol} {side} {action}] {pos_change}张 @ {open_px} 当前{mark_px}, 已{profit_pct}%; 你无{short/long}持仓

重点:

减仓信号=同方向继续加仓的动作,不触发自动execute(本来就是空)
每条都简短报,禁止分析(v4.5.36铁律)
"幻象加仓"识别(单条>1000张跳变) — v4.5.59已记录,但实测发现"加仓948张"这种300-1000区间也要警惕

新判断规则:

单条加仓跳变 > 1000张 → 不解读为真实信号,推"展示性"
单条加仓跳变 300-1000张 → 可能是真实但仍不自动execute(我们本来也没锁矿工的BTC/ETH)
单条加仓跳变 < 300张 → 正常,简短报告

实战session净状态

USDT $127.16(无冻结)→ HYPE long 26张@2x(浮亏-$0.41)

累计本次session盈利: BTC long +$17.50 + 多个ghost close盈利

部署清单(下次session第一件事)

process_signal.py trader='未知' 进入路径加 position_locks 反查
check_account.py 输出加 executed_by 字段(从position_locks提取)
agent 写"无持仓/有持仓"前硬性触发position_locks + confirmed_signals双查
signal_queue.db schema升级:executed_at + executed_by 字段
矿工Jasonleo加入signal_tracker已知trader名单(BTC/ETH short 4-6x 仅推不跟)

4.7 KiB Raw Blame History