让 Cursor 帮你搞定美股 4 个时段：AI Agent 的时段感知实战

一、AI 看到美股数据时，第一个困惑就是时段

给 AI Agent 接美股数据，第一个翻车现场通常是这样的：Agent 在美东时间凌晨 5 点查了一次 AAPL 的价格，兴冲冲告诉你“当前价格 260.81”。你手动打开 tradingview 一看——价格根本不一样。

不是数据源错了，是 Agent 不知道美股有 4 个交易时段。它随便拿了一个时段的报价就当“最新价”用。

给 AI Agent 接美股数据，几乎所有开发者第一次都会忽略时段问题——不是模型的问题，是你把行情 JSON 扔给 Agent，里面没有 trade_session=1 这个字段，它就是瞎的。Claude 或 GPT，换了哪个模型都一样。

美股一天切成四段。盘前和盘后订单簿深度只有正盘的几分之一甚至更薄，但财报、宏观数据、重大公告全挤在这两个窗口发布。也就是说，信息密度最高的时段恰恰是流动性最薄的时段——AI 如果感知不到这个差异，它给出的分析结论会系统性地忽略盘前盘后的价格信号。

特斯拉经常在美东凌晨走出 5% 的涨幅，那不是夜盘异常，是盘前市场在定价。Agent 要是只订了正盘那 6.5 小时，等于每天有 8.5 小时的定价过程对它来说是黑箱。

二、拆解 trade_session：4 个数字背后的交易规则

解决这个问题的关键只有一个字段：trade_session。

TickDB 的交易时段接口 GET /v1/market/trading-sessions?market=US 返回结构长这样：

{
  "market": "US",
  "trading_sessions": [
    {"begin_time": 400,  "end_time": 930,  "trade_session": 1},
    {"begin_time": 930,  "end_time": 1600, "trade_session": 0},
    {"begin_time": 1600, "end_time": 2000, "trade_session": 2}
  ]
}

为了方便你的 Agent 理解，我把这四个时段的逻辑梳理如下：

时段名称	trade_session 枚举	美东时间范围	典型特征	对 Agent 的决策影响
盘前	1	04:00 - 09:30	流动性薄，财报/宏观集中发布	禁止市价大单，适合收集盘前情绪
正盘	0	09:30 - 16:00	流动性最好，价差最小	开启全量策略，适合所有单类型
盘后	2	16:00 - 20:00	流动性迅速萎缩	适合收盘定价，不适合激进策略
夜盘	3	20:00 - 次日 04:00	覆盖 Blue Ocean ATS	标的少，仅监控核心高波动品种

验证流动性的实操方法：如果你想让 Agent 直观感受盘前和正盘的流动性差异，可以在美东时间 8:00（盘前）和 10:00（正盘）分别调一次 TickDB 的 GET /v1/market/depth?symbol=AAPL.US，对比两次返回的 bids/asks 价差。盘前的买卖价差往往是正盘的数倍——Agent 如果不加时段过滤，可能会在盘前用滑点极高的报价做出错误判断。

字段名陷阱：注意 begin_time=400 是 hhmm 格式，表示美东时间凌晨 4:00，不是 400 毫秒。解析时务必先手动换算成分钟数。

三、你踩过的坑，我替你整理好了

在做 AI 金融应用时，你大概率会卡在这几个地方。这些是我在真实项目里排查了很久才搞定的：

坑点	典型表现	正确解法
时区陷阱	服务器跑 UTC，人工查看是北京时间，美东开发却按本地时间看	用 pytz.timezone('America/New_York') 锁死时区，不要写死 UTC-5
字段幻觉	看到 400 以为是毫秒或 Unix 时间戳	写一行函数：hour = begin_time // 100; minute = begin_time % 100
夜盘差异	trade_session=3 并非所有数据源都支持	代码里做好兼容，查不到夜盘字段时不报错，自动降级
缓存失效	缓存了时段表，结果遇到节假日或半日交易	设置缓存过期时间到当天 23:59:59，隔天强制刷新
API 错误码忽视	Agent 遇到 3001（限流）直接 JSON 解析失败退出	必须检查 code 字段，非 0 时返回明确错误信息而非崩溃

四、极简实现：一个能跑的时段感知函数

下面是给 Agent 工具层用的极简版。约 30 行，能直接跑。

import requests
import pytz
from datetime import datetime

API_KEY = "YOUR_API_KEY"  # 替换为你的 TickDB API Key
                          # 测试阶段可覆盖数十个热门标的，无需付费 Key
                          # 详见 TickDB GitHub 的 SKILL.md 说明
API_BASE = "https://api.tickdb.ai"
ET = pytz.timezone("America/New_York")

