📑 本文目录
2026年A股量化工具横评：TqSdk、VnPy、RQAlpha与自建DuckDB四条路线，我为什么选了最难的那条
开篇：为什么2026年还在讨论”用什么工具做量化”
打开2026年7月初的知乎和CSDN，两篇量化工具盘点帖的阅读量仍然在持续走高。一篇是《2026最新A股量化平台盘点》，从学习、回测、实盘三个阶段拆解了QMT/PTrade、聚宽/米筐、RQAlpha/Hikyuu、Wind/Tushare四类工具在编程要求、回测精度、实盘速度、策略自由度上的差异；另一篇是《2026年Python量化框架盘点》，把TqSdk（天勤量化）评为新手首选，理由是全市场Tick和K线数据免费开放，把VnPy定位为适合深度定制的技术大牛的”瑞士军刀”。
这些盘点帖有价值，但它们有一个共同的盲区：几乎所有对比都停留在”功能列表”层面——列一张表，勾几个选项，然后告诉你”新手选TqSdk，大牛选VnPy，省钱选RQAlpha，省心选聚宽”。这种结论听起来很合理，但它回避了一个真正让多数人卡住的问题：当你真的拿着一个策略、一笔资金、一份时间预算走进这片工具森林时，到底该怎么选？
我之所以想认真回答这个问题，是因为我自己走完了这条路——从最早用Tushare/AKShare拉免费数据，到后来用pytdx从通达信服务器批量下载，再到现在用DuckDB搭了一个管理4589只股票、988只可转债、30只ETF、整个数据库只有294MB的本地量化系统。回头看来，选工具这件事不是”选最好的那个”，而是”选和你自己的约束条件最匹配的那个”——而约束条件里最关键的四个维度是：编程能力、资金规模、策略复杂度、实盘需求。
这篇文章就围绕这四个维度展开。我会先把四条路线画成一张全景图，然后用真实数据逐一拆解它们的”底盘”——数据从哪来、回测怎么跑、实盘怎么接、自由度有多大、隐性成本是什么。最后我会给出一张决策矩阵，并坦白我自己为什么最终选了”最难的那条”（自建DuckDB），以及这条路上的三大隐性代价。
一、四条路线全景图：你面前的不是四个工具，是四条哲学
A股量化工具生态，本质上可以归为四条路线。它们的差异不在”功能多寡”，而在**“谁掌控数据和逻辑”这个根本问题上立场完全不同**。
| 路线 | 代表产品 | 核心定位 | 目标用户 | ”掌控权”归属 |
|---|---|---|---|---|
| ①平台型 | QMT、PTrade、聚宽、米筐 | 一站式：数据+回测+实盘，浏览器即用 | 零基础/轻量化需求 | 平台掌控数据和逻辑 |
| ②框架型 | VnPy、TqSdk（天勤） | 本地化框架，封装好行情/交易/策略接口 | 有编程基础、追求定制 | 自己掌控逻辑，数据看框架 |
| ③回测型 | RQAlpha、Hikyuu、Backtrader | 纯回测引擎，事件驱动/向量化 | 策略研究者、论文复现 | 自己掌控一切，但不接实盘 |
| ④自建型 | DuckDB + Python + 数据采集脚本 | 从数据层开始全部自建 | 数据工程师/重度研究者 | 自己完全掌控每一字节 |
这四条路线的”哲学分歧”可以这样概括：
- 平台型的逻辑是”你把数据和策略交给我，我保证你跑得通”。它省心，但代价是你的策略逻辑、持仓数据、回测中间产物都存在平台的服务器上，平台改API、调价格、甚至关停，你都得跟着动。
- 框架型的逻辑是”框架搭好骨架，你自己填血肉”。VnPy和TqSdk提供行情接入、订单管理、风控模块的标准化封装，你写策略函数即可。掌控权回到你手里，但你需要会读框架源码、处理环境依赖。
- 回测型的逻辑是”我只管历史，不管未来”。RQAlpha和Hikyuu是纯粹的研究工具，它们专注于把回测做准（事件驱动、避免未来函数、支持多周期），但不负责实盘对接。
- 自建型的逻辑是”连骨架我自己都搭”。从数据采集（pytdx/akshare）到存储（DuckDB）到回测（自写引擎）到调度（cron），每一层都自己写。掌控权100%在自己手里，但每一层都要自己负责——包括出错时的排错。
理解了这四条哲学，你就能理解为什么”新手选TqSdk，大牛选VnPy”这种一句话结论是对但无用的——它没有告诉你”掌控权”的代价。下面我用真实数据逐一拆解。
二、TqSdk（天勤）深度体验：新手首选的底气在哪，边界在哪
知乎和CSDN的盘点帖里，TqSdk被评为”新手首选""同类最佳”，最大的卖点就一个词：免费数据。
TqSdk提供全市场的Tick和K线数据，免费开放，覆盖期货、股票、期权。
这在中低端量化工具里确实是稀缺的。多数免费数据源（akshare、tushare免费档）给的是日频OHLCV——开盘价、最高价、最低价、收盘价、成交量，一天一条。而Tick数据是逐笔成交，一天几万到几十万条。这个差距对日内策略、高频统计套利来说是质的区别，不是”数据多一点”，而是”能做的策略完全不同”。
2.1 数据质量：免费，但”免费”有边界
TqSdk的数据质量在免费层级里是过硬的，但有三个边界必须讲清楚：
边界一：历史Tick的深度有限。 免费版能拿到实时Tick，但历史Tick的回溯深度和品种覆盖有上限。如果你的策略需要跑5年以上的Tick回测，免费版可能不够，需要付费档或自己存数据。
边界二：数据口径需要自己核对。 任何第三方数据源都有”除权除息处理口径”的问题——前复权、后复权、不复权，三种口径算出来的回测收益可能差几十个百分点。TqSdk默认的口径需要你自己在策略层确认，不能想当然。
边界三：实盘对接需要期货/券商账户。 TqSdk的实盘交易接口对接的是期货公司（天勤背后是信弘资产，主打期货），A股实盘对接需要支持TqSdk协议的券商通道，不是所有券商都支持。
2.2 回测速度：够用，但不是最快的
TqSdk的回测是基于自己的事件驱动引擎，速度在中等量级——日线策略跑3年，几秒到几十秒；Tick策略跑1年，可能要几分钟到十几分钟。这个速度对个人研究者完全够用，但如果你要扫全市场5000只股票做因子回测（每只跑一次），TqSdk不是最优选择——向量化回测框架（如自建DuckDB + pandas）会快一个数量级。
2.3 和自有系统的对比
我用TqSdk能拿到Tick，但我自己的DuckDB系统用的是日频OHLCV（从pytdx/通达信采集）。差距在哪？我会在第四部分用自己的真实表结构详细说，这里先给结论：对于日频以上的中低频策略，自建DuckDB和TqSdk的差距不大；一旦你想做日内或Tick级策略，TqSdk的免费数据是巨大的节省。
三、VnPy：技术大牛的瑞士军刀，深度定制的代价是什么
VnPy在量化圈的地位很像Linux在操作系统里的地位——功能强大、完全开源、社区活跃，但门槛也真实存在。盘点帖里对它的定位是”适合深度定制的技术大牛”，这个判断基本准确。
3.1 VnPy强在哪
一是实盘接口覆盖最全。 VnPy的CTP接口（对接期货）是行业标杆，A股方面对接了多家券商的柜台系统，期权、外盘也有覆盖。如果你要实盘，VnPy几乎是开源框架里实盘能力最强的。
二是模块化设计。 VnPy把行情接入、策略引擎、风控、数据记录拆成独立模块（vnpy_ctp、vnpy_tts、vnpy_datamanager等），你可以按需安装。这种设计的好处是灵活性高，坏处是新手第一次配环境容易踩坑——装错模块版本、接口依赖冲突是常见问题。
三是社区和文档。 VnPy的GitHub有上万star，社区群活跃，遇到问题搜得到答案。这是开源框架最重要的”软实力”。
3.2 深度定制的代价
“深度定制”听起来是优势，但它的代价往往被低估：
代价一：学习曲线陡。 VnPy的策略基类（CtaTemplate）有自己的生命周期方法（on_init、on_bar、on_tick、on_trade），你需要理解它的事件驱动模型才能写好策略。这不是看两篇教程就能上手的，至少要花一两周通读文档和示例。
代价二：实盘对接需要券商支持。 VnPy的A股实盘接口需要券商开放对应的API（通常是券商的量化柜台，如华泰的matic、国泰君安的宽睿等），不是所有券商都支持，而且开户门槛（资金、权限）各不相同。
代价三：运维成本。 VnPy跑实盘需要一台稳定的服务器、稳定的网络、稳定的券商接口，任何一个环节出问题都可能导致策略停跑或订单异常。这就是为什么我在另一篇文章里专门讨论过”量化信号系统的健康监控”——一套不跑的系统，再准也等于零。
3.3 和自有系统的关系
如果有一天我要从DuckDB+日频升级到实盘Tick交易，VnPy能填补什么缺口？答案是：实盘订单管理这块，VnPy几乎是我唯一的选择（除非用商业平台）。我的DuckDB系统是纯数据+回测+信号，没有任何下单能力。VnPy的CTP/券商接口恰好补上这一块。所以我的判断是：自建DuckDB做研究，VnPy做实盘执行，两者互补而非竞争。
四、RQAlpha / Hikyuu：开源回测的天花板，以及一个关键问题
RQAlpha（米筐开源）和Hikyuu是两个专注于”把回测做准”的开源框架。它们不接实盘，只在历史数据上把策略跑得尽可能接近真实。
4.1 RQAlpha：事件驱动的严谨派
RQAlpha最大的特点是严格的事件驱动回测。它的设计目标是”避免未来函数、模拟真实撮合”，这意味着：
- 每一根K线到来时，策略只能用”截止到这一根之前”的信息做决策，不能用”这一根的收盘价”（因为实盘里你下单时收盘价还没发生）；
- 订单撮合模拟了涨跌停限制、停牌、最小价格变动单位，比简单的”按收盘价成交”更接近真实；
- 支持多周期（日线、分钟线）和多种标的（股票、基金、期货）。
对于做策略研究、写论文复现的人来说，RQAlpha的这种严谨是宝贵的。它的缺点是速度偏慢（事件驱动的天然代价），以及实盘对接需要自己另外搭（RQAlpha只管回测）。
4.2 Hikyuu：C++内核的极速派
Hikyuu走的是另一条路——用C++写核心引擎，Python做接口，主打”极速回测”。在向量化场景下，Hikyuu的速度可以达到事件驱动框架的几十倍。但它的学习曲线比RQAlpha更陡（文档相对少，API风格独特），更适合追求极致性能的研究者。
4.3 一个关键问题：我的信号系统迁移到RQAlpha能获得什么？
这是一个我自己认真想过的问题。我目前的CSI800信号系统（覆盖中证800成分股的每日技术信号扫描）和蓝筹v2系统，都是直接在DuckDB上用SQL+Python写的，没有用任何回测框架。如果我把它们迁移到RQAlpha，能得到什么？
答案是三样东西：
- 更严格的”无未来函数”保证——RQAlpha的引擎层面强制了时序，我自己写的话需要自己保证（容易出错）；
- 标准化的撮合模拟——我的系统目前是”信号触发即记录”，不模拟成交，RQAlpha能补上这一层；
- 可复现性——RQAlpha的回测结果是标准化的（净值曲线、夏普、最大回撤），方便和其他人对比。
但也有代价：迁移成本。我的信号系统深度耦合了DuckDB的SQL查询，迁移到RQAlpha意味着重写数据接入层。这是典型的”技术债”权衡——RQAlpha更规范，但当下重写不划算。
我的结论是：RQAlpha/Hikyuu是优秀的回测工具，但它们的价值在”策略验证”阶段，不在”信号生产”阶段。 信号生产用我自己的DuckDB+SQL更灵活，策略验证可以考虑引入RQAlpha做交叉校验。
五、自建DuckDB路线：我为什么选了最难的那条，以及三大隐性成本
终于到了我自己的路线。先说结论：自建DuckDB不是为了省钱，是为了完全掌控数据质量和信号逻辑。 省钱只是副产品。
5.1 用真实表结构说话：一个294MB的数据库能干什么
我的DuckDB数据库（quant_v2.duckdb）只有294MB，管理着：
| 数据维度 | 覆盖范围 | 存储方式 |
|---|---|---|
| 股票日线 | 4589只A股 | 每只一只股票一张逻辑表（按代码分区） |
| 可转债日线 | 988只可转债 | 同上 |
| ETF日线 | 30只主流ETF | 同上 |
| 总体积 | 294MB | 单文件，ZSTD压缩 |
这个数据库支撑了我日常的几套信号系统：
- CSI800信号系统：每日扫描中证800成分股，输出技术面买卖信号（RSI超卖/超买、均线偏离、布林带突破等），最新一次运行产出140只买入信号、34只卖出信号；
- 蓝筹v2系统：跟踪20只核心蓝筹的双轨信号（RSI + 布林带），最新输出显示白名单5只全部处于买入区间（中国石油RSI=23.5、招商蛇口RSI=6.3极度超卖）；
- 估值周报：每周计算全市场行业的PE/PB分位数，输出宏观评分（当前+4.5，连续6周偏多）。
这些系统的共同特点是：它们都建立在我对数据采集、清洗、存储每一层的完全掌控之上。我知道每一根K线是从通达信哪个服务器拉来的、经过了什么清洗规则、存储在DuckDB的哪个分区。这种掌控感是平台型工具给不了的。
5.2 数据采集：pytdx的真实成本
我的数据采集用的是pytdx（通达信数据接口），不需要账号，直接TCP连接通达信行情服务器。真实成本数据：
- 单只采集速度：约0.16秒/只；
- 全市场采集：4589只股票，单线程约12分钟完成；
- 增量更新：每天只下载最新数据，全市场约2-3分钟。
这里有一个大坑必须提醒：pytdx返回的是不复权数据。这意味着如果一只股票发生了分红或送转，它的历史价格不会自动调整——用不复权数据算出来的回测收益，会高估分红股的收益、低估除权股的成本。这是一个能让你回测结果偏差几十个百分点的陷阱。解决方案是在入库时自己做前复权/后复权处理，但这需要额外的除权除息数据。
5.3 为什么是DuckDB而不是SQLite或Parquet
这是我被问得最多的一个问题。三个理由：
一是列式存储+向量化执行。 DuckDB是列式数据库，查询”全市场某一天所有股票的涨幅”这种聚合操作，比SQLite（行式）快一个数量级。我的CSI800系统每天要扫描800只股票的多周期RSI/均线，DuckDB能在几百毫秒内完成。
二是SQL原生支持。 DuckDB兼容PostgreSQL语法的SQL子集，我可以直接用SQL写复杂的JOIN和窗口函数，不用全部用pandas写。这让信号逻辑更清晰、更容易维护。
三是单文件、零部署。 整个数据库就是一个294MB的.duckdb文件，拷到任何机器上就能用，不需要起服务、不需要配连接池。这种”随身携带”的特性对个人研究者极其友好。
5.4 三大隐性成本（自建路线的”代价”）
我必须诚实——自建DuckDB路线有三个经常被低估的隐性成本：
隐性成本一：数据质量完全自负其责。 平台型工具（聚宽、米筐）背后有团队维护数据质量——处理停牌、除权、数据异常、字段补全。自建路线里，这些全是你的活。我的stock_daily表没有主力资金净流入字段，bond_daily没有可转债的到期收益率（YTM）和转股溢价率字段，ETF表只有代码没有中文名——这些缺口是我自己填的，填不了的就只能用代理指标或标注”无法验证”。这是自建路线最硬的代价。
隐性成本二：运维负担。 信号系统靠cron调度，cron会停。我的蓝筹v2系统最近就出过一次”静默失败”——最新输出停留在6月17日，滞后了约两周才被发现。如果你用平台型工具，运维是平台的责任；自建路线里，监控、告警、自愈全是你的责任。这不是写完代码就结束的事，而是持续的工程负担。
隐性成本三：实盘对接要从零搭。 自建DuckDB是纯研究系统，没有下单能力。如果有一天要实盘，我得自己接券商API（或引入VnPy做执行层）。平台型工具（QMT、PTrade）自带实盘通道，省去了这一大块工程。
这三个成本叠加起来，意味着自建路线的真正门槛不是”技术难”，而是”你要愿意持续投入时间去维护一个会出错的系统”。 如果你只想做策略研究、不想当运维工程师，自建可能不是最优解。
六、决策矩阵：什么人该选什么工具
讲了这么多，落到实操。我把”编程能力×资金规模×策略复杂度×实盘需求”四个维度组合成一张决策矩阵，给四类典型用户的推荐：
| 用户画像 | 编程 | 资金 | 策略复杂度 | 实盘需求 | 推荐路线 | 理由 |
|---|---|---|---|---|---|---|
| 零基础新手 | 无 | 小（<10万） | 低（跟信号/简单择时） | 暂无 | 聚宽/米筐（平台型） | 浏览器即用，零运维，先学会跑策略再谈工具 |
| 有编程基础的进阶者 | Python熟练 | 中（10-100万） | 中（多因子/轮动） | 可能要实盘 | TqSdk（框架型） | 免费Tick数据+本地框架，平衡掌控感和易用性 |
| 技术型深度定制者 | Python+工程能力强 | 中大（>50万） | 高（高频/套利/多策略） | 必须实盘 | VnPy（框架型） | 实盘能力最强的开源框架，CTP/券商接口齐全 |
| 数据驱动的研究者 | SQL+Python | 不限 | 中高（因子研究/信号系统） | 研究为主 | 自建DuckDB + RQAlpha验证 | 完全掌控数据，回测用专业框架交叉校验 |
这张矩阵的核心逻辑是：工具选择应该跟着你的”瓶颈”走。 新手的瓶颈是”不会写策略”，所以选最省心的平台；进阶者的瓶颈是”数据不够/回测不准”，所以选数据好的框架；技术大牛的瓶颈是”实盘能力”，所以选实盘最强的VnPy；研究者的瓶颈是”数据掌控度”，所以选自建。
我的个人选择历程
供参考，我的工具演进路径是这样的：
Tushare/AKShare（免费数据） → pytdx + CSV → pytdx + DuckDB → DuckDB + 自写信号系统 + cron调度每一次迁移都是因为前一个方案撞到了瓶颈：Tushare免费档调用次数不够 → 换pytdx自己采；CSV文件多了管理混乱 → 换DuckDB；DuckDB光存数据不够 → 自写信号系统+调度。这是一条”被瓶颈推着走”的路，不是一开始就规划好的。 如果现在让我重来，我可能仍会选自建——因为我享受掌控感，而且愿意为它付运维时间。但如果你不愿意，平台型或框架型是完全合理的选择。
七、2026年趋势判断：AI Agent会成为第五条路线吗
文章最后，我想聊一个当下正在发生的趋势——AI Agent和量化工具的融合。
2026年的Python+AI生态正在经历一次”轻量化爆发”：LoRA/QLoRA微调让消费级显卡跑70B参数的大模型成为常态，FP4/FP8量化把推理成本压到了原来的几分之一，Streamlit/LangChain/vLLM让AI应用开发变得像”搭积木”。Gartner甚至预测，到2028年至少15%的日常工作决策将由智能体自主完成。
这对量化工具生态意味着什么？我看到两个正在成型的方向：
方向一：AI Agent接管”数据采集→清洗→入库”的管道。 我自己已经用Hermes Agent（一个支持cron调度的AI Agent框架）实现了每日自动采集市场数据、运行信号系统、生成选题报告的自动化管道。传统自建路线最痛的”运维负担”（第三节提到的隐性成本二），正在被AI Agent的自愈能力部分解决——Agent可以检测到信号系统停跑、自动排查、甚至自动重启。这意味着自建DuckDB路线的门槛正在降低。
方向二：LLM直接参与策略生成和信号解读。 ICLR 2026会议上已经有多篇论文探索用LLM Agent做量化交易决策——比如TIMI系统提出”理性驱动”的Agent架构，把传统量化因子和多模态LLM融合，实现分钟级交易决策；还有研究用LoRA微调预训练LLM作为Decision Transformer，在纯离线历史数据上学习交易策略。这些方向目前还在学术阶段（StockBench评测显示SOTA模型在实盘模拟里大多还是亏损的），但技术演进的方向是清晰的。
所以，如果让我对2026-2027年的量化工具生态做一个判断，我会说：四条路线的格局不会变，但”自建+AI Agent”正在成为一条值得关注的”第四点五条路线”——它保留了自建的数据掌控优势，又用Agent的自动化能力对冲了运维负担。 这正是我目前在走的路，也是我会持续在这篇博客里记录的方向。
结语：选工具的本质，是选一种和不确定性共处的方式
回到开头那个问题：为什么2026年还在讨论”用什么工具做量化”？
因为工具不是一个静态的”功能列表”，它是你和市场不确定性之间的一层中介。平台型工具让你把不确定性外包给平台；框架型工具让你和框架一起分担不确定性；回测型工具让你在安全的历史沙盘里研究不确定性；自建路线让你直接面对不确定性的每一个字节，代价是孤独，回报是掌控。
没有哪条路线是”对的”，只有哪条路线和你愿意投入的时间、你享受的工作方式、你的资金规模和策略需求最匹配。知乎和CSDN的盘点帖能帮你画出地图，但路要你自己走。
至于我为什么选了最难的那条——因为我相信，在量化这个领域里，对你自己的数据边界的每一次清晰认知，都比一个漂亮的回测曲线更有价值。 自建路线逼着我每天面对数据缺口、字段缺失、系统故障，这些”麻烦”反过来让我对市场的理解更诚实。这种诚实，是任何平台都给不了的。
方法论与数据披露：本文涉及的工具对比基于公开文档、社区反馈和作者个人使用经验，工具版本和功能可能随时间变化，建议读者以各工具官方文档为准。文中DuckDB数据库的真实数据（4589只股票/988只可转债/30只ETF/294MB）来自作者本地
quant_v2.duckdb，数据采集使用pytdx，存储使用DuckDB，信号系统使用Python+SQL+cron调度。文中提及的CSI800信号系统、蓝筹v2系统、估值周报的数据口径已在作者博客的多篇”每日发现”系列文章中详细披露，此处不重复。文中未对任何工具做”最好”的价值判断，仅提供”最适合某类用户”的匹配建议。文中对TqSdk、VnPy、RQAlpha、Hikyuu、QMT、PTrade、聚宽、米筐的描述基于2026年7月公开信息，读者使用前请自行核实最新版本的功能与定价。