不满足50万门槛？聚宽策略+轻量执行端实现小资金自动化交易

去年年底我遇到一个特别尴尬的局面：策略在聚宽上回测得很漂亮，年化收益也说得过去，但真金白银准备上实盘的时候，被券商一句“开通QMT需要50万资产门槛”直接劝退。账户里就几万块钱，难道只能天天手动看盘、手动下单？后来我折腾了几天，搭出一条不用开通QMT也能跑小资金自动化交易的路径，从信号生成到自动下单全程跑通，现在已经稳定运行了大半年。今天把这套方案完整写出来，给同样被资金门槛卡住的朋友一个参考。

先说清楚这篇东西适合谁：手里资金量不大（几万到几十万）、已经在聚宽上写过策略并做过回测、想把自己的策略跑上实盘但又不满足券商QMT开通条件的个人量化爱好者。如果你刚好卡在这个位置，这篇内容可以帮你省下不少弯路。

1. 先认清问题：小资金为什么会被QMT卡住

1.1 QMT到底是什么，常规开通条件有哪些

QMT是券商提供的一套量化交易终端，全称经常被叫做“极速策略交易系统”，它把行情、研究、策略回测、实盘交易全部塞进一个客户端里。很多券商把它当作高端客户专属服务，所以开通条件普遍卡得比较严：常见要求是账户资产达到50万甚至100万，再加上必要的风险测评和交易经验审核。换句话说，哪怕你策略写得再稳，资金量不够，终端界面都摸不着。

另一个让不少人头疼的点是QMT的安装环境。就算资金门槛过了，Windows系统、Python环境、各类依赖包、接口权限，每一环都可能出幺蛾子。我见过有人卡在“QMT终端 client is null”这类报错上，查了半天结果是客户端初始化顺序的问题。明明是想让交易自动化，结果光搞环境就耗了好几天，这就有点本末倒置了。

1.2 小资金量化交易的另一个尴尬：通道限制了策略上线

资金量小的时候，大多数人做量化其实并不需要多极速的行情、多低延迟的交易通道。你的策略可能是日线级别、每天收盘后调仓一次，也可能是小时级别、一天操作几次。这种频率下，QMT的极速能力根本发挥不出来，但它却成了你上实盘的唯一堵点。

更尴尬的是，手动下单会破坏整个策略的执行纪律。我最早试过“回测靠聚宽、实盘靠自己”，结果连续几个星期下来，买点卖点总是被情绪干扰，止损也常常下不去手。明明策略里写了“跌破5日线止损”，真到那一刻还是会犹豫。这种时候你就特别需要一个自动化的执行通道。对，执行通道，而不是研究平台——研究平台聚宽已经帮你做得很好了。

2. 整体设计思路：聚宽当大脑，轻量执行端当手脚

2.1 三层架构：策略层、信号桥、执行端

我最终采用的方案可以拆成三层：策略层、信号桥、执行端。简单说，聚宽负责策略计算和信号生成，相当于大脑；信号桥负责把聚宽产生的交易信号送到本地，相当于神经；执行端负责接收信号并真正下单，相当于手脚。三层各管一摊，彼此解耦，任何一层出问题都能单独排查。

• 策略层：聚宽策略，负责跑回测逻辑、计算买卖信号。它不需要碰交易通道，也不需要管账户资金。
• 信号桥：把聚宽的信号通过HTTP请求或邮件推送出来。这一步是把“云上的策略”和“本地执行”连接起来的关键管线。
• 执行端：在自己电脑或轻量服务器上跑一个小程序，接收信号后调用下单通道完成交易，同时记录日志。

这套结构和软件开发里的前后端分离很像。策略改起来只需要动聚宽上的代码，不碰执行端；执行端想换通道，也不影响策略逻辑。对个人来说，最大的好处是改bug快、试错成本低。

2.2 为什么这种设计能绕开QMT门槛

很多人一听“自动化交易”就默认必须有QMT，其实不是这样。QMT只是把“策略计算”和“交易执行”打包在一个终端里。对小资金低频策略来说，策略计算完全可以放在聚宽云端，交易执行则找一个资金门槛更低的通道来完成。中间只要有一个可靠的信号传输机制，就能把两边拼起来。