def get_current_session():
    resp = requests.get(
        f"{API_BASE}/v1/market/trading-sessions",
        params={"market": "US"},
        headers={"X-API-Key": API_KEY},
        timeout=5
    )
    data = resp.json()

    # 关键：检查业务错误码，而非仅依赖 HTTP 状态码
    code = data.get("code", -1)
    if code != 0:
        if code in [1001]:
            return {"error": "API Key 无效，请检查配置"}
        elif code in [3001, 3002]:
            return {"error": f"请求超限 (code={code})，请降低频率或升级套餐"}
        else:
            return {"error": f"API 错误: {data.get('message', '未知')}"}

    sessions = data["trading_sessions"]  # 注意路径
    now_et = datetime.now(ET)
    now_minutes = now_et.hour * 60 + now_et.minute

    for s in sessions:
        begin_m = (s["begin_time"] // 100) * 60 + (s["begin_time"] % 100)
        end_m   = (s["end_time"]   // 100) * 60 + (s["end_time"]   % 100)

        if begin_m <= end_m:
            if begin_m <= now_minutes < end_m:
                return s["trade_session"]
        else:
            # 处理跨午夜时段 (如夜盘 20:00-次日 04:00)
            if now_minutes >= begin_m or now_minutes < end_m:
                return s["trade_session"]
    return None

工程预警：get_current_session() 不要每次 Agent 做决策时都调。把它缓存住，只在日期切换时刷新。时段表一天变不了一次，每次都调 REST 会持续消耗 API 配额。

极简版代码已在上方完整展示，可直接复制运行。生产版（含 WebSocket 重连后重判时段、按时段动态调整订阅列表）后续更新在 GitHub，搜索仓库 ai-agent-trading-sessions 或关注更新。

五、封装成 MCP 工具给 Claude 调用

刚才那段逻辑要给 Claude Desktop 或 Cursor 用，就要包成 MCP（Model Context Protocol）工具。核心只需要一段 schema 定义和一个服务挂载。

Schema 定义（暴露给 AI 的“说明书”）：

配置项	详细说明
工具名称	get_us_market_session
功能描述	获取当前美股交易时段。Agent 在做任何交易决策前，必须先调此工具判断现在是盘中、盘前还是盘后。
输入参数	无（自动获取当前时间）
返回逻辑	0 盘中 / 1 盘前 / 2 盘后 / 3 夜盘 / None 非交易时段

在 MCP Server 中注册实现（MCP Python SDK 示例）：

from mcp import Server, Tool

server = Server("market-sessions")

@server.tool("get_us_market_session")
def get_us_market_session():
    """获取当前美股交易时段"""
    return get_current_session()  # 复用刚才写的函数

MCP 配置提示：代码示例基于 MCP Python SDK。如遇导入报错，请对照 MCP 官方文档确认当前版本的正确导入路径——不同版本间 Server/Tool 的导入命名空间可能有微小差异。

Claude 调用效果： Agent 接到指令“帮我看看 AAPL 现在适不适合下单”，推理路径就会变成：

用户要下单 AAPL → 调 get_us_market_session → 返回 1 (盘前) → 盘前流动性不足，不适合市价大单 → 回复用户建议用限价单或等正盘。

Agent 自己完成了时段感知——不需要你在 prompt 里写“注意盘前盘后”，它自己查自己判断。

六、如果没有它，你要维护 3 套时段映射逻辑

把视野拉高一点。做金融 Agent 不太可能只盯美股，A 股和港股也要接。TickDB 覆盖美股（12,400+）、港股（4,300+）、A 股（6,000+），三个市场的时段规则极其分裂：

市场	时段复杂度	特殊机制	对 Agent 的映射难度
美股	4 段（盘前/正盘/盘后/夜盘）	夜盘覆盖 Blue Ocean ATS	高：需处理跨午夜区间
港股	3 段（盘前竞价/正盘含午休/收盘竞价）	午休不撤单但无成交	中：需识别午休空窗期
A 股	2 段（集合竞价/连续竞价）	9:15-9:25 特殊撮合规则	中：需区分竞价时段

要么自己维护 3 套时段映射逻辑，每次新增市场就加班加点对时区、写解析、配缓存。要么找一个已经把这层差异封装掉的接入层——TickDB 用同一个 trade_session 枚举覆盖了美股、港股、A 股三个市场。调哪个市场，返回的时段表用同一套字段语义，Agent 工具链里只需要一个 get_market_session(market) 函数。

美股盘前和 A 股集合竞价在语义上都映射为 1，这对 AI 来说是最友好的跨市场推理基础。

七、聊聊你的 Agent 场景

有了美股 API ≠ 有了盘前数据。这两件事文档里都写了，但大部分人第一次读文档会跳过时段部分——不是因为不重要，是因为正式时段能跑通的代码已经够让人忙的了。直到策略在盘前漏掉一个 5% 的跳空信号，才回头翻 API 文档里那一段不到一屏的 trade_session 说明。

如果 Agent 后续需要获取全量美股实时时段状态、夜盘覆盖，或配合 depth（订单簿）在盘前盘后做流动性验证，付费套餐可解锁完整数据能力——从免费测试 Key 开始跑通逻辑，再按需升级。

你的 Agent 跑在哪个时段上？有没有因为没接盘前数据错过信号？评论区聊聊。

本文数据来自 TickDB。