简介量化交易通过程序化策略自动完成行情分析、信号生成与委托下单其核心在于将研究逻辑转化为可稳定执行的工程系统。在真实交易环境中策略不仅需要正确的信号判断更要处理行情订阅、订单撮合、账户管理、风控熔断等环节。QMT作为券商提供的极速策略交易系统打通了从研究到实盘的最后一公里支持Python编写策略并直接连接柜台。本文以MiniQMT与xtquant为核心复盘了一套完整落地流程涵盖环境搭建中的0x80070659安装问题、双均线策略从回测到模拟盘的适配差异、行情与交易接口的分工以及数据落地、日志监控和风控参数等工程化细节为量化投资者提供从研究到实盘的可执行参考。 最近做了一段时间的量化实盘落地越发觉得从研究到实盘之间的那条“河”比大多数人想象的要宽。策略在Notebook里跑得再好一碰到真实柜台、真实账户、真实行情各种问题就全冒出来了。这篇内容想围绕我自己实际在用的这套“QMT量化交易策略系统”做一次完整复盘把从环境搭建、策略代码、回测到实盘运行中该注意的坑尽可能都捋出来。适合那些已经有Python基础、想把策略从“自嗨”变成真金白银运行的读者参考。QMT全称是迅投QMT极速策略交易系统很多券商把它作为官方量化交易终端提供给客户。它最大特点是行情、交易、账户、风控全部打通可以直接用Python写策略也能写C策略策略跑在本地和柜台的连接链路很直接。对比目前常见的开源框架qbot这类工具更适合做研究和模拟QMT更像是把研究和实盘之间的最后一道门打开。1. 为什么我在研究框架转实盘的时候选了QMT1.1 QMT到底是个什么东西先说一个容易混淆的点QMT不只是一个看盘软件它包含完整的行情源、交易通道、策略运行环境和回测组件。市面上很多“量化交易终端”本质是下单软件加一个公式选股器但QMT是正经的“策略运行平台”你写的Python代码是直接跑在本地调用它的API来完成行情订阅、数据获取、下单、撤单、查持仓等动作。它和普通行情软件最大的区别在于“策略作为一个长驻进程”存在。传统交易软件里你手动敲单工具帮你下单QMT里策略启动后会自动监控行情、自动触发买卖条件、自动管理持仓整个过程中你可以完全不碰鼠标。另外QMT分两种形态完整客户端和MiniQMT。完整客户端带交易界面看着像普通行情软件但可以启动Python策略MiniQMT则更干净只保留行情和策略运行环境习惯全代码操作的人一般更爱用后者。我在实际项目中用的就是MiniQMT加xtquant这套组合这也是目前很多个人量化团队的主流方案。1.2 跟qbot这类开源框架比QMT赢在哪这几年qbot、vn.py这些开源框架的讨论度一直很高。我早期也折腾过一段时间qbot它的架构确实漂亮策略模块化、事件驱动、回测引擎一应俱全适合学习和验证想法。但真到了实盘那一步问题就来了普通散户能接的实盘通道非常有限要么通过某些间接服务要么自己写对接各种柜台协议后者门槛高到没边。QMT的逻辑完全不同它是券商直接提供的通道合规层面门槛低很多。这决定了QMT在“从代码到真实下单”这条路上几乎是最短路径。拿qbot做类比的话qbot解决的是“策略怎么写、怎么测”的问题QMT解决的是“策略怎么安全地连接真实柜台”的问题。两者其实可以互补但如果你目标很明确就是跑实盘QMT能省掉大量基础设施工作量。2. 本地环境搭建从下载到跑通MiniQMT踩过的0x80070659这个坑2.1 MiniQMT是什么跟完整版有什么区别QMT下载回来的时候不管哪个渠道默认看到的都是带界面完整版。完整版功能多但对一台常年挂着跑策略的电脑来说负担偏重。MiniQMT可以理解为“精简运行版”类似把一套完整的策展场地换成了一张干净的工作台该有的插座和水管都在只是去掉了花哨装修。两者在API层面没有差别都是xtquant这套库。你用MiniQMT跑策略同样能订阅行情、下单、查持仓。区别主要在启动方式完整版需要手动登录客户端再启动策略MiniQMT则更多依赖程序内部的登录和会话处理。我用MiniQMT的另一个原因是稳定性。完整版界面偶尔会因为行情刷新、弹窗提示之类的原因抢占焦点一不小心就影响策略运行而在无人值守的场景里一个弹窗可能就意味着策略停滞一个晚上。MiniQMT这种“无界面”的设计天然避免了这类问题。2.2 安装报错0x80070659的完整排查链路这是我在安装过程中遇到的最典型的坑值得单独拿出来说。MiniQMT安装的时候有部分Windows电脑会直接弹出错误0x80070659提示“系统策略禁止这个安装”。从报错字面看这不是安装包本身损坏而是Windows安装策略挡住了安装程序。我当时把常见的卸载残留、安装目录权限问题都排查了一遍不是那些原因。完整链路是这样一步步定位出来的看安装日志确认错误发生在Windows InstallerMSI阶段排除下载文件损坏的可能查事件查看器的应用程序日志发现MSI调用时返回了“策略禁止”相关的错误码指向组策略层面的限制核对当前系统的安装策略发现本地计算机策略里对MSI安装包做了限制导致非管理员权限下的安装直接被拦截用管理员身份重新运行安装包配合关闭安全软件安装才正常完成。所以如果你也碰到0x80070659第一步不要怀疑安装包先右键“以管理员身份运行”。如果还是不行再检查本地安全策略、用户账户控制UAC设置以及杀毒软件是否拦截了MSI进程。这几个方向基本覆盖了绝大多数情况。2.3 登录和会话保持那点事很多人在QMT里跑通第一个Hello World之后都会忽略登录会话的问题。QMT和柜台的连接是有时效的登录状态断开后策略程序还在跑但下单接口会报错或者静默失败。我的做法是单独写一个健康检查进程定期通过xtquant的查询接口确认连接状态一旦发现会话断开立即用保存的账号信息重新登录并通过消息推送通知自己。策略的异常恢复能力往往比策略本身的收益能力更影响最终结果这一点后面还会展开讲。3. 第一个Python策略双均线怎么在QMT里跑起来3.1 策略代码的基本骨架先给一个最简版本的策略骨架让大家对QMT下的Python策略长什么样有个直观概念。这个例子不构成投资建议纯粹是讲清楚结构。from xtquant import xtdata from xtquant.xttrader import XtQuantTrader, XtQuantTraderCallback from xtquant import xtconstant class MyStrategy: def __init__(self, account): self.account account self.short_win 5 self.long_win 20 self.last_signal None self.position 0 def on_bar(self, bar): code bar[stock_code] # 这里只做演示用bar的close计算均线 # 实际使用时需要维护历史序列 pass def buy(self, code, price): order_id self.xt_trader.order_stock( self.account, code, xtconstant.STOCK_BUY, 100, xtconstant.FIX_PRICE, price, my_strategy, 双均线测试 ) return order_id def sell(self, code, price): order_id self.xt_trader.order_stock( self.account, code, xtconstant.STOCK_SELL, 100, xtconstant.FIX_PRICE, price, my_strategy, 双均线测试 ) return order_id def initialize(): account 你的资金账号 xt_trader XtQuantTrader(你的QMT路径, 1) xt_trader.start() strategy MyStrategy(account) # 注册回调、订阅行情等 return strategy这段代码强调的是QMT的调用方式通过xtquant.xttrader.XtQuantTrader创建交易实例用order_stock下买卖单用xtdata做行情数据获取。真正的策略逻辑需要填充数据维护和信号判断部分但整体框架就是这样一个“回调函数”的形态。3.2 从行情到下单xtdata和xttrader的分工在QMT里xtdata负责处理“看市场”的部分xttrader负责处理“做交易”的部分。记住这个分工写策略的时候思路会清晰很多。xtdata支持订阅实时行情、拉取历史K线、获取财务数据等。它更偏“数据服务”而且数据是本地缓存加增量更新的方式速度很快。xttrader则是真正的交易通道下单、撤单、查委托、查持仓都走它。双均线策略说白了就是从xtdata拿到K线计算短周期和长周期均线当短线上穿长线时触发买入信号下穿时触发卖出信号。信号产生之后调用xttrader的order_stock接口把指令发到柜台。这里有一个很多新手容易踩的坑策略里的价格信号和实际成交价格是两个东西。K线数据是行情源返回的行情快照而真实下单时要考虑当时的盘口深度、对手单情况。所以写策略时一定不要想当然地“我看到1.5元我下1.5元买单”而是要么用对手价要么用合理偏移的限价。后面在讲回测和实盘差异时会细说。3.3 实盘与回测中的成交细节差异我在回测里构造的双均线策略收益率曲线看起来像模像样但实盘一跑发现几个明显差异回测成交价用的是K线的close价而实盘里你的委托单可能要等好几个tick才能成交价格自然有偏差。回测里默认100股就能买但实盘会有最小交易单位、一手等于100股、部分ETF的最小单位不一样这些约束在回测时不处理实盘就会报错。回测里很少考虑停牌、涨跌停封板但实盘里策略信号触发了发单出去可能根本成交不了因为股票在停牌期或封死跌停。所以回测代码在实盘之前必须针对这些现实约束做一层“适配”。这不是QMT独有的问题任何框架都一样但QMT因为贴近真实柜台这些问题会更加直接地暴露出来。4. 策略从行情到下单的完整链路拆解4.1 行情数据从哪里来又落到哪里去QMT的行情数据来自它的行情服务器启动时会自动做增量下载和本地缓存这也是它行情速度快的原因之一。xtdata提供的download_history_data可以预下载历史数据get_market_data可以取K线数据。数据管理上我一般会把历史数据落地一份到本地数据库比如SQLite或Parquet文件。原因有两个一是QMT的本地缓存目录理论上可能因为客户端清理而丢失自建数据备份更安心二是回测时用的数据源如果和实盘不一致很容易出现“回测赚钱实盘亏钱”。所以我自己维护了一套数据同步脚本每天收盘后从xtdata拉取全量数据更新到本地库里回测和实盘都统一从这套数据出发。4.2 下单接口的几个关键参数xttrader的order_stock是核心下单接口。参数看起来不多但细节很关键stock_code证券代码注意格式。股票通常是“600000.SH”这种带后缀格式不能只写“600000”。order_type买卖方向用xtconstant.STOCK_BUY和xtconstant.STOCK_SELL。order_volume委托数量。股票是股数通常按100股的整数倍报单。price_type定价方式。xtconstant.FIX_PRICE是限价单xtconstant.LATEST_PRICE是最新价不同定价方式对应的成交逻辑差异很大。price委托价格。限价单时必须填价格填错了单子就可能废掉。strategy_name策略名字方便在交易记录里区分不同策略的单子。我自己踩过的最狠的坑是stock_code格式不一致。有些场景下返回的是不带后缀的代码直接拿来做下单参数就会报“证券代码错误”。所以我在整个系统里强制统一代码格式所有代码从接入点就标准化成带后缀的形式宁可多写两行转换不在这种低级错误上翻车。4.3 账户与资金管理的基本姿势QMT的多账户支持做得不错一套代码可以管理多个资金账号前提是这些账号都绑定了QMT权限。在初始化时需要用资金账号去创建账户对象下单时把账户对象作为参数传给order_stock。策略里可以动态查询账户资金、持仓、冻结资金等以此决定下单数量。一个比较务实的建议不要在策略里把仓位写死成“资金全部买入”或“只买100股”而是做一个独立的仓位管理模块根据当前权益、单票最大仓位上限、最大回撤控制等因素动态计算下单数量。这个模块在回测和实盘里共用可以大幅减少“回测赚实盘亏”的概率。5. 回测看着赚钱的策略实盘为什么变样5.1 回测引擎和实盘撮合的本质区别回测最大的问题在于“你知道未来”。回测引擎在计算交易时用的是历史的完整K线信号出现的那一刻你已经知道了那一刻的准确价格。但实盘不一样你的信号是按照行情一步一步推出来的下单到成交之间有延迟甚至可能订单根本没法成交。更关键的一点是回测里的资金曲线不受市场冲击和对手盘深度影响但对于小资金来说这个影响其实又没那么大真正影响最大的是成交假设太乐观。我在回测里用的是“信号触发后按下一根K线开盘价成交”的保守假设依然和实盘有差异如果默认用当根K线收盘价那差异只会更大。5.2 滑点、涨跌停、停牌这些回测里看不见的东西滑点就是发单价格和最终成交价格的差值。对小盘股、高波动股票滑点可能非常夸张。我做过一次对比在一个日内策略上按零滑点回测年化收益可能在30%按真实盘口深度估算滑点后直接就变成负收益。涨跌停的问题也很现实。A股有涨跌停限制股票涨停时你想买买不进跌停时想卖卖不掉。但回测引擎默认所有订单都能成交。如果策略恰好就是在涨停日买入、跌停日卖出回测收益率会被严重高估。停牌更不用说了长期停牌的股票在回测里可能被强行“映射”到某一天的价格导致成交结果完全失真。所以实盘策略上线前我强制做了一件事把历史数据里所有涨停、跌停、停牌的时间段标记出来在回测里遇到这些时段就禁止成交。这个细节能让回测结果真实不少。5.3 在QMT里做近似实盘的模拟验证QMT一般会提供模拟环境交易接口和实盘一致但走的是模拟撮合价格按实时行情模拟。我每次上线新策略都会先让它跑两周以上的模拟盘。模拟盘的意义在于你可以看到真实的策略行为、真实的信号频率、真实的持仓波动但不用担心亏真钱。在这个过程中我经常会发现一些回测里完全发现不了的问题比如策略单子太多导致账户资金不足、信号在两个相邻K线反复横跳导致频繁交易、下单后因为停牌而一直挂着废单等。模拟盘跑稳之后再上小资金实盘用小资金跑一两个月确认逻辑、代码、运维都稳定了再逐步加仓位。这个步骤可能看起来保守但对于希望通过量化稳定做投资的人恰恰是风险最低的路径。6. 跑起来之后必须处理的工程化问题6.1 数据落地别让行情只活在内存里很多人在本地跑策略数据全在QMT的缓存里程序重启、缓存清理历史数据就没了策略复盘就变成“无源之水”。我现在的做法是每日收盘后定时任务拉取行情数据写入Parquet文件存到本地同时做一份数据质量校验。这个“数据资产化”的过程很重要因为你的策略要迭代每次迭代都要基于同一份可靠的历史数据验证改进是否有效。如果没有自己的数据副本你很难判断策略表现变好是因为逻辑改进还是数据不同。6.2 日志与监控策略挂了一晚上第二天早上才知道就晚了策略运行过程中最怕的是静默失败。程序看着在跑实际上行情订阅断了、下单接口报错了持仓和策略逻辑脱节这种过程几乎必然导致回撤。我给自己的系统加了三层保障日志每次下单、撤单、信号触发、异常捕获都写入结构化日志。日志格式包含时间、策略名、证券代码、动作、价格、数量、日志级别方便后续排查。运行监控独立的监控进程定时探测策略进程是否存活以及关键指标持仓数量、当日盈亏是否在合理范围内。异常通知策略内任何未捕获的异常立即推送到手机。我宁可半夜被消息吵醒也不希望第二天发现策略已经“死”了一夜。6.3 风控参数给策略上一道保险策略的交易逻辑再完美也必须有一道独立于策略本身的风控层。我的风控参数集中在四个维度单笔最大下单金额防止单次信号过于激进单票最大持仓比例避免一个票上暴露过多风险单日最大亏损阈值触发后当天暂停新开仓策略总仓位上限防止多个策略叠加后仓位爆表。风控模块有一个非常关键的原则它必须完全独立于策略逻辑运行不能因为策略代码报错就一并失效。我的做法是把风控判断放在下单接口调用的外层用最简单的代码写死不依赖任何策略计算结果。7. 给后来者的选型建议和几句大实话7.1 什么样的人适合QMTQMT适合三类人一是已经有完整策略逻辑、就差一个实盘通道直接落地的个人二是既想自己控制策略代码又不想折腾柜台协议的小型团队三是做期货和股票混合交易的人QMT对期货量化的支持也做得比较完整接口设计相对统一。如果只是刚学量化还在研究指标、调参数阶段我建议先别急着上QMT先拿历史数据、用开源框架把策略逻辑想清楚把策略的期望值、最大回撤、夏普比率这些概念先吃透。QMT是一个运行环境不是一个帮你找到赚钱策略的工具。策略本身没有正向预期换什么平台都一样。7.2 我建议的起步路径如果你决定用QMT按这个顺序推进会少踩很多坑。第一步先按本文的环境搭建步骤把MiniQMT跑起来能通过xtdata拉到数据能用示例代码注册回调把基础链路打通。第二步写一个最简单的策略比如双均线先在模拟盘里跑起来感受一下信号、委托、成交这几个环节在真实环境下的表现。第三步等模拟盘跑顺之后把策略接入自己的数据落地方案、日志和监控体系确保这套系统可持续运行。第四步再考虑上小资金实盘用最小的仓位去验证整个闭环。每个阶段都有各自的坑但越是前期慢一点后面省下的时间越多。7.3 关于这个组合的最终体会我没有选择事后再做更多总结因为每一步都是踩出来的经验。QMT这套系统给我最大的感受是它并不神奇也就是给你提供了一个和真实柜台之间的直连通道但恰恰是这个通道让策略真正开始接受市场的检验。同一套代码在Notebook里跑得流光溢彩放到QMT里跑起来就是各种现实问题轮番上演。也正因为如此如果你想让量化策略从“研究品”变成“能长期运行的产品”环境搭建、回测适配、数据管理、日志监控、风控哪一个环节都不能省。这套工程化的功夫才是实盘跑下来真正决定成败的部分。希望这篇分享能帮你少走一些我走过的弯路。本文还有配套的精品资源点击获取