滑点对策略的绩效影响非常大，甚至决定了一个策略是否成功。由于滑点客观存在，投资者在调试策略的时候，会将滑点预设成一个值：如果把滑点设的比较大，那么对应的策略的交易周期也会比较大，反之亦然。因此，滑点大小的设置影响到策略及其参数的选择，如果把滑点设置成非常小，甚至设置为零，你会发现有很多原本不能盈利的策略变得非常好。

笔者采用的方法是，先将滑点设置很小，在此基础上进行策略的筛选和调试，在调试过程中密切关注策略的单笔盈利，看看是否能超过滑点，以决定策略及其参数的选择。这样做的好处是规避了滑点对策略不应该的干扰，例如，当你预设较大滑点的时候，你的策略会自然的偏向长周期。很明显，这种干扰是不应该的。请看下以下的例子：

以上可以看出，由于滑点在实盘中存在不确定，所以滑点设置过大，会影响策略的正常选择；正确的做法应该是滑点归滑点，策略归策略。我们需要考虑的是策略单笔盈利能否超过滑点，另一个方面，在策略的实盘中想办法采用减少滑点的另外一个层面的策略。

这种情况下，投资者对策略的成败的关注点，从策略本身转到如何建立减少滑点的订单策略，甚至在你的订单策略足够好的情况下，很多原本无法使用的短周期策略都是可行的。但由于订单策略关注的是高频数据，对于一般投资者来说难度较大。下面笔者将分享下设计订单策略的一些思路。

首先分析一下产生滑点的原因。策略是依据价格的变化来产生信号，这个触发信号产生的价格就是信号价；信号价即使是在实盘中，也是一个已经发生的历史数据，而策略的盈亏计算就是按照这个历史数据来计算的。实际的成交价要在信号价产生后的实际成交中产生，对于买入信号，如果成交价比信号价高，那就是不利滑点，反之就是有利滑点（这个情况也完全有可能）。

一般来说，如果你的策略是右侧交易的趋势跟踪，那么大部分情况会产生不利滑点。最终滑点的大小取决于当时的盘口量及策略的下单量。

假设当策略依据最新价发出买入信号时，盘口如图所示。由于对手价与挂单价相差较大，而最新价处于对手价与挂单价之间，这个时候，如果立即要成交， 需要按照对手价委托；这种情况下滑点将很难避免（信号价即最新价<对手价），且不一定保证能够成交。

特别是当策略的下单量远远大于委卖量（卖一量）时，滑点将更大，具体大小取决于后面卖二卖三的量（这个目前在国内期货中没有显示）。这里还有一个变数，就是策略下单时，有可能卖一甚至卖二以上被先成交了，那样的滑点将继续扩大。所以对于这种情况，行情及下单速度很重要，快速的行情及下单速度，能够让你比其他投资者更快获得成交，这也是很多投资者追求行情及交易速度的原因。

讲到这里，敏感的读者应该能感觉到另外一种场景，当你的行情及下单速度足够的快，你的策略信号都成交了，但价格却往成交的反方向运行，哪怕仅仅是短时间反方向运行，那么这种快速成交还不如稍微等待，这样能够更有利。另外， 如果为了提高速度，势必要进行大量硬件设备投入，当很多人都这么做的时候，就会演变成一场军备竞赛，最终导致投入的成本将远大于节省下来的滑点，正是这些因素，本文并不把行情及下单速度作为减少滑点的要素来考虑。

我们知道，价格即使有着明显的方向，短期内也经常不断来回波动，即所谓的噪声、毛刺。很多情况下，这些噪声非常大，甚至大到让你难以觉察到价格的真正方向。如何利用价格的噪声是订单算法策略的关键。

为了便于描述，这里先简单结合TBQuant的交易师下单工具说明关于委托价格的几个概念——指定价、对手价、挂单价、委托偏移、最新价、市价、涨跌停价。如下图：

从上面的分析知道，当策略发出交易信号后，如果直接按照超价（对手价+跳数）的方式委托，虽然这种委托方式立刻成交可能性比较大，但也会产生一些相对固定的滑点，而且在市场价格急剧变化时，也可能不能成交。

