# QuantDinger 策略运行时与算法交易升级规划 **状态**：规划建议 **适用范围**：ScriptStrategy、实盘策略运行时、订单执行、算法交易执行器 **背景**：用户开始提出更复杂的实盘策略需求，例如 5 层分仓、每层 3 个马丁子单、均价止盈、多空模式和自定义杠杆。QuantDinger 需要从“能跑策略”升级为“可靠承载复杂策略和算法执行”的量化交易基础设施。 --- ## 1. 结论 当前 ScriptStrategy 基座可以支持一类复杂策略： - 有状态的分批开仓。 - 运行时参数化。 - 多次加仓、均价止盈。 - 只做多或只做空。 - K 线/实时 tick 循环驱动。 - 回测与实盘复用同一份脚本逻辑。 但对于专业级“阶梯分仓马丁 / basket martingale / layered DCA”这类策略，当前系统还缺少一些基础设施级边界： - 独立 basket 状态持久化。 - 多空双向 basket 的独立状态。 - 重启恢复与成交回放。 - 部分成交、撤单、拒单后的确定性状态机。 - 实盘与回测在逐笔补仓、均价、手续费、滑点上的一致性校验。 - 策略级最大风险预算、爆仓距离、保证金占用和 kill switch。 因此： - **只做多 / 只做空版本**：当前基座可以写出来，适合先落地。 - **多空双开版本**：建议先补强 hedge-mode 状态模型，不建议直接用单一 `ctx.position` 硬写。 - **专业级可售卖模板**：需要配套 basket runtime、订单生命周期和恢复机制后再推广。 --- ## 2. 用户需求是否能由脚本策略表达 用户需求： ```text 5 个大分仓 每个分仓 3 个开单 单内开仓间距可调 每个子单按马丁倍数放大 均价止盈 前一个分仓没有盈利才开下一个分仓 交易品种自定义 只做多 / 只做空 / 多空双开 基础仓位是首单金额 合约按杠杆后的名义价值计算 马丁倍数可自定义 均价止盈可自定义 ``` ### 2.1 当前可直接表达的部分 ScriptStrategy 已经具备这些能力： | 需求 | 当前支持情况 | 说明 | | --- | --- | --- | | 自定义交易品种 | 支持 | 由策略创建参数和运行配置选择 symbol | | 参数可调 | 支持 | 使用 `ctx.param(...)` | | 只做多 | 支持 | `ctx.open_long` / `ctx.add_long` / `ctx.close_position` | | 只做空 | 支持 | `ctx.open_short` / `ctx.add_short` / `ctx.close_position` | | 分批加仓 | 支持 | 脚本维护层级和触发价 | | 马丁倍数 | 支持 | 通过脚本计算每次下单数量 | | 均价止盈 | 支持 | 脚本维护或读取均价后触发平仓 | | K 线或 tick 循环 | 支持 | 运行时按 bar/tick 调用脚本 | | 回测 | 支持 | 可用脚本回测面板验证 | ### 2.2 当前不建议硬写的部分 | 需求 | 风险点 | 建议 | | --- | --- | --- | | 多空双开 | 需要 long basket 和 short basket 独立状态；交易所也必须是 hedge mode | 第一版拆成两个策略实例，后续补 `ctx.long_position` / `ctx.short_position` | | 重启后继续运行 | 内存变量可能丢失，导致重复开单或错误止盈 | 必须有 basket 状态持久化和成交回放 | | 部分成交 | 均价和层级不能只按“已发单”计算 | 必须按实际成交回填 | | 拒单 / 超最小下单量 | 状态机可能误以为已开仓 | 下单确认必须驱动状态迁移 | | 合约杠杆名义价值 | 不同交易所单位、面值、张数规则不同 | 统一 order sizing 层 | | 爆仓/保证金风险 | 马丁连续补仓容易快速提高保证金占用 | 增加策略级风险预算和强制停止 | --- ## 3. 建议的脚本策略模型 这个用户需求应该抽象成 `LayeredMartingaleBasket`，不是普通网格，也不是简单 DCA。 ### 3.1 参数结构 ```text symbol direction: long | short | both base_order_value leverage layers = 5 orders_per_layer = 3 martingale_multiplier = 2.0 intra_spacing_pct = [0.5, 0.8] inter_spacing_pct = [1.2, 1.5, 1.8, 2.2] take_profit_pct = 2.0 max_total_margin_pct max_notional_pct hard_stop_pct cooldown_bars restart_after_take_profit = true ``` ### 3.2 状态结构 ```text basket_id side status: idle | opening | active | closing | closed | failed current_layer current_order_in_layer filled_orders total_qty total_notional avg_entry_price next_entry_trigger take_profit_price last_signal_ts last_order_id error_count ``` ### 3.3 执行流程 ```text if basket is idle: open layer 1 order 1 if price moves adverse by intra/inter spacing: open next child order if weighted average reaches take-profit: close basket reset state if max layer/order reached: stop adding wait for TP or trigger risk exit if hard risk limit reached: close basket or stop strategy ``` --- ## 4. ScriptStrategy 基座需要补齐的边界 ### 4.1 Basket state persistence 复杂策略不能只依赖脚本内存变量。建议新增 basket 状态表或 runtime state 标准： ```text qd_strategy_baskets qd_strategy_basket_orders ``` 核心能力： - 每个 basket 有唯一 ID。 - 每个子单有独立状态。 - 状态由成交事件驱动，而不是由“发单成功”驱动。 - 后端重启后可以恢复当前层级、均价和未完成订单。 #### 4.1.1 脚本线程与持久化边界 脚本策略通常跑在线程或任务循环里，但线程内变量只能作为运行期缓存，不能作为真实状态来源。建议把策略状态拆成三层： | 层级 | 用途 | 建议存储 | 是否可信 | | --- | --- | --- | --- | | 线程内存 | 当前循环临时计算、减少查询 | Python object | 不可信，重启即丢 | | Redis / cache | 分布式锁、短期心跳、运行中标记、限频 | Redis，可选 | 半可信，可重建 | | 数据库 | basket、订单意图、成交、风险状态、恢复检查点 | PostgreSQL / SQLite / MySQL | 可信状态源 | 原则是：脚本可以读写 `ctx.state`，但 `ctx.state` 背后必须由运行时托管并定期落库；策略代码不应该直接操作数据库连接，也不应该自己决定恢复逻辑。 建议提供运行时接口： ```python ctx.state.get("current_layer", 0) ctx.state.set("current_layer", 2) ctx.state.flush() ctx.basket("long").open_child_order(...) ctx.basket("long").checkpoint() ``` 其中： - `ctx.state` 保存轻量策略状态，例如当前层级、最近触发价格、冷却计数。 - `ctx.basket` 保存交易相关状态，例如子单、成交、均价、止盈价、未完成订单。 - `flush()` 由运行时批量落库，也可以在发单前后强制 checkpoint。 - 真实下单前必须先写入 `order_intent`，拿到幂等键，再提交交易所订单。 #### 4.1.2 数据库与 Redis 的分工 数据库是恢复源，Redis 只做加速和协调： - 数据库负责：策略实例、basket、子订单、订单意图、交易所订单 ID、成交回报、风险状态、最后 checkpoint。 - Redis 负责：策略运行锁、线程心跳、短期去重键、任务队列、行情订阅状态。 - 如果没有 Redis，单机版本也能工作，只是不能很好地做多进程调度和快速故障切换。 - 如果 Redis 数据丢失，不应该影响真实持仓恢复；最多影响 UI 的“运行中”即时状态。 推荐表结构方向： ```text strategy_runtime_state strategy_baskets strategy_basket_orders strategy_order_intents strategy_order_fills strategy_recovery_events ``` #### 4.1.3 重启与容灾流程 后端重启、线程崩溃或容器迁移后，不应该直接从脚本第一行重新开始发单。恢复流程应由运行时统一执行： 1. 标记策略实例为 `recovering`，禁止脚本继续发新单。 2. 读取数据库中的最后 checkpoint、basket、未完成 order intent。 3. 拉交易所当前持仓、未成交订单、最近成交。 4. 用交易所事实修正本地状态：成交数量、均价、未完成订单、已关闭订单。 5. 对没有交易所订单 ID 的 intent 做幂等判定：确认未提交才允许重试。 6. 重建 `ctx.state` 和 `ctx.basket`，恢复到线程内存。 7. 写入 recovery event，标记为 `running`。 8. 下一轮策略循环只允许基于恢复后的状态继续运行。 关键点是：恢复优先相信交易所事实，其次相信数据库 checkpoint，最后才相信脚本内存。 #### 4.1.4 防重复下单机制 复杂马丁策略最怕重启后重复补仓。每次下单必须有稳定幂等键： ```text strategy_id + basket_id + side + layer_index + order_index + action ``` 例如： ```text strategy-12:basket-20260629-long:L2:O3:open ``` 运行时提交订单前先创建 `order_intent`： - 如果同一幂等键已有 `submitted / accepted / partially_filled / filled`，禁止再次提交。 - 如果是 `rejected / expired`，根据策略配置决定是否重试。 - 如果是 `unknown`，必须先向交易所对账，不允许盲目重发。 这样即使线程在“写库成功、发单超时、交易所实际已接收”的中间状态崩溃，也可以通过交易所订单查询恢复，而不是重复开单。 ### 4.2 Position model upgrade 当前脚本更适合单方向持仓。后续建议提供清晰接口： ```python ctx.position ctx.long_position ctx.short_position ctx.basket(side="long") ctx.basket(side="short") ``` 这样多空双开不会挤在一个 `ctx.position` 语义里。 ### 4.3 Order lifecycle standard 复杂策略必须清楚区分： - intent created - order submitted - exchange accepted - partially filled - filled - rejected - cancelled - expired - reconciled 状态迁移必须幂等，避免重启后重复下单。 ### 4.4 Fill-driven average price 均价止盈必须基于实际成交： - 不能只按脚本计划价格。 - 不能只按信号价格。 - 必须考虑部分成交、手续费、合约面值和滑点。 ### 4.5 Restart recovery 策略恢复时应执行： 1. 读取本地 basket 状态。 2. 拉交易所持仓和未成交订单。 3. 对账本地订单与交易所订单。 4. 重建均价、层级和风险状态。 5. 再允许继续发新单。 这一节是恢复行为摘要，详细线程、数据库、Redis 与幂等设计见 `4.1.1` 到 `4.1.4`。 ### 4.6 Risk guard 马丁类策略必须内置硬风险边界： - 最大层数。 - 最大子单数。 - 最大名义价值。 - 最大保证金占用。 - 最大账户权益占比。 - 最大连续亏损次数。 - 最大浮亏。 - 距离爆仓价最小安全距离。 - 交易所错误过多自动停止。 ### 4.7 Backtest/live consistency 复杂加仓策略需要增强回测： - 支持逐层成交记录。 - 支持手续费和滑点模型。 - 支持最小下单量和价格步进。 - 支持合约张数换算。 - 支持“下根 K 成交”和“tick 触发”的差异报告。 - 支持实盘偏差报告：计划成交 vs 实际成交。 ### 4.8 Strategy run identity 每一次策略启动都必须有独立 `strategy_run_id`。不要只用 `strategy_id` 表示一次运行，因为同一策略可能多次启动、暂停、恢复、修改参数。 建议记录： ```text strategy_id strategy_run_id source_version_id parameter_snapshot account_id exchange symbol market_type position_mode started_at stopped_at stop_reason runtime_status ``` 这样可以回答： - 这笔订单属于哪一次运行。 - 当时使用的是哪一版脚本代码。 - 当时参数是什么。 - 是正常停止、用户停止、风控停止，还是异常崩溃后恢复。 ### 4.9 Single writer and lock model 同一个策略实例同一时间只能有一个运行时写状态和发单。否则多线程、多进程或容器重启时容易重复补仓。 建议： - 以 `strategy_id + account_id + symbol + side` 作为运行锁范围。 - 单机版可以用数据库锁。 - 多实例部署建议用 Redis lock + 数据库 fencing token。 - 每次写入订单状态时检查 `runtime_epoch` 或 `fencing_token`，旧线程失去锁后不能继续写库。 - UI 上的“启动策略”如果发现已有活动 run，应提示用户恢复、接管或强制停止。 ### 4.10 Event ledger 除了保存当前状态，还应该保存事件流水。当前状态用于快速恢复，事件流水用于审计和重放。 建议事件类型： ```text strategy_started signal_generated order_intent_created order_submitted order_accepted order_partially_filled order_filled order_rejected order_cancelled basket_checkpointed risk_guard_triggered recovery_started recovery_completed strategy_stopped manual_override ``` 有了 event ledger，后续才能做： - 策略事故复盘。 - 回测与实盘偏差报告。 - 用户投诉时还原执行过程。 - 版本升级后的兼容性检查。 ### 4.11 Code and parameter snapshot 实盘运行不能只引用“当前脚本代码”。用户可能在策略运行中修改脚本，如果没有快照，会出现无法复现的问题。 建议： - 每次启动实盘时固定 `source_version_id`。 - 保存代码 hash、参数快照、运行配置、交易账户、交易所模式。 - 修改代码后不影响正在运行的 run，除非用户明确点击“应用并重启”。 - 回测记录、实盘记录和市场模板都引用同一套版本快照。 ### 4.12 Manual intervention and degraded mode 恢复失败、交易所状态不一致或订单状态未知时，不应该让策略继续自动补仓。 建议增加状态： ```text running recovering paused needs_review stopping stopped failed ``` 进入 `needs_review` 时： - 禁止发新开仓单。 - 允许只减仓或撤单。 - UI 显示差异：本地 basket、交易所持仓、未成交订单。 - 用户可以选择：同步交易所状态、关闭 basket、继续观察、强制停止。 --- ## 5. 算法交易能力缺口 目前 QuantDinger 已有基础下单与策略运行能力，但还不是完整 AlgoTrading 执行平台。 ### 5.1 当前已有能力 - 市价单。 - 限价单。 - 基础取消订单。 - 策略信号触发下单。 - 止损、止盈、追踪止损等策略级风控。 - 网格 resting limit orders 的部分执行基础。 - 多交易所适配框架。 ### 5.2 需要补齐的算法交易模块 建议新增独立域： ```text app/services/algo_trading/ order_intent.py scheduler.py child_order.py execution_algorithms/ twap.py iceberg.py best_limit.py sniper.py stop.py order_state.py reconciliation.py risk.py ``` ### 5.3 第一阶段建议实现 | 算法 | 优先级 | 原因 | | --- | --- | --- | | TWAP | P0 | 最容易解释，最适合大额分批成交 | | BestLimit | P0 | 基于盘口最优价挂单，适合低滑点执行 | | Stop / StopLimit | P0 | 用户理解成本低，交易刚需 | | Iceberg | P1 | 大单隐藏，依赖交易所支持或本地拆单 | | Sniper | P1 | 需要盘口、成交量、触发条件和撤单速度 | | VWAP / POV | P2 | 需要可靠成交量曲线和市场深度数据 | --- ## 6. 算法交易必须补齐的边界 ### 6.1 Unified order intent 所有策略和手动交易都应先生成统一订单意图： ```text side symbol market_type position_side reduce_only notional quantity limit_price time_in_force execution_algo risk_budget client_order_id strategy_id basket_id ``` ### 6.2 Child order scheduler TWAP/Iceberg/Sniper 都需要子单调度： - 分片数量。 - 分片间隔。 - 每片最大数量。 - 撤单重挂。 - 超时处理。 - 最大滑点。 - 成交不足补单。 ### 6.3 Market microstructure data 算法交易不能只靠 K 线。至少需要： - best bid/ask。 - order book top levels。 - recent trades。 - spread。 - depth。 - volatility。 - exchange rate limit。 ### 6.4 Reconciliation 执行器必须定期对账： - 本地订单状态。 - 交易所订单状态。 - 实际成交。 - 当前持仓。 - 手续费。 - 平均成交价。 ### 6.5 Kill switch 算法交易需要全局和策略级开关： - 全局暂停发单。 - 单策略暂停。 - 单交易所暂停。 - 最大错误次数自动停止。 - 最大滑点自动停止。 - 仓位异常自动停止。 - API key 异常自动停止。 ### 6.6 Observability 需要能回答： - 为什么下了这笔单？ - 计划成交多少？ - 实际成交多少？ - 滑点多少？ - 哪个子单失败？ - 是策略原因、交易所原因还是风控原因？ 建议新增： ```text algo_order_logs algo_child_order_logs execution_trace_id strategy_run_id ``` ### 6.7 Exchange capability matrix 算法交易不能假设每个交易所能力一致。需要维护交易所能力矩阵： ```text exchange market_type supports_hedge_mode supports_reduce_only supports_post_only supports_stop_order supports_iceberg supports_client_order_id min_notional min_quantity price_tick quantity_step rate_limit order_book_depth ``` 运行时根据能力矩阵决定： - 能否启动某个策略。 - 是否需要本地模拟 stop / iceberg。 - 下单数量和价格如何 round。 - 策略模板是否适合某个交易所。 ### 6.8 Account, permission, and secret boundary 算法交易会放大账户风险，必须把账户权限纳入运行前检查： - API key 是否具备交易权限。 - 是否禁止提现权限。 - 是否支持读取订单和成交历史。 - 是否配置 IP 白名单。 - 是否允许合约交易。 - 是否设置账户级最大风险预算。 策略启动前应做 preflight check，失败时明确告诉用户缺哪个权限或配置，而不是启动后才报错。 ### 6.9 Test and certification suite 如果要把 QuantDinger 做成基础设施，需要有策略运行时验收测试： - 重启恢复测试：发单中途杀进程，恢复后不重复下单。 - 部分成交测试：均价和 TP 按真实成交更新。 - 拒单测试：最小下单量、余额不足、API 错误后不误改 basket。 - 断网测试：状态进入 `needs_review`，不继续补仓。 - 多空 hedge 测试：long basket 与 short basket 独立。 - 回测/实盘一致性测试：同一信号路径能对齐计划成交点。 - 交易所精度测试：价格 tick、数量 step、最小名义金额都正确处理。 --- ## 7. 产品分期路线 ### Phase 1：ScriptStrategy 专业化 目标：让复杂状态机策略可稳定运行。 - Basket runtime state。 - 多空独立 position/basket 接口。 - 成交驱动均价。 - 重启恢复。 - 策略运行 ID、代码版本快照和参数快照。 - 事件流水和恢复审计。 - 单写入者锁，避免重复运行。 - 复杂策略回测报告。 - Layered Martingale Basket 官方模板。 ### Phase 2：基础 AlgoTrading 目标：让用户可以选择执行算法，而不只是市价/限价。 - Unified order intent。 - TWAP。 - BestLimit。 - Stop / StopLimit。 - 子单状态表。 - 执行日志和偏差分析。 - 交易所能力矩阵。 - 账户权限 preflight check。 ### Phase 3：高级执行 目标：降低大额交易滑点，支持专业交易执行。 - Iceberg。 - Sniper。 - VWAP。 - POV。 - 盘口深度驱动。 - 智能撤单重挂。 ### Phase 4：基础设施化 目标：QuantDinger 成为策略、执行、风控、监控一体化基础设施。 - 统一策略运行 ID。 - 全链路 execution trace。 - 交易所能力矩阵。 - 多账户组合执行。 - 回测/模拟盘/实盘一致性报告。 - 策略市场模板准入审核。 - 风险沙盒和资金预算模拟器。 - 运行时验收测试套件。 --- ## 8. 推荐落地顺序 最推荐的实际落地顺序： 1. 先做 `LayeredMartingaleBasket` 官方脚本模板，只支持 `long` / `short`。 2. 增加 `strategy_run_id`、代码快照、参数快照，保证可追溯。 3. 增加 basket 状态持久化和事件流水，解决重启恢复。 4. 增加单写入者锁和幂等下单，解决重复运行和重复补仓。 5. 增加成交驱动均价，解决部分成交和真实 TP。 6. 增加 `long_basket` / `short_basket`，再开放多空双开。 7. 增加交易所能力矩阵和启动前 preflight check。 8. 增加 TWAP / BestLimit，作为算法交易第一版。 9. 再做 Iceberg / Sniper。 这样既能尽快满足用户需求，又不会把复杂风险压到脚本作者身上。 --- ## 9. 对外表述建议 当前阶段建议谨慎表述： ```text QuantDinger supports stateful ScriptStrategy workflows for scale-in, DCA, martingale-style baskets, average-cost exits, backtesting, and live execution. Advanced multi-leg basket persistence, hedge-mode basket accounting, and algorithmic execution orders such as TWAP, Iceberg, Sniper, and BestLimit are planned infrastructure upgrades. ``` 中文： ```text QuantDinger 当前支持有状态脚本策略，可实现分批加仓、DCA、马丁篮子、均价止盈、 回测和实盘执行。多腿篮子持久化、多空独立篮子核算，以及 TWAP、Iceberg、 Sniper、BestLimit 等算法订单执行能力，将作为后续基础设施升级重点。 ``` 不要过早宣传“完整算法交易平台”，应先宣传“可扩展的策略运行时 + 正在建设中的算法执行基础设施”。