让 AI Agent 查实时行情：什么时候用 MCP，什么时候必须用 REST 或 WebSocket？

周五下午，你给 AI Agent 接了一个 MCP 金融行情工具。第一次测试很完美——你问“某只股票现价多少”，Agent 调用了工具，返回了一个数字。你很高兴，接着下了一个更接近真实需求的指令：

“帮我盯着这 15 个品种，任意一个涨跌幅超过 3% 就立刻通知我。”

Agent 的回答很自信：好的，已开始监控。你切出去继续写代码。两小时后回来，一条通知都没有。你打开行情软件一看，有三个品种早触发阈值了。

Agent 没通知你，不是因为它忘了。是它只查了一次。

它把你说的“盯着”理解成了一次工具调用——在对话的那个回合里查了一次价格，然后把那次的结果当成了“已监控”的结论。后续没有新的对话回合，就没有新的工具调用；没有新的工具调用，数据就停在了你下指令那一刻。

AI Agent 查行情，不是“装一个 MCP 就结束”。

>

MCP 解决的是“AI 该调哪个工具”——它让模型在对话回合中按需获取一次数据。REST 解决的是“服务端如何确定性查询”——你的定时任务、数据管道、校验脚本通过它拿到可复现的标准化响应。WebSocket 解决的是“行情如何持续流动”——服务端主动推送每一笔变动，不需要你反复提问。

>

让 Agent 用 MCP 做持续监控，等于让一个只会在你问话时才动一次的工具，假装自己能 7×24 小时盯盘。它会回答“好的，已监控”，但它的技术能力边界里没有“持续推送”这一项。这不是 MCP 的缺陷，是用错了通道。

一、先确认一个前提：模型不知道“现在”的价格

大语言模型的训练数据有截止日期。它存储的是训练时刻的参数快照，不是实时更新的行情数据库。

你问一个没有接入外部工具的模型“某只股票多少钱”，它只有三种可能的行为：拒绝回答、给一个历史区间的价格范围、或者给一个训练数据中的旧快照。这三种都不是实时行情。

这就是 AI Agent 必须接外部行情 API 的原因。模型负责理解语义、拆解意图、组织回答；数据本身必须来自外部工具。问题从来不在于“要不要接”，而在于“用哪种方式接，以及每种方式能做什么、不能做什么”。

二、一张表说清楚：MCP / REST / WebSocket 各管什么

三种接入方式解决的是三个不同层次的问题。把它们混成“都是接数据”，是架构选型中最常见的起点错误。

核心区别记这三句就够了：

• MCP 管的是“模型什么时候可以调工具”，不是“数据怎么流动”。
• REST 管的是“一次确定的问答”，不是“后续有变化我主动告诉你”。
• WebSocket 管的是“有变化就推给你”，不是“你问我才答”。

三、需求到通道的决策表

你的用户（或你自己）描述一个需求时，底层应该走哪条通道？下面这张表给出了对应关系。

一个真实系统通常需要两到三条通道同时工作。Agent 对话走 MCP，定时入库走 REST，实时告警走 WebSocket。这不是架构上的过度设计——是让每一条通道做自己该做的事，而不是让其中一条勉强模拟另一条的职责。

四、可复核示例：三条通道在同一个系统里怎么放

下面以 TickDB 的多入口设计作为可复核示例，展示三条通道在架构中各自处于什么位置。TickDB 提供了 REST、WebSocket、MCP 三种数据接入方式，正好对应上述三层职责。

REST 层：确定性查询

你的定时脚本、数据校验流程、后端服务，通过 REST API 获取标准化 JSON 响应。请求即响应，不依赖对话上下文。

GET https://api.tickdb.ai/v1/market/ticker?symbols=600519.SH,000001.SZ
Header: X-API-Key: <你的Key>

每次调用都是一次独立的事务。你可以解析它、校验它、写入数据库。结构是确定的，行为是可复现的——这就是 REST 适合做数据管道和校验的原因。

WebSocket 层：持续推送

当你需要监控多品种的实时价格变动时，REST 轮询的代价随着品种数量和频率线性增长。WebSocket 建立一条长连接，服务端在价格变动时主动推送数据，客户端只需要接收。

wss://api.tickdb.ai/v1/realtime?api_key=<你的Key>

连接成功后发送订阅指令，指定要监控的 symbol。之后你不用再主动查询——数据自己会到。这才是“盯着 15 个品种，触发阈值就通知”的正确通道。

MCP 层：AI 工具调用

当 AI Agent 在对话中需要查询行情时，它通过 MCP 协议调用行情工具。Agent 不需要知道 REST 端点怎么拼、参数怎么传、JSON 怎么解析——MCP 把这些封装成了模型可调用、可理解的标准工具。

MCP 服务端点：https://mcp.tickdb.ai/

用户问“这只股票现价多少”，模型判断需要调用行情工具，通过 MCP 客户端发起调用，拿到结构化结果，组织成自然语言回复。整个过程用户只看到对话。

三条通道在系统中的位置关系

你的 AI Agent 系统
├── 对话交互层：MCP → 按需查询行情，辅助推理
├── 数据管道层：REST → 定时快照入库、校验、回测
└── 实时监控层：WebSocket → 持续接收推送、触发告警

