A股行情数据源选型：面板、脚本、AI各接一套的代价有多大？
TickDB Research ·
A股行情数据源选型：面板、脚本、AI各接一套的代价有多大？
摘要：很多团队做行情产品时，把“查价格”“拉K线”“做实时看板”“让AI回答行情问题”拆给了不同来源。开始看似省事，后来却要反复处理代码格式、字段名称、时间口径和数据留痕。更稳妥的起点，是先选一层能被自己验证的数据入口。本文用一次当天重新运行的TickDB实测，检查REST ticker、REST K线和WebSocket订阅三条基础链路，说明一套A股行情数据层能解决什么，又不能替你解决什么。
这篇文章解决什么问题
一个行情面板、一段研究脚本和一个会回答问题的AI工具，表面上是三件事。但它们的第一层需求其实相同：都需要一份说得清来源、字段和时间的行情数据。
很多人是在系统长大以后才发现问题。面板从一个接口取最新价，研究脚本从另一个来源拉K线，AI又根据第三套信息回答问题。每个局部看起来都能用，可一旦数字不一致，就没人能快速解释：是哪一个symbol、哪一个字段、哪一个时间窗口出了问题？
产品选型的第一问，不是“它有多少功能”，而是“我能不能把它放进自己的数据链路，并且每一步都能复核”。
本文的核心方法论
这篇文章只做一件事：用TickDB对A股样本跑通REST ticker、REST K线和WebSocket订阅三条基础链路，说明一套统一行情数据层能解决什么，不能解决什么。全文的逻辑结构是——
是什么：一套A股行情数据层，至少要能回答三类问题——查快照时能不能确认symbol和字段身份，拉K线时能不能确认周期和OHLCV契约，做实时面板时能不能确认连接和订阅链路。这三类问题不解决，面板、脚本和AI工具就是各说各话。
为什么：很多人把数据源当成“能出数字就行”的工具，但不同数据源的symbol格式、字段名称、时间戳语义各不相同。等系统长大、数据源增多、团队成员变多后，每一次数字不一致都要花时间排查——不是策略错了，不是模型错了，是三个数据源对“同一个价格”的定义不一样。
怎么样：先对三个A股样本发ticker请求，验symbol一致性和字段可解析性；再用600519.SH拉K线，验周期、OHLCV字段和字段之间的逻辑关系；最后用WebSocket订阅ticker，验连接和订阅确认链路是否走通。每一步都配真实终端截图、字段核对表和最小校验代码。最后给一张三条链路的检查清单，你可以直接拿去验自己的候选数据源。
这套方法不绑定TickDB——你用任何行情API，都可以用同样的逻辑跑一遍ticker、K线和WebSocket，确认三条基础链路是否能被程序化验证。
读完你能拿走什么
- 一套A股行情数据层的最小验收框架：ticker验身份，K线验周期和OHLCV契约，WebSocket验连接和订阅链路。
- 三份可直接运行的校验代码片段，覆盖REST ticker、REST K线和WebSocket订阅的核心校验逻辑。
- 一张三条链路的检查清单，每次切换数据源、接入新品种或排查数据不一致时直接对照。
- 一套“能证明什么、不能证明什么”的边界声明，帮你区分接入验证、交易信号和生产稳定性。
一套行情数据层，先服务三种任务
对大多数A股应用来说，先把下面三类任务分清，比一上来堆功能更重要：
| 你的任务 | 先需要什么 | 本文的验证方式 |
|---|---|---|
| 查询某只股票当前快照 | ticker与字段身份 | REST ticker |
| 准备历史图表或研究样本 | K线周期与OHLCV字段 | REST kline |
| 做持续更新的面板或监控 | 连接与订阅链路 | WebSocket ticker |
它们不是三种互相替代的产品，而是同一条数据链路上的不同环节。
TickDB在这里的位置，是作为面向开发者、AI Agent、量化研究者和金融应用团队的行情数据API。它支持REST、WebSocket、MCP、Skill、CLI等接入方式；本文只验证其中REST与WebSocket的三条A股基础路径。AI工具调用（MCP）需要单独跑证据，不能从这次REST成功直接推出。
第一件事：用ticker确认“你问的是谁，拿到的是谁”
这次我重新请求了600519.SH、000001.SZ和300750.SZ。请求使用REST GET /v1/market/ticker，通过X-API-Key鉴权，并明确传入type=stock。
本轮运行中，HTTP返回200、业务code=0，三个请求symbol都出现在返回数组里。脚本没有只看“有价格”，还逐项检查了：返回的symbol是否和请求一致；type是否为stock；last_price等数值字段能否被程序解析；timestamp是否是13位毫秒整数；返回是不是数组，而不是被客户端错误地当成一个对象。
这一步的产品价值不在于“展示三只股票的价格”，而在于让你的面板、脚本或后续AI流程先有一份可核对的结构化输入。
下面是本次runner中实际使用的最小ticker校验逻辑：
resp = requests.get(
"https://api.tickdb.ai/v1/market/ticker",
headers={"X-API-Key": os.environ["TICKDB_API_KEY"]},
params={
"symbols": "600519.SH,000001.SZ,300750.SZ",
"type": "stock",
},
timeout=20,
)
payload = resp.json()
rows = payload.get("data")
assert resp.status_code == 200
assert payload.get("code") == 0
assert isinstance(rows, list)
assert {row["symbol"] for row in rows} == {
"600519.SH", "000001.SZ", "300750.SZ"
}
第二件事：K线不是“历史价格列表”，而是一份周期契约
当你从最新价走向图表、研究或回测，真正要检查的不只是“有没有10年数据”之类的宣传句，而是请求的周期、返回的字段和字段之间的关系。
本轮用600519.SH请求interval=1d、limit=3的K线。结果返回3条样本，symbol和interval与请求相符，单根K线包含time/open/high/low/close/volume/quote_volume。
这里最值得保留的不是某个具体价格，而是校验习惯：high不应低于开盘、最低和收盘等价格；low不应高于这些价格；time的精度需要明示，但不能被误解为延迟承诺；close是周期字段，不能和某次ticker的last_price混成同一件事。
如果你把数据层建立在这样的可检查约束上，后面换成图表、导出CSV或交给分析工具时，至少知道自己传递的是哪一类数据。
第三件事：WebSocket连上了，不等于实时面板已经完成
做行情面板时，最诱人的一句话是“我已经连上WebSocket了”。但连接成功只是起点。
本轮WebSocket使用wss://api.tickdb.ai/v1/realtime?api_key=YOUR_API_KEY，订阅ticker的实际JSON为{"cmd": "subscribe", "data": {"channel": "ticker", "symbols": ["600519.SH"]}}。
这次运行收到connected和subscribe成功确认。因此，能确认的是连接和订阅结构走通；不能确认的是交易时段的持续推送、推送频率、端到端延迟或生产稳定性。
这个边界很重要。真正的面板还要由应用自己补上断线处理、本地接收时间、状态标识和异常记录。TickDB提供数据入口，不会替你的应用自动完成这些业务侧工作。
TickDB适合放在什么位置
如果你只是偶尔看一眼价格，成熟行情软件已经足够。TickDB更适合这些需要把数据“拿出来用”的场景：把A股数据接进自己的研究脚本、图表或监控服务；需要REST快照、历史K线和WebSocket订阅分别承担不同工作；希望在A股之外继续接入港股、美股、外汇、贵金属、指数或加密货币，而不是为每种资产重新设计一套数据入口；想让AI Agent处理真实行情数据，但愿意先把工具调用、原始返回和结论之间的链路留痕。
它不替你给出投资结论，也不承诺策略有效。它解决的是更前置的工程问题：让行情数据能被程序查询、被字段校验、被不同应用复用，并在出现差异时有迹可查。
选择前，先用自己的symbol跑这张清单
不要因为本文调用成功，就直接替自己的场景下结论。用你的API Key、你的关注标的和目标时间段，至少走完下面三项：
| 检查 | 你要确认什么 |
|---|---|
| ticker | 请求和返回的symbol是否一致，字段是否能被解析 |
| kline | 周期、OHLCV与时间字段是否符合你的图表或研究需求 |
| WebSocket | 是否收到了连接、订阅确认；盘中另测连续更新与异常恢复 |
一次运行成功只能建立一个验证基线，不能证明所有品种、所有时段和所有场景都一样。可复核，才是后续接入、扩展和排错的起点。
FAQ
Q1：TickDB是行情软件还是数据API？
它更适合作为数据API使用：开发者或金融应用把结构化行情接到自己的脚本、面板、监控和AI工具流程中。
Q2：REST、WebSocket、MCP要同时用吗？
不必。REST适合主动查询快照和历史数据；WebSocket适合持续更新；MCP面向支持工具调用的AI环境。应按场景选，并各自验证，不能混用鉴权和证据。
Q3：这次验证能证明实时性或稳定性吗？
不能。本次只证明了A股样本的REST ticker、REST K线，以及WebSocket的连接和订阅确认。延迟、交易时段连续推送与稳定性需要另做连续采样。
Q4：想先看官方资料，从哪里开始？
可先看TickDB官方GitHub：https://github.com/TickDB/tickdb-unified-realtime-marketdata-api
最后
当一个数据源能先帮你把“请求了谁、返回了谁、什么时候拿到、字段代表什么”说清楚，面板、研究脚本和AI工具才有条件站在同一份事实之上。
这比看到一个漂亮的最新价更重要。
本文仅展示一次A股行情数据接入验证，不构成投资建议。具体字段、端点和可用范围以官方文档及你的当日实测为准。