去年年底我遇到一个特别尴尬的局面策略在聚宽上回测得很漂亮年化收益也说得过去但真金白银准备上实盘的时候被券商一句“开通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里把所有当日信号打包成一个JSONPOST到我部署在云函数上的接口地址。接口那边只需要做身份校验、数据落库、返回确认就算一次完整推送。示例代码长这样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 }, timeout10 ) 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(forceTrue) 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视券商政策而定部分较低高低券商官方通道中easytrader操作普通客户端无额外门槛中依赖客户端UI稳定性中高需确认是否违反券商条款中券商条件单/半自动手动无高低低先聊最推荐的方案券商轻量级量化API。现在很多券商推出了针对个人投资者的轻量级API通道资金门槛比QMT低不少有的甚至开个普通账户就能申请。具体政策和接口形式各券商不一样建议你直接找自己的客户经理问一句“你们有没有低门槛的量化交易接口不对接QMT的那种”。这条路最稳因为它本身就是券商官方提供的合规上最干净稳定性也有保障。如果你所在的券商没有这种通道那就只能考虑第二种方案用easytrader这类Python库去操作普通交易客户端。底层原理是模拟人的操作读取窗口控件、发送点击和键盘指令最终通过客户端内置的交易通道下单。我用它跑过一段时间确实能实现自动化代价是要保证电脑开机、客户端登录而且券商一旦升级客户端UI控件位置变了代码就可能失效。一个最小化的easytrader示例import easytrader user easytrader.use(universal_client) # 根据客户端类型选择 user.connect(rC:\同花顺\xiadan.exe) # 客户端路径 user.prepare(user.json, account.json) # 用户和账户配置 # 读取最新的信号 signal get_latest_signal_from_db() if signal: user.buy(signal[symbol], pricesignal[price], amount100)这里贴代码不是鼓励你一定用这条路而是让你知道圈子里确实有这种玩法。必须提醒一点用脚本模拟人工操作客户端是否违反券商使用协议每个券商的条款不一样你需要自己确认清楚。我个人的建议是这类方案只用于小资金自用不要代理别人的账户不要碰大额资金并且在下单前留一道人工确认的开关给自己留一个安全垫。最后一种方案是半自动聚宽把信号推送到手机你收到后手动在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 执行端的典型故障与处理执行端最容易出的问题集中在“下单失败”上。我整理了一个速查表你可以保存下来现象可能原因排查方法客户端已登录但不下单客户端版本更新UI控件位置变化重新匹配控件检查easytrader是否兼容最新版下单提示资金不足没有扣除手续费和滑点估算下单前按当前价滑点预算可用资金股票停牌/涨跌停无法成交策略信号没有过滤可交易状态下单前调用行情接口检查交易状态成交回报没记录回报解析逻辑出错或成交确认弹窗变化打印原始界面文字更新解析规则账户被券商风控限制高频登录或短时间频繁撤单降低交易频率联系券商确认限制原因我踩过最疼的一次坑是某天策略信号触发了一个卖出指令因为客户端弹出了一个风险提示框脚本没识别到就继续跑下一个信号结果卖出指令完全没执行当天持仓超了第二天下跌直接吃了大亏。从那之后我在执行端做了一个“弹窗哨兵”逻辑凡是检测到异常弹窗立即停止执行并发送报警短信宁可当天不交易也不能带着错误状态继续跑。5.3 安全底线与合规提示最后说几句非常重要的话。这套方案的目的是帮你降低自动化交易的门槛但不代表可以无视规则。不管用哪种下单通道都请遵守几条底线第一只用自己的账户做自用交易不要代客理财第二提前确认券商是否允许你使用的这种下单方式尤其是模拟点击客户端这类方案不同券商的态度不一样第三别在你的代码仓库里提交任何包含账户密码的配置文件Git仓库要是公开了账号信息就等于裸奔第四保留人工干预的能力自动化不是甩手掌柜行情异常、脚本报错、网络故障这些情况都可能发生你要随时能停下来。6. 跑了半年后我自己的几点体会这套方案跑了大概半年最大的体会是自动化的价值不只在于“省事”更在于让你像一个旁观者一样审视自己的交易。以前手动交易时策略执行走样了也不知道现在每一笔信号、每一笔成交都有记录回看复盘时非常清楚到底是策略问题还是执行问题一目了然。另外我强烈建议你在整个链路里留一个“总开关”。我自己的实现是在本地配置里放了一个enable_trade字段默认False。刚开始跑的时候只让脚本接收信号、打印日志不真正下单确认信号推送和执行逻辑都稳定了再把开关打开。这个习惯帮我避免了好几次刚上线时的低级错误。等跑顺之后你还可以加一些小功能比如信号落地后钉钉或企业微信推送提醒、每天收盘后自动生成对账报表。总之先跑通再跑稳最后再追求“全自动”这条路对个人量化来说是更踏实的节奏。