打个比方，QMT像是一家“全包婚庆公司”，从策划到现场全给你包了，但门槛高、价格贵。而我的方案更像是“自己请策划（聚宽）+自己找场地（本地执行）”，中间的对接环节自己动手解决。虽然前期要多花点开发功夫，但对小资金来说，这是把自动化交易跑起来最务实的路子。

2.3 与“直接买QMT”相比，这套方案的优势

除了绕开资金门槛，这套方案还有几个实际好处。第一，可审计性更强。聚宽负责信号生成，本地负责执行，每一笔信号、每一笔成交都有日志，出问题能对账。第二，开发迭代快。策略代码在聚宽上改完就能跑，不用等本地环境重新部署。第三，不受QMT客户端版本升级、环境依赖之类的问题影响。第四，成本低。聚宽的基础功能足够用，本地跑个Python脚本也不花钱，不需要为用不上的极速行情买单。

当然，它也有代价：你需要自己维护信号桥和执行端，下单通道不一定100%稳定，还需要处理各种边界情况。这些坑我在后面会详细讲。

3. 聚宽策略怎么把信号送出来

3.1 最简单的方式：邮件/短信推送

聚宽策略里自带一个消息通知功能，可以直接在策略中调用send_message，把策略信号发到邮箱或手机短信。这个方式的好处是零成本、零服务器、几分钟就能配好。聚宽文档里支持在策略代码的任意位置调用send_message，比如收盘后运行：

def after_trading_end(context): if should_buy(context): send_message('买入信号：000001.XSHE，建议仓位 30%', title='交易信号')

但这种方式有个天然缺陷：信号是发给“人”的，不是发给“程序”的。如果你的执行端要去邮箱里解析邮件内容，就得写一套邮件IMAP解析逻辑，不仅开发量上去了，邮件延迟、被丢进垃圾箱、解析失败都是潜在问题。所以邮件推送更适合作为“半自动”方案的辅助提醒，或者做信号备份，不太适合直接对接全自动交易。

3.2 更稳的信号桥：HTTP请求直推自己的服务

我更推荐的方式是在聚宽策略里直接发起HTTP请求，把信号POST到你自己部署的公网服务上。这样信号从聚宽云端发出，直接落进你的服务端，不需要中间解析环节，延迟低、稳定性高，也方便自动化处理。

聚宽策略环境本身支持Python的requests库，实测可以发起外网HTTP请求。我自己的做法是：在策略的after_trading_end里，把所有当日信号打包成一个JSON，POST到我部署在云函数上的接口地址。接口那边只需要做身份校验、数据落库、返回确认，就算一次完整推送。

示例代码长这样：

import requests import json def after_trading_end(context): signals = [] for stock in context.portfolio.positions: signals.append({ 'symbol': stock, 'action': 'buy', 'position_percent': 0.3 }) if signals: try: resp = requests.post( 'https://your-domain.com/jq-signal', json={ 'token': 'your_secret_token', 'signals': signals }, timeout=10 ) if resp.status_code == 200: log.info('signal push success') else: log.error('signal push failed: %s', resp.text) except Exception as e: log.error('signal push exception: %s', e)

注意几个关键点：token必须加，不然任何人都能往你的执行端发假信号；timeout一定要设置，聚宽策略运行环境里一个请求卡住会影响正常调度；推送失败时用log记录而不是直接抛异常，这样策略主体还能继续跑。

3.3 信号数据格式：一次把字段设计全

信号推送的JSON结构虽然简单，但字段设计直接决定你后面“省心”还是“糟心”。我早期的信号字段只有“股票代码”和“买卖方向”，跑了两个月想复盘时发现信息根本不够，不知道当时信号对应的价格、仓位、策略版本，对起账来痛苦得要命。

后来我把信号格式统一成这样：

{ "token": "your_secret_token", "strategy_name": "dual_ma_v1", "strategy_version": "20250101", "signal_time": "2026-01-05 15:00:00", "signals": [ { "symbol": "000001.XSHE", "action": "buy", "price": 11.25, "position_percent": 0.3, "signal_id": "sig_20260105_000001" } ] }

这里每个字段都有用处。strategy_name和strategy_version方便回溯对照，signal_time用来判断信号是否过期，signal_id是唯一标识，执行端需要靠它做幂等去重。position_percent表示这只股票想占组合多少仓位，执行端可以根据账户总资产算出手数。

这个格式是我踩过几次坑之后定下来的，建议你直接抄作业。信号格式越规范，后面写执行端、写对账脚本就越省事。

