摘要

在云上搭建 AI 行情面板或数据管道时，选数据源最容易掉进一个陷阱：只看覆盖市场。A 股、美股、港股都覆盖了，就觉得“够用了”。但真正踩过坑的人知道，同样是“覆盖 A 股”，做历史回放和做实时推送对数据的要求完全不同——前者要历史深度与复权一致性，后者要推送稳定与时间戳语义清楚。本文从云上数据流的三种通道分工出发，给出六个选型闸门，帮助开发者在接入行情数据前建立自己的评估框架，而非依赖服务商排名。

---

你正在云上搭一套行情面板：看板用 WebSocket 刷新实时价格，回测模块用 REST 拉历史 K 线，AI Agent 通过 MCP 按需查询快照。三个通道，三种数据流，对上游行情数据源的要求完全不同。

此时最容易犯的错误，是拿着一份“覆盖市场列表”做决定——A 股、美股、港股都打勾了，就觉得这家数据源够用了。但同样是“支持 WebSocket”，推送的是 ticker 快照还是 K 线聚合结果，断流后有没有回补机制，时间戳是行情发生时间还是服务端处理时间——这些问题的答案，才决定了一条数据管道能不能在凌晨三点自动恢复，还是一直跑到策略回测偏差超标才被人发现。

选数据源不是在找“最好的一家”，而是在确认你愿意为哪类任务承担哪类工程约束。

---

一、云上行情数据流的三种通道

云上行情应用通常同时依赖三种数据通道，各自对上游有不同要求：

通道	用途	对数据源的要求
REST	历史回放、批量初始化、断流回补	返回结构稳定、字段口径清晰、时间窗口查询语义明确
WebSocket	实时看板、盘中监控、告警触发	推送稳定、重连后有状态标记、时间戳是行情发生时间而非到达时间
MCP	AI Agent 对话式查询	工具描述与返回结构一致、异常时有结构化错误返回、字段语义可被 LLM 理解

三种通道不能互相替代。 WebSocket 不是历史数据源，REST 不是实时推送通道，MCP 不适合放进自动化监控链路。你的选型需要为每种通道分别验证，而不是看“支持 WebSocket”就假设推送质量达标。

---

二、六个选型闸门

在确定目标市场后，用以下六个闸门逐项核验候选数据源。每道闸门对应一条数据管道可能的故障模式。

闸门	核验问题	不通过会怎样
① 市场匹配	目标市场的品种覆盖深度如何？退市股是否保留？成分股调整历史是否可查？	A 股回测缺少退市样本，收益被系统性高估
② 数据能力	历史 K 线深度、实时推送稳定性、盘口深度档位	回测窗口不够长，盘中高峰时段推送延迟堆积
③ 工程接入	API 设计是否一致？鉴权方式、错误码、限流策略是否文档化？	不同端点的鉴权和错误处理各自为政，维护成本线性增长
④ 字段口径	symbol 规则、时间戳语义、OHLCV 字段定义是否清晰可核对？	跨市场面板的时间轴天生不对齐，多源拼接字段映射出错
⑤ 维护成本	免费层限制、接口变更频率、团队协作时口径统一成本	初期零成本，后期接口一变全链路重写
⑥ AI 工具友好度	返回结构是否稳定？异常时返回空值还是错误码？MCP 支持是原生还是需自写适配层？	AI Agent 基于错误数据结构生成分析结论

每道闸门的权重因场景而异。 A 股回测场景，①市场匹配和②数据能力的权重远高于⑥AI 工具友好度；AI Agent 调用场景则正好相反。选型前先明确你的场景，再决定哪道闸门是“一票否决”，哪道可以暂时降低标准。

---

三、REST 通道：初始化与历史回放

REST 通道承载两类任务：系统初始化时的历史数据批量拉取，以及运行期间的断流缺口回补。这两类任务对数据源的核心要求是返回结构稳定、字段口径一致。

稳定性：同一端点、同一参数，今天返回的字段结构和三个月前是否一致？如果 last_price 在交易日返回字符串、非交易日返回 null，解析代码就需要为每一种情况单独写分支。时间窗口查询的语义也必须明确——start 和 end 是左闭右闭还是左闭右开？