鉴于超价（对手价+跳数）、市价、涨跌停价等委托方式的局限性，我们尝试以挂单价甚至挂单价以内（即：挂单价-跳数）进行委托。挂单是一种等待状态，由此而产生的后续一系列操作就是一个基本的订单策略。挂单委托方式需要考虑的要素是：

要挂多少量，全部挂， 还是先挂一部分，分几次挂？

挂单等待，最长应该等多久？

什么情况应该是等不到了要撤单重新委托尽快追？

或者是不成交就放弃这次交易？

如果选择撤单追价，那要按什么委托价， 如果又不成交怎么办？部分成交怎么办？等等。

对于这些问题的处理方式就构成一个订单策略，这种策略本质上是一种以时间换空间的委托方式，其目标是找到一个最优的概率，尽量使得滑点最小。比如，十次委托，几次占到便宜，几次滑点，总体来说是否比直接下单尽快成交的委托方式更有利。

订单策略的编写，对投资者的编程能力要求非常高，一般非IT专业的投资者往往是知难而退。笔者这里推荐基于开拓者量化平台的TB语言，该策略语言，封装了各类交易接口， 提供了各种事件驱动如行情驱动、订单驱动（各类委托、成交回报、挂单、撤单等状态驱动）、时间驱动、自定义驱动等，让用户在没有专业的IT技术背景下，专注于策略本身，非常便捷的进行订单策略的编写，有兴趣涉足订单策略编写的投资者可以尝试使用。

当然，关于TB语言的订单策略编写不是本文要讨论的话题，笔者想介绍的是TBQuant量化平台系统自带的三个订单策略，用户可以无需编程即可方便使用，相信对想使用订单策略的投资者有所帮助。

TBQuant量化平台系统自带的三个订单策略分别是：TB算法代理、TB三步检查算法代理、TWAP算法代理。之所以叫代理，是因为这些订单策略是开放式的，用户只要告诉代理要做的方向和数量，其他都无需关注；当然，因为是开放式的，所有这些代理还有较多的设置参数，用户想深入使用时是需要了解的。下面分别介绍。  

一、TB算法代理

这个算法的基本思路是，当算法代理接收到策略信号后，会根据算法代理的参数计算出本次任务的下单要素（包括委托价格、委托数量、委托队列方式），然后依次下单委托；下单后，算法代理将实时跟踪成交情况——如果成交了，会依照队列顺序继续委托，当然这个时候会根据参数重新计算下单要素；如果未成交，算法会监督挂单情况，同时依据撤单条件进行判断，选择撤单重新委托或者继续挂单等待，以此类推，直至完成所有队列任务。该算法流程图如下。

TB算法代理的思路比较简单，但其算法的关键是参数的选择。下面介绍TB算法代理的主要参数，这些参数中最重要的有两类，一类是下单要素的参数，另外一类是撤单条件的参数。

下单要素包括委托价格、委托数量、委托队列方式，具体如下：

——委托基准价：指算法代理准备下单时的委托基准价类型，共有三种类型，对应着参数的三个枚举值，分别为对手价、挂单价、最新价。当选择后，后面的所有的委托基准价都以此类型。

——成交后委托偏移：指首次委托或上次成交后本次委托的偏移值，偏移值有两种计数方式，分别为跳数和万分比， 参数值为数组型，各个值的含义如图。

——撤单后委托偏移：指上次的委托撤单后本次委托的偏移值，参数值与成交后委托偏移值的设置类似，如图。

上述的三个参数构成了委托价格的计算方式，下面是委托量的参数：

——单次委托量：指每一次委托的数量，该参数有三种计数方式，分别是每次委托的手数、每次委托占总量的百分比、每次委托量为占盘口量的百分比，这里的盘口量在委托买入时指卖一量，在委托卖出时指买一量。

下面是撤单条件的参数，共有四个，其中两个为充分条件，两个为必要条件。

——撤单所需最小偏移：该参数为撤单的必要条件，也有两种计数方式按跳数和按万分比。

——撤单所需最小时间（秒数）：该参数也是为撤单的必要条件。

