聚宽策略自动链接本地大QMT下单连接器有市场吗？

让聚宽继续负责数据、因子和目标仓位计算，由本地QMT负责执行：这种通用连接器是否有真实需求？

因为最近各家券商陆续收紧或关闭 MiniQMT，很多不会编写迁移程序的朋友，原来能运行的自动化策略无法顺利迁移到大QMT上。所以我产生了一个想法：做一个“聚宽策略自动连接本地大QMT下单”的通用连接器。不知道大家觉得怎么样？如果这条路线可行，那么只要有一套能够在聚宽稳定运行的策略，就可以把策略产生的目标仓位同步到自己电脑上的大QMT，由本地程序完成下单。

但我认为，真正困难的还不只是“不会迁移代码”。很多聚宽数据、财务字段和因子，在大QMT环境中很难找到完全相同的来源和计算口径。即使代码表面上移植成功，两端也可能选出不同的股票、ETF或交易日期，最终运行结果自然会逐渐偏离聚宽回测。

因此，这个连接器最想解决的问题是：策略继续使用聚宽原来的数据和因子完成判断，不在大QMT端重新计算信号；大QMT只负责按照聚宽给出的最终目标仓位执行。这样就不必为了迁移而重新寻找数据、重写因子，也能最大限度保留策略在聚宽中的原始判断口径。

我目前还在验证需求，本文先把产品设想、使用流程和安全边界讲清楚，也想听听大家最真实的意见。

我想解决什么问题？

聚宽非常适合研究、回测和运行策略，但把完整策略搬到另一个环境，往往不是把Python代码复制过去那么简单。策略背后还依赖数据源、复权方式、交易日处理、财务字段、因子定义、停牌和涨跌停判断，以及股票池过滤规则。

例如，同一个“市值”字段可能使用不同更新时间；同一个价格序列可能采用不同复权方式；财务数据可能存在公告日与报告期处理差异；技术指标又可能因为是否包含当日数据、窗口端点和缺失值处理不同而产生偏差。单个差异看起来很小，经过排序、打分和择时后，却可能直接改变最终入选标的。

同一套策略逻辑
      │
      ├─ 聚宽数据口径 → 排名A → 买入标的A
      │
      └─ 本地数据口径 → 排名B → 买入标的B

这也是很多迁移项目最尴尬的地方：程序没有报错、每天也正常下单，但交易结果就是对不上。之后很难判断差异来自策略代码、数据源、因子计算，还是交易执行。

如果为了对齐而在本地重建聚宽的全部数据链条，开发量和维护量都会迅速增加。聚宽新增或调整接口后，本地版本还要继续同步。对于已经在聚宽反复回测和验证过的策略，这种重复建设并不一定划算。

连接器的思路是不迁移“策略大脑”，只迁移“执行动作”：

这个连接器希望把两端的工作分开：

• 聚宽继续负责策略计算，决定持有什么、持有多少；
• 聚宽继续使用原有数据、因子和过滤规则，不在另一端重复计算；
• 连接器只负责安全地传送“目标仓位”；
• 客户电脑上的执行端负责读取真实持仓、计算差额和提交订单；
• 策略、账户和最终控制权始终属于客户本人。

连接器本身不提供策略，也不推荐任何证券，只执行用户自己策略产生的结果。

为什么直接传信号更容易保持一致？

传统迁移需要在大QMT端重新完成整条计算链：

本地数据 → 本地因子 → 本地排名 → 本地择时 → 本地下单

连接器则把计算链保留在策略原本验证过的环境中：

聚宽数据 → 聚宽因子 → 聚宽排名 → 聚宽目标仓位
                                      ↓
                             大QMT只负责执行

这样可以减少以下常见偏差：

• 前复权、后复权与真实价格口径不同；
• 日线收盘时间和当天数据是否完整不同；
• 财务数据公告日、报告期和可见时间不同；
• 市值、估值、质量和技术因子的定义不同；
• 停牌、ST、上市天数和涨跌停过滤规则不同；
• 缺失值、异常值和排序并列的处理不同；
• 股票池成分及历史成分获取方式不同；
• 交易日历和节假日前后调度不同。

连接器收到的是“计算完成后的答案”，而不是原始数据。因此，大QMT端不需要猜测聚宽如何计算某个因子，只需要忠实执行目标仓位。

