一、90%的新手都踩过的坑
先问你一个问题：你是不是也这样？
在Jupyter Notebook里写了一段策略代码，回测曲线漂亮得不行，年化30%、夏普2.0。于是兴奋地准备实盘，结果发现------回测代码根本没法直接用。
数据获取方式不一样、信号触发的逻辑要重写、订单成交的情况比想象中复杂一万倍......
我感觉大多数的量化新手都可能会踩到这个坑：回测一套代码，实盘另一套代码。
所以，我个人认为对应的解决方案是什么呢？答案是：分层架构。
今天这篇文章，我分享一个生产级量化交易系统的4层架构的拆解，不涉及代码，只讲核心思路和设计要点。希望看完你也就能画出自己的架构图。
- 量化交易系统的4层架构
分层的价值：
- 改策略时，不影响数据获取和下单
- 换数据源时，策略层不需要改动
- 核心优势：回测和实盘共用同一套策略逻辑
三、第1层：数据层
职责：获取、清洗、对齐行情数据
设计要点：
|----------|--------|-------------|
| 数据类型 | 用途 | 要点 |
| 历史数据 | 回测 | 需要清洗，注意未来函数 |
| 实时数据 | 实盘 | 处理延迟，保证连续性 |
最容易踩的坑------未来函数
用"未来"的数据计算"现在"的信号。例如：用当天的收盘价计算均线，然后在同一天买入。
回测里没问题，因为你知道当天收盘价。但实盘里，收盘价是收盘后才确定的。
正确做法：日线策略用前一天收盘价计算信号，第二天开盘交易。
数据层原则：策略层拿到的数据，无论回测还是实盘，格式必须一致。
四、第2层：策略层
职责：根据行情数据和当前持仓，生成交易信号
输入：行情数据 + 持仓状态
输出：买入/卖出/持有
设计原则：
不关心数据从哪里来，只接收标准格式
不负责下单，只返回信号
核心判断逻辑可复用
回测与实盘的差异：策略逻辑可以复用，但需要适配不同的接口（回测引擎的模拟接口 vs 实盘的API接口）。
五、第3层：风控层
这是最容易放错位置的一层。
风控层应该在策略层和执行层之间，而不是在执行层之后。因为风控应该在下单之前检查，而不是等订单发出后再拦截。
风控指标示例：
|---------|-----------|
| 指标 | 触发动作 |
| 单笔亏损超限 | 拒绝信号或强制平仓 |
| 账户回撤超限 | 暂停所有新开仓 |
| 持仓集中度超限 | 拒绝超限的开仓信号 |
| 信号频率过高 | 拒绝高频信号 |
设计原则：
- 独立运行，与策略逻辑分离
- 优先执行，优先级高于策略信号
- 实时监控，在每个信号进入执行层之前检查
六、第4层： 执行层
职责：接收通过风控的信号，转换成订单，发送到交易所
核心功能：
|--------|---------------------|
| 功能 | 说明 |
| 订单转换 | 信号转为具体的限价单/市价单 |
| 状态管理 | 跟踪订单状态（已提交/已成交/已取消） |
| 重试机制 | 未成交时按规则撤单重发 |
| 成交反馈 | 将成交结果回写给策略层 |
最容易忽略的坑------假设一定能成交
回测里下买单，默认下一秒成交。实盘里可能遇到流动性不足、滑点、网络延迟。
执行层原则：
- 不假设成交，等待交易所返回确认
- 设置超时，超时后撤单或降级
- 记录实际成交价，反馈给风控层
七、完整数据流
- 数据层推送最新行情
- 策略层计算信号
- 风控层检查：通过则继续，拒绝则记录日志
- 执行层发送订单到交易所
- 交易所返回成交结果
- 执行层更新持仓，回写给策略层
- 等待下一笔行情，循环
关键点：成交回报必须回写给策略层，否则策略层不知道当前仓位，无法决定下一个信号。
八、总结
核心收获：
四层架构：数据层、策略层、风控层、执行层
风控层必须在策略层和执行层之间
分层的价值：策略逻辑可复用，每层独立优化
你可以立即做的：
检查现有系统：风控在下单前还是下单后？
如果在下单后，考虑调整位置
加上最简单的风控：比如单笔亏损超限就拒绝下一个开仓信号
你的量化系统现在的架构是怎么样的呢？欢迎在评论区跟我分享讨论！