期货量化策略改代码要停机吗：天勤发版与进程重启边界

前言国内期货量化策略本质上是一个长时间运行的 Python 程序根据 K 线或 tick 算出「目标持仓几手」再通过天勤量化TqSdk连到期货公司或模拟账户去执行。策略不会一写好就永远不变——你会改均线周期、换交易合约月份、调风控阈值、修 bug。这种「换一版程序」叫发版。有人希望像网站一样「热更新」程序不停机改一行配置就生效有人习惯夜盘结束或周末停机替换代码后再开盘。天勤的程序结构和普通脚本不同核心是TqApi长连接每个交易合约通常只有一个TargetPosTask实例负责调仓K 线订阅缓冲绑在进程里。不是所有改动都能在持仓运行时在线生效不懂这一点可能在还有持仓时改了offset_priority行为混乱或叠了两个TqApi连接。下面按改动类型说明什么必须重启进程、发版时持仓怎么处理。一、先弄清几个名词名称是什么和发版的关系发版部署新一版 Python 代码或配置可能需停机TqApi天勤主连接订阅与交易入口一个进程宜一个实例换版常close()后重建api.close()释放连接发版前正常退出用TargetPosTask自动把净仓调到目标的工具创建时定price、offset_priority等事后难改get_kline_serialK 线订阅改合约或 data_length 常需重订state 文件自建 JSON记 last_bar 等新进程可读但与内存变量要一致systemd/supervisorLinux 进程守护崩溃可拉起换代码应 stop→替换→startVERSION策略版本号日志里标记哪版逻辑下的单二、为何天勤策略多数要「停机发版」绑在进程上的内容为何难热更新TargetPosTask单例同一 symbol 不能事后改 price、offset_priority、min_volume/max_volumeTqApi连接状态改环境常需 close 重建K 线订阅改 symbol、周期、data_length 需重新订阅内存里的变量新逻辑与旧 state 可能矛盾官方文档同一合约勿用不同参数重复创建TargetPosTask否则会抛异常。三、改动分类什么可以什么不可以改动内容建议方式均线周期、信号阈值、日亏线停机或代码实现「每根新 K 线重新读 config」且不改 task 构造参数交易合约月份如 rb2510→rb2511停机并走移仓平旧月、对新月建 taskACTIVE/PASSIVE、offset_priority必须停机新建TargetPosTask日志路径、钉钉 webhook若写了 reload_config 可热更否则停机信号逻辑 bug 修复停机回测和模拟验证后再上实盘「热更新」在期货实盘里风险高持仓还在、旧 task 还在发单新逻辑已算出新目标容易乱。四、推荐发版流程有持仓时尤其要遵守选成交清淡时段如白盘午休、夜盘结束后。记录当前各品种get_position().pos、在途ALIVE委托。程序内api.close()正常退出或由 systemdstop。替换代码与配置文件检查.env中合约月份、MODE 是否正确。守护进程start拉起新进程。启动后先多次wait_update()读 position、order、account 全量对账再恢复自动交易。勿在复杂持仓时kill -9且不对账否则新进程可能带着错误假设set_target_volume。五、VERSION 与守护进程的区别日志第一行写VERSION1.2.3state JSON 里也写version事后复盘能对应「这笔单是哪个版本的逻辑」。Restartalways适合进程崩溃自动拉起不等于「不停机换代码」换代码应明确 stop → 部署 → start。总结期货量化策略发版在国内实盘环境下多数应视为停机发版凡涉及TargetPosTask创建参数、订阅合约、核心信号逻辑的改动都不适合在持仓运行中在线替换。天勤靠wait_update驱动交易进程边界就是一致执行边界。把发版窗口、对账步骤、VERSION 标记写进运维习惯需要明确的是不是改完 py 文件就立即生效而是 close、部署、拉起、对账的完整闭环。FAQ1只改一个均线数字要重启吗若只改 config 且程序每 bar 重读、且不涉及 task 参数可能不必若改的是 task 的 price/offset 等必须重启。2Docker 换镜像算啥等同停机state 文件用数据卷挂载保留。3在 Jupyter 里改策略须 restart kernel 并api.close()否则会叠连接。4双机热备两台同时跑同一资金账户不能两个进程同时自动报单。风险提示以上内容用于发版流程参考不构成投资建议。