当然，这并不意味着实盘收益能够与回测完全相同。成交价格、滑点、手续费、涨跌停、部分成交、信号传输时间和账户资金规模仍会产生差异。连接器能够重点解决的是选什么、何时换、目标仓位是多少的信号一致性，而不是消除所有交易摩擦。

整体结构

客户电脑一般处在家庭或公司的内网，没有公网地址。解决方法并不是让聚宽直接访问客户电脑，而是由聚宽和客户电脑分别主动访问一台信号中转服务器。

客户自己的聚宽策略
        │
        │ 发送目标仓位
        ▼
   公网信号中转服务
        ▲
        │ 客户端主动获取信号
        │
客户本地执行器 ── 大QMT ── 券商账户

客户电脑只需要正常访问互联网，不需要公网IP，不需要修改路由器，也不需要开放入站端口。

中转服务器只负责接收和转交信号，不保存交易密码，也不直接操作证券账户。真正的委托仍然由客户电脑上的本地程序，通过客户本人拥有权限的大QMT提交。

用户实际怎样操作？

理想情况下，整个安装过程应该控制在几步内：

1. 在Windows电脑安装连接器客户端；
2. 登录自己的大QMT；
3. 在聚宽策略末尾粘贴一段信号发送代码；
4. 使用连接码绑定聚宽策略与本地客户端；
5. 先运行模拟计算，核对目标仓位和订单；
6. 确认无误后，选择人工确认或自动执行。

我希望最终的使用体验接近：

下载安装 → 登录大QMT → 粘贴发送代码
→ 绑定策略 → 测试信号 → 开始运行

客户不需要配置服务器、数据库、IP地址，也不需要自己安装Python依赖。

为什么发送“目标仓位”，而不是买卖指令？

这是整个设计中最重要的一点。

假设策略希望持有某只ETF的98%仓位，聚宽发送的应该是：

{
  "signal_id": "rotation-20260915-142900",
  "generated_at": "2026-09-15T14:29:00+08:00",
  "valid_until": "2026-09-15T14:35:00+08:00",
  "targets": {
    "示例证券代码": 0.98
  }
}

而不是简单发送“买入10万元”。

本地执行器收到目标仓位后，会根据客户账户的总资产、可用资金和当前持仓计算差额。这样即使发生网络重发，同一个信号也不会重复买入；客户手工调整过账户后，系统也能重新向目标仓位靠拢。

目标仓位模式还有几个好处：

• 不同资金规模可以使用同一套接口；
• 聚宽与本地账户金额不必完全相同；
• 便于处理整数交易单位和部分成交；
• 可以持续核对“策略希望持有多少”和“账户实际持有多少”；
• 相同信号重复到达时能够自动拦截。

一条信号如何完成执行？

完整流程大致如下：

策略计算完成
    ↓
生成唯一信号编号和有效期
    ↓
加密发送至中转服务
    ↓
客户本地连接器主动获取
    ↓
校验身份、签名、时间和重复状态
    ↓
读取大QMT真实资金与持仓
    ↓
计算卖出和买入差额
    ↓
本地风控检查
    ↓
人工确认或自动提交
    ↓
检查委托、成交与剩余数量
    ↓
重新对账并通知客户

对于日频或低频轮动策略，本地客户端每隔几秒检查一次新信号已经足够，没有必要追求毫秒级速度。稳定、可恢复、不会重复交易，比极低延迟更加重要。

连接器应该具备哪些保护？

自动下单不能只有“买入”和“卖出”两个按钮。一个可以长期使用的版本，至少应包括以下保护。

信号保护

• 每条信号都有唯一编号；
• 同一编号只能执行一次；
• 超过有效时间的信号自动作废；
• 身份或签名不正确时拒绝执行；
• 网络恢复后不盲目执行过期信号。

账户保护

• 单只证券最大仓位；
• 账户最大总仓位；
• 单笔最大金额；
• 每日最大委托次数；
• 可用资金和整数交易单位检查；
• 停牌、涨跌停及不可交易状态检查；
• 一键暂停与紧急停止。

执行保护

• 原则上先卖后买；
• 未成交订单可按规则撤单或重新报价；
• 部分成交后只处理剩余差额；
• 软件重启后恢复当日执行状态；
• 以真实成交回报为准，而不是把“已提交”当成“已成交”。

对账与通知

