一、信号与订单协同概述
做量化交易这些年，我见过太多团队把信号生成和订单执行当成两个独立模块来开发。结果呢？信号模型跑得漂亮，实盘一跑就亏钱。说白了，这两个环节就像人的大脑和手脚——大脑想得再好，手脚跟不上也是白搭。
交易系统整体架构
先聊聊一个完整的交易系统长什么样。我个人习惯把它分成四个层次：
- 数据层：行情数据、订单簿数据、基本面数据。这是地基，数据质量不行，后面全白搭。
- 信号层：策略逻辑、因子计算、信号生成。这里产出的是「什么时候买、什么时候卖」的决策。
- 执行层：订单管理、路由选择、成交算法。负责把信号变成真实的成交单。
- 风控层：资金管理、仓位控制、异常检测。贯穿始终的守护者。
我在项目中遇到过一种典型情况：信号层每秒钟产生100个交易信号，但执行层每秒只能处理20个订单。你想想看，这中间80%的信号就白白浪费了。所以架构设计时，必须把吞吐量匹配问题考虑进去。
核心要点：交易系统不是简单的「信号→订单」单向流水线，而是一个闭环反馈系统。执行结果要能反馈回信号层，用于调整策略参数。
下面这张图展示了信号与订单协同的核心流程：
信号生成与订单执行的关系
这两个模块的关系，我总结为三个关键词：
- 时序依赖：信号必须先于订单产生。但这里有个坑——信号产生的时间点和实际下单的时间点之间，存在延迟。我曾经因为没处理好这个延迟，导致高频策略在波动行情中频繁吃瘪。
- 质量传递：信号的质量直接影响执行效果。一个模糊的信号（比如「可能涨」），执行层根本没法做精细化操作。反过来，执行层的滑点、延迟也会扭曲信号的真实表现。
- 双向反馈：执行结果应该反哺信号优化。比如，如果发现某个信号总是产生大量撤单，那这个信号的可靠性就要打问号了。
实战技巧：我建议在信号层和执行层之间加一个「信号适配器」。它的作用是把信号层的「意图」翻译成执行层能理解的「指令」。比如信号层说「买入100股」，适配器会根据当前流动性状况，决定是直接市价单还是拆分成多个小单。
协同优化的核心目标
说白了，协同优化就奔着三个目标去：
| 目标 | 说明 | 我的经验 |
|---|---|---|
| 降低延迟 | 从信号产生到订单成交的时间差最小化 | 我曾经把信号生成从Python改到C++，延迟从5ms降到0.3ms，但收益提升并不明显。后来发现瓶颈在订单路由上。 |
| 减少滑点 | 实际成交价与信号触发价的偏差最小化 | 信号层如果能提供「价格容忍度」参数，执行层就能灵活选择限价单或市价单。这个配合做好了，滑点能降30%以上。 |
| 提高成交率 | 信号触发的订单最终成交的比例 | 嗯，这里要注意：不是成交率越高越好。有些策略故意用撤单来试探市场深度，这时候成交率低反而是正常的。 |
避坑指南：我曾经犯过一个错误——为了追求低延迟，把信号层和执行层部署在同一台机器上。结果信号层的内存泄漏导致整台机器宕机，订单执行也跟着停了。后来我强制要求：信号层和执行层必须物理隔离，即使延迟会多几微秒。
最后说一句实在的：协同优化不是一锤子买卖。它需要你在实盘运行中不断调整参数。我习惯每周跑一次回测，对比信号层记录的「理想成交价」和执行层实际的「成交价」，看看偏差趋势。如果偏差在扩大，就说明协同出了问题，得赶紧排查。
你想想看，信号再准，执行跟不上也是白搭。反过来，执行再快，信号不准更是灾难。只有两者协同好了，交易系统才能真正稳定盈利。
公众号:蓝海资料掘金营，微信deep3321