——触发撤单偏移：该参数为撤单的充分条件，指最新价相对委托价达到参数偏移值但仍未成交时进行撤单，也有两种计数方式按跳数和按万分比。

——触发撤单时间（秒数）：该参数为撤单的充分条件，指从委托后开始计时，当计时时间达到参数值但仍未成交时进行撤单。

另外还有一个参数：

——成交委托间隔（秒数）：该参数有两个值，分别为成交价有利间隔、成交价不利间隔。这里的有利和不利是成交价与理论价相比的结果，而间隔指的是成交后与下一轮委托之间等待的时间（秒数）。这个参数体现了有利多等不利尽快的原则。

二、TB三步检查算法代理

该算法代理与TB算法代理有很多相似之处，区别在于成交后的等待及判断后的等待。其基本思路如下：

当算法代理接收到策略信号后，会根据算法代理的参数计算出本次任务的下单要素，包括委托价格、委托数量、委托队列方式等，依次下单委托；下单后，算法代理将实时跟踪成交情况。

如果成交了，则会先等待一定时间（参数B），然后比较最新价与等待前的成交价；如果最新价比成交价有利，则继续等待一定时间（参数C）后，再进入下一轮新的委托；如果最新价比成交价不利，则立刻进入下一轮新的委托。

下单后如果未成交，则根据条件（参数A）判断是否撤单，符合条件则撤单并进入下一轮新的委托，否则继续等待。这个思路的基本理念是，价格有利则多等待，价格不利则少等待。下面是该算法的流程图。

TB三步检查算法代理与TB算法代理的参数大部分相同，区别在于三步检查参数，说明如下：

——三步检查A：该参数为撤单条件，时间和偏移满足一个即撤单。

——三步检查B：该参数为等待秒数，即成交后等待的时间。

——三步检查C：该参数也是等待秒数，指判断最新价比成交价有利后的等待时间。  

三、TWAP算法代理

该算法将总下单量按照指定的时间段平均分配下去。下面是该算法的流程图。

TWAP算法代理的下单要素参数与前面两个代理是一样的，其他参数区别在于撤单参数与委托间隔参数，该算法的撤单参数是简单的时间（秒数）参数。

上述三个代理还有一个重要的参数，说明如下：

——同一品种并发委托条件：并发委托指的是委托单以不同的队列形式，独立并行下单，相互不影响。在算法代理中，不同品种都是并发委托的，这个参数界定的是同一品种下，什么来源的委托单进行并发委托，委托来源有账户和操作源两种。该参数类型为枚举值，目前有三个参数值，分别为账户+操作源并发、仅操作源并发、不并发。举例如下。

假设算法代理收到了如下信号：

1、参数为“不并发”，算法按照不区分操作源不区分账户，区分品种的原则只形成 2 个队列，如下图：

2、参数为“仅操作源并发”，算法按照不区分账户，区分操作源，区分品种的原则形成 7个并发队列，如下图：

3、参数为“账户+操作源并发”，算法按照区分品种区分账户区分操作源的原则形成 10个并发队列，如下图：

这里有一点需要提醒，当参数选择不并发时，同一个品种不同账户之间的委托需要进行排队下单，这样就有可能造成虽然信号时间一样，但不同的账户因为队列排队的原因导致下单时间和成交价格不一样。鉴于此笔者更多时候将同一品种并发委托条件参数值设为账户+操作源并发，这样保证同一个品种不同账户能够处于不同队列并行发单。

当然，这样也会带来另外的一个问题，当下单量很大的时候，不同账户并发下单有可能冲击市场，相互抢单，所以选择什么样的委托队列方式，应该根据实际的情况。

上述算法代理的流程中，为了简化理解，笔者将流程中的监控流程独立了出来，这些监控流程也是各个算法代理流程的组成部分，下面分别说明。

一、是否加快监控

上述三个算法代理中都有两套一样的参数，一套是正常节奏的参数（如上述），另外一套是加快节奏的参数，这两套参数的形式一样，只是参数值不一样，这是考虑到当临近收盘或者小节结束前，算法代理还有未完成的任务，为了尽快委托成交而提供给用户设置的一套加快节奏的参数，其监控流程如图：