• 展示聚宽目标仓位；
• 展示大QMT实际仓位；
• 标记两端差异；
• 记录信号、委托、成交和异常；
• 发生断线、拒单或仓位不一致时及时通知。

两种运行模式

为了降低第一次使用的心理压力，我考虑提供两种模式。

人工确认模式

收到信号后先展示执行计划：准备卖出什么、买入什么、目标金额是多少，由客户点击确认后再下单。这个模式适合刚开始试用以及希望保留人工控制的人。

自动执行模式

系统在通过所有风控检查后自动执行。适合已经长期核对过信号、熟悉策略波动并且确认系统稳定的用户。

不论使用哪种模式，客户都可以随时暂停连接器，大QMT和证券账户仍然由客户本人掌握。

首次使用如何验收？

正式自动执行前，连接器应当提供一次完整但不真实下单的检测：

✓ 聚宽测试信号已收到
✓ 客户身份与签名验证通过
✓ 大QMT连接正常
✓ 证券代码转换成功
✓ 聚宽信号未被本地重新计算
✓ 目标仓位计算完成
✓ 重复信号拦截有效
✓ 本地风控检查通过
✓ 理论订单与预期一致

通过测试后，再进行小资金、人工确认的实盘验证。验收时应把“一致性”拆成两层：第一层检查聚宽输出的标的和目标仓位是否被原样接收；第二层检查本地订单是否正确向目标仓位靠拢。经过一段时间对账，确认信号、委托、成交和真实持仓持续匹配，再考虑开启自动执行。

需要特别说明：聚宽回测成交价与实盘成交价存在少量差异属于正常现象；如果两端最终选择的证券或换仓方向不同，才说明信号传输或执行过程可能存在问题。

这个工具不做什么？

为了把产品边界说清楚，我设想的连接器不会：

• 提供或销售交易策略；
• 推荐具体股票、ETF或买卖时机；
• 修改客户策略信号；
• 保存客户的交易密码；
• 在云端集中登录客户账户；
• 承诺收益或按收益进行分成；
• 绕过券商对程序化交易和接口权限的要求。

它更像是一条可靠的“信号传送带＋本地执行管家”。客户自行编写策略、自行作出投资决策，并自行承担交易结果。

实际使用还应以开户券商提供的大QMT权限、接口规则和程序化交易管理要求为准。

我最想了解大家的需求

这个设想是否值得继续做，关键还是看聚宽用户真正遇到了什么问题。如果你愿意，希望在评论区告诉我：

1. 你现在是否有聚宽策略需要同步到本地大QMT？
2. 你在迁移时是否遇到过数据、因子或选股结果无法对齐？
3. 哪类口径最难处理：行情复权、财务数据、因子、股票池还是交易日？
4. 你更需要人工确认，还是完全自动执行？
5. 你最担心的是信号不一致、错单、断线、未成交，还是两端持仓偏离？
6. 你希望支持目标仓位、目标金额，还是两者都支持？
7. 你使用的是ETF轮动、股票选股、网格，还是多策略组合？
8. 你是否愿意先使用只计算订单、不真实下单的测试版本？
9. 你认为一次性授权和年度维护，哪种方式更容易接受？

如果有足够多的人确实需要，我会优先做一个简单版本：单账户、单策略、目标仓位同步、人工确认、完整日志和持仓对账。先把可靠性做好，再讨论多账户、多策略和全自动功能。

结语

这个连接器的目的不是创造一套新的投资策略，也不只是减少几步代码迁移，而是避免在大QMT端重复建设一套很难与聚宽完全对齐的数据和因子系统。

策略研究和交易执行本来就是两个不同的问题。聚宽负责数据、因子、选股和仓位判断，大QMT负责本地执行，中间通过标准化目标仓位、安全校验、风险控制和成交对账连接起来。这样既保留聚宽策略原有的计算口径，也避免为了一次迁移而重新解决大量数据一致性问题。

现在还只是一个产品设想。欢迎大家直接说真实需求，也欢迎指出其中的问题：你会使用这样的连接器吗？什么功能会让你愿意尝试，什么风险又会让你拒绝使用？

风险提示：本文仅讨论通用技术工具的产品设想，不构成任何证券分析、证券推荐或投资建议。程序化交易和软件接口的开通、报告及使用要求，以用户开户券商和相关规则为准。任何自动化程序都可能因网络、行情、接口、系统或人为因素产生错误，使用者应充分测试并独立承担交易风险。