第五部分 · 量化研究如何产生可信结论 · 第 33 章

交易执行和实盘系统: 策略如何真的下到市场里

量化策略在研究报告里输出的是一条干净的目标仓位,在真实市场里执行的却是一串跌跌撞撞的订单: 会排队、会部分成交、会被拒绝、会撤不掉、成交价会变差,还要被风控和交易规则管着。实盘系统的任务,绝不是把 buy 函数调用出去就完事,而是把策略意图可靠地翻译成真实成交,并且在出错的时候保护账户。这一章讲的,就是研究到实盘之间那段最容易被低估的路。

主线五 本部分第 6 / 10 章

本部分的问题:一个金融判断怎样变成可证伪假设,再经过数据、回测、模型和实盘约束?

读完后,你能从问题出发完成研究闭环,而不是先找模型、再给结果编故事。

读完这一章,你会明白

  • 实盘交易是一台订单状态机,必须处理好拒单、部分成交、撤单、成交回报和对账。
  • 执行要在速度、成本和成交确定性之间取舍,大订单还得额外考虑冲击和参与率。

1. 订单生命周期

一笔订单从产生到结束,通常要走过一串状态。策略先生成交易意图,组合层把它变成目标买卖数量,交易系统做风控检查,然后向券商或交易通道提交订单。接下来,这笔订单可能被接受、被拒绝、部分成交、全部成交、撤单中、撤单成功、撤单失败——每个状态都可能停留,也可能跳到别的状态。

这些状态全部要落日志。你不能只记一句“我想买 10000 股”。真实系统要知道: 已报多少、成交多少、剩余多少、平均成交价多少、费用多少、是否可撤、是否失败、失败原因是什么。否则下一次下单,就是基于错误持仓继续行动——错误会利滚利。

用程序员的话说,订单生命周期就是一个状态机。量化开发里很多严重事故,根本不是模型错,而是状态机错: 以为撤单成功其实没撤,以为没成交其实已经部分成交,以为订单被拒其实内部账已经加仓。状态不一致,是交易系统的头号死因。

订单生命周期:从下单到成交的六步 下单 → 风控校验 → 排队 → 部分成交或全数成交 → 撤/改可选 → 日终结算。 每一步都可能失败:风控拦住、行情断层未成交、撤单没成功、部分成交只在清仓边缘。 回测忽略订单路径,会变成纯理论——你实际下的每一个单子都要走完这条路。

量化执行的核心不是算信号,是订单走完这条链。回测里的“今日买入”在真实世界里可能是六次努力:提交、校验、排队、成交、撤单、结算。

2. 市价单、限价单和算法单

市价单追求尽快成交,但成交价可能很差;限价单指定最差可接受价格,能控制价格,但不保证成交。一个追确定性,一个追价格,各有代价。还要提醒一句: A 股普通股票没有完全等同于海外市场的简单市价单机制,实际订单类型和申报方式,得按交易所和券商的规则来理解,不能照搬段子。

机构的玩法更细: 常用算法单把大订单拆成一串串小订单。比如按时间均匀成交的 TWAP,按市场成交量比例参与的 VWAP,或者根据盘口和冲击动态调整的执行算法。注意,这些算法的目的不是预测股票涨跌,而是在完成交易这件事上,尽量降低冲击和滑点。

个人做量化,不一定需要复杂算法单,但至少要理解一件事: 大单不能一次砸进市场。哪怕你只是用小资金交易,也要在回测里考虑限价、成交不足和价格滑点,别假设任何数量都能按理想价格成交。

3. 快、便宜和确定性不能同时最大化

交易执行有三个常见目标: 尽快成交、尽量低成本、尽量确定地完成。坏消息是,这三个没法同时要。想快,就可能主动吃对手盘,滑点更高;想便宜,就可能挂单慢慢等,成交不确定;想确定完成,就可能得在价格上让步。工程上这叫不可能三角,选两个,放掉一个。

场景不同,选择就完全不同。比如你必须今天把仓位降下来,就不能只挂一个保守的卖价佛系等待——市场如果继续下跌,没卖掉的风险比滑点大得多。反过来,如果只是小幅调仓,完全可以更耐心,把冲击成本省下来。

所以执行算法要按策略需求来选择: 高频信号衰减快,晚一分钟信号就贬值,需要更快成交;长期配置调仓不着急,可以慢慢执行;风控减仓则是保命优先,成交确定性压倒成本考虑。

