简介这是一套面向股票量化交易与自动化下单场景的插件工具适配大智慧、通达信两大行情软件通过TradeX.dll或Trade.dll连接券商服务器实现买入、卖出、撤单、按预设比例清仓以及账户信息、持仓和可撤单信息的查询同时支持股票池与预警公式系统联动适合有一定软件使用基础、希望把交易信号落地为自动委托的投资者与策略开发者。资源包共20个文件约14.71MB以9个dll动态库为核心配合ini配置、uid授权、lic许可、xml参数及pdf用户指南和exe主程序另附大智慧、通达信各自的安装说明文本标准版免费使用。目前已有3079人学习下载。借助其中的接口库与配置样例读者可快速完成插件部署、对接券商通道并参考用户指南排查连接与下单异常搭建起从预警到委托的完整链路。1. 交易插件 TradeX-TPS把行情终端的下单动作接进自己的策略里很多人第一次听到「大智慧、通达信交易插件 TradeX-TPS」脑子里冒出来的问题是行情软件不是只能看盘吗怎么还能被外部程序接管下单答案是可以而且这件事在量化圈里已经跑了很多年。TradeX-TPS 这类插件要解决的核心痛点只有一个——把「看盘终端」和「策略程序」之间的那道墙拆掉让策略算出来的信号能直接变成委托单而不是靠人盯着屏幕手点。它适合谁三类人一是手里已经有 Python 或 C 策略、但下单还靠人工的开发者二是想在自己熟悉的行情终端里做半自动交易、保留人工干预余地的操盘手三是需要把多个账户的下单入口统一到一个中间层、方便做风控和日志的团队。不适合谁完全不懂委托、成交、撤单这些基础概念的新手以及指望「装上就能自动赚钱」的人——插件只是通道不是策略。这一章先把边界划清楚TradeX-TPS 本质是一个中间件向下对接行情终端的交易接口向上暴露一套可编程的调用约定。它不产生信号不判断方向只负责把「买 100 股某某代码、限价多少」这件事可靠地送出去并把回报拿回来。理解这一点后面所有配置和排错才有落脚点。2. TradeX-TPS 的对接原理与三种常见接入姿势2.1 插件到底挂在哪一层要理解 TradeX-TPS先要理解行情终端的交易功能是怎么实现的。大智慧、通达信这类终端本身并不直接连交易所它们连的是券商提供的交易网关。终端内部有一层「交易适配层」负责把用户在界面上的点击翻译成网关能懂的委托指令。TradeX-TPS 做的事情就是在这层适配层旁边开一个口子让外部程序也能往同一个网关发指令。常见的实现方式有三种。第一种是进程内注入插件以动态库形式被终端加载直接调用终端内部的函数。这种方式延迟最低但和终端版本强绑定终端一升级就可能失效。第二种是本地回环通信插件在本地起一个服务外部策略通过约定的协议把指令发过来插件再转成终端调用。这种方式解耦好调试方便代价是多一跳。第三种是模拟操作插件通过模拟键盘鼠标或窗口消息来触发终端的下单按钮。这种方式最脆弱界面一改就翻车只适合临时验证。我一般推荐第二种。原因很实际策略代码和终端生命周期解耦终端崩了策略不受影响策略重启也不用重挂插件。延迟上多出来的那一跳在分钟级或秒级策略里完全可以接受。2.2 最小可跑通的调用链路下面用 Python 写一个最小示例演示策略侧如何通过本地回环把一笔委托发给 TradeX-TPS。注意这里用的是通用 socket 约定实际协议字段要以你拿到的插件文档为准。import socket import json # TradeX-TPS 本地服务默认监听地址端口按插件配置改 TPS_HOST 127.0.0.1 TPS_PORT 17888 def send_order(symbol, side, price, volume, account): symbol: 证券代码如 600000 side: buy 或 sell price: 限价市价单传 0 volume: 股数 account: 资金账号 payload { cmd: place_order, account: account, symbol: symbol, side: side, price: price, volume: volume, order_type: limit if price 0 else market } # 约定用换行符作为消息边界避免粘包 raw (json.dumps(payload) \n).encode(utf-8) with socket.create_connection((TPS_HOST, TPS_PORT), timeout3) as s: s.sendall(raw) resp s.recv(4096).decode(utf-8).strip() return json.loads(resp) if __name__ __main__: result send_order(600000, buy, 10.50, 100, A123456) print(result)这段代码的逻辑很直白拼一个 JSON加换行做边界发出去读回执。参数上有三个点必须注意。order_type决定走限价还是市价很多终端的市价单实际是按对手价成交别把它当成「一定成交」。volume单位是股不是手100 股等于 1 手填错一位就是 100 倍误差。account必须和终端里登录的账号一致不一致时插件通常直接拒单回执里会带错误码。回执的解析同样重要。正常回执里会有本地委托编号这个编号是你后续查成交、撤单的唯一凭据务必落库。失败回执里一般有错误码和错误信息错误码要对照插件文档查不要只看文字描述。2.3 行情和交易为什么要分开处理一个容易踩的坑是把行情订阅和交易下单塞进同一个连接。行情是高频推送交易是低频请求两者混在一起一旦行情数据量大交易指令就可能被堵在缓冲区里表现出来就是「信号出了但单子半天没下出去」。常见做法是开两条链路一条订阅行情一条专门下单。行情链路可以容忍丢包和延迟交易链路必须保证顺序和可达。如果插件本身只提供一个端口那就在策略侧做队列把交易指令单独排队优先级高于行情处理。3. 参数配置账户、风控和委托类型的实操设定3.1 账户映射表怎么建多账户场景下最容易出问题的不是下单本身而是「下错账户」。我一般会在插件配置里建一张映射表把策略里的逻辑账户名映射到真实的资金账号策略代码里只出现逻辑名。逻辑账户资金账号市场用途alpha_mainA123456上海主策略alpha_hedgeA123457深圳对冲manual_testA123458上海手工验证这张表放在插件侧而不是策略侧好处是换账号时只改一处。表里「市场」这一列不能省同一代码在不同市场可能重名插件需要靠它路由到正确的网关。3.2 风控参数必须卡在插件层策略代码再严谨也可能因为 bug 发出异常指令。风控要卡在插件层因为那是指令出门前的最后一道关。下面这几个参数是必设的。{ max_order_volume: 10000, max_order_amount: 200000, max_orders_per_minute: 20, price_limit_pct: 0.02, forbidden_symbols: [000001], allow_market_order: false }max_order_volume限制单笔股数防止手滑多打一个零。max_order_amount限制单笔金额按价格乘股数算市价单按最新价估算。max_orders_per_minute是频率闸门防止策略死循环刷单。price_limit_pct限制委托价偏离最新价的比例超过就拒单这一条能挡掉大部分「价格填错」的事故。forbidden_symbols是黑名单某些标的因为合规或流动性原因不该被策略碰。allow_market_order默认关掉市价单在极端行情下成交价可能很离谱需要时再单独开。这些参数设完不是一劳永逸。行情波动大的时候price_limit_pct太紧会导致正常单子被拒太松又失去保护意义。我的习惯是按标的的日内波动率动态调波动率高的标的放宽到 3% 到 5%。3.3 委托类型的选择逻辑限价单和市价单不是随便选的。限价单保证价格不超预期但不保证成交市价单保证成交但不保证价格。TradeX-TPS 通常还支持「对手价」「最优五档即时成交剩余撤销」这类终端特有的委托类型这些类型在不同券商网关上的行为可能不一样。一个实用的判断规则如果策略对成交确定性要求高、对滑点容忍度也高用市价或对手价如果策略对价格敏感、可以接受不成交用限价。介于两者之间的可以用「限价 超时撤单重发」的组合把控制权拿回自己手里。4. 避坑与排查五条血泪经验4.1 现象回执成功但委托没进交易所原因通常是插件把指令发给了终端终端因为未登录或登录过期没有真正转发。终端的登录状态和插件的运行状态是两回事插件活着不代表终端在线。解决在插件层加一个心跳检查定期查询终端登录状态状态异常时拒绝所有下单请求并告警。不要依赖回执里的「成功」那个成功只代表插件收到了指令。4.2 现象同一笔信号重复下单原因是策略侧重试逻辑和插件侧重试逻辑叠加。策略发出指令后没及时收到回执触发重试插件那边其实已经发出去了于是变成两笔。解决给每笔指令带一个全局唯一的客户端订单号插件侧做幂等同一个号只处理一次。策略侧的重试要用同一个号不要每次重试都生成新号。4.3 现象撤单撤不掉提示「委托不存在」原因是撤单用的编号不对。有的终端用本地委托编号撤单有的用交易所委托编号两者不是一回事。插件回执里如果同时给了两个编号要看清文档说的是哪个。解决落库时把两个编号都存下来撤单时按插件文档指定的那个传。撤单失败后不要盲目重试先查一次委托状态确认是「已成交」还是「已撤」还是「真的不存在」。4.4 现象行情延迟突然变大交易也变慢原因是行情和交易共用了一条链路或者插件所在进程被行情数据处理占满了 CPU。解决把行情和交易拆到不同进程或不同链路交易进程的优先级调高。如果插件是单进程的检查是否有行情回调里做了重计算把重计算挪到独立线程或独立进程。4.5 现象终端升级后插件失效原因是插件依赖了终端内部未公开的接口升级后接口签名或地址变了。这是进程内注入方式的固有风险。解决如果业务允许改用本地回环方式减少对终端内部的依赖。如果必须用注入方式把终端版本号纳入配置管理升级前先在测试环境验证插件不要在生产环境直接升。5. 进阶把 TradeX-TPS 做成可观测的下单中间层前面讲的都是「能用」这一章讲「用得放心」。一个只负责转发的插件出问题时你只能靠猜一个带可观测能力的中间层出问题时你能直接看到哪一环断了。第一件事是给每笔指令打全链路日志。从策略生成信号、到插件收到、到终端转发、到回执返回每个环节都记时间戳和状态。日志格式建议用结构化 JSON方便后续检索。下面是一个日志记录的示例。import time import json import logging logger logging.getLogger(tps_audit) def log_order_event(client_order_id, stage, detail): client_order_id: 客户端唯一订单号 stage: 信号生成 / 插件接收 / 终端转发 / 回执返回 detail: 该阶段的补充信息 record { ts: time.time(), client_order_id: client_order_id, stage: stage, detail: detail } # 审计日志单独落文件不跟业务日志混 logger.info(json.dumps(record, ensure_asciiFalse))有了这条链路排查问题时可以直接按client_order_id把一笔单子的完整生命周期拉出来哪一环耗时异常、哪一环状态不对一目了然。参数上要注意ts用高精度时间戳秒级精度在排查延迟问题时不够用。第二件事是做对账。每天收盘后把插件记录的委托和成交跟终端导出的对账单做一次比对。比对维度包括委托编号、成交数量、成交均价。不一致的记录要单独列出来人工核查。对账脚本不需要复杂关键是每天跑跑出差异就查不要攒着。第三件事是给插件加一个「演练模式」。这个模式下所有指令只走风控和日志不真正发给终端。新策略上线前先在演练模式跑几天确认信号频率、委托价格、风控触发都符合预期再切到实盘。这个习惯帮我挡掉过好几次「策略参数写错导致疯狂下单」的事故。最后说一个我自己的教训。早期我图省事把风控参数直接写在策略代码里结果有一次策略进程崩了重启加载了旧版本的配置文件风控参数回到了默认值当天就出了一笔超限委托。从那以后风控参数一律放在插件侧策略侧改不动插件侧改参数要走变更记录。这个习惯看起来麻烦但它是后悔药真出事的时候能救命。希望帮到你。本文还有配套的精品资源点击获取