有些原miniQMT使用者，并不是只写了一个简单买卖脚本，而是已经有完整外部系统。里面可能有本地数据库、因子计算、股票池、策略日志、风控规则、复盘报表，甚至还有自己的信号看板。

miniQMT不能继续使用以后，这类人最容易走向一个误区：既然QMT能写Python，那就把原来所有代码都搬进QMT。

这件事看起来直接，实际未必合适。

复杂策略之所以复杂，是因为它承担了很多不适合放在交易回调里的任务。比如大量数据清洗、全市场因子计算、数据库扫描、报表生成、外部信息处理。这些任务更适合继续放在外部系统里。

QMT更适合作为执行端。

比较合理的结构是：

外部系统负责计算。

QMT负责执行。

外部系统先完成数据清洗、因子计算、股票池筛选、仓位计划和风控判断，最后只输出一条可执行信号。QMT读取信号以后，再检查账户资金、持仓、信号有效期和是否重复处理，确认无误后再提交委托。

这种分层的好处，是两边职责清楚。外部系统继续做它擅长的复杂计算，QMT侧保持轻量，不会被大量计算拖慢。

一条可执行信号至少要说清楚几件事：什么时候生成，什么时候过期，交易什么标的，方向是什么，数量多少，价格条件是什么，来自哪个策略。没有这些信息，QMT侧就很难判断该不该执行。

比信号本身更重要的是状态。信号读过没有？委托提交没有？订单是已报、已成、已撤还是废单？如果程序重启，之前的信号还会不会重复执行？这些问题不解决，代码能跑也不等于系统安全。

这也是为什么复杂策略迁移不能只盯着“QMT怎么读取文件”。读取文件只是入口，真正影响长期运行的是去重、状态、反馈和恢复。

如果策略频率不高，可以先用本地文件验证。比如外部系统写出一条信号，QMT读取后只打印日志，不下单。等这个过程稳定后，再进入模拟环境，最后才考虑小规模实盘。

如果信号较多、需要长期追踪，SQLite会更适合。它可以保存信号状态、处理结果和订单反馈。至于更复杂的队列和网络方式，要看具体环境是否支持，不适合一开始就作为普通人的第一步。

PTrade也能承接一部分策略，但它更适合标准化和低维护场景。如果策略不依赖外部数据库和复杂信号，只是固定时间调仓，PTrade可能更省心。

如果原来已经有完整外部系统，那么“外部计算加QMT执行”更接近原来的思路。核心不是把代码搬家，而是重新分层：研究归研究，信号归信号，执行归执行，反馈归反馈。

还有一个容易忽略的问题：复杂策略通常不是只有一个入口。它可能盘前生成股票池，盘中更新信号，收盘后复盘归档。把这些动作全部放在同一个策略回调里，短期能凑合，长期会让逻辑越来越乱。分层以后，每个模块只处理自己的任务，问题也更容易定位。

真正好的迁移，不是把旧代码强行改到能跑，而是把系统结构重新理顺。外部端负责计算和记录，QMT端负责读取、校验和执行。这样即使以后执行工具再变化，也不会牵动整个策略体系。

这条路线能不能落地，要看策略频率、数据来源、账户权限和执行要求。先把这些信息梳理出来，再判断具体该用本地文件、SQLite，还是更复杂的信号方式。主页后续会继续整理外部信号与QMT执行端的迁移思路，本文仅作量化系统迁移参考，不构成投资建议。