执行三原则:快、便宜、确定,你只能三选二 极限成交:快+确定(市价单),但滑点最贵的成本会从价差里收走 不成交:便宜+确定(限价单子慢),结果可能滑出一眼,边际却变成了错过成交的判断 下单是选择做什么,在最坏的行情里,是买单在最丟逼的环境中存不存快乐——市场可能并不在乎你再挂一手

'自动下单'复杂的地方不是指标连好怎么算,而是'都给了货能不能也不肯让你跟随它'的秩序。

4. 下单前先挡住低级错误

前置风控,是订单发出市场之前的最后一道安检。常见检查包括: 账户资金够不够、可卖持仓够不够、证券是否可交易、价格是否越界、数量是否符合交易单位、单笔金额是否过大、个股和行业仓位是否超限、标的是否在黑名单或限制名单里。

这些检查看起来琐碎,像表单校验一样无聊,但它们能拦住成片的事故: 模型输出异常、数据缺失、价格单位错了、重复下单、股票停牌、涨跌停不可成交——都可能在安检口被拦下,而不是在市场上爆炸。

一个实盘系统的默认世界观应该是: 模型会犯错、数据会坏、网络会断、券商会拒单。前置风控不是对研究员不信任,而是承认在真实市场里,任何环节都可能出问题,所以每道门都要有守卫。

5. 市场正在变

订单发出去,风险不是结束了,而是刚开始。盘中价格可能快速变化,成交可能只完成一半,账户净值可能在下跌,保证金可能不足,市场可能触发异常波动。盘中风控要做的,就是持续盯持仓、现金、成交、回撤、暴露和订单状态。

举个具体的坑: 一个策略原计划买入 50 只股票,结果只成交了 20 只,剩下 30 只因为涨停买不到。此刻你的真实组合,和模型预期里的组合已经是两个东西——如果系统还按目标组合计算风险,就会严重低估真实偏离。

盘中风控的常见动作包括: 暂停新单、撤销未成交订单、降低参与率、强制减仓、切换备用通道、通知人工确认。记住,自动化不等于无人负责——关键节点必须有清晰的告警和明确的权限,告警响了要有人接。

实盘的组合和回测的组合,是两个组合

计划买 50 只,涨停拦住 30 只,你实际持有的已经是另一个组合:行业权重变了、风格暴露变了、资金占用也变了。如果监控还按“目标组合”算风险,你盯的就是一块假仪表盘。盘中风控的第一原则,是把“我想买什么”和“我真的买到了什么”分开记账——回测里它们永远相等,实盘里它们天天岔开。

6. 部分成交和撤单失败

部分成交是实盘常态,不是异常。你想买 10000 股,可能先成交 3000 股,剩下 7000 股还在队列里排队。这一瞬间,你的真实持仓已经变了,现金也被占用或冻结了,但目标仓位还没完成——系统必须同时记住这三件事。

撤单也不是一键瞬间完成。你发出撤单请求的那一刻,订单可能已经部分成交,也可能正在交易所的队列里等着;最终结果可能是撤单成功、撤单失败,或者先成交了导致无可撤。所有这些中间态,系统都必须处理。

如果系统简单地认为“发出撤单 = 订单不存在了”,迟早出事。正确做法是等交易通道返回确认,再根据成交回报更新状态。交易系统最怕的东西只有一样: 内部状态,和券商那边的真实状态,对不上。

7. 成交回报和内部账本

成交回报,是券商或交易通道给你回执: 订单成交了多少、价格多少、费用多少。内部账本就得根据这些回执,更新现金、持仓、冻结资金、可卖数量、成本价和盈亏。

关键

关键原则: 内部账本不能只靠自己推演。真实成交可能和预期不同,费用可能有细碎名目,订单可能被拆成几笔成交。所以盘中和盘后,都要拿内部账本和券商或托管的数据对账,确认两边一致。

对账这件事听起来一点不性感,但非常关键。很多金融系统的稳定性,不在模型层,在账务层。钱和仓位一旦记错,后面一切都跟着错: 收益、风险、申赎、合规、报表,全盘失真。

8. 真实成交比预期差多少

滑点监控做的事,是比较预期成交价和实际成交价。基准可以选下单时的中间价、买一卖一、VWAP 或到达价格。实际成交比买入基准更高、比卖出基准更低,差出来的那截,就是你付的成本。

只看一个总滑点没有用,要拆开看: 按股票、行业、时间、订单大小、参与率、交易员或算法逐层分解。某些股票滑点长期偏大,可能是流动性差;某个时间段滑点偏大,可能是市场在剧烈波动;某个执行算法滑点偏大,可能该调参了。

