bison-strategy

🦬 BISON v3.0.1 — 信念持有者

资产白名单（BTC/ETH/SOL）。 信念门槛（minScore 11）。 不设时间止损 — 所有退出均由 Phase 1 + Phase 2 阶梯式追踪机制掌控。

v3.0.1 (2026-05-18) — 已持有资产去重竞态修复 + DSL 限流

运维可靠性补丁。不改变交易论点。不改变评分。

发现的错误。 对 Bison12（M192943）在 2026-05-13 至 2026-05-17 期间的审计 显示，有 16 次 create_position ENGINE_FAILURE 携带 BISON_CONVICTION 推理文本，涉及的资产均为钱包已持有资产。每次失败 都是运行时 LLM 门控在生产器发出的信号上触发，而这些信号本应被去重 —— 生产器的链上 heldAssets 检查在 push_signal() 返回 OK 与对应持仓 出现在下一 tick 的 clearinghouseState 拉取结果之间的竞态窗口内失效。

修复 1 — 最近信号缓存（scripts/bison_config.py）。 每次成功推送后，record_signal(coin) 都会将 {coin: epoch_seconds} 写入 state/recent-signals.json。main() 会在调用 build_thesis() 之前 先调用 was_recently_signaled(coin)，并跳过在 RECENT_SIGNAL_TTL_SEC（默认值为 180s，约为典型 ALO 开仓成交窗口的 3 倍） 内出现过的任何币种。每个 tick 的输出都会在 recently_signaled_skipped 中记录被跳过的币种，供审计使用。

修复 2 — DSL 退出间隔从 30s 调整为 60s（runtime.yaml）。 审计还发现，在成功平仓后 1–2 个 tick 内，会集中触发 CLOSE_FEE_OPTIMIZED_FAILED "Reduce only order would increase position" 和 CLOSE_NO_POSITION 错误。 运行时对已平仓持仓状态的更新，比 30s 的 DSL 间隔更慢，因此 DSL 会在 HL 持仓已清零后再次触发平仓。将间隔加倍可为运行时持仓状态拉取留出 追上进度的时间，并将无效平仓尝试减半。根本原因（运行时侧持仓状态 同步）已升级至运行时团队处理 — 此 YAML 更改仅为下游缓解措施。

此补丁无法修复的问题。 DSL 状态与 HL 状态长期不同步时出现的幽灵孤立持仓 （即运行时在外部完全平仓后仍认为持仓处于开仓状态，反之亦然）。 此类错误需要运行时侧进行对账；生产器无权控制 DSL 状态。

v3.0.0 (2026-05-12) — 仅迁移底层管道

不改变交易论点。v2.1 的资产白名单、minScore 11、按信念等级调整的保证金档位、 方向瀑布、9 组件评分以及 DSL 预设均原样保留。底层管道有六处切换：

1. MCP 传输：mcporter 子进程（每次调用冷启动需 2.5-5s）→ 进程内 HTTPS 调用 senpi_runtime_helpers.SenpiClient.mcp_call()（约 280ms）。
2. 信号发出：扫描器此前直接调用 create_position（Wolverine 模式）；现在生产器通过 push_signal() 向运行时 /signals 发出信号。运行时经过 LLM 门控的 bison_entry 动作会通过 FEE_OPTIMIZED_LIMIT 开仓，并将 marginUsd 和 leverage 从信号数据传递过来，以按档位确定仓位规模。
3. 重入控制：无需替换 v2 锁文件（Bison v2.x 在没有生产器侧锁的情况下通过 openclaw cron 运行）；producer_daemon 负责每个 tick 的 scanner_lock，并可在 PID 过期时自动恢复。
4. 调度器：openclaw cron（5 分钟）→ producer_daemon(interval_seconds=300)。长期运行的进程；每个 tick 均无冷启动开销。
5. 风险门控：Python 中的 MAX_DAILY_LOSS_PCT、基于 PnL 的动态槽位上限、每资产冷却状态文件 → 声明式 risk.guard_rails 区块。state/trade-counter.json 和 state/asset-cooldowns.json 在 v3.0 中已无实际用途，可以删除。
6. 退出手续费：DSL 退出从 MARKET（吃单，0.045%）切换为 FEE_OPTIMIZED_LIMIT（优先挂单，0.015%，60s ALO 超时，超时后回退为吃单）。入场退出保留 ensure_execution_as_taker: false（v2.1 的 ALO 耐心规则）。

重要规则

规则 1：生产器负责入场。DSL 负责退出。生产器绝不平仓。

v1.x 会重新评估交易论点，导致盈利仓位被过早平掉。v2.0 移除了此功能。v3.0 从结构上彻底杜绝了这种情况 — 生产器中没有 close_position 调用点。

规则 2：生产者通过 push_signal() 发出信号；运行时负责开仓

