前言国内期货趋势量化程序的典型链路是天勤TqApi订阅螺纹钢 5 分钟 K 线双均线算出「目标净持仓 5 手」这一交易信号执行层调用TargetPosTask.set_target_volume(5)task 在后续每次api.wait_update()里向期货公司发单、撤单、对价改价柜台回报刷新到get_position(SHFE.rb2510).pos净持仓手数正为多、负为空。排查实盘时日志连续三天写着 target5但pos一直是 4 或 6差一两手对不齐。第一反应往往是「均线算错」更常见却是部分成交、场上还有statusALIVE的在途单、同一合约重复建了 task、或手写insert_order与 task 抢仓位。set_target_volume当下并不成交target 与 pos 短期不一致可以是正常现象。下面按天勤单例约束、调仓时序和排查顺序说明怎么区分正常过渡与真故障。一、先弄清几个名词名称是什么偏差排查里怎么用set_target_volume(n)告诉 task 目标净持仓手数只改意图不立刻成交get_position(symbol).pos柜台确认的净持仓真相正负表示多空TargetPosTask天勤自动调仓类在 wait_update 里执行wait_update()收行情与交易回报不调就不会推进 taskget_order()当前委托字典看在途 ALIVE 单volume_left委托剩余未成交量部分成交时大于 0status委托状态 ALIVE/FINISHED是否在途min_volume/max_volume大单拆分参数分批导致短期对不齐offset_priority开平顺序平今失败时 pos 卡住二、为什么 target 和 pos 可以短期不一致TargetPosTask文档写得很清楚set_target_volume当下不下单下单撤单发生在之后的wait_update()。因此下列情况属于正常现象刚调用set_target_volume(5)下一行就读pos仍是旧值。单子已报入交易所部分成交pos在 4 与 5 之间。启用了min_volume/max_volume拆分多帧wait_update才凑满目标。对价priceACTIVE追价时旧单撤完新单未成交中间有空窗。需要告警的是连续多个交易时段、无 ALIVE 单、无拒单而pos仍与 target 差值不变。三、天勤单例约束重复建 task 会埋雷target_pos_task.py里TargetPosTask用单例元类同一账户同一symbol只能有一个 task 实例。若用不同price、offset_priority、min_volume再建一次会直接抛异常。更隐蔽的是同一合约既用TargetPosTask又手写insert_order。文档明确禁止混用否则 task 内部状态与柜台持仓错位表现为 target 已改但 pos 长期不对或莫名多出一笔委托。排查时全局搜索该symbol是否只有一处TargetPosTask以及是否还有insert_order调用。四、推荐排查顺序api.wait_update()至少跑几帧确认不是读太早。读pos api.get_position(symbol).pos记target自己维护或 task 日志。遍历get_order()筛symbol相同且status ALIVE的项看volume_left与direction。若有拒单读last_msg开平、资金类错误会导致 task 停在某一手数。查是否拆分模式看创建 task 时的max_volume。多账户模式是否漏传account参数导致读到别的账户持仓。可落地的日志字段建议每次调仓记bar_datetime、target、pos、alive_volume在途剩余量之和、deltatarget-pos。deflog_pos_gap(api,symbol,target,logger):api.wait_update()posapi.get_position(symbol).pos alivesum(o.volume_leftforoinapi.get_order().values()ifo.instrument_idinsymbolando.statusALIVE)logger.info(pos_gap symbol%s target%s pos%s alive_left%s,symbol,target,pos,alive,)五、纠偏与恢复确认无在途单且pos仍不对时以get_position为准重置本地 state再set_target_volume到真实目标。若怀疑 task 内部错乱进程级重启停机、对账、重建TargetPosTask改创建参数必须重启见发版边界。不要连续狂调set_target_volume试图「催成交」容易触发报单频率规则。六、典型 last_msg 与偏差共存last_msg 关键词常见后果资金不足target 不变pos 落后非交易时段夜盘衔接误发单平今不足空头减仓卡住超过最大委托量部分成交拒单后若不读last_msg会误以为 task 还在正常追价。七、模拟与实盘偏差对比TqSim往往更快对齐实盘 ACTIVE 追价在波动大时可能反复撤单重报gap持续更久。应用同一套log_pos_gap在两种环境各跑一天建立「正常 gap 持续时间」基线。总结期货量化里目标仓与净持仓短期不一致多数是天勤TargetPosTask的正常过渡调仓在wait_update里分步完成部分成交和拆单都会拉长对齐时间。持续对不齐时按 pos、在途 ALIVE 单、last_msg、是否混用insert_order、是否重复建 task 这条链排查日志里同时记 target 与 pos比单看信号可靠得多。在TqSim或TqKq上把偏差场景跑一遍再挂实盘能少踩很多「以为程序坏了其实是成交慢」的坑。FAQ1差 1 手要不要强行补单先看在途单和部分成交无在途且拒单已排除再set_target_volume一次即可避免与 task 内部循环打架。2反手时偏差更大正常吗反手要先平后开中间帧pos可能经过 0 或反向属于正常用日志看全过程。3模拟盘会对得更齐吗TqSim成交模型更理想实盘偏差更大模拟对齐不能代表实盘一定对齐。4能否不用 TargetPosTask可以全程insert_order但要自己管开平和在途单工作量更大。本文基于天勤 TqSdk 公开 API 与源码整理不构成投资建议。实盘前请在仿真环境验证。
期货量化目标仓和净持仓对不齐：天勤 TargetPosTask 与 pos 偏差排查
前言国内期货趋势量化程序的典型链路是天勤TqApi订阅螺纹钢 5 分钟 K 线双均线算出「目标净持仓 5 手」这一交易信号执行层调用TargetPosTask.set_target_volume(5)task 在后续每次api.wait_update()里向期货公司发单、撤单、对价改价柜台回报刷新到get_position(SHFE.rb2510).pos净持仓手数正为多、负为空。排查实盘时日志连续三天写着 target5但pos一直是 4 或 6差一两手对不齐。第一反应往往是「均线算错」更常见却是部分成交、场上还有statusALIVE的在途单、同一合约重复建了 task、或手写insert_order与 task 抢仓位。set_target_volume当下并不成交target 与 pos 短期不一致可以是正常现象。下面按天勤单例约束、调仓时序和排查顺序说明怎么区分正常过渡与真故障。一、先弄清几个名词名称是什么偏差排查里怎么用set_target_volume(n)告诉 task 目标净持仓手数只改意图不立刻成交get_position(symbol).pos柜台确认的净持仓真相正负表示多空TargetPosTask天勤自动调仓类在 wait_update 里执行wait_update()收行情与交易回报不调就不会推进 taskget_order()当前委托字典看在途 ALIVE 单volume_left委托剩余未成交量部分成交时大于 0status委托状态 ALIVE/FINISHED是否在途min_volume/max_volume大单拆分参数分批导致短期对不齐offset_priority开平顺序平今失败时 pos 卡住二、为什么 target 和 pos 可以短期不一致TargetPosTask文档写得很清楚set_target_volume当下不下单下单撤单发生在之后的wait_update()。因此下列情况属于正常现象刚调用set_target_volume(5)下一行就读pos仍是旧值。单子已报入交易所部分成交pos在 4 与 5 之间。启用了min_volume/max_volume拆分多帧wait_update才凑满目标。对价priceACTIVE追价时旧单撤完新单未成交中间有空窗。需要告警的是连续多个交易时段、无 ALIVE 单、无拒单而pos仍与 target 差值不变。三、天勤单例约束重复建 task 会埋雷target_pos_task.py里TargetPosTask用单例元类同一账户同一symbol只能有一个 task 实例。若用不同price、offset_priority、min_volume再建一次会直接抛异常。更隐蔽的是同一合约既用TargetPosTask又手写insert_order。文档明确禁止混用否则 task 内部状态与柜台持仓错位表现为 target 已改但 pos 长期不对或莫名多出一笔委托。排查时全局搜索该symbol是否只有一处TargetPosTask以及是否还有insert_order调用。四、推荐排查顺序api.wait_update()至少跑几帧确认不是读太早。读pos api.get_position(symbol).pos记target自己维护或 task 日志。遍历get_order()筛symbol相同且status ALIVE的项看volume_left与direction。若有拒单读last_msg开平、资金类错误会导致 task 停在某一手数。查是否拆分模式看创建 task 时的max_volume。多账户模式是否漏传account参数导致读到别的账户持仓。可落地的日志字段建议每次调仓记bar_datetime、target、pos、alive_volume在途剩余量之和、deltatarget-pos。deflog_pos_gap(api,symbol,target,logger):api.wait_update()posapi.get_position(symbol).pos alivesum(o.volume_leftforoinapi.get_order().values()ifo.instrument_idinsymbolando.statusALIVE)logger.info(pos_gap symbol%s target%s pos%s alive_left%s,symbol,target,pos,alive,)五、纠偏与恢复确认无在途单且pos仍不对时以get_position为准重置本地 state再set_target_volume到真实目标。若怀疑 task 内部错乱进程级重启停机、对账、重建TargetPosTask改创建参数必须重启见发版边界。不要连续狂调set_target_volume试图「催成交」容易触发报单频率规则。六、典型 last_msg 与偏差共存last_msg 关键词常见后果资金不足target 不变pos 落后非交易时段夜盘衔接误发单平今不足空头减仓卡住超过最大委托量部分成交拒单后若不读last_msg会误以为 task 还在正常追价。七、模拟与实盘偏差对比TqSim往往更快对齐实盘 ACTIVE 追价在波动大时可能反复撤单重报gap持续更久。应用同一套log_pos_gap在两种环境各跑一天建立「正常 gap 持续时间」基线。总结期货量化里目标仓与净持仓短期不一致多数是天勤TargetPosTask的正常过渡调仓在wait_update里分步完成部分成交和拆单都会拉长对齐时间。持续对不齐时按 pos、在途 ALIVE 单、last_msg、是否混用insert_order、是否重复建 task 这条链排查日志里同时记 target 与 pos比单看信号可靠得多。在TqSim或TqKq上把偏差场景跑一遍再挂实盘能少踩很多「以为程序坏了其实是成交慢」的坑。FAQ1差 1 手要不要强行补单先看在途单和部分成交无在途且拒单已排除再set_target_volume一次即可避免与 task 内部循环打架。2反手时偏差更大正常吗反手要先平后开中间帧pos可能经过 0 或反向属于正常用日志看全过程。3模拟盘会对得更齐吗TqSim成交模型更理想实盘偏差更大模拟对齐不能代表实盘一定对齐。4能否不用 TargetPosTask可以全程insert_order但要自己管开平和在途单工作量更大。本文基于天勤 TqSdk 公开 API 与源码整理不构成投资建议。实盘前请在仿真环境验证。