这里有两个判断是否启用加快节奏的参数如下：

——节奏加快规则：该参数为枚举值，参数值有四个，分别是：“不加快”、“夜盘结束前+白盘结束前”、“仅白盘结束前”、“所有小节结束前”。

——结束前偏移（秒数）：该参数指在收盘或者小节结束前多长时间（参数值）启动加快节奏参数。

二、涨跌停监控

当最新价接近涨跌停板的时候，算法为了防止因为涨跌停导致挂单无法成交，会触发涨跌停监控流程，如下图：

下面是触发涨跌停监控的参数：

——涨跌停并发偏移：这是一个阈值，当最新价接近涨跌停价达到该阈值时，算法将撤掉所有顺势的挂单，将所有的顺势的任务以涨跌停价委托，并一直挂单直至成交。 参数值为负数时不起作用，该参数有两种计数方式为跳数和万分比。

三、撤单次数监控

国内交易所对品种的撤单次数有规定，当账户的撤单次数超过交易所规则的次数，该账户的超限品种将会被限制交易一段时间，为了防止这种情况，算法设置了撤单次数监控流程， 达到限制次数后，该品种的委托当日将不撤单，如下图：

下面是对应的参数：

——合约撤单限制次数：该参数让用户设定合约的撤单上限。

——撤单达到次数后委托偏移： 这个参数是为了确保在当日的撤单次数达到交易所的限制次数后，委托单能够及时成交而设置的一个偏移值，这个偏移值一般会设置很大，大到算法会自动转为涨跌停价进行委托，该参数有两种计数方式跳数和万分比。

四、委托是否成功监控

这个流程是容错流程，如下图：

下面是参数：

——委托失败等待时间：这个参数属于容错参数。

算法代理的参数设置确实有点复杂，要设置好，需要对算法本身有较深的理解。但TBQuant算法代理的默认参数也代表了一种算法思路，用户完全可以不进行参数设置，直接使用默认参数。

现在简要介绍一下，如何在策略中使用算法代理。

1、设置步骤：在策略单元公式最后增加一个系统公式（仓差发送器）并保存策略单元， 该系统公式的名称为：TodayPosSender。

2、运行步骤：先启动算法代理，后启动加载了仓差发送器的策略单元。
3、运行流程：仓差发送器其功能相当于将用户策略单元的策略信号截住，同时计算出当日仓差，然后发送给算法代理，由代理按照算法进行下单。见下图：

仓差发送器的参数含义：

——对齐方式：参数为枚举值，有两个参数值为启动仓差和日初仓差。这里有几个基本概念如下：

仓差=最新持仓-昨日持仓，多头仓位为正，空头仓位为负

初始仓差值：在每次启动算法代理与策略单元时，仓差发送器都会发送一次仓差值到算法代理，这个仓差值就叫做初始仓差值。之后只有在仓差值发生变化的时候，仓差发送器才会发送仓差值到算法代理。

本次任务量=最新仓差值-上次仓差值

当日未完成任务量=从当日开盘至今算法代理未完成的任务量

启动后未完成任务量=从启动算法至今算法代理未完成的任务量

总任务量=当前需要完成的任务量

下图为算法代理计算任务量的流程：

算法代理收到仓差并计算出本次的任务量后，开始下单操作，并保持同步接受仓差信号的状态。

从上面的场景可以看出，参数日初仓差与启动仓差的区别在于对初始仓差值的处理：前者正常处理，后者不处理。设计这种差异的原因在于，使用者对于已发生信号的历史仓位是否同步有着不同选择，这种差别较难理解，笔者建议使用者直接采用日初仓差即可，采用日初仓差后，基本可以不需要头寸监控器。

下面是发送器的另外三个参数：

——代理事件目标：参数为枚举值，有 4 个选项，其中三个为上述的三个系统算法代理的名称，通过这个参数设置，可以选择所要使用的算法代理。另外一个参数值为“自定义”，这给了有较好编程能力的使用者自己写算法的选项。选择了自定义，需要配合下面的参数自定义目标一起使用。

