prediction-market-backtesting是一个构建在 NautilusTrader 之上的 Polymarket 预测市场回测框架，支持 L2 订单簿数据回放、真实成交撮合、滑点与延迟建模。而新手上路时最常卡住的第一步就是：PMXT 与 Telonex 两大数据供应商到底怎么选？本文用一张对比表和几条实操建议，帮你在 10 分钟内做出决策。

为什么回测必须依赖历史订单簿数据源

预测市场和股票的最大区别：策略往往要看整本 L2 订单簿（多档买卖盘口与深度），而不仅是一个中间价。没有真实的历史盘口数据，任何"回测盈利"都是纸上谈兵。

prediction-market-backtesting 的做法是把数据加载本身当作回测保真度的一部分，而不是纯粹的 I/O 细节：两条数据通道最终都会转换成 Nautilus 的OrderBookDelta（盘口增量），再穿插真实的TradeTick（成交记录）用于撮合与排队位置推进。

📁 两条通道的完整说明见 docs/data-vendors.md、docs/data-loading.md 和 docs/vendor-fetch-sources.md。

先认识两位主角：PMXT 与 Telonex

PMXT：小时级"增量流"原始档案

🕐 PMXT 提供的是Polymarket L2 订单簿的小时级原始档案，每个小时一个 Parquet 文件，里面可能包含全平台许多市场和代币的数据。加载器会先按你请求的 market/token 过滤，再解码两类事件：

• book_snapshot：一份全新的完整盘口快照；
• price_change：单个价格档位的增量更新。

它有两个对新手非常友好的特性：

1. 公开可读，无需 API key——除了本地镜像，还可以直接回退到公共档案archive:r2v2.pmxt.dev与archive:r2.pmxt.dev；
2. 自带增量下载器——make download-pmxt-raws DESTINATION=/path/to/pmxt_raws会从2026-02-21T16:00:00Z开始按小时倒序镜像，已存在的小时会自动跳过，重复运行安全。

Telonex：天级"全深度快照" + 执行成交数据

📸 Telonex 提供的是天级的全深度订单簿快照（book_snapshot_full通道）。相邻两份全量快照之间的差异由框架自动 diff 成 L2 增量，策略拿到的依然是OrderBookDelta，而不仅仅是报价点。

除了盘口，Telonex 还提供两条执行数据通道，这是它相对 PMXT 的独特价值：

• onchain_fills：链上成交，是 Telonex 回放中首选的成交 tick 来源；
• trades：常规成交，用于填补onchain_fills缺失或为空的日期。

使用 Telonex API 需要TELONEX_API_KEY；项目也提供了断点续传、失败自动重试的下载器（make download-telonex-data），下载进度记录在本地 DuckDB 清单中，中途 Ctrl-C 也不会丢失已完成的天。

📁 两条通道的数据源适配器分别位于 prediction_market_extensions/backtesting/data_sources/pmxt.py 与 prediction_market_extensions/backtesting/data_sources/telonex.py。

一张表看懂 PMXT 与 Telonex 核心差异

缓存机制：第二条命也是白送的

两条通道都有多级缓存，首次运行稍慢，之后会明显提速：

• PMXT 过滤缓存：按"条件 / 代币 / 小时"切片存成紧凑 Parquet，热缓存读取是毫秒级的；批量加载多个市场时，同一个原始小时文件只扫描一次就分发给所有市场，避免重复 I/O；
• Telonex 三层缓存：api-days（避免重复下载 API 日报，附带.fast.parquet侧车文件加速读取）、book-deltas-v1与trade-ticks-v1（已转换好的 Nautilus 回放对象，热运行直接跳过解码）。

💡 清缓存命令是make clear-pmxt-cache与make clear-telonex-cache，它们只清理回放缓存，不会误删你配置的本地原始镜像。

保真度关键：缺了数据，框架怎么处理

这一条最容易被新手忽略，但它直接决定回测结论可信与否：

• PMXT 缺一个小时：框架会告警并重置本地盘口状态——它拒绝把增量更新"跨过缺口"硬应用，直到一份新的book_snapshot重建盘口。这会让回放"显得没那么自信"，但比假装数据完整更诚实；
• Telonex 某个 API 日缺失或为空：自动回退到下一个已配置数据源；onchain_fills为空不代表当天没有成交，加载器会继续尝试trades，最后才是 Polymarket 公共成交。

一句话：两条通道都遵循"宁可暴露缺口，也不粉饰数据"的失败语义，这一点在 docs/data-loading.md 的 Failure Semantics 一节有详细说明。

到底怎么选？三条建议帮你决策

1️⃣看策略的时间粒度。做 BTC 5 分钟这类短周期、高频档位的盘口策略，小时级增量流（PMXT）的时间分辨率更贴合；策略以天为决策单位（深价值、恐慌回补等慢节奏研究），Telonex 的全量快照足够，且回放转换有物化缓存，多市场批量研究更省心。

2️⃣看资源与预算。PMXT 零门槛——不需要 key，跑 100 市场组合回放（backtests/polymarket_pmxt_book_100_replay_runner.py）即可上手；Telonex 的api:通道需要 API key，更适合订阅了 Telonex 或已有本地全量镜像（book_snapshot_full+onchain_fills+trades三个通道）的场景。

3️⃣看你要研究的策略类型。若策略的成交撮合依赖链上 fill 细节，或要复现仓库中归档的 BTC 快照模型研究流程（backtests/private/ 下的一批 Telonex 验证器），选 Telonex；若只是快速验证策略思路，PMXT 是成本最低的路径。

🎯 不确定也没关系：两条通道的运行入口是平行的，同一策略换一下MarketDataConfig里的vendor=就能在两者间切换对比，这正是"选型"最实际的做法。

常用命令速查

# 镜像 PMXT 小时级原始档案（增量、可重复运行） make download-pmxt-raws DESTINATION=/path/to/pmxt_raws # 镜像 Telonex 指定市场窗口（需要 API key） TELONEX_API_KEY=... make download-telonex-data TELONEX_DOWNLOAD_FLAGS=' \ --market-slug us-recession-by-end-of-2026 \ --outcome-id 0 \ --channels book_snapshot_full onchain_fills trades \ --start-date 2026-01-19 \ --end-date 2026-02-01' # 全市场镜像（加 --max-days 100 可先做冒烟测试） uv run python scripts/telonex_download_data.py \ --destination /Volumes/storage/telonex_data \ --all-markets \ --channels book_snapshot_full onchain_fills trades

📁 下载脚本与 Make 目标的定义分别在 scripts/pmxt_download_raws.py、scripts/telonex_download_data.py 和 Makefile。

新手最容易踩的 3 个坑

1. 数据源前缀写错会被直接拒绝。PMXT 的sources只接受local:与archive:；Telonex 只接受local:与api:。裸路径、裸主机名、旧版别名都会报错——这是框架故意做的严格校验。
2. 只配了local:缺小时不会自动下载。想让它自动补数据，需要在本地源后面追加archive:r2v2.pmxt.dev之类的远端源；否则缺失的小时会被记为缺口并重置盘口状态。
3. 别把TELONEX_CACHE_ROOT指向本地镜像。make clear-telonex-cache明确拒绝清理配置的本地数据目录，所以缓存根和镜像根要保持分离。

📌 更多细节建议配合官方文档阅读：docs/backtests.md（回测运行器与数据源说明）、docs/setup.md（环境安装与首次运行）、docs/execution-modeling.md（费率、滑点与各供应商 L2 行为）。