生产者为信念论点评分，并通过 client.push_signal() 发出信号。运行时的 LLM 门控 bison_entry 操作通过 FEE_OPTIMIZED_LIMIT 开仓，并设置 ensure_execution_as_taker: false（保留 v2.1 的耐心规则——入场 ALO 等待 30 秒以 maker 方式成交）。

规则 3：所有信号都是评分贡献项，而非硬性门槛

4H 趋势、1H 趋势、1H 动量、SM 方向、资金费率——这些因素都会加减分。minScore 阈值（v2.1+：11）是唯一门槛。评分前不会有任何信号被排除。

规则 4：强制执行资产白名单（v2.1+）

默认仅允许 BTC/ETH/SOL（可通过 bison-config.json 中的 allowedAssets 配置）。v2.1 之前会获取按 24 小时名义成交量排名前 10 的资产——让因成交量激增而进入资产范围的小市值资产（例如 5 月 4 日的 ZEC）占用了当天唯一的交易机会。

规则 5：入场时 ensureExecutionAsTaker = false

入场使用 FEE_OPTIMIZED_LIMIT，并设置 ensure_execution_as_taker: false（v2.1 耐心规则）。出场使用 ensure_execution_as_taker: true（必须完成平仓——以 taker 方式成交作为安全底线）。

规则 6：使用 runtime.yaml 中的 DSL 预设，而非自定义 DSL 状态文件

v2.x 在扫描器输出中提供了硬编码的 DSL 状态模板。v3.0 将运行时 YAML 中的 dsl_preset 区块作为唯一真实来源。扫描器端不再有 DSL 状态。

BISON v3.0 如何交易

入场（所有评分贡献项——沿用 v2.1）

信号	分值	类型
4H 趋势一致	+3	评分
4H 趋势相反	-1	评分
1H 趋势一致	+2	评分
1H 趋势相反	-1	评分
1H 强劲动量（≥1%）	+2	评分
1H 中等动量（≥0.5%）	+1	评分
1H 反向动量	-1	评分
SM 方向一致	+2	评分
SM 方向相反	-2	评分
资金费率方向一致	+2	评分
资金费率拥挤	-1	评分
成交量上升	+1	评分
OI 增长	+1	评分
RSI 有余量	+1	评分
RSI 处于极值	-1	评分
4H 动量（>1.5%）	+1	评分

最低分：11。最高可能分数：约 16。

方向判定（逐级回退）

1. 4H 趋势结构 → 若为 BULLISH，则做多；若为 BEARISH，则做空
2. 若 4H 为 NEUTRAL → 跟随 SM 方向
3. 若 SM 为 NEUTRAL → 跟随 1H 动量（>0.5%）
4. 若全部为 NEUTRAL → 不发出信号

按信念度缩放保证金

分数	保证金
8-9	账户的 25%
10-11	31%
12+	37%

生产者根据档位计算 marginUsd；信号数据携带该值；LLM 门控将其传递到运行时负载中。leverage 也采用相同模式（默认 10x，最低 7x，最高 10x）。

出场 — 仅使用 RatchetStop

DSL 预设刻意设置得较宽，为信念仓位留出波动空间：

• ROE +10%：不锁定（确认仓位表现正常）
• +20% / +25% 锁定
• +30% / +40% 锁定
• +50% / +60% 锁定
• +75% / +75% 锁定
• ROE +100%：锁定 85%——无限尾随

阶段 1 的 max_loss：30%。时间止损：禁用 hard_timeout 和 dead_weight_cut。保留 weak_peak_cut（在 60 分钟/峰值 3.0% 时自我限制）。

风险门槛（runtime.yaml risk.guard_rails）

门槛	设置	替代项
max_entries_per_day	3	v2.1 基础每日上限
per_asset_cooldown_minutes	120	v2.1 cooldownMinutes
daily_loss_limit_pct	10	v2.1 MAX_DAILY_LOSS_PCT
max_consecutive_losses	3	v2.1（隐式设置）
cooldown_minutes（亏损后）	30	新增（舰队标准）
drawdown_halt_pct	25	新增（舰队标准，Roach 经验）
drawdown_reset_on_day_rollover	false	舰队标准

v2.1 中基于盈亏动态调整的每日上限（基础 3 次/硬上限 6 次，根据已实现盈亏分档）已被移除，改为静态的 max_entries_per_day=3 + drawdown_halt_pct=25。保守的上限和 -25% 硬止损得以保留；为了免除状态文件、提高可靠性，放弃了“乘胜追击”档位。

硬编码常量（不可配置）

• MAX_LEVERAGE：10
• MIN_LEVERAGE：7
• XYZ_BANNED：true（在生产者扫描层级禁用）

操作方部署拓扑

Bison 的运行时与生产器组合按策略钱包部署，而非按操作方部署。希望增加资金敞口的操作方可以部署多个策略钱包，每个钱包都运行自己的运行时实例和 bison-producer 守护进程。每个实例：