——自定义目标：该参数与代理事件目标参数配合使用

——策略单元停止后暂停发单：该参数为布尔型，是发给算法代理的，可以顾名思义。

关于自定义目标，还有一些需要说明，目前的算法代理运行是通过策略的仓差发送器将仓差值以事件的形式发送到算法代理策略，这个策略专门在一个模块（算法代理模块）运行， 可以接受来自不同来源的事件；当算法代理接受的事件很多的时候（理论上可以接受无数的事件），有可能存在运行效率的瓶颈。

针对此种情况，TBQuant提供了两种解决方案，一种是允许在算法代理模块启动多份的算法代理策略，用户只要在仓差发送器设置自定义及目标即可。另外一种解决方案是直接把算法代理策略与仓差发送器一起加载到策略单元，设置参数代理事件目标为自定义同时参数自定义目标设为空，就可以实现将仓差发送到本策略单元的算法代理策略。

以上部分介绍了策略信号到算法代理，下面简要介绍一下手动下单如何使用算法代理。请看手动下单工具交易师。

这里的三个算法下单与上面的介绍的三个算法代理的差别在多了两个参数，其他全部一样，包括运行机制和其他参数。在勾选了模式的算法下单后，交易师界面所下的委托单全部由算法下单接过去执行。
新增的参数如下：

——下单量分段数：该参数可以将总下单量进行分段下单，每一段作为一个任务，使用算法代理

——下单量分段总时间（秒数）：该参数与下单量分段数配合使用，比如，分段数10，总时间3600 秒，相当于将总下单量分成10份，每隔360秒启动一个任务（这里也可以把一个任务等同于策略的一个信号）。

可以看出来，手动下单的算法代理，相当于一个大的 TWAP分段+多个小的算法代理， 默认参数不分段。

最后，介绍一下与算法代理配套的滑点的统计工具。

滑点的计算是通过成交价与理论价比较而得，对于策略信号，理论价等于信号价，对于手动下单，理论价等于下单时的对手价。TBQuant平台可以对每一次委托和成交的滑点大小进行实时监控，也提供了对当日滑点的合计统计，共三个模块提供滑点的监控与统计，具体如下：

——委托成交（账户透视）

——策略运行管理

——策略监控器

从上面的讨论看出，算法代理有点复杂，但系统自带的三个算法代理，已经设置好了比较实用的默认参数，用户可以非常便捷的直接使用。这里归结为 2 步使用算法代理，第一步在用户的策略单元添加发送器策略TodayPosSender，第二步，在算法代理模块，启动选择使用的代理。

综上所述，算法代理作为一种订单策略，其目标是找到一个概率优势，利用价格的噪声， 降低交易成本。那么到底有没有优势，这个需要对订单策略进行测试，以衡量其有效性。由于订单策略用的都是高频数据，而且都与盘口成交撤单有关，因此CTA 策略测试的方法对于订单策略来说是无效的。目前的TBQuant量化平台，还不能提供对于订单策略的历史测试，但投资者还是可以借助TBQuant模拟账户，采用模拟交易，对其进行测试。

大家可能有一个疑问，模拟账户的挂撤单及成交条件能与真实交易环境一样吗？这个就关系到模拟账户的设计问题了，TBQuant模拟账户，其设计思路是模拟真实账户成交，笔者使用该模拟账户时，对比了真实行情，应该完全能够满足订单策略的测试需求。尽管如此，模拟账户只能对参数进行单次运行，无法回测，与策略测试的需求还有差距，因此，我们期待TBQuant的Tick级别回放测试早日实现。

关于上述的几个订单策略，虽然比较复杂，但都是用TB策略语言实现的，用户完全可以根据成交和盘口的统计分析来自制定不同的委托节奏，实现自己独立的算法，甚至还可以做成短期的方向判断和时机选择，这个其实也就是高频交易策略。

说到高频交易策略，一般就与计算机编程联系起来，这让非IT专业的人员望而却步，但有了TB策略语言，可以让高频交易策略的编程门槛大幅减低，有兴趣朋友完全可以对TB策略语言更进一步的了解，实现属于自己的高频交易思路。