WonderTrader / Engines
wondertrader 四大引擎怎么选：CTA、SEL、HFT、UFT 的分工与延迟口径
这四个引擎经常被误读成「性能从低到高」的四档。官方 FAQ 的说法是按标的数量、单次计算时长与延迟要求分工：标少算得快走同步引擎，标多算得慢走异步引擎，要低延迟才进高频与极速引擎。本文把官方文档里的选型依据、延迟数字的两处口径，以及官方自己记录的延迟优化过程整理成可核对的表。
四引擎与执行模块的完整对照
驱动方式与适用规模取自官方文档，延迟数字是官方自述值，官方未完整公布测试环境。
| 模块 | 驱动方式 | 适用标的与计算时长 | 官方延迟口径 | 适用场景 | 注意点 |
|---|---|---|---|---|---|
| CTA 同步策略引擎 | 事件 + 时间驱动 | 标的较少；官方 FAQ 给的口径是单策略 50 个标的以内 | 未单独公布 | 单标的择时、中频以下套利 | 主 K 线闭合、且所有已订阅 K 线都闭合后才触发一次重算 |
| SEL 异步策略引擎 | 时间驱动（异步） | 标的较多；适合单次计算超过 1 分钟的策略 | 未单独公布 | 多因子选股、截面多空 | 按注册的重算时间调度，支持日内、每日、每周、每月等周期 |
| HFT 高频策略引擎 | 事件驱动 | 一般高频或低延迟策略 | 1–2 微秒之间（官方自述） | 盘口驱动、高频挂撤 | 定位是「向应用层提供高性能底层组件」，会兼顾兼容性与应用层对接，不是极限形态 |
| UFT 极速策略引擎 | 事件驱动 | 超高频、超低延迟 | README 写 175 纳秒之内；官方文档写 200 纳秒之内 | 延迟敏感的自营场景 | 完全从核心项目剥离，不向应用层提供接口，全部 C++ 实现 —— 无法用 Python 写 UFT 策略 |
| 执行单元 WtExecMon | 独立执行器入口 | 与策略计算解耦 | 不适用 | 把执行环节单独拿出来做算法交易 | 把组合架构中「1+N」的执行部分剥离即可独立使用，可通过实现自己的执行单元工厂扩展算法 |
| 统一回测引擎 | 配置项切换 cta/sel/hft/exec/uft | 随所选引擎而定 | 不适用 | 研发阶段的策略验证 | 官方文档该配置项的注释把 uft 写作 uf，属原文笔误，指的是 UFT 引擎 |
| 仿真交易模块 TraderMocker | 随所选引擎 | 覆盖已支持的股票与期货 | 不适用 | 无柜台条件下的流程演练 | 来自官方更新日志 0.3.6；仿真不等于实盘，撮合与回报细节与真实柜台不同 |
延迟数字：两处口径和它们的前提
官方在仓库与文档里给出的数字并不完全一致，先把它们并排列出来，再谈这些数字能推出什么、不能推出什么。
| 来源 | 原文表述 | 测的是什么 | 能推出什么 | 不能推出什么 | 注意点 |
|---|---|---|---|---|---|
| 仓库 README | UFT 引擎「系统延迟在 175 纳秒之内」 | 引擎内部系统延迟 | 官方在自身测量口径下给出的数量级 | 不能推出你的环境也有同量级延迟 | 与官方文档的 200 纳秒表述存在差异，页面并列保留 |
| 官方文档《WonderTrader 简介》 | UFT「系统延迟在 200 纳秒之内」；HFT「1-2 微秒之间」 | 引擎内部系统延迟 | HFT 与 UFT 差一个量级 | 不能推出端到端延迟或成交速度 | 官方未在该页公布测试环境 |
| 仓库 README（CTA 段） | DualThrust 单次重算：Python 约 70 多微秒，C++ 约 4.5 微秒 | 单个策略单次重算耗时 | 同一策略下 C++ 与 Python 的差距量级 | 不能推出所有策略都有同样倍差 | 官方未公布测试机器与数据区间 |
| 官方文档《延迟优化日记》 | 五阶段优化后系统延迟 175 纳秒 | 专门的延迟测试工程 WtLatencyUFT | 优化过程与每阶段量级可追溯 | 不能推出实盘端到端延迟 | 测试环境为 Intel i9-10980XE，未超频、未关闭超线程 |
| 官方文档（执行器相关） | 执行器使用线程池以减少对网络线程的占用 | 架构说明 | 执行链路对网络线程做了隔离 | 不能推出具体延迟收益 | 来自官方更新日志 0.3.6，属版本变更记录 |
官方《延迟优化日记》五阶段
这是官方文档里少见地把优化过程逐步公开的章节，对判断「175 纳秒是怎么来的」很有用。
| 阶段 | 优化手段（官方原文要点） | 完成后系统延迟 | 适用场景 | 注意点 |
|---|---|---|---|---|
| 第一阶段：UFT 拆分 | 弃用内部标准代码转换、去掉主力与次主力判断、下单接口去掉用户标签、把合约与品种信息在初始化时直接关联、接口数据类型增设合约信息指针 | 1 微秒 | 先砍掉高频路径上的非必要转换 | 去掉主力判断意味着 UFT 不再享受主力合约映射的便利 |
| 第二阶段：时间函数 | 延迟测试工具每次模拟 tick 都取系统时间，开销过大；实盘中行情接口已完成时间处理，故测试工具去掉取时间逻辑 | 500 纳秒 | 仅在测试工具层面成立，不改实盘逻辑 | Windows 与 Linux 下时间函数开销不同，官方记录了 Linux 更慢的现象 |
| 第三阶段：字符串 | 用性能探查器定位到字符串切分与格式化开销大；关键路径改自实现查找、格式改预分配缓冲区、结构体里的字符串成员全部改定长数组 | 250 纳秒 | 高频路径上任何字符串操作都要审计 | 结构体改为定长数组会改变应用层访问方式 |
| 第四阶段：内存分配 | 瓶颈转到对象创建与释放；引入对象池模板类，内部用 boost 对象池管理分配，频繁创建释放的对象改为从池派生 | 185 纳秒 | 频繁短生命周期对象的场景 | 引入对象池需注意对象生命周期，不能跨池长期持有 |
| 第五阶段：哈希表 | 瓶颈集中在合约查询；容器已是高性能哈希表，于是把键改为整型数组并自实现哈希函数，利用整数计算更快的特性 | 175 纳秒 | 合约查询密集的热路径 | 自实现哈希需自行保证键的唯一性与一致性 |
选型决策：场景到引擎
把官方 FAQ 的判定条件翻译成「你遇到的情况 → 该用哪个引擎」。
| 你的场景 | 选哪个 | 理由 | 需要接受的代价 |
|---|---|---|---|
| 跟踪 1–2 个品种做日内择时 | CTA | 事件 + 时间驱动，逻辑简单，重算频率可控 | 标的一多就会拖慢整体重算 |
| 从数千只股票里逐步筛出目标股池 | SEL | 官方明确 SEL 就是为「计算量庞大、耗时也长」的场景定制 | 异步执行，信号与执行之间有调度延迟 |
| 需要跨品种配对或中频套利 | CTA 优先 | 官方把「中频以下的套利」列为 CTA 的典型场景 | 多品种同周期时需注意 K 线闭合顺序 |
| 策略依赖盘口与逐笔，要求低延迟 | HFT | 事件驱动，官方口径 1–2 微秒 | 仍可兼顾兼容性，不是极限形态 |
| 延迟本身就是策略的一部分 | UFT | 系统延迟官方口径 175/200 纳秒 | 不能用 Python 写策略，且不支持主力合约映射 |
| 只想把执行过程单独复用到别的框架 | WtExecMon | 官方把「1+N」剥离成独立算法交易执行器 | 需要自己定义目标头寸的输入来源 |
引擎在仓库里的位置
要读源码或做二次开发，先用这张表定位。以下目录名来自仓库 src 目录的实际条目（2026-09-16 核验）。
| 目录 / 模块 | 对应能力 | 你要读它的场景 | 注意点 |
|---|---|---|---|
| WtCore | 交易引擎核心 | 理解引擎主循环与调度 | 核心逻辑都在这层，改动风险最高 |
| WtUftCore | UFT 极速引擎独立实现 | 研究极限延迟路径 | 与 WtCore 分离，不向应用层开放接口 |
| WtCtaStraFact | CTA 策略工厂 | 新增 CTA 策略类型 | 工厂决定策略的创建与注册方式 |
| WtSelStraFact | SEL 策略工厂 | 新增选股策略类型 | 与 CTA 的工厂平行，不要混用 |
| WtHftStraFact | HFT 策略工厂 | 新增高频策略类型 | 高频策略对内存与字符串开销更敏感 |
| WtUftStraFact | UFT 策略工厂 | 新增极速策略类型 | 仅 C++，应用层无法用 Python 接入 |
| WtExeFact / WtExecMon | 执行单元与独立执行器 | 实现自定义执行算法 | 执行单元与策略计算分离，各自独立演进 |
| WtLatencyHFT / WtLatencyUFT | 延迟测试工程 | 复现官方延迟测试 | 官方日记的测试项目为 WtLatencyUFT |
引擎选型与运行的高频误用
下面几条是官方文档里明确写出的语义与限制，踩中任意一条都会得到「看起来能跑但结果不对」的现象。
| 现象 | 可能原因 | 核对方法 | 处理方向 |
|---|---|---|---|
| 策略一直不重算 | 把重算逻辑写进了 K 线闭合回调，但重算只在主 K 线闭合且其余已订阅 K 线都闭合后才触发 | 看官方 FAQ「on_bar 和 on_schedule（on_calculate）有什么区别」 | 把核心逻辑放回重算回调，闭合回调只做特殊响应 |
| SEL 策略信号当天不生效 | SEL 是异步时间驱动，重算按注册的调度周期触发 | 检查注册的重算周期与调度时间 | 明确周期语义，日级调度需接受次日执行 |
| 标的数一多就明显变慢 | 用 CTA 引擎承载了本该由 SEL 处理的多标的选股任务 | 对照本文第一张表的适用规模列 | 换用 SEL，或把标的池收敛到 CTA 适用范围内 |
| 想用 Python 写 UFT 策略失败 | UFT 引擎全部在 C++ 实现且不向应用层提供接口 | 看官方文档与 README 的 UFT 段 | 改用 HFT 引擎，或把策略改写为 C++ |
| 延迟体感与官方数字差很多 | 把官方自述的引擎系统延迟当成了端到端预期 | 核对自己的柜台、网络与策略计算耗时 | 自建压测；不要以官方数字作为验收标准 |
| 回测里 uft 配置项不被识别 | 官方文档注释把 uft 写作 uf（原文笔误） | 对照官方文档 usage/mystrategy.html 的配置说明 | 按文档注释实际可用的取值填写，或参考官方 demo |
常见问题
选型问题大多能在官方 FAQ「如何选择交易引擎」里找到出处，以下是常见追问。
CTA 和 SEL 最本质的区别是什么？
驱动方式与标的规模。CTA 是「事件 + 时间驱动」的同步引擎，适合标的少、计算快的策略，官方口径是单策略 50 个标的以内；SEL 是异步时间驱动，按注册的重算时间调度，适合标的很多、单次计算超过 1 分钟的策略，比如多因子选股。两者都沿用同一套组合执行架构，所以差别不在执行层，而在重算触发方式。
HFT 和 UFT 我该选哪个？
看你对「能不能用 Python」和「延迟要求」的取舍。HFT 官方口径 1–2 微秒，支持 wtpy 开发策略，并且会考虑兼容性与应用层对接；UFT 官方口径 175/200 纳秒，但完全从核心项目剥离、不向应用层提供接口、全部 C++ 实现，也就是只能用 C++ 写策略。如果你还没到必须用 C++ 的阶段，先上 HFT 更现实。
为什么同一个数字有两个版本？
因为官方在两处文档里写的不一样：仓库 README 写 UFT「175 纳秒之内」，官方文档《简介》写「200 纳秒之内」。本文并列保留两处口径而不择一，是为了避免把官方文本差异当成定论。以官方最新文档为准即可，且都不构成对你环境的性能预期。
官方延迟测试环境是什么样的？
官方《延迟优化日记》给出的测试环境是 Intel i9-10980XE、未超频、未关闭超线程，测试项目为 WtLatencyUFT。官方没有公布操作的标的、行情频率与柜台条件，所以这些数字只能作为相对量级参考，不能直接外推。
执行单元和执行器是一回事吗？
官方把它们放在同一执行链路上：组合的目标头寸交给执行器执行，执行内部按执行单元定义的算法下单。官方还提供了独立执行器入口，可以把组合架构中「1+N」的执行部分单独拿出来，作为一个独立的算法交易执行器使用；用户也可以通过实现自己的执行单元工厂来增加算法。
选引擎这件事，EasyClaw 能帮忙判断吗？
不能直接代劳。引擎选型依赖你的柜台权限、标的数量与延迟要求，属于实盘工程决策；EasyClaw 侧提供的是行情数据、技术分析、选股与研究回测类技能，可以帮助你在写策略前做研究验证，但不提供本框架式的引擎选型与实盘执行能力。两者之间没有已证实的集成关系，具体以官方文档与你自己的压测结果为准。