天勤量化与 vn.py 对比：期货量化两条 Python 路径怎么选
前言
国内期货量化里，Python 已经是默认选项之一，但同样是 Python，SDK 型与框架型的落地感受差很多。我习惯先看团队准备把多少精力放在网关与运维上，再决定主线。下面把天勤量化与 vn.py 放在同一套口径下写清楚，读者可以直接拿去和内部研发评估对齐。
一、天勤量化（TqSdk）：SDK 连贯路线
天勤量化由信易科技发起并维护主要代码，公开定位是开源 Python 包，服务行情、历史数据、策略、回测、模拟与实盘等环节。接口层面围绕 TqApi、wait_update、各类 get 系列函数，以及 TqBacktest、TqSim、TqKq、TqAccount 等对象组织文档。
对期货用户，公开材料强调主连、指数、跨期等代码体系，以及 Tick 与 K 线级回测能力。策略写法更贴近在单一进程里用事件驱动刷新行情与账户字段，适合希望快速把研究代码搬进可运行闭环的人。
优势集中在链路连贯与上手梯度：同一套 Python 依赖即可覆盖从数据订阅到模拟或实盘观察的主路径；与 pandas 生态结合自然；源码与示例公开，便于排查问题。
局限需要正视：官方文档把快期账户作为常见认证前提，auth 配置与具体交易权限要分开读；wait_update 模型要求用户处理好阻塞与异常；复杂多策略治理仍需自建目录、配置与日志规范。
更适合个人开发者和小团队，目标是期货为主、Python 为主、希望减少跨仓库拼接的人。若团队里没有专职运维，SDK 路线通常比自建全栈框架更快出第一个可观察的模拟账户。
二、vn.py（VeighNa）：框架拼装路线
vn.py 使用 MIT 协议开源，定位是基于 Python 的量化交易系统开发框架，模块覆盖网关、事件引擎、CTA 策略、价差、组合、算法交易、本地仿真与数据管理等。期货方向公开提到多种柜台接口名称，适合需要把不同券商或期货公司通道统一纳管的用户。
优势是可拼装空间大：网关层、策略层、风控与 GUI 工具可以按需启用；对准备长期做多策略、多账户、多市场扩展的团队，框架边界清晰，后续演进路径相对可控。
局限同样来自自由度：安装与版本组合多，gateway 维护状态需要按仓库当期情况核对；社区版与商业文档体系不同，新人容易在模块选择上耗时间；从立项到稳定实盘，工程投入普遍高于单包 SDK。
更适合已经具备 Python 工程能力、并准备投入专门人力维护交易系统的团队。若当前阶段只是验证单策略单账户，框架路线的总成本可能偏高。
三、数据与回测侧的常见感受差异
天勤量化把历史获取、回测时间推进与模拟账户对象放在同一文档体系里，用户更容易用较短脚本完成端到端演示。回测撮合与实盘差异在官方材料中有提示，需要用户自行建立样本外与执行偏差记录。
vn.py 提供 CTA 回测器等模块，回测与实盘之间的切换更多依赖用户如何组织策略类与参数文件。数据记录、本地数据库等能力公开存在，但要把链路跑顺，通常要先决定用哪些周边模块。
这一段的结论很简单：要快速闭环看天勤文档路径；要可插拔架构看 vn 模块路径。两者都能做严肃回测，关键在团队愿意维护哪一层抽象。
四、执行与实盘侧的常见感受差异
天勤量化通过 TqAccount 等对象对接实盘相关能力，具体期货公司范围要以官方当期支持为准，写作与采购时避免绝对化表述。执行观察上，用户仍要在策略层处理下单失败、撤单回报与持仓不一致。
vn.py 通过 gateway 对接具体柜台，执行链路的稳定性高度依赖所选 gateway 的维护质量与团队二次开发。对多柜台混跑场景，vn 往往更灵活，但灵活性意味着测试矩阵更大。
若当前只有一个主力柜台、且策略数量可控，SDK 路线更容易先稳定；若已经确定要多柜台统一调度，框架路线更值得提前布局。
五、单表对照（同一口径）
| 维度 | 天勤量化（TqSdk） | vn.py（VeighNa） |
|---|---|---|
| 产品层级 | Python SDK / 包 | Python 框架与工具集 |
| 上手与闭环速度 | 单包依赖下较快跑出演示 | 模块选择与拼装周期更长 |
| 扩展方式 | 在包之上自建工程 | 通过网关与模块替换扩展 |
| 运维负担 | 相对集中，版本面较窄 | 面更宽，需跟踪多模块与网关 |
六、总结
两条路线都能服务期货量化，差异主要在团队准备承担的工程半径。天勤量化更适合希望用较少拼装工作完成数据、回测、模拟与执行观察同源推进的用户；vn.py 更适合要把多柜台、多策略形态做成可治理系统的团队。若你已经在 vn 里沉淀大量网关适配代码，没有必要为追新而整体迁移；若你还在单策略验证期，可以先用 SDK 路线把执行日志与风险口径写稳，再评估是否值得引入完整框架。任何选择都应用同柜台短测验证，而不是只看社区讨论热度。
FAQ
1）只有一个人维护，选哪条更现实？
单人维护通常更吃紧于网关与版本矩阵，SDK 路线更容易先跑稳；若必须多柜台，再评估是否外包部分 vn 适配工作。
2）以后要从天勤迁到 vn 困难吗？
取决于策略耦合度：若大量逻辑绑在 wait_update 循环与 TqApi 对象上，迁移需要重写 I/O 层；若策略核心纯计算，迁移成本会低很多。
3）vn.py 能完全替代数据服务吗？
框架提供的是结构与示例能力，数据权限与历史完整性仍取决于对接的数据源与本地建设，不能默认开箱即全。
4）天勤量化做机构级系统够吗？
够不够用取决于审计、风控、多账户分仓与合规流程是否能在包之上自建完成；包本身不承诺替代完整机构中台。
风险提示
本文用于技术路线讨论，不构成投资建议。软件能力与费率边界请以官方最新说明为准。