Polymarket Bot 教程 · 第 15 章，共 32 章
Polymarket 上的体育微观结构 bots：赛中优势、由比分驱动的错误定价、NBA 标签（745）和 Tennis 标签（864）、实时数据源，以及高频体育市场的执行模式。
本章内容
体育市场是 Polymarket 上最持续活跃的非政治板块。真正有效的 bots 只分成两类：赛前线捕捉器，在盘口刚形成时交易；以及赛中微观结构 bots，在比赛进行中根据订单簿变化做出反应。本章将结合适用的具体 tag ID、数据源和延迟预算，覆盖这两类策略。
体育市场是 Polymarket 上最繁忙的非政治板块。有效的执行模式会把实时比分源（ESPN、PandaScore）与订单簿微观结构信号结合起来。本章具体说明 NFL、NBA、足球和网球中哪些方法有效，以及 esports 有何不同。
- 为什么体育市场可交易
- 赛前 vs 赛中（不同 bots）
- 已验证的 tag ID（745 NBA，864 Tennis）
- 数据源：ESPN、官方 APIs、屏幕识别
- 赛中延迟预算
- 0.99 / 0.01 陷阱
- 代码：订阅 games book 并做出反应
为什么体育市场可交易
体育市场在明确的时间框架内结算（几小时到几天），拥有公开的实时数据，并且在比赛期间会持续产生订单流。这三点对于一个可交易市场都必不可少-政治市场缺少“明确时间框架”，天气市场缺少“持续流动”，冷门赛事则缺少“公开实时数据”。
体育市场上的 trader 人群也比例如选举市场更为多样。普通体育赌客会情绪化定价；有信息的 trader 则会在比赛过程中把价格修正到合理价值。两者之间的差距，就是 bot 的优势来源。
成交量分布并不均匀：一个 NFL 周日会在 Polymarket 体育市场上轮转数亿美元；而周二晚上的沙特职业联赛可能连 5 万美元都不到。策略规模要根据真正有流动性的地方来定。
赛前 vs 赛中（不同 bots）
这是两种根本不同的 bot 设计。
赛前 line-catcher：扫描刚开盘的市场，识别与你的模型或更锋利的盘口相比被错误定价的线，提交 FOK 买单。持有到比赛进行中，有时一直持有到结算。速度要求：分钟级，而不是秒级。优势来源：模型 + 盘口比较。
赛中 microstructure：订阅某场比赛的实时订单簿 WebSocket，在几秒内对失衡信号 + 比分事件作出反应。速度要求：秒级，而不是分钟级。优势来源：延迟 + 读取订单流。
这两类策略几乎不共享代码。它们的风险画像不同，数据源不同，退出策略也不同。想同时做两者的 bot 往往两边都做不好；最好选一个。
已验证的 tag ID（745 NBA，864 Tennis）
以下是截至 2026 年 5 月、已为主要体育类别验证的 production tag ID。使用它们可以高效过滤 /events 调用。
| Sport / League | Tag ID | Tag slug | Notes |
|---|---|---|---|
| NBA | 745 | nba | 10 月至 6 月成交量最高 |
| NFL | 450 | nfl | 9 月至 2 月的周日/周一高峰 |
| Tennis (all) | 864 | tennis | 全年，按赛事节奏波动 |
| Soccer (general) | 1059 | soccer | 与下方子标签组合使用 |
| EPL | 739 | epl | |
| UCL | 2186 | uefa-champions-league | |
| Esports (all) | 702 | esports | LoL + CS2 + Valorant + Dota |
| MLB | 1245 | mlb | 4 月至 10 月高峰 |
| NHL | 823 | nhl | 10 月至 6 月高峰 |
tag ID 会跨年份保持稳定。新的 tag 会被添加（沙特职业联赛、IPL），但旧 tag 不会重新编号。
数据源：ESPN、官方 APIs、屏幕识别
对于传统体育，免费的 ESPN scoreboard API 就能覆盖你需要的一切：比分、节次/时钟、win-probability，有时还有投篮位置。不需要 key；只在 IP 级别限流。endpoint 模式：https://site.api.espn.com/apis/site/v2/sports/<sport>/<league>/scoreboard。
对于 esports，ESPN 没有覆盖。可选方案有：PandaScore（每月 30-60 美元，行业标准）、HLTV（仅 CS2，可抓取，无 API）、Liquipedia（社区维护，可抓取，更新节奏较慢）。
屏幕识别型 feed（为电视流付费并通过 OCR 读取 scorebug）虽然可行，但运维开销很大。只建议在你的策略确实需要某项没有任何 API 可实时覆盖的运动，并且需要 3 秒以内更新时使用。
赛中 latency budget
赛中 reactive bot 的端到端延迟预算如下。
- 比分事件发生：t=0
- 源 feed 反映出来：t+3-15 秒（ESPN：约 10 秒；PandaScore：约 3 秒）
- 你的 bot 读取 feed：t+10-16 秒
- bot 决定动作：+50ms
- FOK 订单发出：+200-500ms
- 在 CLOB 成交：+300-1000ms（网络 + 撮合）
总计：11-17 秒。最快的专业机构借助付费 premium feeds 和 co-located VPS，能做到 3-5 秒端到端。运行在标准主机和免费 ESPN 上的零售 bot 则通常处于更慢的一端。
需要 5 秒以内的策略对零售来说不可行。能在 10-17 秒窗口内工作的策略包括：比分后跟随买入、反向交易过度反应、临近结束时的确定性交易。
0.99 / 0.01 陷阱
最常见的赛中体育 bot 失败模式：在只剩一分钟时买入 0.99 的重度热门，期待轻松赚 +1 美分。它失败有三个原因。
第一，1% 的隐含概率并不是零-最后时刻的逆转会以不可忽视的频率发生。一个 99.5% 确定的胜局，重复 200 次，就会出现一次全仓位损失。
第二，0.99/0.01 的价差意味着你每股支付 99 美分，成功时只赚 1 美分，若罕见逆转则亏 99 美分。风险回报极其糟糕。
第三，使用 GTC 卖单挂到 0.999 的 bot 几乎不会成交-那个价位没有买家。仓位会一直持有到结算。赢了，你只赚 1 美分；若发生逆转，你会亏 99 美分。
这个陷阱是真金白银的亏损，很多 builder 都是在没算清楚数学的时候踩进去的。除非你的策略就是专门为 redemption-arbitrage 这种剖面设计的，否则要避开 0.95 以上的市场。
代码：订阅一个 games book 并做出反应
参考示例：订阅某个 NBA 比赛的 WebSocket，记录 book 更新，在失衡信号出现时发出 FOK。
import websocket, json
THRESHOLD = 0.5 # imbalance level to trigger
def on_message(ws, message):
msg = json.loads(message)
if msg.get("event_type") != "book": return
bids = msg.get("bids", [])
asks = msg.get("asks", [])
bid_depth = sum(float(b["price"]) * float(b["size"]) for b in bids[:5])
ask_depth = sum(float(a["price"]) * float(a["size"]) for a in asks[:5])
total = bid_depth + ask_depth
if total < 100: return # too illiquid
imb = (bid_depth - ask_depth) / total
if abs(imb) > THRESHOLD:
print(f"signal imb={imb:.2f} bid={bid_depth:.0f} ask={ask_depth:.0f}")
# fire FOK here
ws = websocket.WebSocketApp(
"wss://ws-subscriptions-clob.polymarket.com/ws/market",
on_open=lambda ws: ws.send(json.dumps({"type":"Market","markets":["<CONDITION_ID>"]})),
on_message=on_message
)
ws.run_forever()生产环境可添加的内容：两次触发之间的 cooldown、单个 token 的仓位上限、如果 30 秒内没有消息则 kill 掉 stale book。
