3、VWAP执行算法架构：订单管理模块、调度引擎、风控模块、绩效归因模块

做VWAP执行算法，说白了就是要把一个大单子拆成无数个小单子，然后像滴水一样均匀地流进市场。我做了这么多年，发现很多团队一开始就扎进策略细节里，结果架构没搭好，后面改起来痛不欲生。今天我就把核心的四个模块拆开来讲——订单管理、调度引擎、风控、绩效归因。

3.1 订单管理模块

这个模块管什么？说白了就是订单的整个生命周期。从接收父订单开始，到拆分子订单，再到跟踪成交状态，最后汇总回报。我见过最坑的情况是，订单状态机没设计好，成交了还继续发单，直接超买。

我个人习惯把订单状态分成这几个阶段：

• PENDING —— 刚收到，还没开始处理
• ACTIVE —— 正在执行中
• PARTIAL_FILLED —— 部分成交
• FILLED —— 全部成交
• CANCELLED —— 被撤销
• REJECTED —— 被交易所拒绝

嗯，这里要注意。状态转换必须严格单向，不能从FILLED再回到ACTIVE。我曾经在项目中遇到过因为状态机没加锁，多线程环境下订单状态乱跳的问题，最后查了两天才发现是并发更新导致的。

订单管理模块还需要维护一个订单簿，记录所有未成交订单的详细信息。你想想看，如果交易所突然断连，你得能根据订单簿恢复所有挂单状态，不然资金就悬在那了。

3.2 调度引擎

调度引擎是整个VWAP算法的大脑。它决定什么时候发单、发多少、发到什么价格。我习惯把它分成三层：

1. 时间切片层 —— 把交易时间切成N个等份，比如每5分钟一个切片
2. 量分配层 —— 根据历史成交量曲线，给每个切片分配目标量
3. 微操层 —— 在切片内部，决定具体怎么发单

举个例子，假设我们要在4小时内买入100万股。时间切片层切成48个5分钟切片。量分配层根据历史数据，发现10:30-10:35这个切片成交量最大，就多分配一些。微操层再把这个切片的目标量拆成几十个小单，用TWAP或者更精细的策略发出去。

我建议调度引擎采用事件驱动架构。每个切片结束时触发一个事件，调度引擎根据当前成交进度和剩余时间，重新计算剩余切片的分配量。这样做的好处是灵活，坏处是逻辑复杂。我在项目中遇到过因为事件队列积压导致调度延迟的问题，后来加了优先级队列才解决。

下面是我画的一个调度引擎的核心流程图：

3.3 风控模块

风控模块，说白了就是给算法上保险。没有风控的VWAP算法，就像没有刹车的跑车。我见过最惨的案例是，算法在流动性枯竭时还在猛发单，结果把价格打飞了，亏损几百万。

风控模块我建议至少包含这几层：

风控层级	检查内容	触发动作
事前风控	订单金额是否超限、股票是否可交易、账户余额是否充足	拒绝订单，返回错误码
事中风控	偏离VWAP是否超过阈值、成交速度是否异常、市场波动是否过大	减速执行、暂停算法、人工介入
事后风控	成交回报是否完整、是否有漏单、是否有异常交易	生成告警、触发回滚

我个人习惯在事中风控里加一个滑点监控。如果当前成交价偏离VWAP超过0.3%，就自动降低发单频率。如果超过0.5%，直接暂停算法，等市场恢复再说。你想想看，如果市场突然跳水，你还按原计划买，那不是接飞刀吗？

3.4 绩效归因模块

绩效归因，就是算账。这笔交易到底做得好不好？好在哪里？差在哪里？没有归因，你永远不知道算法该往哪个方向优化。

我常用的归因框架是这样的：

• 执行成本 —— 实际成交均价 vs VWAP基准，算出差额
• 时间成本 —— 如果执行时间拉长，市场波动带来的额外成本
• 冲击成本 —— 因为我们的订单影响了市场价格，导致的额外成本
• 机会成本 —— 如果没成交，错过的收益

举个例子，假设VWAP是10.00元，我们实际成交均价是10.02元。那执行成本就是-0.02元（负的说明比基准差）。但如果我们分析发现，这0.02元里有0.015元是市场整体上涨导致的，只有0.005元是算法执行不好导致的。那算法其实还行，主要是市场环境不好。

绩效归因还有一个重要功能——回测验证。每次算法上线前，我都会用历史数据跑一遍回测，看看归因结果是否合理。如果回测显示算法能跑赢VWAP，实盘却跑不赢，那八成是数据问题或者市场环境变了。

嗯，这四个模块讲完了。订单管理管生命周期，调度引擎管执行节奏，风控管安全底线，绩效归因管复盘优化。四者缺一不可。我见过太多团队只重视调度引擎，结果订单管理一团糟，风控形同虚设，归因全靠拍脑袋。这样的算法，能赚钱才怪。

---