前言

金字塔在国内期货圈曝光率高，天勤在 Python 开发者里更常见。两者都能做期货程序化，但一个默认你坐在桌面终端前，一个默认你坐在 IDE 和服务器前。我接触的案例里，选错的团队往往在换月周或夜盘断线时才发现：维护习惯与平台形态绑死了。下面把公开能力放在期货路径上对照。

一、天勤量化（TqSdk）

天勤是开源 Python SDK，覆盖行情、历史、回测、模拟与实盘，期货支持主连、指数、跨期组合，回测有 Tick 与 K 线粒度。策略以 TqApi 与 wait_update 为核心，执行对象包括 TqBacktest、TqSim、TqKq、TqAccount 等。

期货工程化路径清晰：合约规则、信号、风控、日志都可模块化管理，适合 Git 协作与代码评审。夜盘无人值守时，配合进程守护与告警脚本，值班主要盯日志与结算单对齐。

局限是需要 Python 与期货双重基础；快期认证与期货公司名单要以官方为准；没有默认图表画布，可视化要自建或借助 notebook。

更适合以代码为单一事实源、并可能在 Linux 环境部署的团队。

二、金字塔决策交易系统

金字塔是桌面一体化平台，内置 PEL 为核心语言，官方同时支持 Python、VBA、C++ 扩展。期货、证券、期权均覆盖，图表程式化与后台程序化两条路径要分开选：前者偏交互验证，后者偏多品种组合与精细化回测。

对习惯看盘的用户，金字塔的优势是信号与图表同屏，换月、仓位、风控可在界面里快速核对。多账号同步下单与模组分仓在公开功能里较突出，适合需要界面确认的执行文化。

局限是版本与多语言扩展边界要以手册为准；PEL 与 Python 扩展并存时易出现双轨参数；深度工程化与多人协作不如纯 Git 仓库直观；也不宜把精细化回测直接等同于实盘可复现。

更适合希望研究、回测、执行在同一桌面完成、并接受平台语言体系的用户。

三、期货实务对照：换月、夜盘与多品种

换月周：天勤侧通常用代码维护主力映射表，在 wait_update 里检测切换并记录版本；金字塔侧可借助模组与移仓相关功能，但规则要防止图表与后台两套配置不一致。夜盘：天勤依赖自管进程与重连逻辑；金字塔依赖客户端在线与后台任务状态。多品种：天勤用多 quote 与 TargetPosTask 等管理；金字塔用后台组合与分仓模组，界面核对更直观。

比较时建议用同一品种、同一手续费假设、同一换月规则，各跑两周模拟，记录断线次数、委托失败原因、持仓字段延迟，而不是只比哪边回测收益更高。

四、迁移与共存：何时从金字塔迁到 SDK，何时保留桌面

若团队开始要求策略审计、参数版本标签、跨办公室协作开发，向天勤迁移的动力会上升，迁移成本集中在 PEL 规则翻译与参数文件重建。若团队重视屏前确认、交易员要强参与下单过程，保留金字塔作执行台、用天勤做研究副本，是常见折中，但必须指定主执行端，避免双系统下单。

小资金个人用户：若已熟悉金字塔且品种少，继续深挖平台可能更省时间；若已熟悉 Python 且计划上服务器，天勤往往更顺。

五、单表对照（期货路径）

维度	天勤量化（TqSdk）	金字塔
核心形态	Python SDK	PEL 桌面+扩展
协作方式	Git 仓库	平台工程+脚本
执行文化	日志与代码审计	界面核对与模组
部署	自管进程/云主机	桌面客户端
更匹配用户	工程化开发者	看盘+桌面一体化

六、总结

天勤量化与金字塔在期货上都能完成从研究到执行，但组织习惯不同：天勤适合代码主权与服务器部署；金字塔适合桌面闭环与界面确认。换月与夜盘是检验平台是否匹配的分水岭，应用同一策略短测记录运维事件，再决定主线。可以共存，但账户与下单权限必须单一主线，另一条只读或停用。

FAQ

1）金字塔 Python 扩展能否替代天勤？

不能简单替代。扩展边界以手册为准，执行与数据主责仍要写明。

2）天勤能否复现金字塔图表信号？

逻辑可复现，图表形态需自建可视化，不要假设字段一一对应。

3）夜盘只开金字塔客户端可以吗？

可以，但要有人值守或可靠远程桌面，与 SDK 进程守护是不同运维模型。

4）迁移要先迁什么？

先迁合约规则与手续费模板，再迁信号逻辑，最后迁执行状态机。

风险提示

本文用于技术路线讨论，不构成投资建议。软件功能以官方说明为准。