库卡c2程序调用_海龟交易实盘记录 2020-12-24 海龟系统程序化

从2020年7月25号读完《海龟交易法则》第一次用它的思想来实盘交易开始，刚好已经五个月过去了。这五个月我已经熟悉了海龟系统的方方页面，账户权益也从 40w 到了 60w （外加出金 4w)。11月初始报名参加了水木论坛期货版的实盘大赛，更是从与其它选手的交流中获益匪浅。

最近一个月的主要业余时间都花在写代码把海龟系统程序化上了，听起来简单，做起来固然不太难，但有很多细节需要抠。下面就写一下这个过程中的一些思考和体会。

软件选择

国内市场上期货量化交易的软件有很多，我使用的是快期公司的天勤量化（tqsdk), 基于 python。

在此之前，我也评估过几个不同的技术选项：

• 文华财权的WH软件：使用文华自己的“麦语言”
• vnpy：开源的 python 项目, 但需要自己向期货公司申请穿透测试
• 天勤量化 (tqsdk)：快期公司出品，基于 python

文华财经的麦语言首先就被排除了，因为它是一个封闭的系统，写的代码离开这个平台就没有任何价值了。

在对比了 vnpy 和天勤之后，我还是选择了天勤。主要是两个原因：

• 我的开发机器是 mac, 而 vnpy 对 mac 的支持不太好。
• 天勤的行情可以随时从服务器上获取，这样回测非常方便（回测是付费专业版的功能，我是申请了15天的试用）。

架构设计

整个程序分为两层：策略层(policy)和引擎层（engine)。

• 策略层：根据引擎层传递来的信息，决定开仓、加仓、止盈、止损。这一层是与 tqsdk 无关的。
• 引擎层：接受策略层的指令，使用 tqsdk 来获取行情、进行交易。

这样分层最大的好处是策略层可以单独做单元测试，从而能快速地迭代开发。如果两层搅合在一起，策略层任何一个小的改动都需要启动回测来进行测试，效率将非常低。并且通过分层，策略层的实现将是平台无关的，将来如果要迁移到其它平台，甚至用到外盘期货都比较简单。

程序状态

其实整个海龟策略其实就是一个状态机，或者说每个品种是一个状态机。状态机的核心就是这个公式：

下一个状态 = f(当前状态 , 检测到的事件)

我的程序中为任何一个品种定义了以下状态:

• c0: 没有仓位
• c1: 20日突破，建仓一个单位
• c2: 继续突破 0.5N, 加仓一个单位
• c3: 继续突破 0.5N, 加仓一个单位
• c4: 继续突破 0.5N, 加仓一个单位
• closing: 止损或者止盈，平仓中
• closed: 已经平仓、出场

定义了这些事件:

• hh20-breakout (20日向上突破，多头建仓)
• ll20-breakout (20日向下突破，空头建仓)
• h-breakout (向上突破指定的价位，多头加仓)
• l-breakout (向上突破指定的价位，空头加仓)
• ll10-breakout （反向10日向下突破，多头止盈）
• hh10-breakout （反向10日向上突破，空头止盈）

每个事件都有自己的附加信息，比如 hh20-breakout 会附加上该品种的当前价位、当前 ATR 等必要信息。

举例来讲，C2105 合约，引擎层告诉策略层: 合约 C2105 发生 hh20-breakout 事件，那么策略层将 C2105 合约的状态由 c0 转换到 c1。

每个状态对应一个仓位 c1 对应 1 个海龟头寸单位（3张玉米）, c2 对应 2 个海龟头寸单位, closing 对应 0 个单位，等等。

