简介这是一套基于JAVA的AI开源量化交易平台源码面向具备一定编程基础的程序员与量化爱好者可用于期货、股票、外汇、数字货币等多种交易场景实现自动与半自动交易覆盖历史回放、策略研发、模拟交易到实盘交易的完整链路适合想自建量化系统或替代文华、MC、金字塔等工具的用户。资源包共579个文件整体约1.83MB以408个java源码为核心配合62个js与24个vue构建前端界面另有xml、json、yml等配置与部署文件以及proto协议、dockerfile、sh脚本和少量图片、字体等静态资源结构完整、便于二次开发。目前已有378人学习下载。通过研读源码读者可掌握量化平台的整体架构、策略引擎与行情接入思路理解CTP等交易接口的对接方式并借鉴其前后端分离与容器化部署方案为自研交易系统提供可复用的工程参考。1. 从一张 Java 写的开源量化交易平台说起它到底能替你做什么很多人第一次听到「基于 JAVA 的 AI 开源量化交易平台」脑子里冒出来的画面是下载一个压缩包双击运行然后它自己开始赚钱。我先把这句话拆开——它其实是一个用 Java 写的、代码公开的、把 AI 模型接进交易决策链路的系统覆盖期货、股票、外汇、数字货币等多种标的目标是让下单、风控、持仓管理这些动作自动跑起来。它解决的不是「预测涨跌」这一件事而是把「数据接入 → 策略计算 → 信号生成 → 订单执行 → 风控拦截」串成一条能无人值守运行的流水线。适合谁如果你写过 Java、懂一点面向对象编程手里有某个市场的行情接口或模拟账户想把自己的交易想法变成能 7×24 跑的代码那这套东西就是给你准备的。如果你完全没碰过编程只想找个「股票自动交易助手」点两下就用那大概率会在环境配置这一步就卡住。量化交易的门槛从来不在策略本身而在工程链路——数据怎么来、订单怎么发、断了怎么恢复这些才是真正吃时间的地方。这一章先把地图铺开后面几章带你从零跑通一条最小链路再讲清楚参数和坑。2. 拆开这套平台Java 量化系统的四层结构与选型理由2.1 为什么是 Java而不是 Python 量化那一套网上搜「python量化交易策略代码」能搜出一大堆pandas backtrader 几行就能回测。那为什么还有人用 Java 做量化平台核心原因是生产环境的稳定性与并发。Python 在研究和回测阶段无敌但真到了实盘一个策略要同时盯几十个合约的行情、维持多个 WebSocket 长连接、在毫秒级做风控判断GIL 和动态类型的短板就出来了。Java 的强类型、成熟的线程模型、JVM 的 JIT 预热后性能以及大量经过生产验证的中间件客户端Kafka、Redis、Netty让它在「长期稳定运行」这件事上更省心。我一般的选型判断是研究回测用 Python实盘执行用 Java两者通过消息队列或数据库对接。这套开源平台选 Java 作为主语言本质是押注在「跑得久、不出玄学崩溃」上。代价是开发速度慢一些写个策略要定义类、接口不像 Python 那样随手改。但对要拿真金白银跑的自动交易来说这个代价值得。2.2 四层结构数据层、策略层、执行层、风控层不管哪套 Java 量化框架骨架都逃不出这四层理解它们比记 API 重要得多。层职责常见技术选型关键指标数据层行情接入、K线合成、历史存储Netty / WebSocket / Kafka / Redis / 时序库延迟、丢包率、时间戳对齐策略层指标计算、信号生成、AI 模型推理自研策略接口 / ONNX Runtime / DJL单次计算耗时、内存占用执行层订单组装、报单、撤单、成交回报交易所 REST / FIX 协议报单成功率、往返延迟风控层仓位限制、最大回撤、频率限制独立拦截器 / 前置校验拦截准确率、误杀率数据层是地基。行情进来第一件事是统一时间戳不同交易所的时间精度不一样有的毫秒有的微秒不做对齐后面 K 线合成就会错位回测和实盘对不上这是最隐蔽的坑之一。策略层负责把行情变成「买/卖/不动」的信号AI 模型通常在这一层以推理服务的形式挂进去而不是直接嵌在策略类里——解耦之后模型可以独立更新。执行层要处理网络抖动、部分成交、订单被拒这些现实问题。风控层必须是独立于策略的一道闸策略可以写错风控不能失效。2.3 把 AI 模型接进决策链路推理服务怎么挂「AI 开源量化交易平台」里的 AI落地方式通常是三种一是把模型当信号过滤器策略给出候选信号模型判断要不要执行二是把模型当仓位调节器根据市场状态动态调整下单量三是端到端的价格预测直接输出目标仓位。第一种最稳第三种最容易翻车。工程上我一般把模型封装成一个独立的推理服务用 HTTP 或 gRPC 暴露接口策略层通过客户端调用。这样模型可以用 Python 训练、导出成 ONNXJava 侧用 ONNX Runtime 加载避免跨语言训练的麻烦。下面是一个 Java 侧加载 ONNX 模型并做推理的最小骨架// 依赖: com.microsoft.onnxruntime:onnxruntime:1.x import ai.onnxruntime.*; import java.util.*; public class ModelInference implements AutoCloseable { private final OrtEnvironment env; private final OrtSession session; public ModelInference(String modelPath) throws OrtException { this.env OrtEnvironment.getEnvironment(); // 单线程加载模型只读多线程共享 session 是安全的 this.session env.createSession(modelPath, new OrtSession.SessionOptions()); } // features: 归一化后的特征向量长度必须与训练时一致 public float[] predict(float[] features) throws OrtException { long[] shape {1, features.length}; OnnxTensor input OnnxTensor.createTensor(env, java.nio.FloatBuffer.wrap(features), shape); MapString, OnnxTensor inputs Collections.singletonMap(input, input); try (OrtSession.Result result session.run(inputs)) { // 输出名要和导出模型时约定的一致 float[][] output (float[][]) result.get(output).get().getValue(); return output[0]; } finally { input.close(); } } Override public void close() throws Exception { session.close(); env.close(); } }逻辑说明OrtSession是线程安全的加载一次全局复用不要每次推理都 new 一个否则内存会爆。features的归一化方式必须和训练时完全一致训练用 z-score 标准化推理也得用同一套均值和方差这是 AI 量化最常见的翻车点——离线指标漂亮上线就废八成是特征处理不一致。参数上shape的第一维是 batch size实盘一般用 1输出维度取决于你的模型设计分类模型是概率回归模型是预测值。2.4 最小可运行链路从行情到一笔模拟订单跑通链路比调参重要。我建议第一步不接真实交易所先用本地模拟数据把「行情 → 策略 → 信号 → 订单」串起来。下面是一个极简的策略接口和主循环public interface Strategy { // 每根K线收盘调用一次返回目标仓位比例 [-1, 1] double onBar(Bar bar); } public class MaCrossStrategy implements Strategy { private final int fast, slow; private final DequeDouble closes new ArrayDeque(); public MaCrossStrategy(int fast, int slow) { this.fast fast; this.slow slow; } Override public double onBar(Bar bar) { closes.addLast(bar.getClose()); if (closes.size() slow) closes.removeFirst(); if (closes.size() slow) return 0.0; // 数据不够空仓 double fastMa avgLast(fast); double slowMa avgLast(slow); // 金叉满仓死叉空仓简单但能验证链路 return fastMa slowMa ? 1.0 : 0.0; } private double avgLast(int n) { double sum 0; int i 0; for (Double c : closes) { if (i closes.size() - n) sum c; } return sum / n; } }逻辑说明策略接口只暴露onBar把「怎么算」和「怎么执行」彻底分开这样换策略不用动执行代码。closes用ArrayDeque维护滑动窗口避免每次遍历全量历史。参数fast、slow是均线周期常见组合 5/20、10/60但不要迷信参数均线交叉在震荡市里会被反复打脸它的价值是验证链路通不通不是赚钱。主循环里拿到onBar的返回值后交给执行层换算成手数再交给风控层校验最后才报单。这条链路每一环都要能单独打日志否则出了问题就是黑匣子。3. 参数怎么设数据、策略、执行三层的关键配置3.1 数据层参数K线周期、时间戳对齐、断线重连数据层的参数直接决定策略看到的「世界」准不准。K 线周期要和策略匹配做日内高频用 1 分钟甚至 tick做趋势用 15 分钟或小时线。时间戳对齐是最容易被忽略的交易所推送的行情带的是交易所本地时间你的服务器时间是另一套两者差几百毫秒K 线边界就会漂移。常见做法是统一用 UTC 毫秒时间戳收到行情后立刻打上本地接收时间两个都存回测用交易所时间实盘监控用本地时间。断线重连参数要设得保守。WebSocket 断开后不要立刻疯狂重连容易触发交易所的频率限制被封 IP。我一般用指数退避第一次 1 秒之后翻倍上限 30 秒同时记录断线次数超过阈值告警。下面是一个退避重连的写法public void connectWithBackoff() { int attempt 0; long maxBackoff 30_000L; while (!connected) { try { doConnect(); attempt 0; // 成功则重置 } catch (Exception e) { attempt; long wait Math.min((long) Math.pow(2, attempt) * 1000, maxBackoff); log.warn(连接失败第{}次{}ms后重试, attempt, wait); sleep(wait); } } }逻辑说明Math.pow(2, attempt)实现指数增长Math.min封顶防止等待过久。参数maxBackoff设 30 秒是经验值太短会频繁重连太长会错过行情恢复。注意重连成功后要把本地维护的持仓和订单状态和交易所对账一次因为断线期间可能已经有成交这是血泪经验——不对账就会出现「本地以为空仓、实际有持仓」的鬼故事。3.2 策略层参数均线周期、AI 阈值、仓位系数策略参数分两类规则参数和模型参数。规则参数比如均线周期、布林带宽度这些靠回测网格搜索但要注意过拟合——在历史数据上调到完美的参数实盘往往失效。我的习惯是留一段样本外数据参数只在样本内调样本外验证两边差距太大就说明过拟合了。AI 模型的阈值参数更微妙。模型输出一个 0 到 1 的概率你得定一个阈值决定「多大概率才动手」。阈值设 0.5 太激进信号多但噪音大设 0.8 太保守错过机会。常见做法是结合仓位系数概率 0.6 时下 0.3 仓0.8 时下 0.6 仓让模型置信度和仓位挂钩而不是非黑即白。这样即使模型偶尔犯错损失也可控。3.3 执行层参数报单价格、超时撤单、滑点容忍执行层参数决定「想法」能不能变成「成交」。报单价格用对手价还是排队价差别很大对手价成交快但滑点大排队价省成本但可能不成交。我一般对流动性好的品种用对手价流动性差的用中间价挂单。超时撤单是必须的。订单发出去没成交不能一直挂着否则行情反转时被动成交。设一个超时时间比如 3 秒没成交就撤单重报。滑点容忍度也要设比如预期价格和实际成交价差超过 0.5% 就告警说明流动性出了问题。这些参数没有标准答案要在模拟盘上跑一段时间看成交回报的分布再定。4. 避坑与排查自动交易上线前必须过的五道坎4.1 回测赚钱实盘亏先查特征和手续费现象回测年化 30%实盘一个月亏 10%。原因通常有两个一是特征处理不一致回测用了未来数据比如用收盘价算指标又用收盘价成交实盘拿不到二是手续费和滑点没算进去高频策略尤其明显回测里忽略的万三手续费一年能吃掉大半利润。解决回测框架强制用「下一根 K 线开盘价」成交手续费按真实费率扣滑点按历史盘口估算。4.2 订单重复提交幂等键没做现象网络抖动后重试同一笔订单发出去两次仓位翻倍。原因报单接口没有幂等设计。解决每笔订单生成唯一clientOrderId交易所侧和本地都按这个 ID 去重重试时带同一个 ID交易所会拒绝重复单。这是自动交易的生命线必须做。4.3 时间戳错位导致 K 线错乱现象策略在整点前后行为异常K 线数量对不上。原因交易所时间和本地时间没对齐或者不同数据源时间精度不同。解决所有时间统一转 UTC 毫秒K 线合成用交易所时间戳落库时额外存本地接收时间用于排查。4.4 风控被策略绕过现象策略 bug 导致连续下单风控没拦住。原因风控逻辑写在策略内部策略出错风控跟着失效。解决风控做成独立的拦截器在订单进入执行层之前强制校验策略无权跳过。仓位上限、单日最大亏损、下单频率这三个是底线。4.5 内存泄漏推理 session 和行情缓存没释放现象跑几天后 JVM 内存持续上涨最后 OOM。原因每次推理 new 一个OrtSession或者行情缓存无上限增长。解决模型 session 全局单例行情缓存用固定大小的环形缓冲或定期清理别用无界队列。用jmap和jstat定期看堆内存早发现早处理。5. 进阶用 AI Agent 做策略监控与异常自愈跑通基础链路之后真正拉开差距的是运维自动化。实盘系统最怕的不是策略亏钱而是半夜挂了没人知道。我现在的做法是加一个轻量的 AI Agent 层专门做监控和自愈它不参与交易决策只盯着系统健康度。具体做法把关键指标行情延迟、报单成功率、持仓偏离度、策略信号频率打成时间序列Agent 定期拉取用简单的规则加异常检测模型判断是否异常。比如报单成功率 5 分钟内低于 90%Agent 自动触发「暂停策略 → 告警 → 检查网络 → 恢复」的流程。下面是一个监控循环的骨架public class HealthAgent { private final StrategyEngine engine; private final Notifier notifier; // 连续N次异常才触发避免抖动误判 private static final int FAIL_THRESHOLD 3; private int failCount 0; public void check() { Metrics m engine.collectMetrics(); boolean abnormal m.getOrderSuccessRate() 0.9 || m.getMarketDelayMs() 2000 || m.getPositionDeviation() 0.05; if (abnormal) { failCount; if (failCount FAIL_THRESHOLD) { engine.pause(); // 先停别让错误继续放大 notifier.alert(m); // 再告警带上指标快照 failCount 0; } } else { failCount 0; // 恢复正常就清零 } } }逻辑说明FAIL_THRESHOLD是防抖参数设 3 表示连续三次检查都异常才动手避免网络瞬时抖动导致误停。engine.pause()要保证是「软暂停」——停止开新仓但保留平仓能力否则暂停后行情反转跑不掉。notifier建议接多个通道邮件加即时消息单一通道挂了就瞎了。这套 Agent 的价值在于把「人盯盘」变成「系统盯系统」你睡觉的时候它替你守着。验证这套东西有没有用方法很土但有效故意制造故障。手动断开行情连接、手动让报单接口超时、手动改一个持仓数据看 Agent 能不能在预期时间内发现并处理。我踩过的坑是 Agent 自己也会挂所以它得是个独立进程和交易主进程分开部署通过心跳互相监控。主进程挂了 Agent 报警Agent 挂了主进程报警两个都挂——那就认了第二天看日志复盘。最后说个习惯任何参数改动先在模拟盘跑满一周再上实盘别嫌慢。我早年图快改完参数直接上结果一个滑点参数设错一天的手续费顶过去一个月。量化交易这行慢就是快稳就是赚。希望帮到你。本文还有配套的精品资源点击获取