4. 本地接收端与自动化下单实现

4.1 用轻量服务接收信号并落库

接收端可以部署在一台云服务器上，技术上不挑语言，Python写最简单。我用Flask搭了一个极简接口，监听POST请求，校验token后把信号写入SQLite数据库，然后返回200确认。SQLite足够用了，不需要上MySQL。如果你不想维护服务器，用腾讯云函数、阿里云函数这类Serverless服务也可以，但要注意函数执行超时时间，信号推送一般几秒钟内就能完成，所以问题不大。

Flask接口大概是这样的：

from flask import Flask, request, jsonify import sqlite3 import datetime app = Flask(__name__) VALID_TOKEN = 'your_secret_token' def save_signal(payload): conn = sqlite3.connect('signals.db') c = conn.cursor() for sig in payload.get('signals', []): c.execute( 'INSERT OR IGNORE INTO signals (signal_id, strategy, symbol, action, price, created_at) ' 'VALUES (?, ?, ?, ?, ?, ?)', (sig['signal_id'], payload.get('strategy_name'), sig['symbol'], sig['action'], sig['price'], datetime.datetime.now()) ) conn.commit() conn.close() @app.route('/jq-signal', methods=['POST']) def receive_signal(): payload = request.get_json(force=True) if payload.get('token') != VALID_TOKEN: return jsonify({'status': 'unauthorized'}), 401 save_signal(payload) return jsonify({'status': 'ok'})

数据库表结构别偷懒，signal_id字段要设计成唯一索引，配合INSERT OR IGNORE实现天然的幂等去重。就算聚宽那边因为网络超时重发了一次信号，本地最多只会处理第一次，不会重复下单。这是自动化交易里最容易忽略又最重要的一环。

4.2 执行端对接下单通道（含三种方案对比）

信号落到数据库之后，下一步就是让执行端去读取信号并下单。这部分是整个方案里最需要谨慎的地方，因为“下单”是动真金白银的动作，一旦出错，钱就真没了。

我整理了几种可用的下单通道，按稳定性和门槛做了个对比：

先聊最推荐的方案：券商轻量级量化API。现在很多券商推出了针对个人投资者的轻量级API通道，资金门槛比QMT低不少，有的甚至开个普通账户就能申请。具体政策和接口形式各券商不一样，建议你直接找自己的客户经理问一句“你们有没有低门槛的量化交易接口，不对接QMT的那种”。这条路最稳，因为它本身就是券商官方提供的，合规上最干净，稳定性也有保障。

如果你所在的券商没有这种通道，那就只能考虑第二种方案：用easytrader这类Python库去操作普通交易客户端。底层原理是模拟人的操作，读取窗口控件、发送点击和键盘指令，最终通过客户端内置的交易通道下单。我用它跑过一段时间，确实能实现自动化，代价是要保证电脑开机、客户端登录，而且券商一旦升级客户端，UI控件位置变了，代码就可能失效。

一个最小化的easytrader示例：

import easytrader user = easytrader.use('universal_client') # 根据客户端类型选择 user.connect(r'C:\同花顺\xiadan.exe') # 客户端路径 user.prepare('user.json', 'account.json') # 用户和账户配置 # 读取最新的信号 signal = get_latest_signal_from_db() if signal: user.buy(signal['symbol'], price=signal['price'], amount=100)

这里贴代码不是鼓励你一定用这条路，而是让你知道圈子里确实有这种玩法。必须提醒一点：用脚本模拟人工操作客户端是否违反券商使用协议，每个券商的条款不一样，你需要自己确认清楚。我个人的建议是，这类方案只用于小资金自用，不要代理别人的账户，不要碰大额资金，并且在下单前留一道人工确认的开关，给自己留一个安全垫。

最后一种方案是半自动：聚宽把信号推送到手机，你收到后手动在App里下单，或者借助券商自带的“条件单”功能设置好触发价格，让它自动帮你执行一部分逻辑。别看不起这条路，小资金起步阶段，策略稳健比完全自动化重要得多。我认识好几个一直跑半自动策略的朋友，收益反而比那些盲目追求全自动的人稳定。

4.3 日志、持仓对齐和幂等控制

自动化交易不怕策略亏钱，怕的是“你以为买了但实际没买”“你以为卖了你还有持仓”这种状态错乱。所以日志和对账是绝对少不了的。我在接收端和执行端分别打了日志，每一条信号都有signal_id，每一笔下单都会记录：触发了哪个信号、尝试下多少股、是否成功、成交价多少、失败原因是什么。

