让 Cursor 帮你搞定美股 4 个时段:AI Agent 的时段感知实战
作者: TickDB Research · 发布: 2026/4/25 · 阅读: 8
标签: B/C 类, 知乎/掘金, 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。
通过 TickDB API 获取实时行情数据
一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送,免费开始使用。
免费领取 API Key查看 API 文档