量化策略上线后,如果只盯预测效果、不看执行效果,会漏掉真正的失血点。模型赚 5%,执行亏 3%,客户最后只看到 2%。所以有句话要记住: 执行质量,本身就是 Alpha 的一部分。

滑点:成交额的隐形税 一笔 100 万的小额订单,你按收盘价下的模拟单,真实成交可能偏离标价 0.05 元 一笔 2000 万的大额订单可能要动用半本书的卖出队列——成交容积被吸完,价格就移动了几档,损耗从 0.1% 到几个个百分点都有可能 滑点不可避免,但可以被量化——写进策略的容量评估里,不然你要到实盘才知道

滑点不是“我发现成交贵了”,是市场深度在你的订单面前撑不住。滑点=你拿到的价格考市场中间价的差,这个差随成交额一起上涨,直到大到一个不能忽略的数字。

9. 灾难开关和人工接管

实盘系统必须设计灾难开关,也就是一键拉闸的能力。数据源异常、行情延迟、订单拒绝率异常、成交价偏离过大、单账户亏损超过阈值、重复下单、持仓暴露越界——任何一种出现,都应该触发暂停或人工确认。

历史上很多交易事故,不是因为没人会写模型,而是因为系统在异常状态下继续自动交易。最著名的一课来自骑士资本(Knight Capital),它当时是美国股市最大的做市商之一。2012 年 8 月 1 日开盘,一次软件部署出了岔子: 一段本该废弃的旧代码被意外激活,交易系统开始疯狂、错误地自动下单。在大约 45 分钟里,它向市场发出了 400 多万笔订单,买高卖低、越亏越交易,最高峰每分钟烧掉约一千万美元。等工程师手忙脚乱地把它停下来,公司已经亏了大约 4.4 亿美元——一家上市巨头几乎在三刻钟内被自己的程序搞垮,几天后就被迫贱卖求生。

对每天写代码、发版的人来说,这个故事格外扎心: 杀死骑士资本的不是市场,是一次没做好灰度和回滚、又缺乏有效急停开关的部署。模型再聪明,只要实盘系统在异常时还在自动下单,几分钟就能把多年利润清零。所以灾难开关、人工接管、部署纪律,在量化里和策略本身同等重要。

当然,灾难开关不是为了让系统保守到不敢交易,而是为了确保异常不会无限放大。一个专业的交易系统必须能回答四个问题: 什么时候自动停? 谁有权限恢复? 停止后如何平仓或恢复状态? 日志如何追溯?

10. 个人实盘从小规模开始

个人做量化,千万别从全自动大资金起步。更稳的路线是台阶式的: 先离线回测,再模拟盘,再小资金半自动,最后才考虑自动化。每上一级台阶,都要确认数据、订单、成交、费用、持仓和净值能对得上。

小资金阶段,重点不是赚不赚钱,而是系统有没有按预期运行: 信号是否按时生成,订单是否正确,成交是否记录,失败是否告警,盘后是否对账,日志够不够复盘用。

道理很朴素: 一个系统在小钱时都经常状态错、日志缺、成本算不清,放大资金只会放大问题,不会解决问题。量化实盘的第一目标不是马上赚大钱,而是证明系统能在真实市场里稳定、可控、可解释地运行。

小结

这一章的正文不是让你记住几个孤立名词,而是要把它们放回同一条因果链里。读完后,先用自己的话复述下面几条判断,再顺着“小节回看”检查是否能解释每一步。

  • 实盘交易是一台订单状态机,必须处理好拒单、部分成交、撤单、成交回报和对账。
  • 执行要在速度、成本和成交确定性之间取舍,大订单还得额外考虑冲击和参与率。

小节回看

  • 1. 订单生命周期
  • 2. 市价单、限价单和算法单
  • 3. 快、便宜和确定性不能同时最大化
  • 4. 下单前先挡住低级错误
  • 5. 市场正在变
  • 6. 部分成交和撤单失败
  • 7. 成交回报和内部账本
  • 8. 真实成交比预期差多少
  • 9. 灾难开关和人工接管
  • 10. 个人实盘从小规模开始

自测

为什么策略目标仓位不能直接等于成交结果?

因为订单可能被拒、部分成交、排队未成交、撤单失败,或因涨跌停停牌根本无法交易。

执行为什么不能同时最快、最便宜、最确定?

追求快速和确定通常要主动吃对手盘、付出滑点;耐心挂单成本低,但成交不确定,三者只能取其二。

下一章为什么接在这里

风险控制和组合监控: 什么时候该减仓、停用和复盘

讲清暴露、集中度、VaR、压力测试、止损、模型失效和风险监控。