每天收盘后，我还会跑一个对账脚本，把三份数据拉出来对比：聚宽模拟盘的持仓、本地数据库里的成交记录、券商账户里的真实持仓。如果发现不一致，脚本会高亮报警。这套机制帮我抓出过好几个问题，比如有一次某只股票分红送股导致持仓数量对不上，还有一次本地把“卖出”误解析成了“买入”，都是靠对账及时发现并手工修正的。

幂等控制这块，除了数据库唯一索引之外，我还加了一层“信号状态机”。每个信号进入执行端后有三种状态：pending、executed、failed。执行端重启之后会扫描所有pending信号，重新尝试执行。如果某条信号已经executed，就不会再动。这样即使本地服务半夜崩了，第二天拉起来也能把没执行的信号补齐，不会造成重复交易或者漏交易。

5. 常见问题与排查技巧实录

5.1 信号链路排查

信号链路指的是“聚宽策略 → HTTP请求 → 接收端数据库”这一段。最常见的现象是：策略日志显示推送成功，但本地数据库没有新信号。

遇到这种情况，先确认接收端有没有收到请求。最粗暴的办法是在Flask接口里加一行日志，打印每个进来的POST请求的IP、时间和payload。还有另一种情况是聚宽策略环境里requests请求超时了，原因是你的云服务器没有配置公网域名或者域名解析有问题。聚宽策略只能访问公网域名，不能用内网地址，所以本地电脑上连一个局域网IP是收不到信号的。如果你只是想在本地电脑测试，用内网穿透工具暴露一个公网地址出来会方便很多，但生产环境还是建议放一台云服务器上。

还有一类问题出在时间上。聚宽策略里的after_trading_end是在收盘后某个时间点执行，不同券商会略有差异，如果你还没等到那个时点就检查信号，自然会觉得“没推送”。解决方式是给每个信号带上signal_time字段，接收端按时间戳判断信号新鲜度，超过一定阈值（比如24小时）的信号直接标记为过期。

5.2 执行端的典型故障与处理

执行端最容易出的问题集中在“下单失败”上。我整理了一个速查表，你可以保存下来：

我踩过最疼的一次坑是：某天策略信号触发了一个卖出指令，因为客户端弹出了一个风险提示框，脚本没识别到就继续跑下一个信号，结果卖出指令完全没执行，当天持仓超了，第二天下跌直接吃了大亏。从那之后，我在执行端做了一个“弹窗哨兵”逻辑，凡是检测到异常弹窗，立即停止执行并发送报警短信，宁可当天不交易，也不能带着错误状态继续跑。

5.3 安全底线与合规提示

最后说几句非常重要的话。这套方案的目的是帮你降低自动化交易的门槛，但不代表可以无视规则。不管用哪种下单通道，都请遵守几条底线：第一，只用自己的账户做自用交易，不要代客理财；第二，提前确认券商是否允许你使用的这种下单方式，尤其是模拟点击客户端这类方案，不同券商的态度不一样；第三，别在你的代码仓库里提交任何包含账户密码的配置文件，Git仓库要是公开了，账号信息就等于裸奔；第四，保留人工干预的能力，自动化不是甩手掌柜，行情异常、脚本报错、网络故障这些情况都可能发生，你要随时能停下来。

6. 跑了半年后，我自己的几点体会

这套方案跑了大概半年，最大的体会是：自动化的价值不只在于“省事”，更在于让你像一个旁观者一样审视自己的交易。以前手动交易时，策略执行走样了也不知道，现在每一笔信号、每一笔成交都有记录，回看复盘时非常清楚，到底是策略问题还是执行问题，一目了然。

另外，我强烈建议你在整个链路里留一个“总开关”。我自己的实现是在本地配置里放了一个enable_trade字段，默认False。刚开始跑的时候，只让脚本接收信号、打印日志，不真正下单；确认信号推送和执行逻辑都稳定了，再把开关打开。这个习惯帮我避免了好几次刚上线时的低级错误。等跑顺之后，你还可以加一些小功能，比如信号落地后钉钉或企业微信推送提醒、每天收盘后自动生成对账报表。总之，先跑通，再跑稳，最后再追求“全自动”，这条路对个人量化来说是更踏实的节奏。