简介AutoTrader是一套面向恒生电子交易接口的自动交易系统开源项目核心代码使用C实现适合具备C基础、希望深入程序化交易或量化策略开发的工程师与爱好者学习研究。资源共84个文件以.h/.cpp源文件为主导同时包含Visual Studio解决方案.sln、工程配置.vcxproj、静态库.lib与SQL数据库脚本整体压缩包约69.94MB目录结构清晰便于按模块阅读与二次构建。目前已有1823人学习项目覆盖交易接口对接、策略调度、风险控制等关键模块并附带资源配置与编译工程可作为理解恒生自动交易系统整体架构的完整范例。通过通读源码读者既能掌握自动交易系统的工程组织方式和常见交互流程也能学习到订单管理、持仓监控等落地细节为后续自主开发或功能扩展提供切实参考。 做量化和程序化交易这些年市面上各种落地系统见过不少但真正在券商柜台体系里绕不开的恒生系绝对算一个。我这边有段时间集中精力搞了一套基于恒生UFX接口的自动交易系统项目代号就叫AutoTrader目标很直接把行情、策略、下单、风控全部串成一条自动化流水线人只负责盯状态不负责手动敲单。这篇文章就围绕这套系统的设计思路和落地过程来写。恒生UFX接口怎么理解会话和回报怎么处理行情和下单模块怎么搭踩过的坑有哪些我都会展开讲清楚。如果你正在做股票、基金或者场内衍生品的程序化交易或者在券商、资管、私募团队里负责交易系统开发这篇文章应该能帮你省掉不少试错时间。1. 项目背景与需求梳理1.1 为什么要做这样一套自动交易系统先说个最现实的痛点手动下单在行情剧烈波动的时候根本来不及。尤其是多标的、多策略并行运行时人工盯盘加手工敲单单笔延迟动辄几百毫秒甚至几秒遇到盘中价格跳空滑点成本一下子就吃掉不少利润。如果是做市或者套利这类对速度敏感的策略手点的结果就是频繁漏单、错单。另一个痛点是批量操作。一个产品账户下面可能有几十只持仓调仓的时候要一个个输入代码、价格、数量又慢又容易出错。做程序化交易的人应该都有体会下单动作本身没什么技术含量但它必须做到稳定、快速、可追溯。人工操作恰恰在这三点上最弱。AutoTrader要解决的就是这三件事行情自动接入、策略信号自动执行、交易全流程留痕。它不是一个完整的多因子研究平台而是一个偏向实盘执行的轻量级系统范围控制在行情获取、策略调度、订单发送、回报处理、风控校验这几个核心环节。1.2 系统边界与最小可用版本立项的时候我就把范围卡得很死第一版不碰策略研究不碰回测不碰组合优化只做“策略信号到柜台成交”这一条链路。换句话讲策略模型算好发出买入信号系统负责把信号翻译成一张合法订单以最快速度送到柜台再把成交流水接回来更新持仓。这里有个很重要的设计理念交易系统和策略系统解耦。策略代码可以频繁改动、回测迭代但交易执行模块必须保持稳定改一个标点都要重新走测试流程。AutoTrader把策略层和执行层用消息队列隔开策略跑得再烂也不会把下单线程拖垮。第一版实现的功能清单如下行情接入支持订阅多只证券的实时行情内部缓存最新快照委托管理支持限价单、市价单的发送与撤单客户端本地维护订单状态回报处理接收柜台推送的委托回报和成交回报实时更新订单状态风控校验单笔委托上限、单标的总仓位上限、单日委托次数限制运行监控记录全量日志异常情况输出告警。2. 系统架构与核心技术选型2.1 模块划分与数据流转AutoTrader从逻辑上分成了五层接入层、数据层、策略层、执行层和风控层。接入层负责跟恒生柜台建立连接完成登录认证收发报文数据层维护行情快照、订单记录、成交记录和资金持仓的本地镜像策略层跑用户的策略逻辑输出买卖信号执行层把信号转换成委托并跟踪生命周期风控层则嵌在信号到委托之间所有单子进来先过风控再出门。实际数据流是这样的行情前置推送tick数据接入层解析后写入内存队列数据层刷新快照。策略线程从数据层拿到最新行情跑完逻辑后如果触发信号就生成一个信号对象投递到执行队列。执行线程收到信号后先请求风控校验通过后封装成UFX委托报文发送到柜台。柜台返回的委托回报和成交回报由接入层统一接收更新订单状态最终反映到持仓和资金上。这套流程有点像工厂流水线原料是行情加工是策略质检是风控包装出货是下单仓库管理是回报对账。每一道工序清晰分开任何一个环节出问题都可以单独排查不会互相干扰。2.2 为什么选择恒生UFX接口接入先说个经常被问到的问题恒生UF系统中UF字母表示什么意思。UFX在恒生产品体系里通常被解读为统一金融接口体系UF这两个字母可以理解成Unified Financial的缩写核心用意是把不同柜台、不同交易品种、不同交易所的差异化协议封装成一套相对统一的开发接口。对开发者来说同一个接口规范可以对接多种柜台版本省去大量适配工作。选择UFX而不是自己直接连交易所是因为国内二级市场交易链路里券商柜台是绕不开的中间层。交易所的接口不是随便一个机构就能接入的绝大多数私募和资管团队都是通过券商提供的柜台系统完成交易。恒生柜台在证券行业占有率很高UFX基本成了事实上的标准接口之一技术文档丰富开发社区也能找到不少经验。我当时对比过几个接入方案包括券商提供的其他 API、Windows 客户端自动化模拟最终还是选了 UFX。原因有三一是 UFX 走 TCP 长连接报文结构清晰相比 HTTP 轮询延迟低很多更适合对速度有要求的场景二是 UFX 是官方支持的接口通道合规性有保障不会像模拟键鼠那样随时可能因为界面改版而失效三是它对委托、成交、资金、持仓的回报推送比较完整做本地状态同步很方便。3. 恒生UFX接口的关键细节3.1 会话管理与登录流程UFX接口接入的第一步是建立会话这不是简单的TCP连上就完事还要完成应用层登录认证。通常需要配置前置机地址、端口、用户名、密码、AppID、通信密钥等信息其中通信密钥主要用于报文加密和校验务必保管好不要硬编码在代码仓库里。登录流程大致是初始化API环境设置回调函数建立TCP连接发送登录请求等待登录回报。登录成功后API会维护一个会话状态后续所有交易请求都基于这个会话发起。这里有个特别容易踩坑的地方同一套账号密码如果重复登录前置机会把旧会话踢掉。测试的时候多开几个客户端经常会出现“你已被踢下线”的诡异情况排查半天发现是之前调试进程没关干净。会话建立之后还有一个重要机制心跳保活。UFX的TCP长连不是永久的如果一段时间没有业务报文连接可能被网络设备或前置机判定为超时断开。所以必须启动一个定时任务按照接口文档要求的时间间隔发送心跳报文。我一般把心跳间隔设置在接口允许区间内的中间值太短会增加无谓流量太长容易被中间设备掐断。这里的核心就是“会话状态机”。我维护了 Disconnected、Connecting、Authorized、Ready 四个状态只有处于 Ready 状态才允许发送交易请求任何异常都先降级到 Disconnected 再走重连流程。重连不能太激进连续失败要退避否则前置机可能把频繁重连的IP拉黑。3.2 委托回报与成交回报的处理UFX的回报机制是异步推送也就是说你发了一笔委托系统不会同步告诉你结果而是通过回调函数在不确定的时间点把委托回报推回来。这个异步模型对刚接触的人来说要适应一阵子一个明显的后果是代码写起来不能像普通函数调用那样顺序执行。委托回报是“已报、部成、已成、已撤、废单”这些状态变更成交回报则是实际撮合成交的明细包含成交价格、成交量、成交时间。设计本地订单状态机时要以柜台的回报为准本地只是做映射和缓存。举例来说本地发出一笔限价买单后状态是PendingSubmit收到已报回报后变成Submitted收到部分成交后变成PartiallyFilled全部成交后变成Filled收到撤单确认后变成Cancelled。这里容易出问题的是回报乱序和重复推送。极端情况下成交回报可能先于委托回报到达或者同一笔成交推了两遍。所以我的处理逻辑里加了订单号和柜台流水号两个维度的去重本地缓存最近处理过的流水号重复的直接丢弃。经验是不要把“本地状态”和“柜台状态”混为一谈所有业务判断以最终回报为准本地状态只做展示和辅助判断。4. 核心模块实现要点4.1 行情订阅与快照合成行情模块里最基本的操作是订阅。UFX的行情接口支持按代码批量订阅订阅成功后系统会持续推送快照数据。快照里包含最新价、成交量、买卖五档、开盘价、最高最低价等字段。做策略的时候我通常维护一个本地mapkey是证券代码value是最新快照结构体每次推送直接覆盖更新策略读取时拿到的一定是当前最新状态。行情模块有一个专门需要注意的点时间对齐。柜台推送的行情时间戳、本地接收时间、策略计算时间这三者之间有微妙的时间差。做高频策略时不能直接把“本地接收时间”当作“行情发生时间”必须用行情自带的时间戳字段否则回测和实盘的数据口径不一致策略表现会失真。我还做了一个小优化行情推送线程和策略计算线程之间用无锁环形队列衔接避免加锁竞争损耗。订阅几百只标的时行情消息量非常大如果直接在回调函数里跑策略逻辑会把行情接收线程堵死导致行情延迟越来越高。正确做法是回调里只做轻量解析和入队策略线程自己按节奏消费。4.2 下单与撤单的幂等处理下单接口的调用看起来简单传个合约代码、价格、数量、方向就能发出但难点在“重复”和“丢失”这两个极端情况的处理。网络抖动可能导致请求报文虽然发到了柜台本地却没有收到确认这时如果贸然重发同一笔委托就可能造成双倍下单的严重后果。UFX接口通常支持客户端生成并维护一个有序的业务流水号服务端用它来识别重复请求。我的做法是每个策略信号生成时分配一个唯一订单引用编号后续所有与该信号相关的查询、撤单、重发都带这个编号。重发逻辑只针对“未收到任何回报”的委托并且重发前会先查询柜台端状态确认不是已受理后才操作。撤单的坑也很典型。很多时候发出撤单请求后委托最终以“已成交”收场并不是“已撤”。原因可能是撤单报文到达柜台时订单已经撮合完成。所以撤单后的状态判断不能只等撤单回报还要并行等待可能的成交回报最终状态以两者中后到者为准。我在状态机里专门加了PendingCancel这个中间态收到成交回报就转Filled收到撤单回报才转Cancelled这样逻辑就清晰了。4.3 风控模块怎么设计才靠谱风控是整个系统里最不能省的部分。我的原则是宁可错杀不可漏过。AutoTrader的风控模块挂在执行链路里所有委托在发送前必须通过校验校验要求全部通过才可以走U F X下单接口。具体的风控规则我分为四类资金校验预估委托金额不能超过当前可用资金的一定比例防止资金不足导致废单持仓校验卖出数量不能超过当前持仓数量防止裸卖空除非策略本身就是对冲模式限额校验单笔委托数量、单标的总持仓市值、单日委托次数都要有硬上限熔断机制如果系统检测到单位时间内的废单率或撤单率异常升高自动停止所有新委托并告警。实现时要把核心校验函数设计成无状态纯函数输入订单参数和账户快照输出通过或拒绝及原因。账户快照从回报模块实时更新数据一致性很关键如果资金数据更新延迟风控判断就会出问题。另外所有被拒绝的委托都要留下详细日志方便事后复盘是策略问题还是风控规则设置不合理。5. 常见问题与排查技巧实录5.1 连接频繁断开与心跳超时实盘中最常见的问题是连接不稳定。表现是运行一段时间后收不到行情或回报重连后又能恢复一阵子循环往复。排查思路首先要看网络层柜台前置机到本机的链路中间有没有防火墙、负载均衡设备这些设备经常会掐断空闲连接。如果没有业务报文但心跳报文正常连接一般不会被断真正容易出问题的是心跳配置和中间设备超时时间不匹配。另一个容易被忽略的原因是客户端本地时间不正确。UFX接口的很多报文里带了时间戳如果本地时间偏差过大服务端校验不通过就会拒绝连接。排查时先对时看系统时间和标准时间差多少。我遇到过一台没开网络对时的服务器时间越走越偏最后花了半天才发现是时间问题而不是代码问题。5.2 委托回报丢失或乱序回报丢失的情况一般和本地处理逻辑有关而不是柜台真的没推。最常见的原因是把回调函数里的异常吞掉了回报解析抛了个异常外层没有捕获导致后续回报全部积压或丢弃。调试时一定要在回调入口加全局异常捕获任何异常都记录到独立日志文件。乱序问题则需要引入“先排序再处理”的机制。我的做法是每个订单单独维护一个回报队列收到回报先缓存再按柜台流水号排序处理。当然正常网络环境下乱序不会特别频繁但做市和套利这类场景对状态切换的容错要求高宁可多写一点排序逻辑也不能容忍状态跳变导致错单。5.3 成交流水与本地持仓对不上这是所有交易系统运维中最让人头疼的问题。每天收盘后做对账发现本地持仓和柜台持仓差了几百股又不知道是哪个环节出的错。这类问题十有八九是成交回报漏处理或重复处理。解决办法是建立一套独立的核心账本不依赖中间状态。每一笔成交回报到达后核心账本做“原子化”的增减操作并且记录操作前后的余额快照。对账时不仅对最终数量还要逐笔核对每笔成交的时间、价格、数量是否和柜台流水完全一致。发现差异时用柜台的当日成交查询接口拉全量流水做比对定位到具体哪一笔出问题。5.4 一些值得长期坚持的实战习惯最后分享几个我对这套系统持续迭代后的体会。第一日志就是生命线所有报文的发送和接收都要留原始报文日志不要只记录转译后的业务字段。有时候一个问题排查到最后靠的就是对比原始报文里某个标志位的差异。第二重要参数修改要走配置中心不能直接改代码。比如风控阈值、心跳间隔、重连次数这些做成可动态修改的配置项线上调参会方便很多。第三每次实盘交易结束都要留一个收盘快照包括最终持仓、资金、当日委托流水和成交流水。这些数据不仅用于对账也是后续优化系统的宝贵素材。像AutoTrader这类系统真正让它变得可靠的往往不是某一次架构上的大改而是日复一日把这些细节做好、做扎实。我现在每次新接触一家柜台接口都会把这套经验迁移过去——先摸清状态机再处理异步回报最后坚决把风控前置这套方法论放到任何交易系统上都适用。本文还有配套的精品资源点击获取
