量化交易系统设计与搭建全攻略：基于QMT的实战架构解析
本系列文章的首篇将从全局视角出发，剖析量化交易系统的核心组件，阐述选择QMT作为交易通道的原因，并逐步指导开发环境的搭建。阅读本文后，您将对系统架构有全景式理解，并能配置好本地开发环境。
核心组件：量化交易系统的六大模块
一个真正可运行的量化交易系统，其复杂性远超单一的“策略脚本”。
设想您正坐在电脑前，准备借助程序进行交易。您需要哪些要素？
行情——首先必须洞察市场动态。这包括每只股票的实时报价、逐笔成交记录以及K线图表数据。
策略——获取数据后，您的程序需具备决策能力。判断买入时机、确定仓位大小以及选择卖出时点。
执行——策略产生决策后，还需将订单传送至交易所。应使用限价单还是市价单？如何处理部分成交情况？撤单操作又该如何执行？
持仓——买入后必须准确记录持有标的。特别是多个策略交易同一标的时，需区分各策略的持仓份额。此外，一个策略可能分批买入相同标的，程序需知晓每笔买入的可卖出日期。不同标的可能涉及T+1或T+0等差异规则。同时，还需监控止损线是否触及。
风控——必须防止单笔交易导致重大亏损。这包括单只股票仓位上限、日内最大交易次数以及最大回撤控制等规则。
数据——回测需要历史数据，选股依赖因子数据，并且每日需更新交易日历。
这六大模块相互关联，共同构成一个完整的交易系统：
许多初学者尝试将所有逻辑写入单个Python脚本，初期运行或许无碍。然而，当策略数量从1个增至5个，数据频率从分钟级提升至Tick级，或从模拟盘转向实盘时，这种“大杂烩”式架构将带来诸多困扰。
新手在实际项目中常遭遇以下典型问题：
- 多个策略各自维护一套持仓管理代码，导致逻辑重复且经常不一致
- 添加新策略时需要修改启动脚本、调整行情订阅及风控逻辑
- 单一策略的缺陷可能导致整个系统崩溃
- 持仓数据与券商记录不同步却难以察觉
这些问题促使我们重新设计了一套分层解耦的系统架构。
平台选择：为何QMT成为个人开发者的首选
在A股市场，个人量化交易者可选的券商接口相对有限：
QMT（Quantitative Model Trader）是由迅投科技开发的量化交易平台。对于个人开发者而言，它几乎是唯一支持通过Python直接调用、同时提供行情和实盘交易功能的A股接口。
QMT提供两种运行模式：
- 标准QMT：完整的图形用户界面客户端，内置策略编辑器和回测功能，但灵活性相对受限
- MiniQMT：轻量级客户端，通过XtQuant SDK的Python API完全控制行情和交易，适合自建系统
我们选择MiniQMT结合XtQuant SDK，主要基于以下理由：
- 真正的编程自由度：策略逻辑、风控规则、持仓管理全部由您的代码控制，不受QMT平台固有限制
- Tick级数据支持：xtdata提供逐笔Tick和五档行情数据，满足高频策略需求
- 异步事件驱动：行情推送和交易回报均采用回调驱动，天然契合事件驱动架构
- Python原生环境：无需学习新的领域特定语言或脚本语言，可直接利用pandas和numpy等生态工具
XtQuant SDK的核心模块构成如下：
系统分层架构设计
我们的系统采用四层架构设计：
每一层职责单一，仅依赖其下一层：
这种分层设计的核心思想在于：策略开发者只需专注于交易逻辑本身。持仓管理、风控检查、订单提交等操作均由引擎层统一处理。
Bar级策略与Tick级策略的对比
A股市场的数据频率从低到高可分为：日线 → 分钟线 → Tick（逐笔）。相应地，我们的系统支持两种策略类型：
Bar级策略
数据频率：K线（如1分钟、5分钟、日线等）
典型场景：趋势跟踪、均线交叉、动量策略
策略接口：
数据流：
Bar级策略的特点是简单直观。策略只需返回一个整数信号，系统便会自动将其转换为订单。这种模式非常适合入门级及中等频率的策略开发。
Tick级策略
数据频率：Tick（约每3秒一次快照，包含五档买卖盘信息）
典型场景：集合竞价打板、可转债竞价、高频做市
策略接口：
数据流：
Tick级策略不直接返回信号，而是构造OrderRequest对象并提交。这赋予策略更高的自由度——您可以在单个Tick内下达多笔订单，也可以基于复杂的内部状态进行决策。
两者的关键区别
项目目录结构规划
良好的目录结构是系统可维护性的基石。我们按照职责将代码组织如下：
开发环境搭建步骤
前提条件
- 操作系统：Windows（QMT客户端仅支持Windows。若仅使用数据工具和研究模块，Linux系统也可运行）
- Python版本：3.10及以上（使用了match-case、ParamSpec等新特性）
- QMT账户：已在支持QMT的券商完成开户
安装MiniQMT
- 从券商官方网站下载QMT客户端并进行安装
- 在安装目录下找到
userdata_mini文件夹，该路径后续配置需要用到 - 登录MiniQMT客户端，确保行情和交易连接正常
搭建Python环境
Python环境配置属于基础知识，可参考任意教程完成安装。
配置环境变量
复制环境变量模板并填入您的信息：
cp .env.example .env
编辑.env文件，至少需要配置以下内容：
# 您的券商资金账号
BROKER_ACCOUNT_ID=12345678
# MiniQMT的userdata_mini路径
BROKER_SESSION_PATH=D:\XX证券QMT实盘交易端\userdata_mini
验证安装
创建一个简单的验证脚本test_connection.py：
运行后若能成功获取浦发银行（600000.SH）的日K线数据，则说明环境搭建完成。
最简系统的运行全貌
在深入各模块细节之前，先通过main.py了解系统启动的完整流程：
启动过程分为五步，清晰明了。其中第四步的策略注册采用动态加载机制：
配置文件中的"strategy_class": "strategies.multi_factor.strategy.AuctionMultiFactorStrategy"会被自动解析为Python类并实例化。这意味着：
- 添加新策略：只需在
system_config.json中添加一条配置 - 禁用策略：将
enabled字段设为false - 修改参数：更改策略对应的JSON文件，无需触动代码
对应的系统主配置文件configs/system_config.json：
注意"dry_run": false这个字段。当设为true时，系统会跳过真实券商下单，返回模拟订单ID——这就是模拟盘模式，非常适合开发和调试阶段使用。
一个交易日的完整生命周期
理解系统全貌的最佳方式，是跟踪其在单个交易日内的完整行为：
[盘前] scripts/scan_stock_pool.py 运行
→ 筛选当日候选标的，保存至data/pools/目录
[09:00] main.py 启动
→ 加载配置 → 连接QMT → 初始化引擎 → 注册策略 → 订阅行情
[09:15-09:25] 集合竞价阶段 → 引擎接收Tick数据，分发给策略 → 策略记录竞价数据，09:24:55生成信号并下单
[09:30-11:30] 上午连续竞价 → 持续接收行情，策略决策 → 成交回报更新持仓，风控持续检查
[11:30-13:00] 午休（系统保持运行）
[13:00-14:55] 下午连续竞价 → 继续交易 → T+N出场策略执行卖出
[14:56] 收盘锁定 → EodManager启动：撤销所有未成交订单
[15:00] 收盘 → 保存持仓快照（JSON格式，精确到Lot级别） → 重置日统计，阻断新订单
[15:15] 系统自动退出
对于夜盘策略，时间线更为复杂：
[19:00-22:00] 夜盘挂单阶段 → 加载收盘后选股器生成的信号 → 并发提交限价买单至券商
[22:00-09:15] 跨午夜等待 → 系统保持连接，等待次日开盘
[次日 09:30-15:00] 出场执行 → T+N撤单重挂（价格递减 → 市价降级） → 止损止盈监控 → T+N到期卖出
核心设计决策解析
在开始后续章节的深入探讨之前，了解这些关键设计决策将帮助您理解“为何如此设计”：
为何使用asyncio而非多线程？
QMT的行情推送和交易回报采用回调驱动机制。回调在QMT内部线程触发，若直接在回调中处理业务逻辑，可能会阻塞后续回调。使用asyncio事件循环作为中枢：
所有业务逻辑在同一个asyncio事件循环中串行执行，天然避免了并发冲突问题。
为何持仓记录使用Lot而非仅记总数量？
每一笔买入即为一“手”（Lot）。每手记录买入日期、价格及对应策略ID。这种方式使我们能够实现：
- FIFO出场：先买入的先卖出，符合税务优化逻辑
- T+1控制：精确知晓哪一笔今日可卖、哪一笔不可卖
- 策略归因：每手关联到具体策略，便于进行策略级别的盈亏统计
- 冻结机制：卖出前先冻结，成交后扣减，撤单后释放——有效防止超卖
为何策略不直接调用券商接口？
所有订单必须经过统一引擎的_submit_order()方法，该方法串联以下步骤：
对账门控 → 交易时段检查 → 风控检查 → 持仓冻结 → 提交券商
若策略能直接调用券商接口，这些安全网将全部失效。统一入口等于统一管控。
为何使用Mixin模式而非继承？
策略需要五个独立功能：状态持久化、Phase状态机、仓位计算、出场策略、订单重试。若使用继承，层级会非常深：
Mixin模式使每个功能独立可测试、按需组合，不同策略可实现不同功能组合。
每个Mixin均可独立测试，策略按需“混入”所需功能。
下一篇内容预告
第一篇我们从万米高空俯瞰了整个系统的全貌。接下来，我们将逐层深入探索。
第二篇：配置管理——将详细讲解三层配置体系的实现：.env环境变量、Pydantic Settings类型安全层、JSON配置文件与环境变量插值。这是系统安全运行的第一道防线——配置一旦出错，一切免谈。
本文属于「基于QMT构建量化交易实战系统」系列的第一篇。