聚宽转QMT的核心技术痛点

一、 架构选型：除了“硬改”，还有“信号中转”

在代码重构之外，目前业界非常流行**“策略研发与交易执行分离”**的架构。如果不想彻底重写代码，可以采用信号中转法：

• Redis/Flask中转：聚宽策略生成交易信号后，通过 redis 库写入云服务器（如阿里云），QMT端通过 run_time() 高频轮询（如500ms）拉取信号并执行 passorder。这种方式信号延迟通常在1-3秒内，且完全保留了聚宽原有的事件驱动逻辑。

• 第三方跟单系统：利用封装好的QMT跟单脚本，在聚宽策略开头插入特定代码段，将信号发送至中转服务器，QMT端每3秒自动读取并执行，内置了止损止盈、黑名单等风控模块。

二、 底层机制：QMT的运行框架与数据本地化

QMT与聚宽的云端环境有本质区别，迁移时必须注意以下底层差异：

• 生命周期函数重构：聚宽的 initialize 和 handle_data 必须替换为QMT的 init(ContextInfo) 和 handlebar(ContextInfo)。同时，聚宽的 run_daily/run_weekly 在QMT中需改为 run_time()，开发者需要自行编写时间判断逻辑来控制策略运行时段。

• 数据获取方式变更：聚宽直接调用云端API，而QMT的数据存储在本地。迁移时必须先使用 download_history_data 下载数据，再通过 get_local_data 或 get_market_data_ex 读取。此外，QMT的持仓查询更为复杂，需要通过遍历 get_trade_detail_data 返回的字典来获取，而非聚宽中简单的 context.portfolio 属性。

• 环境兼容性：QMT仅支持Windows系统，且内置Python环境（一般3.7以上）。用户应直接使用QMT内置环境，切勿自行安装Python解释器，以免引发版本冲突和依赖库报错。

三、 进阶工程：解决“状态割裂”的影子对账法

在“聚宽发信号 + QMT执行”的架构中，极易出现状态割裂问题（例如：盘中人工手动平仓，导致聚宽账本与QMT真实持仓不一致，后续触发错误的卖出指令）。

• 影子对账（Shadow Reconciliation）：建议在核心业务节点（如尾盘风控执行前）强制执行一次对账。通过调用QMT API拉取真实持仓，与聚宽沙盒账本取并集比对。

• 安全发单机制：若发现数量不一致，需临时切断实盘发单路由（设置标志位为False），在沙盒内调用聚宽原生 order_target 强制对齐持仓，随后利用 try...finally 原语强制恢复实盘路由。这能有效防止因状态机变量泄漏导致的系统永久熔断。

四、 实盘过渡：从仿真到实盘的“安全阀”

代码在QMT跑通回测后，切勿直接全量实盘，建议遵循以下过渡机制：

• 小资金试运行：初期仓位控制在策略设计值的10%以内，验证买卖逻辑触发、委托提交及订单状态反馈。

• 参数校验与异常处理：在代码中固化核心参数，并增加 try...except 异常处理。必须添加参数校验逻辑（检查代码有效性、价格涨跌停范围、数量整手要求），以及断线重连、订单缓存等稳定性保障措施。

• 合规与风控：QMT实盘默认开启“人工确认”开关，首次下单需弹窗授权。若要实现全自动化，需签署《程序化交易风险揭示书》并完成适当性评估。

总结建议： 对于简单策略，建议直接进行代码重构与API映射；对于复杂策略或希望快速上线的场景，推荐采用Redis信号中转 + 影子对账的解耦架构。无论选择哪种路径，都必须经历“本地数据下载验证 → 仿真环境过单 → 小资金实盘陪跑”的完整闭环。