自动化跑单的三个失败模式:断线、限频、参数漂移

把策略交给程序自动跑,真正让人吃亏的地方往往不是策略本身,而是运行时:程序还在跑,但它已经不在做你以为的那件事。这类问题集中在三个地方——断线、限频、参数漂移。三个里前两个会报错,第三个不会,所以第三个最贵。下面一个个拆开,最后给三条能立刻用上的运行纪律。

策略的对错,和程序的死法,是两件事

回测里没有网络。没有请求超时,没有接口拒绝你,没有"这段行情跟你调参数时长得完全不一样"。这三样实盘里全都有。

所以一个跑单程序的失败可以分三层看:

• 策略层错——你的想法本来就不成立。这一层回测能查出一部分。
• 执行层错——单没下出去、下错了价、滑点比预想大。这一层至少有痕迹,查日志能对上。
• 运行时坏——程序活着,进程没退,日志还在滚,但它的状态、它的配额、它的参数,已经跟真实世界脱节了。

第三层最难,因为它不长得像故障。这篇只讲第三层。

断线:委托单还在,做决策的那个东西没了

先把最容易搞混的一点讲清楚:已经挂在平台上的委托单,不会因为你掉线而消失。它们躺在平台的撮合系统里,不在你的程序里。价格到了照样成交,条件触发了照样触发。这一点让很多人松一口气,然后松错了地方。

因为断线真正切掉的是另外一半:你的程序收不到成交回报、发不出新指令、算不出新信号。所以有一句话值得记住——"仓位安全"和"策略安全"是两回事。仓位可能一直好好在那儿,但管这个仓位的大脑离线了。

最坏的一种配置是止损写在你自己的程序里,靠程序判断价格再发平仓单,而不是提前挂到平台上。这种情况下断线等于止损直接消失,行情往反方向走的时候没有任何东西接得住。能挂到平台上的保护性委托,就别留在本地逻辑里。

还有一个坑在重连之后。程序恢复了,但它内存里那份状态停在断线前那一刻:它以为某个挂单还没成交,其实早成交了;它以为自己空仓,其实已经有仓位。接着它会基于这份错的前提继续下单,而且一路不报错。

限频:最常见的死法是自己把自己撞进去

接口都有调用频率上限,超了轻则请求被拒绝,重则被临时限制一段时间。具体多少次、按什么窗口算、不同接口权重怎么分,各家不一样,同一家不同接口也不一样——以你实际在用的那份接口文档为准,别抄别人文章里的数字,那类数字过期得很快。

需要注意的是,正常运行时撞限频的其实不多。真正把人撞进去的是出错之后:一个请求失败,程序立刻重试,又失败,再立刻重试……一个循环几秒钟就能把配额烧干净。然后你到了最需要撤单的那一刻,发现撤单请求也发不出去了。

这条路径的可怕之处在于它会放大:本来只是一次网络抖动,被重试逻辑变成了全面失联。小故障升级成事故,中间那一步就是限频。

正当的做法是退避重试(backoff),几个要点:

• 失败后不要立刻重试,先等一小段时间。
• 连续失败就把等待拉长,常见做法是每次把间隔翻倍。
• 在间隔上加一点随机抖动,免得多个程序或多个循环卡在同一个节奏上,一起重试、一起再失败。
• 设一个上限:连续失败到一定次数就停下来报警,交给人处理,不要无限重试。

另外把请求分个优先级。查行情失败了可以慢慢退,撤单、平仓这类"救命"请求得留出余量。别让一个高频轮询行情的循环,把你在关键时刻要用的那点配额吃光。

参数漂移:不报错,只是安静地不再合适

网格的上下轨和间距、趋势策略的周期长度、止损用的百分比,这些参数都是在某一段行情里调出来的。调的时候你没说出口、但确实做了的假设是:接下来的波动会跟当时差不多。

行情换了状态,这个假设就不成立了。可是没有任何东西会告诉你。程序不报错,接口返回一切正常,日志一片干净,它只是按一套不再合适的参数继续下单。前面两种失败至少有信号——断线有报错、限频有拒绝——漂移一个信号都没有。

它露出来的形状通常很含蓄,得你主动去看才看得见:

• 成交频率和你当初设参数时的预期明显对不上,要么半天不动,要么疯狂来回。
• 区间类策略的价格长期贴在一侧,另一边的格子从头到尾没用上。
• 单笔的盈亏比在变差:还在赚,但赚的和亏的比例已经不是原来那样了。

处理办法不是"修",是"回看"。给自己定一个固定节奏,到点就把这段时间的实际成交拉出来,和当初设参数时的假设并排比一遍:波动幅度变了没有?成交频率变了没有?价格还在你划的那个区间里吗?

至于多久回看一次,各人的策略节奏差得远,没有一个通用数字可抄。要紧的是这件事真的有人做,而不是永远排在"有空再说"里。

三种放一起看,区别在"有没有信号"

把三种失败并排摆一下,你会发现真正决定它们难度的不是后果大小,而是会不会主动告诉你:

失败模式	有没有报错	你靠什么发现	最坏的情况
断线	有	日志断掉、心跳超时、收不到回报	本地止损失效,仓位裸奔;重连后拿旧状态继续下单
限频	有	请求被拒绝、返回错误码	最想撤单时撤不掉,小抖动升级成事故
参数漂移	没有	只能靠主动回看成交记录	长期安静地亏,等你发现时已经亏了一段

前两种可以靠工程手段兜住:加心跳、加告警、加退避。第三种没有工程解,只能靠一个人定期坐下来看。这也是为什么很多人程序写得挺扎实,还是在第三种上栽跟头——前两种有人提醒,第三种没有。

顺带说一句:这三种失败还有一个共同的上游,就是你的程序看到的行情本身可能就不对。数据源不同、价格口径不同、延迟不同,同一时刻会出现好几个"当前价"。用错口径的程序,哪怕运行时一点毛病没有,决策依据也是歪的。这部分单独写在 数据源、延迟与价格口径 里。

三条运行纪律

不复杂,但得在开跑之前就做,事后补往往来不及。

再补一条不算纪律但很省事的做法:让程序把关键状态定期落盘或者推到一个你能看到的地方——当前持仓、挂单数量、最近一次成功请求的时间。有这三个数,大部分故障你扫一眼就知道是哪一类。没有这三个数,你只能翻日志猜。

顺便提醒一句:如果你的策略灵感或者代码骨架是让 AI 帮着出的,那它给的参数和阈值只是起点,不是结论——原因写在 AI 给的交易建议为什么不能直接照做 里。

最后一句

自动化最大的好处是它不会累、不会手抖、不会半夜情绪化地追单。代价是它也不会觉得不对劲。人盯盘的时候,行情变得不对会本能地停手;程序不会,它会一直按你上个月的想法执行下去。

所以判断一套自动化靠不靠谱,别只看回测曲线,看这三个问题:它掉线会怎样、它出错会怎样、它的参数过时了谁来发现。三个都能答上来,再谈收益。

接着读:AI 工具看到的行情和你看到的不一样 讲数据源、延迟和价格口径;AI 给的交易建议为什么不能直接照做 讲模型本身的三个限制。想换个题材看具体实操,可以读 用 USDT 能不能买美股 和 不开券商账户怎么买美股。

本页不含推广链接,也没有邀请码;文中说的"平台""你用的那家"都是泛指,不指向具体某一家。本站的披露口径与免责说明见 商业披露 和 风险提示。