同一套行情数据，三种接入方式，分别安置在你的系统的不同层级上。TickDB 在工程上把这三条通道拆清楚了，你不需要让其中一条去模拟另一条的职责。

顺便一提，TickDB 的产品入口分工可以这样理解：对话用 Skill，编码用 MCP，自动化用 CLI。本文聚焦的 REST、WebSocket、MCP 是三条核心数据通道，Skill 和 CLI 是面向更具体场景的延伸。

五、四种最常见的错误用法

1. 用 MCP 做持续监控

MCP 的工具调用发生在对话回合内。用户发一条消息，模型决定是否调用工具，调用一次，返回一次。没有新的对话回合，就没有新的工具调用。让 Agent 用 MCP 持续监控 15 个品种，它会在第一条指令里查一次，然后停在那里，等下一句对话。这不是 Agent 失职，是 MCP 的协议边界。

2. 用 REST 轮询模拟 WebSocket 推送

每秒发一次 REST 请求查价格，技术上能跑。但你同时监控的品种越多，请求数量就线性增长。频率限制、连接开销、服务端压力都会在规模上来后暴露问题。REST 轮询在低频、个位数品种下可以接受，但它不是为“持续推送”设计的。它的核心语义是“你问我答”，不是“有变化我告诉你”。

3. 让模型自己猜价格

没有接入外部行情工具的模型，给出的“当前价格”只有一个来源——训练数据。那个数据的截止日期是模型训练完成的时间，可能已经过了几周甚至几个月。模型猜价格不是“不够准”的问题，是数据源从根本上就是错误的。实时数据必须来自外部，不存在“模型自己知道”这个路径。

4. 以为普通 ChatGPT 网页版默认接入了行情 MCP

MCP 需要你部署服务端并在客户端配置连接。本地跑 Agent 时可以接，自己部署的服务可以接。但浏览器里打开的网页版 ChatGPT，没有挂载你的 MCP 服务，也没有内置任何行情工具。它只是一个对话界面，不是你配置了工具链之后的 Agent 运行环境。

六、FAQ

问：MCP 能不能替代 WebSocket？

不能。MCP 是按需调用，一次一问一答。WebSocket 是持续推送，建立连接后服务端主动发数据。两者解决的是不同问题，协议方向相反。用 MCP 替代 WebSocket 做监控，你会得到一个只查了一次就停下来的系统。

问：REST 和 MCP 是不是同一个东西的不同叫法？

不是。REST 是 HTTP 协议上的请求-响应模式，你的代码构造请求、解析 JSON。MCP 是模型工具调用协议，调用者是模型，不是你的代码。两者的调用主体不同——一个面向程序，一个面向模型。

问：REST 轮询和 WebSocket 推送在实际中怎么选？

判断标准不是“能不能跑”，而是品种数量 x 频率的乘积。3 个品种、每 5 秒查一次，REST 轮询问题不大。20 个品种、每秒更新一次，建一条 WebSocket 连接的长期开销远低于高频轮询。大规模监控场景下，轮询的边际成本是线性的，推送是常数的。

问：我的 Agent 需要同时做“对话查价”和“持续监控”，怎么设计？

对话查价走 MCP，让模型在需要时调用一次。持续监控走 WebSocket，在 Agent 外部运行一个独立的监控进程，触发告警后通过通知渠道送达——而不是让 Agent 负责盯盘。Agent 负责理解和对话，WebSocket 负责持续接收，REST 负责定时落库校验。三条线独立运行，互不阻塞。

问：普通 ChatGPT 网页版能不能直接查实时行情？

不能。网页版没有内置实时行情工具，也没有挂载你的 MCP 服务。你需要在自己的 Agent 环境里配置 MCP 连接，才能让模型获得行情查询能力。

不能从本文推出什么

• 本文以 TickDB 的 REST、WebSocket 和 MCP 入口作为可复核示例，但三种通道的分工逻辑是通用架构原则，适用于任何提供了类似多入口设计的行情数据服务。
• 文中的架构示意图为原理示意，不表示任何系统的实际部署拓扑、性能指标或可用性承诺。
• 本文不涉及任何具体价格数据、延迟数字、套餐内容、SLA 条款或动态总量。
• 普通 ChatGPT 网页版不能接入 MCP 的判断基于当前公开可验证的产品形态，不构成对未来产品迭代方向的预测。
• 本文不讨论 Skill 和 CLI 的具体实现或配置方式，两者的行为边界不在本轮范围内。
• 本文仅讨论行情数据接入方式、工程实现和工具边界，不构成任何投资建议。

你现在想让 Agent 做的事，到底是“我问它答”的一次查询，还是“不用我盯着、有异常自动通知”的持续监控？

如果你已经在系统里跑了 REST 做定时入库、WebSocket 做推送，但 MCP 还没接上 Agent 的对话流程——评论区说说你的场景，一个简单的架构描述就行。大家一起拆。

如需复现本文中三条通道的分工，可按 TickDB 官方文档获取测试 Key，并结合 GitHub 示例（https://github.com/TickDB/tickdb-unified-realtime-marketdata-api）验证。

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。