• 读取自己的 ${WALLET_ADDRESS}（通常通过环境变量获取）——运行时 YAML 中的 ${WALLET_ADDRESS} 占位符会在 runtime create 时解析；生产器则会回退到 bison-config.json 的 wallet 字段。
• 根据自己钱包链上的 clearinghouseState 计算 held_assets——各实例不会看到彼此的持仓。
• 写入自己的 state/recent-signals.json（实例级缓存）。
• 复用同一个 SENPI_AUTH_TOKEN（作用于操作方）——单个操作方可以在一个身份验证令牌下运行 N 个策略钱包。

影响：双钱包部署会使资金敞口翻倍，并行选择资产。 钱包 A 可能买入 SOL，而钱包 B 同时买入 BTC，从而捕捉相关性较低的入场机会。每个钱包的 DSL 追踪器彼此独立。

这种拓扑是 Bison 线上部署的实际情况（参见 Predator MCP bison-v1-0 slug，strategyWalletCount: 2）。 这不是 Bison 专属功能——senpi-trading-runtime 插件本身就是按这种方式扩展的：每个钱包对应一个运行时，一个操作方可以有多个钱包。

信号频率（预期情况）

• **生产器轮询：**每 300s（5 min）一次。守护进程长期运行，不存在每轮轮询的冷启动成本。
• **每轮扫描的资产范围：**最多 10 种资产，并筛选至白名单（默认为 BTC/ETH/SOL，共 3 种资产）。
• **每轮 MCP 调用成本：**约 4-7 次调用（market_list_instruments、leaderboard_get_markets、针对每个候选资产的 market_get_asset_data、以及用于检查持仓的 strategy_get_clearinghouse_state）。
• **信号发出频率：**在典型市场环境下每天 0-5 个信号。MIN_SCORE 11 门槛加上 2h per_asset_cooldown 会让信号发出保持审慎。
• **安静日特征：**每轮输出都以 "note": "WAITING — no conviction thesis (min score 11)" 结尾。这是最常见的状态——生产器正常运行，只是尚未触发交易论点。
• **怀疑生产器静默：**检查 audit_query({tool_name: "market_get_asset_data", user_ids: [<MID>]})——如果市场交易时段内条目数连续 >15 min 降为零，说明守护进程已停止，需要通过 disown 重新启动（2026-05-13 的集群模式）。

查看决策日志

Bison 通过运行时 LLM 门控发出每笔交易的决策遥测信息。要检查特定时段的推理链：

mcp__senpi-prod__audit_query({
  user_ids: ["<your Senpi MID>"],     # e.g. "M192943" for Bison12
  tool_name: "create_position",
  action_type: "create",
  limit: 50
})

每条记录的 ai_reasoning 字段是 LLM 门控的 reasoning 输出——通常为 "BISON_CONVICTION <ASSET> <DIRECTION> - <top_score_reason>"。成功的记录带有 success: true；失败的记录则带有 error_code 和 error_message。

结合 close_position 审计查询，查看 DSL 的退出原因（weak_peak_cut、dsl_breach 等）。

对于 Bison，审计查询路径是事后验证的标准工具——Predator MCP 会显示汇总数据（PnL、ROI、成交量），但不会显示每笔交易的推理过程。遇到“这笔交易为何触发”的问题时，务必使用 audit_query。

v3.0.0 (2026-05-12) — 仅迁移基础设施

Claude 用户对话会话的硬性规则

Claude 用户对话会话绝不能调用： create_position、close_position、edit_position、 ratchet_stop_add、ratchet_stop_edit、ratchet_stop_delete、 cancel_order、strategy_close、strategy_close_positions。

这些工具仅供生产器守护进程（入场路径）和 DSL 追踪引擎（退出路径）使用。用户对话会话只能读取。

操作方安装

全新安装和从 v2.1 迁移的命令，请参阅 README.md。

更新日志

v3.0.0 (2026-05-12) — 仅迁移基础设施

已迁移至原生助手（senpi_runtime_helpers）。交易论点原样保留。参见上文的六层切换。

v2.1（2026-05-07）

• 资产白名单（BTC/ETH/SOL）；v2.1 之前会获取交易量排名前 10 的资产，导致 ZEC 这类小市值资产占用每日名额
• minScore 从 8 提高到 11；此前午夜后出现第一个平平无奇的形态时就会触发，现在需要有充分把握才会触发
• 按照单资产模式，在 runtime.yaml 中禁用 DSL 时间截断

v2.0（2026-04-06）

• 所有硬性门槛都改为评分项
• 移除论点退出（evaluate_held_position）
• 扫描器在内部调用 create_position（Wolverine 模式；在 v3.0 中由 helpers-native push_signal 取代）
• 方向判定链：4H → SM → 1H 动量

许可证

Apache-2.0 — 衍生作品必须注明出处。版权所有 2026 Senpi（https://senpi.ai）。

技能归属

创建策略时，请在调用中包含 skill_name 和 skill_version。详情请参阅 references/skill-attribution.md。