策略层只需要告诉引擎层：该品种当前的仓位应该有 X 手持仓(由状态决定），而不必关心引擎层是怎样调整持仓到 X 手持仓的。这里也是 tqsdk 一个非常强大的地方，它提供的辅助类 TargetPosTask 就是专门做这事儿的，直接拿来就能用。

策略层根据当前的状态，告诉引擎层两个信息：一是要监控哪些信号，二是要持有哪些仓位。

新的状态 = f(当前状态, 检测到的价格信号)
要监控的信号 = f(当前状态)
要持有的仓位 = f(当前状态)

仓位控制

引擎层每次将事件返回给策略层时，同时也把当前账户的情况一并传递给它。比如当前账户权益 50w, 其中保证金 30w。

策略层在保证金占用超过 80% 时不再开仓。即使有新的20日突破信号也不会再处理。

关联品种总仓位控制

根据我之前统计的各个品种的关联性，我把它们分为了三类:

• 强关联的品种：这些品种同一方向上的持仓加起来最多不超过 4 个单位，比如豆粕和菜粕，塑料和PP，玉米和淀粉
• 较强关联：加起来持仓最多不超过 5 个单位，比如金银、热卷和螺纹，PTA 和燃油。
• 松散关联：加起来持仓最多不超过 10 个单位，主要是 PTA/燃油/低硫燃油/沥青/EG 这一组。

当某一组关联品种总持仓达到上限后，即使有新的突破加仓信号，也不会再加仓了。

一个需要思考的小细节是：如果今天因为仓位控制导致了某个突破的品种没有开仓，第二天有仓位了（比如其它品种止盈或者止损了），还要补开昨天突破那个品种吗？我的策略里还是会的，毕竟海龟最怕错过大行情。当然这种情况其实本身就很罕见。

移仓换月

策略层只会做各个品种的主力合约，并且在主力合约切换后马上启动换月。

换月的检测：主力合约切换是通过让引擎层监控 "main-changed" 信号实现的。tqsdk 提供了某个品种当前主力合约的具体合约。

在策略这个层面，换月的过程就是把老合约的状态转换到 "closing", 并且为新的合约创建出对应的状态。

当需要换月时，比如从老合约 C2101 换月到 C2105:

• 老的状态: C2101=>c3 (9 手), C2105=>c0 (0 手)
• 新的状态：C2101=>closing(0 手), C2105=>c3 (0 手)

然后引擎层就会自动平仓老的合约平仓，开仓新的合约。

关于开平的先后顺序，我的代码中是不控制的。知乎上有一篇不错的文章讲这个讲得很好：天启大烁哥：期货交易，最“完美”的换月方式是什么？。简单来说就是：单次的换月可能存在一个最优的选择，但是长期来看，一直坚持先开后平或者先平后开的话，其优势或者劣势会在平均之后趋于零，所以并不重要。

回测

天勤的回测非常方便，开通专业版试用之后就可以用了，90% 的代码基本上都不需要改变。

唯一的问题是：天勤在回测时不能告诉你知道当时的主力合约是什么、以及主力合约是什么时候变化的。我咨询了天勤的技术支持和产品经理，他们也暂时没有解决的方法，不过将来会解决这个问题的，并且回测的速度还会进一步优化。

所以我用另一个工具库 Tushare 来获取了各个品种主力合约的历年变化的数据，这样在回测时就能根据当前历史时间点知道当前的历史合约是什么，以及什么时候发生的主力合约切换。

下面是一些以 50w 为初始资金的回测结果。

2016年3月到 2019年6月。2016年是趋势大年，整个文华指数都上涨了 50%，2017年还行，2018/2019 年就很一般了。

2019年6月 到 2020年12 月的回测。蓝线是N值始终为 1k, 黄色是N值随着账户权益增加而增加(最大2k)。可以看到到20年3月底的时候几乎回撤了 20w。整个2020年是近几年来的最大趋势年份，海龟账户可以实现翻一倍多。下一次这么好的行情可能又得等到几年之后了。

人工干预

计算机自动化擅长做机械化、重复、准确的事，但是投机交易的决策有时是需要灵活应变的。因此这个程序化系统必须能够允许手工干预，在手工干预之后仍然能够合理地运行下去。

手工干预的场景：

1. 觉得仓位太重了, 需要手动降低仓位。 虽然有关联品种控制的算法, 但是有时可能整体仓位太高, 需要手动平一些。
2. 一些因为关联控制或者总仓位控制而错过的开仓的品种, 希望手动开仓或者加仓。
3. 希望提前换月, 比如有时远月品种要强一些。

所以我在代码中提供了一些辅助函数，专门手工来更改持仓状态。我的整个程序是 clojure 写的 (使用 clj-python/libpython-clj 来调用 python), 可以远程连接到运行中的程序上去，执行任意代码。

当然这也意味着不能再通过文化财经去手动操作了，否则会与程序的操作相冲突。

代码测试

策略层写了很多单元测试，覆盖到了每个细节。总共 5k 行 clojure 代码, 策略层写了很多单元测试，覆盖到了上面提到的每个方面的细节，测试代码共 1.5k 行。

引擎层的测试就是跑回测，以及用天勤提供的快期模拟账号来运行。

布署和运行

整个程序运行在一台 linux 服务器上，每天上午、下午、晚上开盘前10分钟自动重启一次程序（每天重启是天勤官方推荐的最佳实践）。后面考虑再加一个监控和报警进去。

数据库每半小时备份一次到 OSS 中。如果状态没有变化就不备份了。

新的开始

从 2020.7.25 开始到今天 (2020.12.24)，五个月的手动交易之后，从今天晚上开始，整个交易就完全由程序负责了。平安夜，希望一切平安，没有 surprise :)