口径一致性：A 股的复权方式（前复权还是后复权）是否在整个历史区间保持一致？美股盘前/盘后/常规交易时段的数据是分表存储还是混在一起？港股的非收市竞价时段的收盘价形成方式与 A 股集合竞价完全不同——同样是“收盘价”，形成机制不同，数据质量控制的起点也不同。TickDB 提供约 10 年 A 股历史 K 线，复权标识和 K 线周期可查，但退市样本和成分股调整仍需自行判断。

---

四、WebSocket 通道：实时更新与监控

WebSocket 通道承载实时看板和告警系统的数据流。它的核心风险不在“能不能连上”，而在“重连成功后数据是否连续”。

推送稳定性：盘中高峰时段推送延迟是否稳定？断流后重连，推送的第一批数据是否有状态标记（实时/回填/缓存）？如果没有状态标记，回填数据会以“实时数据”的面目进入系统，下游告警和看板无法区分。

时间戳语义：时间戳是行情发生时间还是服务端处理时间？跨市场场景中，不同市场的推送延迟天然不同——A 股的几十毫秒与美股的几百毫秒是正常差异。如果时间戳语义不统一，跨市场事件排序就可能颠倒。

TickDB WebSocket 提供实时行情推送，ticker、depth、trade 等频道按需订阅，但 volume_24h 在股票/期货推送中不包含，盘口需单独订阅 depth 频道。这些频道边界如果不在接入前弄清楚，消费端就会在空字段上做计算。

---

五、MCP 通道：给 AI Agent 的查询接口

MCP 通道是 AI 工具调用行情数据的标准化入口。它的核心要求不是推送速度，而是返回结构可被 LLM 稳定解析。

AI Agent 调用行情工具时，最隐蔽的错误不是调用失败，而是工具返回了格式正确但语义不清的数据——code=0 但 data 为空，last_price 为字符串但缺失时返回空字符串而非错误码。Agent 没有“这数据可能不完整”的判断能力，它会基于不完整的数据生成分析结论。

TickDB MCP 提供 get_ticker、get_kline、get_order_book、get_recent_trades 四个工具，Cursor 和 Claude Code 可直接配置调用。但 MCP 是给 AI 对话式按需查询设计的，不适合放进自动化监控链路——断流回补和实时告警应走 REST 和 WebSocket。

---

六、不同数据源类型适合什么任务

没有一家数据源在所有场景下都是最优解。以下按数据源类型，说明各自最适合的任务。

机构终端：金融数据的标准答案。Wind、Choice 等终端退市样本和成分股调整表最完整，适合需要完整数据口径的严肃回测。但数据锁在终端里，外部 AI 工具无法直接调用。

海外行情 API：美股开发者的首选。API 设计现代、文档清晰，WebSocket 推送稳定。但 A 股和港股覆盖是短板。

统一行情 API：跨市场的统一接入层。A 股、美股、港股、外汇、加密从一套接口拉，symbol 规则统一、时间戳语义一致，省去多源拼接和字段对齐的工作。TickDB 作为这类代表，REST/WebSocket/MCP/Skill/CLI 五种接入方式覆盖不同场景，MCP 支持让 AI 工具直接调用真实行情。但生态不如开源社区庞大，高阶定制需结合其他工具。

国内开源工具：A 股量化的社区基石。Tushare、Baostock 等初始成本极低，A 股覆盖广，退市股数据保留。但数据深度和实时性不如商业服务，不同工具之间数据口径可能不一致。

券商接口：行情和下单的直通车。已有 IB 账户的用户可直接接入，延迟可控。但跨市场整合成本高。

公共数据：零成本的起步选项。Yahoo Finance 美股日线覆盖广，短期验证方便。但长期维护压力大，接口变更频繁。

---

七、你的选择

在云上搭行情面板前，先回答两个问题：

1. 你的数据流主要走哪个通道——REST 回放、WebSocket 推送、还是 MCP 查询？
2. 这六个闸门里，哪一道是你的“一票否决项”——是字段口径不一致就直接换源，还是稳定性不达标才做决定？

没有一家数据源能同时满足所有要求。你的选择，取决于你愿意为哪类任务承担哪类工程约束。

---

标签：云上行情面板 / 数据源选型 / REST / WebSocket / MCP / AI Agent / TickDB / 火山引擎

本文以 TickDB 作为统一行情 API 示例。场景分析为通用评估框架，不构成服务商排名或投资建议。所有字段、端点和接入细节以各数据源官方文档和实测为准。