QMT文件读写转换器——策略环境文件IO的合规代理方案（开源）

QMT文件读写转换器——策略环境文件IO的合规代理方案（开源）

---

iQuant 平台策略禁止读写外部文件——信号日志、股票池、状态文件都没地方放，这个限制做过连续实盘的朋友都懂。

分享一个我的解法：QMT文件读写转换器（qmt-file-bridge），本机 TCP 文件桥。QMT 端只粘贴一个纯标准库客户端文件，所有真实磁盘 IO 由同机的普通 Python 服务端在白名单目录内代做。已开源（MIT），QMT 端 16 项自测 + 电脑端 20 项回归全过。

大QMT策略(内置Python)                          普通Python服务端(同机)
┌────────────────────────────┐   TCP 51757   ┌───────────────────────────┐
│ 粘贴的客户端(纯标准库)        │ ────────────► │ 白名单校验 → 真实文件读写    │
└────────────────────────────┘ ◄──────────── └───────────────────────────┘

三步上手

1. 服务端（QMT 同机）：免安装 exe 双击运行（GitHub Release 下载），或 py -3.14 qmt_file_bridge_server.py。默认放行自身目录，--root D:\某目录 可加放行目录
2. 客户端：QMT 新建策略，把 qmt_file_bridge_client.py 全文粘贴到 #coding:gbk 之后
3. 替换调用：

# 原来: f = open('D:/out/信号日志.jsonl', 'a'); f.write(line); f.close()
append_text('D:/out/信号日志.jsonl', line)

# 最小改动方案(仿open, 整体读入/整体写回):
f = bridge_open('D:/out/输出.csv', 'w', 'gbk'); f.write(s); f.close()

客户端 API 全景

read_text/read_bytes/write_text/write_bytes/append_text/exists/file_size/stat_file/list_dir/make_dir/delete_file/rename_file + 仿 open() 的 bridge_open（r/rb/w/wb/a/ab，支持 with，不支持 seek）+ ping()/set_bridge()/self_test()。

实盘可靠性设计（这部分是重点）

• 重试与报错的边界：断线自动重连、传输错误自动重试一次；但业务错误（路径未放行）明确报错不重试——否则越权路径会被反复请求
• 并发安全：客户端内部加锁，handlebar 与 run_time 定时器并发调用安全
• QMT 兼容性：客户端 GBK 源码、无 f-string 等新语法（兼容老 Python）、不依赖 __name__（exec 加载安全）、自带连通自检
• 性能：回环延迟约 0.1ms/次，日频/小时级策略无感

安全模型（文件桥做错就是全盘后门）

• 服务端默认只放行自身所在目录；--root 按需追加；--any 全盘放行慎用
• 客户端必须传绝对路径，服务端 realpath 后按放行目录前缀校验，防穿越
• 只删文件不删目录；rename 目标已存在即拒绝；空字节路径拒绝
• 服务端只监听 127.0.0.1，不对外网暴露

测试体系

QMT 端 16 项自测策略（连通、GBK/UTF-8 往返、二进制、追加、多级目录、改名删除、越权拒绝、并发、延迟等）——把自测文件粘贴进 QMT 跑，逐条 [PASS] 末行 16/16；自测报告本身也经转换器写盘，双重验证。电脑端 20 项协议回归。自测策略由脚本自动拼装（客户端全文嵌入用例），保证被测客户端与主文件零偏差。

一个工程习惯供参考：自测文件不要手工复制粘贴——主文件一改测试就脱节了，用拼装器生成才靠得住。

---

工具已开源（MIT）：GitHub 搜 foxneet/qmt-file-bridge（Release 提供免安装 exe）。与之前分享的 foxneet/tq-relay（跨机调通达信接口的 HTTP 网关）配套，QMT 策略环境的数据进出两条通道就齐了。量化工具链实测笔记在公众号「晋盈投资」（不荐股、不承诺收益）。

欢迎讨论：你们的 QMT 策略现在把日志和状态文件放在哪？

风险提示：本文为工程工具分享，不构成投资建议；文件白名单按最小权限原则配置，遵守所在平台规则。

10.23后 内置Python任何网络连接（Http TCP UDP等）都被阻断，你这个方案还能跑通吗？

乐雨 发表于 2026-10-10 10:16
10.23后 内置Python任何网络连接（Http TCP UDP等）都被阻断，你这个方案还能跑通吗？ ...

不只是网络连接，连读取文件都不行，目前DB证券的测试端已经不能读取文件，只能写文件，为了策略稳定运行，还是要提前做好准备。
大家有没有解决办法？有没有其他更好的平台，可以推荐一下。

感谢这位朋友的一手信息，10.23 这个时间点很有价值，我先认账再说方案：

① 你说得对，纯 TCP 通道（我现在的文件桥）在网络全断的环境下确实跑不通，这点不回避；
② 但「只能写文件」反而留了一条单向活路：策略端只写不读（把请求写进信号文件），外部 Python 进程轮询读取、执行真正的磁盘 IO，再把结果写到另一个文件——比双向 TCP 更土，但在「只写」环境里能活；
③ 我这两天就在 DB 同款环境下实测这条单向链路，跑通了会发新帖，把代码和坑全部公开；
④ 方便的话私信或留言说下 DB 证券是哪家、模拟还是实盘端，测试环境能对齐，验证结果才对你们有用。

foxneet 发表于 2026-10-14 13:04
感谢这位朋友的一手信息，10.23 这个时间点很有价值，我先认账再说方案：

① 你说得对，纯 TCP 通道（我现 ...

单向链路只能向外写，拿不到下单信息吧。

问到点子上了，这正是单向链路的边界：它只解决"策略→外部"的信号下达，回传确实回不来。

我的实测方案是这样分层的： ① 若 10.23 只封网络、不禁读（两种强度都出现过）→ 外部进程把下单结果/成交回报写到回传文件，策略端照常读——双向都能活，问题不大； ② 若真的"只写不读" → 策略侧拿不到实时反馈，只剩两条路：盲发模式（信号照发，事后人工对账，适合低频日线策略）或者干脆策略整体迁到不受限的环境（通达信TQ 外部 Python 模式，我已实测模拟+实盘全链路）； ③ 说实话，如果"只写不读"是真的，单向桥的意义就是给"来不及搬家的策略"续命——不是终态，是缓冲。

周日（10.25，限制生效满 48 小时后）我会把真实环境实测结果发出来——刚切换时测不准，周日测出的才是终态：限制强度、单向桥能不能活、TQ 全链路状态，代码全开源。你如果有 DB 端的一手信息，欢迎同步。

乐雨 发表于 2026-10-10 10:16
10.23后 内置Python任何网络连接（Http TCP UDP等）都被阻断，你这个方案还能跑通吗？ ...

实测还能用

foxneet 发表于 2026-10-26 12:17
实测还能用

为什么我的不能用了，会弹框 非法IP

那家券商？方便私信我日志内容吗？