简介面向程序员与量化交易开发者的基于Java的AI开源量化交易平台可替代文华、MC、金字塔等商业软件支持期货、股票、外汇、数字货币等多种交易场景具备历史回放、策略研发、模拟交易和实盘交易能力兼顾全自动与半自动操作适合需要自主搭建程序化交易系统的技术团队或个人研究。资源包为zip压缩格式共578个文件大小约1.83MB以407个Java源码文件作为后端核心配合62个JS、24个Vue前端文件构建交互界面另有XML、JSON、yml等配置文件及Dockerfile部署文件结构清晰便于二次开发与本地化部署。目前已有195人浏览学习适合有一定Java基础、希望深入理解量化交易平台架构的开发者。通过学习可以获得完整的平台源码与配置方案梳理从策略研发到实盘对接的模块设计结合历史回放功能验证交易逻辑为后续功能扩展和自定义策略提供可落地参考。1. 为什么说它是能“秒替”文华/MC/金字塔的Java量化平台做期货CTA和股票日内的人大多被文华、MC、金字塔的“黑匣子”策略编辑器和受限的数据接口折磨过。这套基于Java的AI开源量化交易平台一上来就把交易链路拆成了历史回放、策略研发、模拟交易、实盘交易四个独立模块而且把CTP、行情推送、策略引擎、风控、下单这五层解耦开程序员可以直接读源码改逻辑。对我来说它真正解决的是两个问题一是策略从回测到实盘的逻辑一致性不用再怀疑回测是“未来函数”堆出来的二是半自动场景下AI信号先出人工确认再下单既保留了程序执行的纪律性又给了交易员最后一道拦截。适合手里有Java基础、受够了商业软件封闭生态的程序员和量化爱好者也适合要在期货、股票、外汇、币圈多市场共用一套策略框架的团队。2. 平台核心架构从CTP接入到策略引擎的分层设计2.1 技术栈与模块划分从项目源码和配置文件能看出来这套平台不是把交易逻辑揉在一个大类里的单体应用而是按“数据、决策、执行”三个维度拆模块。底层用Java NIO和非阻塞队列处理行情流上层用Spring管理策略Bean的生命周期界面层则是JavaFX做的桌面客户端。核心的交易部分不依赖任何商业闭源库CTP接口用的是官方原生JNI封装行情和交易通道分开连这点很重要因为CTP的行情服务器和交易服务器本来就是两个地址。模块划分大致是接入层负责连接行情源CTP、穿透式柜台、模拟盘和交易通道把原始TCP报文转成统一事件。策略引擎加载jar包或脚本策略管理策略的初始化、行情回调、定时任务、下单请求。风控模块在策略和下单通道之间插入一层检查手数限制、单日亏损上限、频率限制。回放引擎把历史tick或K线按时间顺序重新推送给策略用于回测。账户中心管理真实账户和模拟账户的资金、持仓、委托、成交。GUI与监控行情图表、持仓盈亏、策略状态、日志面板。我建议拿到源码后先从engine和broker两个包看起一个管策略生命周期一个管交易通道剩下的都是围绕它们的细节。2.2 事件驱动与行情/交易接口的解耦平台的核心是事件驱动模型。行情到达后不是直接调用策略的方法而是先包装成MarketDataEvent放到一个链式分发器里。分发器会按照“风控前处理 → 策略回调 → 风控后处理 → 下单指令生成”的顺序流转。这样做的好处是策略里不需要关心行情来自实盘还是回放也不需要在策略代码里直接动账户下单接口。public interface BarHandler { // 每根K线结束时触发isReplay为true时表示来自历史回放 void onBar(Bar bar, boolean isReplay); } public class StrategyBase implements BarHandler { protected OrderSendResult sendOrder(OrderRequest req) { if (getContext().isReplayMode()) { // 回放模式下只做模拟撮合不真正发单 return getContext().getMatchEngine().match(req); } return getContext().getBroker().sendOrder(req); } }回放和实盘用的是同一套sendOrder入口只是底层broker不同。这段代码的逻辑说明策略层只感知sendOrder这个方法至于内部走的是回放撮合还是真实CTP通道由运行环境决定。参数isReplay是回放引擎从环境变量里读到的标识matchEngine里封装了tick级别的撮合规则比如按对手价成交或按盘口深度成交。这样设计之后回测和实盘共用一套策略代码杜绝了“回测一个样、实盘另一个样”的典型翻车点。接口解耦还体现在账户资金查询上。策略里取可用资金统一调用getContext().getAccount().getAvailable()而不是直接读某个全局静态变量。我实际拆代码时发现这个Account对象内部维护了一个“快照 增量”的缓存实盘时每次交易回报或资金变动都会更新快照回放时则从历史数据重建账户状态。这种设计在回测时能准确模拟强平和手续费扣除做高频回测时不会出现资金越算越多的情况。2.3 配置文件与启动流程平台用了一个application.yaml做主配置分local、backtest、simulate、live四套profile启动时通过-Dspring.profiles.activebacktest切换。这里贴一份我常用的回放配置骨架server: port: 8080 quant: mode: backtest # backtest / simulate / live >public class MaCrossStrategy extends StrategyBase { private MaIndicator fastMa; private MaIndicator slowMa; private PositionManager pm; Override public void onInit() { // 用策略参数中的fast/slow作为周期 fastMa new MaIndicator(getParam(fast, 5)); slowMa new MaIndicator(getParam(slow, 20)); pm new PositionManager(getContext()); } Override public void onBar(Bar bar, boolean isReplay) { fastMa.update(bar.getClose()); slowMa.update(bar.getClose()); // 金叉且当前无持仓时做多 if (fastMa.getValue() slowMa.getValue() !pm.hasPosition(long)) { OrderRequest req new OrderRequest(); req.setSymbol(bar.getSymbol()); req.setDirection(OrderDirection.BUY); req.setOffset(OrderOffset.OPEN); req.setVolume(1); int orderId sendOrder(req).getOrderId(); log.info(open long at {} via {}, bar.getClose(), orderId); } } }这段代码演示了最小可用策略。getParam在策略启动时从yaml的strategy.params里注入参数如果yaml没写就用默认值。pm.hasPosition(long)是通过账户中心的持仓对象判断当前是否已有净多头避免信号连续触发导致重复开仓。sendOrder返回一个OrderSendResult里面有订单ID和错误信息这里我习惯把orderId打进日志后续排查撤单、部分成交都要靠它。如果你要做半自动场景onBar里不要直接sendOrder而是把信号写进一个待确认队列if (signal SIGNAL_BUY) { SignalEvent evt new SignalEvent(bar.getSymbol(), BUY, bar.getClose()); getContext().getConfirmationQueue().offer(evt); }这样GUI上会弹出一个窗口显示“策略建议做多1手价格3500”由人工点确认后再真正发单。半自动模式下策略永远不能直接下单所有指令都必须经过确认这一关这是平台在风控上的一个关键设计。3.2 历史回放的参数与数据源设置回放质量直接决定策略可信度。平台支持三种数据源本地文件、CTP历史行情、外部导入的csv。本地文件是首选因为它不受网络影响回放速度最快。一套合格的本地数据应该是这样组织的data/ rb2410/ 20240101.tick 20240102.tick 20240103.tick每个tick文件一行是一条行情包含时间戳、最后价、买一价、买一量、卖一价、卖一量、持仓量字段。如果只有分钟K线平台也可以按K线做模拟撮合但成交价精度会差一截。我一般从期货公司官网或第三方数据商把每日tick行情导出成csv再用平台自带的CsvToTickDataTool转成二进制格式转换命令是java -cp quant-platform.jar com.quant.tools.CsvToTickDataTool \ --input ./csv/rb2410.csv \ --output ./data/rb2410/20240101.tick \ --symbol rb2410 \ --date 20240101参数--symbol是合约代码--date是交易日工具会把csv里的时间字符串转成平台的纳秒时间戳并按成交量过滤掉异常快照。转换完成后yaml里>[2024-01-15 09:31:00] BUY OPEN rb2410 5手 3502.0 [2024-01-15 10:15:00] SELL CLOSE rb2410 5手 3520.0 profit: 18.0*5 - 手续费 32 58.0 元平台会把每次平仓后扣除手续费和滑点的净额标出来方便你直接对比策略在不同手续费参数下的敏感性。如果看到连续几笔亏损单的亏损金额恰好等于手续费加滑点那不是策略失效是策略在噪音区间反复打脸这种情况应该先加过滤条件再去调指标周期。回放引擎还提供了一个“盯盘模式”能够像实盘一样一根一根K线地推。我经常用这个模式观察策略在极端行情下的表现比如某根K线突然跳空高开策略是否在开盘价上追单。跳空场景下opponent撮合会直接按跳空后的第一笔对手价成交这会让滑点成本瞬间吃掉好几笔利润。如果你实在不想被跳空伤害可以把match.price-type改成same-as但这属于自欺欺人因为实盘遇到跳空必然按对手价成交。4. 模拟交易与实盘切换半自动和全自动的操作边界4.1 模拟交易环境与风控参数模拟交易是收费实盘的完整预演。平台连的是CTP的simnow或券商的仿真柜台行情、报单、成交回报、资金变动全部走真实交易所协议只是不产生真实资金。在这个环境里策略代码不需要改动只需要把quant.mode从backtest切到simulate然后配置模拟账户的账号密码。quant: mode: simulate broker: type: ctp auth-code: ******** app-id: quant_client_test user: sim_user password: ******* flow-path: ./flows/sim/这里的flow-path是CTP会话的流目录用来保存登录后的会话状态。CTP要求每次客户端启动生成一个新的回话编号平台会在flow-path下自动创建以时间戳命名的子目录。如果你把这个目录设为只读或者手工删除了里面的文件CTP会报“会话编号重复”错误。我一般会固定一个目录然后在启动前清空一次避免历史会话文件干扰。模拟交易时的风控参数和实盘最好保持一致。平台里风控模块是可插拔的默认打开四个过滤器过滤器参数默认值说明手数限制max-orders-per-second5每秒最多报单次数单笔资金限制max-order-value500000单笔报单的名义金额上限单日亏损限制max-daily-loss20000当日亏损超过后禁止开新仓持仓限制max-positions-per-symbol10同一合约最多净持仓手数我建议第一次上模拟盘时把max-orders-per-second调到2就是为了逼自己暴露“信号重复触发”和“策略逻辑中未过滤的已发订单”这两个问题。模拟盘不会真亏钱但会放大你策略里的算法bug。4.2 半自动模式的“人工确认”机制半自动模式是这套平台相对商业软件最有价值的地方。你在策略里产生的每一个信号都会先进入一个待人工确认列表GUI会显示信号来源策略、合约、方向、价格、建议手数、触发时间。人工可以在提示栏里看到信号附带的“策略置信度”——平台内置了一个简单评分器基于当前信号与过去N次同类信号的历史胜率给出0到1的分值。高于0.7显示绿色确认按钮低于0.3显示红色忽略按钮介于之间则只显示原数据不做任何颜色提示。这套设计的核心在于机器负责“想”人负责“拍板”。人可以有最后5秒的冷静期不被策略的追单情绪带动。我自己的规则是人工确认时不允许直接双击确认必须按一下空格键锁定按钮再点击“确认下单”这就保证了每次确认都是有意识的动作。人工确认后还可以临时修改手数。比如策略建议开2手你看盘口觉得流动性不够可以改成1手再确认。这个操作不会影响策略内部的持仓记录因为修改动作最终会同步回账户中心的“待执行委托”里。如果策略在人工确认期间又发来一个反向信号平台不会自动取消防问列表里的旧信号但会在旧信号上打一个“已被新信号覆盖”的标记。这是为了避免人机纠缠导致的误操作也提醒你要小心同一时刻多个策略产生冲突信号。4.3 实盘切换前的检查清单从模拟盘切到实盘不是改一个配置文件那么简单。我把自己的检查清单列在这里照着走一遍能挡掉大多数低级问题。检查CTP账号权限是否已开实盘交易权限包括上期所、大商所、郑商所、中金所、能源中心的品种权限。某些品种如原油、国际铜需要单独验资和考试模拟盘能下单不代表实盘也能下单。确认柜台模式是“即时”还是“预埋”。如果你在盘中用sendOrder发单没问题但是你在夜盘收盘后发单某些柜台会拒绝因为非交易时段不允许普通报单。平台支持把这类单子转成“预埋单”需要在yaml里把broker.prematch.enabled设为true。校准时间源。实盘环境下策略的本地时间必须由JVM内部时钟与行情服务器时间做对齐平台会定期发出一个同步偏移日志。如果偏移超过500ms下单时间戳会出现偏差影响后续的撤单和条件单触发。实盘账号绑定的回调地址。CTP的私有流和公有流用的是同一个账号和密码但回报回调的IP白名单必须先在期货公司备案。如果flow-path和本机IP不在白名单里登录时能连上行情但交易回报会断断续续。我踩过一个坑拿联调环境的auth-code直接去连实盘柜台的地址结果CTP返回“不合法的会话”日志里面BrokerId和FlowPath不匹配。后来意识到实盘环境必须用独立的auth-code代码里写死的是联调环境变量必须从配置文件里改成实盘对应的值。从那以后我每次切实盘都要先在终端跑一条netstat -apn | grep java确认出去连接的IP是不是实盘柜台再放行资金。5. 避坑指南CTP连接、回放数据、平仓方向、并发下单的高频问题5.1 现象CTP登录后自动退出日志报“RejectTThost”原因CTP的客户端认证AppID和AuthCode在每次连接时都会校验如果你的进程之前已经用同一套账号密码连接过并且没有正常登出服务端会话表里还会残留旧会话新会话就会被拒绝。 解决先确认flow-path里有没有历史会话目录有的话手动清空然后在平台GUI的“连接管理”里点“安全登出”而不是直接关窗口。我写了个小脚本在每次启动实盘前自动删除flows/live/下所有子文件夹但保留latest软链接。find ./flows/live/ -mindepth 1 -maxdepth 1 -type d ! -name latest -exec rm -rf {} 5.2 现象历史回放成交价格和当时实盘盘口明显不一致原因本地tick数据里可能混入了交易所的“截断快照”比如某些合约在09:00:00后的第一笔快照带有上日收盘价标记导致最后价和买卖一价不在同一价位。如果回放用的是opponent撮合就会按这个失真价成交。 解决转换csv数据时增加一个过滤条件时间戳小于指定交易时段首笔有效快照的数据一律丢弃。平台实现里有一个valid-tick-time参数默认是开盘后3秒。如果策略是对秒级启动有要求的把3秒调成1秒并在回放报告里看“第一笔成交时间”是否与预期一致。5.3 现象策略平仓方向写反导致“开仓平仓”被同时挂出原因OrderDirection和OrderOffset的组合写错了。比如手里有2手多单想平仓却发了BUY CLOSECTP会直接返回“平仓手数超过持仓数量”如果发了SELL OPEN则会变成反向开空持仓变成4手。 解决平台里封装了一个PositionManager它会检查指令方向与当前持仓方向如果冲突自动转换成CLOSE_TODAY或CLOSE_YESTERDAY。我建议所有策略都统一走pm.close(symbol, volume)方法而不是底层直接构造OrderRequest。下面是正确写法pm.close(rb2410, 2, makerOrCancel);makerOrCancel是下单方式表示委托类型是“挂单成交优先”。如果盘口无法立即成交会撤销剩余部分这能避免普通限价单挂在一边占用冻结资金。5.4 现象同一信号在tick级别重复触发瞬间下了好几单原因策略里没有做“当前K线是否已处理”的判断。onBar回调每根K线都会执行一次但是如果你在onTick模式里写的判断条件是“最新价突破”那同一根K线内的几十个tick都会满足条件每来一个tick就发一单。 解决在策略基类里加一个去重标记Override public void onTick(Tick tick) { if (tick.getTimestamp() lastProcessedBarTimestamp) { return; } // 处理逻辑 lastProcessedBarTimestamp tick.getTimestamp(); }lastProcessedBarTimestamp是每个策略实例私有的字段不用担心多策略并发。还有一个更稳妥的方式是让风控模块的max-orders-per-second生效但那只起兜底作用策略逻辑层面必须做幂等。我把这个问题放在避坑章的最后一个因为它是程序化交易里最常见的“放大人性追涨杀跌”的算法根源。6. 让策略跑得更稳的进阶技巧从日志定位到参数优化闭环6.1 用结构化日志还原每一次决策实盘一天下来交易日志可能有几万行。如果只靠System.out.println输出大括号拼接的字符串崩溃后你根本找不到线索。平台内置了一套基于Logback的结构化日志我一般会给策略的输出单独加一个markerLogger logger LoggerFactory.getLogger(STRATEGY); logger.info(MarkerFactory.getMarker(MA_CROSS), signal{}, symbol{}, price{}, pos{}, BUY, bar.getSymbol(), bar.getClose(), pm.getPosition(rb2410));日志出来后每一行是keyvalue格式可以直接用grep和awk做统计分析。排错时最常用的一条命令是grep STRATEGY logs/quant.log | awk -F , {if($1 ~ /BUY/) print $3} buys.txt这能快速提取出所有买入信号的触发价格。我还会在onBar里把当时的关键指标值一并打出来比如fastMa和slowMa这样事后复盘时不必重新回放就能知道策略在哪个价位、哪个指标状态下做了决定。这就是还原现场的基本功。6.2 参数敏感性测试的简单做法参数优化不代表要把策略跑成千上万组参数组合。平台提供了一个ParamSweeper工具可以在回放模式里批量跑参数网格并输出“参数-收益-回撤”的二维表。我通常先跑一个粗略网格比如MA周期从5到60步长5再对表现比较好的区间用步长1加密扫描。这样既控制回放时间又能找到收益面的局部峰值。跑完参数扫描我必做的一步是样本外验证。比如用1月到6月数据选参数然后强制用7月到9月数据做一次回放如果参数在样本外仍然能盈利才算合格。平台里只需要在yaml里改start和end不用重启进程。我习惯在优化报告里看到“样本外收益率/样本内收益率”超过0.6才认为这组参数有泛化能力低于0.3就直接丢弃。6.3 验证实盘与回放一致性的最后一关上实盘前我会先把回放时生成的成交明细导出来对比实盘模拟盘的成交明细看两边的“下单时间、价格、手数、手续费”是否匹配。如果出现同样的策略同一时刻实盘成交价和回放成交价差超过两个最小变动价位说明回放撮合逻辑和真实撮合有系统性偏差这种情况下不要急着上实盘而是回过去检查slip-point设置和tick数据质量。从那以后我每次上线新策略都强制走一遍同样的流程本地回放看收益特征 → 参数敏感性测试找稳定区间 → 模拟盘跑三个交易日 → 导出成交明细做一致性比对 → 实盘先用半自动模式观察一周。这套流程不是平台提供的现成按钮而是要自己把每个环节的日志和数据都保存下来。它帮我挡掉了至少三次“回测猛如虎、实盘亏成狗”的意外。希望帮到你。本文还有配套的精品资源点击获取 Java开源量化交易平台：CTP接入、事件驱动与回测实盘一致性设计
简介面向程序员与量化交易开发者的基于Java的AI开源量化交易平台可替代文华、MC、金字塔等商业软件支持期货、股票、外汇、数字货币等多种交易场景具备历史回放、策略研发、模拟交易和实盘交易能力兼顾全自动与半自动操作适合需要自主搭建程序化交易系统的技术团队或个人研究。资源包为zip压缩格式共578个文件大小约1.83MB以407个Java源码文件作为后端核心配合62个JS、24个Vue前端文件构建交互界面另有XML、JSON、yml等配置文件及Dockerfile部署文件结构清晰便于二次开发与本地化部署。目前已有195人浏览学习适合有一定Java基础、希望深入理解量化交易平台架构的开发者。通过学习可以获得完整的平台源码与配置方案梳理从策略研发到实盘对接的模块设计结合历史回放功能验证交易逻辑为后续功能扩展和自定义策略提供可落地参考。1. 为什么说它是能“秒替”文华/MC/金字塔的Java量化平台做期货CTA和股票日内的人大多被文华、MC、金字塔的“黑匣子”策略编辑器和受限的数据接口折磨过。这套基于Java的AI开源量化交易平台一上来就把交易链路拆成了历史回放、策略研发、模拟交易、实盘交易四个独立模块而且把CTP、行情推送、策略引擎、风控、下单这五层解耦开程序员可以直接读源码改逻辑。对我来说它真正解决的是两个问题一是策略从回测到实盘的逻辑一致性不用再怀疑回测是“未来函数”堆出来的二是半自动场景下AI信号先出人工确认再下单既保留了程序执行的纪律性又给了交易员最后一道拦截。适合手里有Java基础、受够了商业软件封闭生态的程序员和量化爱好者也适合要在期货、股票、外汇、币圈多市场共用一套策略框架的团队。2. 平台核心架构从CTP接入到策略引擎的分层设计2.1 技术栈与模块划分从项目源码和配置文件能看出来这套平台不是把交易逻辑揉在一个大类里的单体应用而是按“数据、决策、执行”三个维度拆模块。底层用Java NIO和非阻塞队列处理行情流上层用Spring管理策略Bean的生命周期界面层则是JavaFX做的桌面客户端。核心的交易部分不依赖任何商业闭源库CTP接口用的是官方原生JNI封装行情和交易通道分开连这点很重要因为CTP的行情服务器和交易服务器本来就是两个地址。模块划分大致是接入层负责连接行情源CTP、穿透式柜台、模拟盘和交易通道把原始TCP报文转成统一事件。策略引擎加载jar包或脚本策略管理策略的初始化、行情回调、定时任务、下单请求。风控模块在策略和下单通道之间插入一层检查手数限制、单日亏损上限、频率限制。回放引擎把历史tick或K线按时间顺序重新推送给策略用于回测。账户中心管理真实账户和模拟账户的资金、持仓、委托、成交。GUI与监控行情图表、持仓盈亏、策略状态、日志面板。我建议拿到源码后先从engine和broker两个包看起一个管策略生命周期一个管交易通道剩下的都是围绕它们的细节。2.2 事件驱动与行情/交易接口的解耦平台的核心是事件驱动模型。行情到达后不是直接调用策略的方法而是先包装成MarketDataEvent放到一个链式分发器里。分发器会按照“风控前处理 → 策略回调 → 风控后处理 → 下单指令生成”的顺序流转。这样做的好处是策略里不需要关心行情来自实盘还是回放也不需要在策略代码里直接动账户下单接口。public interface BarHandler { // 每根K线结束时触发isReplay为true时表示来自历史回放 void onBar(Bar bar, boolean isReplay); } public class StrategyBase implements BarHandler { protected OrderSendResult sendOrder(OrderRequest req) { if (getContext().isReplayMode()) { // 回放模式下只做模拟撮合不真正发单 return getContext().getMatchEngine().match(req); } return getContext().getBroker().sendOrder(req); } }回放和实盘用的是同一套sendOrder入口只是底层broker不同。这段代码的逻辑说明策略层只感知sendOrder这个方法至于内部走的是回放撮合还是真实CTP通道由运行环境决定。参数isReplay是回放引擎从环境变量里读到的标识matchEngine里封装了tick级别的撮合规则比如按对手价成交或按盘口深度成交。这样设计之后回测和实盘共用一套策略代码杜绝了“回测一个样、实盘另一个样”的典型翻车点。接口解耦还体现在账户资金查询上。策略里取可用资金统一调用getContext().getAccount().getAvailable()而不是直接读某个全局静态变量。我实际拆代码时发现这个Account对象内部维护了一个“快照 增量”的缓存实盘时每次交易回报或资金变动都会更新快照回放时则从历史数据重建账户状态。这种设计在回测时能准确模拟强平和手续费扣除做高频回测时不会出现资金越算越多的情况。2.3 配置文件与启动流程平台用了一个application.yaml做主配置分local、backtest、simulate、live四套profile启动时通过-Dspring.profiles.activebacktest切换。这里贴一份我常用的回放配置骨架server: port: 8080 quant: mode: backtest # backtest / simulate / live >public class MaCrossStrategy extends StrategyBase { private MaIndicator fastMa; private MaIndicator slowMa; private PositionManager pm; Override public void onInit() { // 用策略参数中的fast/slow作为周期 fastMa new MaIndicator(getParam(fast, 5)); slowMa new MaIndicator(getParam(slow, 20)); pm new PositionManager(getContext()); } Override public void onBar(Bar bar, boolean isReplay) { fastMa.update(bar.getClose()); slowMa.update(bar.getClose()); // 金叉且当前无持仓时做多 if (fastMa.getValue() slowMa.getValue() !pm.hasPosition(long)) { OrderRequest req new OrderRequest(); req.setSymbol(bar.getSymbol()); req.setDirection(OrderDirection.BUY); req.setOffset(OrderOffset.OPEN); req.setVolume(1); int orderId sendOrder(req).getOrderId(); log.info(open long at {} via {}, bar.getClose(), orderId); } } }这段代码演示了最小可用策略。getParam在策略启动时从yaml的strategy.params里注入参数如果yaml没写就用默认值。pm.hasPosition(long)是通过账户中心的持仓对象判断当前是否已有净多头避免信号连续触发导致重复开仓。sendOrder返回一个OrderSendResult里面有订单ID和错误信息这里我习惯把orderId打进日志后续排查撤单、部分成交都要靠它。如果你要做半自动场景onBar里不要直接sendOrder而是把信号写进一个待确认队列if (signal SIGNAL_BUY) { SignalEvent evt new SignalEvent(bar.getSymbol(), BUY, bar.getClose()); getContext().getConfirmationQueue().offer(evt); }这样GUI上会弹出一个窗口显示“策略建议做多1手价格3500”由人工点确认后再真正发单。半自动模式下策略永远不能直接下单所有指令都必须经过确认这一关这是平台在风控上的一个关键设计。3.2 历史回放的参数与数据源设置回放质量直接决定策略可信度。平台支持三种数据源本地文件、CTP历史行情、外部导入的csv。本地文件是首选因为它不受网络影响回放速度最快。一套合格的本地数据应该是这样组织的data/ rb2410/ 20240101.tick 20240102.tick 20240103.tick每个tick文件一行是一条行情包含时间戳、最后价、买一价、买一量、卖一价、卖一量、持仓量字段。如果只有分钟K线平台也可以按K线做模拟撮合但成交价精度会差一截。我一般从期货公司官网或第三方数据商把每日tick行情导出成csv再用平台自带的CsvToTickDataTool转成二进制格式转换命令是java -cp quant-platform.jar com.quant.tools.CsvToTickDataTool \ --input ./csv/rb2410.csv \ --output ./data/rb2410/20240101.tick \ --symbol rb2410 \ --date 20240101参数--symbol是合约代码--date是交易日工具会把csv里的时间字符串转成平台的纳秒时间戳并按成交量过滤掉异常快照。转换完成后yaml里>[2024-01-15 09:31:00] BUY OPEN rb2410 5手 3502.0 [2024-01-15 10:15:00] SELL CLOSE rb2410 5手 3520.0 profit: 18.0*5 - 手续费 32 58.0 元平台会把每次平仓后扣除手续费和滑点的净额标出来方便你直接对比策略在不同手续费参数下的敏感性。如果看到连续几笔亏损单的亏损金额恰好等于手续费加滑点那不是策略失效是策略在噪音区间反复打脸这种情况应该先加过滤条件再去调指标周期。回放引擎还提供了一个“盯盘模式”能够像实盘一样一根一根K线地推。我经常用这个模式观察策略在极端行情下的表现比如某根K线突然跳空高开策略是否在开盘价上追单。跳空场景下opponent撮合会直接按跳空后的第一笔对手价成交这会让滑点成本瞬间吃掉好几笔利润。如果你实在不想被跳空伤害可以把match.price-type改成same-as但这属于自欺欺人因为实盘遇到跳空必然按对手价成交。4. 模拟交易与实盘切换半自动和全自动的操作边界4.1 模拟交易环境与风控参数模拟交易是收费实盘的完整预演。平台连的是CTP的simnow或券商的仿真柜台行情、报单、成交回报、资金变动全部走真实交易所协议只是不产生真实资金。在这个环境里策略代码不需要改动只需要把quant.mode从backtest切到simulate然后配置模拟账户的账号密码。quant: mode: simulate broker: type: ctp auth-code: ******** app-id: quant_client_test user: sim_user password: ******* flow-path: ./flows/sim/这里的flow-path是CTP会话的流目录用来保存登录后的会话状态。CTP要求每次客户端启动生成一个新的回话编号平台会在flow-path下自动创建以时间戳命名的子目录。如果你把这个目录设为只读或者手工删除了里面的文件CTP会报“会话编号重复”错误。我一般会固定一个目录然后在启动前清空一次避免历史会话文件干扰。模拟交易时的风控参数和实盘最好保持一致。平台里风控模块是可插拔的默认打开四个过滤器过滤器参数默认值说明手数限制max-orders-per-second5每秒最多报单次数单笔资金限制max-order-value500000单笔报单的名义金额上限单日亏损限制max-daily-loss20000当日亏损超过后禁止开新仓持仓限制max-positions-per-symbol10同一合约最多净持仓手数我建议第一次上模拟盘时把max-orders-per-second调到2就是为了逼自己暴露“信号重复触发”和“策略逻辑中未过滤的已发订单”这两个问题。模拟盘不会真亏钱但会放大你策略里的算法bug。4.2 半自动模式的“人工确认”机制半自动模式是这套平台相对商业软件最有价值的地方。你在策略里产生的每一个信号都会先进入一个待人工确认列表GUI会显示信号来源策略、合约、方向、价格、建议手数、触发时间。人工可以在提示栏里看到信号附带的“策略置信度”——平台内置了一个简单评分器基于当前信号与过去N次同类信号的历史胜率给出0到1的分值。高于0.7显示绿色确认按钮低于0.3显示红色忽略按钮介于之间则只显示原数据不做任何颜色提示。这套设计的核心在于机器负责“想”人负责“拍板”。人可以有最后5秒的冷静期不被策略的追单情绪带动。我自己的规则是人工确认时不允许直接双击确认必须按一下空格键锁定按钮再点击“确认下单”这就保证了每次确认都是有意识的动作。人工确认后还可以临时修改手数。比如策略建议开2手你看盘口觉得流动性不够可以改成1手再确认。这个操作不会影响策略内部的持仓记录因为修改动作最终会同步回账户中心的“待执行委托”里。如果策略在人工确认期间又发来一个反向信号平台不会自动取消防问列表里的旧信号但会在旧信号上打一个“已被新信号覆盖”的标记。这是为了避免人机纠缠导致的误操作也提醒你要小心同一时刻多个策略产生冲突信号。4.3 实盘切换前的检查清单从模拟盘切到实盘不是改一个配置文件那么简单。我把自己的检查清单列在这里照着走一遍能挡掉大多数低级问题。检查CTP账号权限是否已开实盘交易权限包括上期所、大商所、郑商所、中金所、能源中心的品种权限。某些品种如原油、国际铜需要单独验资和考试模拟盘能下单不代表实盘也能下单。确认柜台模式是“即时”还是“预埋”。如果你在盘中用sendOrder发单没问题但是你在夜盘收盘后发单某些柜台会拒绝因为非交易时段不允许普通报单。平台支持把这类单子转成“预埋单”需要在yaml里把broker.prematch.enabled设为true。校准时间源。实盘环境下策略的本地时间必须由JVM内部时钟与行情服务器时间做对齐平台会定期发出一个同步偏移日志。如果偏移超过500ms下单时间戳会出现偏差影响后续的撤单和条件单触发。实盘账号绑定的回调地址。CTP的私有流和公有流用的是同一个账号和密码但回报回调的IP白名单必须先在期货公司备案。如果flow-path和本机IP不在白名单里登录时能连上行情但交易回报会断断续续。我踩过一个坑拿联调环境的auth-code直接去连实盘柜台的地址结果CTP返回“不合法的会话”日志里面BrokerId和FlowPath不匹配。后来意识到实盘环境必须用独立的auth-code代码里写死的是联调环境变量必须从配置文件里改成实盘对应的值。从那以后我每次切实盘都要先在终端跑一条netstat -apn | grep java确认出去连接的IP是不是实盘柜台再放行资金。5. 避坑指南CTP连接、回放数据、平仓方向、并发下单的高频问题5.1 现象CTP登录后自动退出日志报“RejectTThost”原因CTP的客户端认证AppID和AuthCode在每次连接时都会校验如果你的进程之前已经用同一套账号密码连接过并且没有正常登出服务端会话表里还会残留旧会话新会话就会被拒绝。 解决先确认flow-path里有没有历史会话目录有的话手动清空然后在平台GUI的“连接管理”里点“安全登出”而不是直接关窗口。我写了个小脚本在每次启动实盘前自动删除flows/live/下所有子文件夹但保留latest软链接。find ./flows/live/ -mindepth 1 -maxdepth 1 -type d ! -name latest -exec rm -rf {} 5.2 现象历史回放成交价格和当时实盘盘口明显不一致原因本地tick数据里可能混入了交易所的“截断快照”比如某些合约在09:00:00后的第一笔快照带有上日收盘价标记导致最后价和买卖一价不在同一价位。如果回放用的是opponent撮合就会按这个失真价成交。 解决转换csv数据时增加一个过滤条件时间戳小于指定交易时段首笔有效快照的数据一律丢弃。平台实现里有一个valid-tick-time参数默认是开盘后3秒。如果策略是对秒级启动有要求的把3秒调成1秒并在回放报告里看“第一笔成交时间”是否与预期一致。5.3 现象策略平仓方向写反导致“开仓平仓”被同时挂出原因OrderDirection和OrderOffset的组合写错了。比如手里有2手多单想平仓却发了BUY CLOSECTP会直接返回“平仓手数超过持仓数量”如果发了SELL OPEN则会变成反向开空持仓变成4手。 解决平台里封装了一个PositionManager它会检查指令方向与当前持仓方向如果冲突自动转换成CLOSE_TODAY或CLOSE_YESTERDAY。我建议所有策略都统一走pm.close(symbol, volume)方法而不是底层直接构造OrderRequest。下面是正确写法pm.close(rb2410, 2, makerOrCancel);makerOrCancel是下单方式表示委托类型是“挂单成交优先”。如果盘口无法立即成交会撤销剩余部分这能避免普通限价单挂在一边占用冻结资金。5.4 现象同一信号在tick级别重复触发瞬间下了好几单原因策略里没有做“当前K线是否已处理”的判断。onBar回调每根K线都会执行一次但是如果你在onTick模式里写的判断条件是“最新价突破”那同一根K线内的几十个tick都会满足条件每来一个tick就发一单。 解决在策略基类里加一个去重标记Override public void onTick(Tick tick) { if (tick.getTimestamp() lastProcessedBarTimestamp) { return; } // 处理逻辑 lastProcessedBarTimestamp tick.getTimestamp(); }lastProcessedBarTimestamp是每个策略实例私有的字段不用担心多策略并发。还有一个更稳妥的方式是让风控模块的max-orders-per-second生效但那只起兜底作用策略逻辑层面必须做幂等。我把这个问题放在避坑章的最后一个因为它是程序化交易里最常见的“放大人性追涨杀跌”的算法根源。6. 让策略跑得更稳的进阶技巧从日志定位到参数优化闭环6.1 用结构化日志还原每一次决策实盘一天下来交易日志可能有几万行。如果只靠System.out.println输出大括号拼接的字符串崩溃后你根本找不到线索。平台内置了一套基于Logback的结构化日志我一般会给策略的输出单独加一个markerLogger logger LoggerFactory.getLogger(STRATEGY); logger.info(MarkerFactory.getMarker(MA_CROSS), signal{}, symbol{}, price{}, pos{}, BUY, bar.getSymbol(), bar.getClose(), pm.getPosition(rb2410));日志出来后每一行是keyvalue格式可以直接用grep和awk做统计分析。排错时最常用的一条命令是grep STRATEGY logs/quant.log | awk -F , {if($1 ~ /BUY/) print $3} buys.txt这能快速提取出所有买入信号的触发价格。我还会在onBar里把当时的关键指标值一并打出来比如fastMa和slowMa这样事后复盘时不必重新回放就能知道策略在哪个价位、哪个指标状态下做了决定。这就是还原现场的基本功。6.2 参数敏感性测试的简单做法参数优化不代表要把策略跑成千上万组参数组合。平台提供了一个ParamSweeper工具可以在回放模式里批量跑参数网格并输出“参数-收益-回撤”的二维表。我通常先跑一个粗略网格比如MA周期从5到60步长5再对表现比较好的区间用步长1加密扫描。这样既控制回放时间又能找到收益面的局部峰值。跑完参数扫描我必做的一步是样本外验证。比如用1月到6月数据选参数然后强制用7月到9月数据做一次回放如果参数在样本外仍然能盈利才算合格。平台里只需要在yaml里改start和end不用重启进程。我习惯在优化报告里看到“样本外收益率/样本内收益率”超过0.6才认为这组参数有泛化能力低于0.3就直接丢弃。6.3 验证实盘与回放一致性的最后一关上实盘前我会先把回放时生成的成交明细导出来对比实盘模拟盘的成交明细看两边的“下单时间、价格、手数、手续费”是否匹配。如果出现同样的策略同一时刻实盘成交价和回放成交价差超过两个最小变动价位说明回放撮合逻辑和真实撮合有系统性偏差这种情况下不要急着上实盘而是回过去检查slip-point设置和tick数据质量。从那以后我每次上线新策略都强制走一遍同样的流程本地回放看收益特征 → 参数敏感性测试找稳定区间 → 模拟盘跑三个交易日 → 导出成交明细做一致性比对 → 实盘先用半自动模式观察一周。这套流程不是平台提供的现成按钮而是要自己把每个环节的日志和数据都保存下来。它帮我挡掉了至少三次“回测猛如虎、实盘亏成狗”的意外。希望帮到你。本文还有配套的精品资源点击获取