一个可维护的 TqSdk 策略至少要把行情更新、信号计算、目标生成、执行管理和状态核对分开。最小闭环不是“均线上穿就下单”这一句而是每根有效数据只计算一次、目标只在变化时更新、委托由单一入口管理、成交后持仓能够与目标对账、异常时停止新增风险。先把纯计算函数独立出来信号函数只接收固定数据不创建 API、不读取账户也不下单。这样同一函数可以用小样本测试、在回测中调用也能在实时循环使用。def moving_average_signal(closes, short5, long20): if len(closes) long: return 0 short_ma closes.iloc[-short:].mean() long_ma closes.iloc[-long:].mean() if short_ma long_ma: return 1 if short_ma long_ma: return -1 return 0返回值只表达方向示例不代表完整盈利策略。窗口、交叉确认、退出条件和重复信号都需要按真实规则定义。纯函数的价值是输入与输出清楚计算错误不会和网络、账户问题混在一起。行情层只在正确事件上触发策略若按一分钟收盘判断就订阅足够长度的 K 线在末行datetime变化时使用已完成数据。当前末行仍在形成不应提前当成收盘值。import os from tqsdk import TqApi, TqAuth, TqSim, TargetPosTask symbol SHFE.rb2610 sim TqSim(init_balance100000) api TqApi( sim, authTqAuth(os.environ[TQ_USER], os.environ[TQ_PASSWORD]), ) klines api.get_kline_serial(symbol, 60, data_length50) position sim.get_position(symbol) executor TargetPosTask(api, symbol, priceACTIVE) last_target None try: while True: api.wait_update() if not api.is_changing(klines.iloc[-1], datetime): continue closed klines.close.iloc[:-1] signal moving_average_signal(closed) target signal if target ! last_target: executor.set_target_volume(target) last_target target print(目标, target, 当前持仓, position.pos) finally: api.close()代码使用本地模拟账户并把方向直接映射为一手目标仅用于骨架演示。正式策略要把风险预算、合约有效性、交易时段和退出规则放在目标进入执行器之前。目标层把信号翻译成账户意图信号为一不一定等于目标一手。目标手数可能取决于账户资金、合约风险、当前持仓和组合限制。应有独立函数把信号转换为目标并返回拒绝原因。def build_target(signal, risk_ok, unit_size1): if not risk_ok: return None, RISK_BLOCKED if signal not in {-1, 0, 1}: return None, INVALID_SIGNAL return signal * unit_size, OK返回None表示本轮不允许改变目标不等同于目标零。零是明确空仓意图二者必须区分。否则风险检查失败时程序可能意外发出平仓目标。目标也要带信号时间和规则版本。执行前发现行情已经过期或规则已切换就应丢弃旧目标。只传一个整数会让后续无法判断它为何产生。目标函数还应保持确定性相同信号、账户快照和配置得到相同结果。若函数内部读取随时变化的全局变量回测复现与实时排错都会变得困难。需要动态风险数据时把它作为显式输入并记录时间。组合策略中单合约目标还要经过账户级汇总。每个信号分别看都合规合在一起可能超过资金或方向限制。先生成候选目标再由统一风险层批准避免各合约自行占用同一份预算。执行层必须只有一个订单入口示例使用 TargetPosTask 后不再对同一合约调用insert_order。若改为手工订单管理也应由一个执行组件负责创建、撤销和跟踪订单。多个信号函数不能各自直接下单。执行层读取当前持仓、活动委托和目标差额记录每个动作的业务标识。目标未完成时新信号如何处理需要明确覆盖旧目标、排队还是先取消再评估。没有规则就会产生重复订单。成交后执行层更新账户事实不反向修改信号。信号解释市场判断成交解释实际执行两者分开才能看出偏差来自策略还是交易过程。执行动作也需要幂等边界。相同业务标识被重复提交时执行层应识别已有目标或活动委托而不是再次创建订单。网络重试、任务重启和重复行情事件都可能让同一请求到达两次防重复不能只依赖上游。当目标被新目标覆盖时先记录覆盖关系再决定撤销旧委托还是等待完成。没有明确策略时最安全的是停止新增动作并核对当前账户而不是同时追赶两个目标。状态核对让闭环真正结束每次目标变化后至少要核对订单状态、成交记录、持仓和资金。持仓等于目标但仍有活动委托时任务尚未完全安全订单结束但持仓不符时也不能直接重发。可以为一次目标建立状态序列已产生、已通过风险检查、已交给执行器、出现订单、出现成交、持仓达到目标、活动委托归零。每一步都保留时间和关键标识。程序重启后从账户读取持仓与订单再结合最后目标恢复。内存中的last_target会丢失不能因为它恢复成None就再次提交同一动作。日志与配置怎样支撑复现配置保存合约、周期、窗口、手数上限和账户环境不保存凭据。启动时校验每个参数并输出非敏感摘要。任何默认值都应明确不能因缺少配置静默切换到实盘或另一合约。日志按事件记录而不是每轮打印全部对象。新 K 线、信号变化、目标变化、风险拒绝、订单变化、成交和退出各有清楚类型。看到最终持仓时可以沿标识回到产生它的信号。同一策略在回测和实时模拟中尽量复用计算与目标函数只更换数据推进和账户环境。若两边各写一套条件结果差异很难解释。测试也按层进行。计算层用固定表格验证边界目标层用不同信号和风险状态验证输出执行层在模拟账户测试未成交与撤单整合层再跑完整事件循环。分层测试能在最终持仓错误前找到更早的原因。每层输出都保留最小定位数据时间、信号标识、目标标识、订单标识。它们不是给读者看的复杂流程字段而是让运行中的一次动作能够从结果回到来源。策略骨架的适用边界这份骨架没有处理复杂开平、换月、多账户、多合约组合和真实交易成本也没有证明均线规则有效。它只展示职责如何连接。任何新增功能应放进对应层而不是直接塞进主循环。高频数据或耗时计算可能需要异步任务或外部进程但先保证单循环版本正确。并发不会修复错误状态只会增加重现难度。进入实盘前必须在回测与实时模拟分别验证并主动测试异常、重启和未成交场景。能运行一段时间不报错只说明顺利路径没有立刻失败。最小闭环清单数据只在定义好的事件更新计算函数不接触 API 与账户。信号经风险和仓位规则转换为目标None与零目标含义分开。同一合约只有一个执行入口目标、订单、成交与持仓可追溯。重启从账户事实恢复日志和配置足以复现每次目标变化。回测、模拟与异常演练通过后才评估受控实盘验证。策略骨架的价值是让每个问题都有固定位置。行情不对查数据层信号不对查计算层手数不对查目标层持仓不对查执行与核对层。边界清楚后策略复杂度增加也不会把所有错误挤进同一个循环。