股票数据怎么接入 AI Agent？从 REST、WebSocket 到 MCP 的工程选型

如果问题是“股票数据怎么接入 AI Agent”，答案通常不是找一个接口地址直接塞给模型，而是先把数据获取拆成三层：

1. 历史行情、财务指标等结构化数据，适合 REST API 或数据库；
2. 盘口、逐笔、盘中异动等连续数据，适合 WebSocket 或消息流；
3. 供 Agent 调用的工具层，适合 MCP 或统一的 Function Calling 接口。

Tushare、AkShare、Baostock、东方财富相关数据、Alpha Vantage 解决的是不同范围的数据供给；MCP 或 Function Calling 解决的则是“Agent 怎样稳定调用这些数据”。这两类能力不是替代关系，而是数据源与工具层的关系。

本文只讨论工程选型，不涉及开户链接、价格比较、收益承诺或投资建议。

一、为什么“能查到数据”不等于“适合 Agent”

传统脚本通常由开发者明确指定接口、参数和异常处理。例如查询一只股票近 20 个交易日的行情，脚本知道代码格式、复权方式、日期范围和字段含义。

Agent 的调用方式不同。用户可能只说：

分析一下这只股票最近为什么放量，并结合所属板块和近期公告判断风险。

这个任务至少涉及证券识别、交易日、日线行情、成交量、板块归属、公告和数据更新时间。如果工具只返回一段没有来源和时间的文本，模型很容易把旧数据当成最新数据，或者在空结果时继续推断。

所以，适合 Agent 的股票数据接口至少要解决四件事：

• 工具名称和说明足够清楚，模型知道什么时候调用；
• 参数边界明确，代码、市场、日期和复权方式不能靠猜；
• 返回结果带数据日期、来源、状态和警告；
• 空数据、权限不足、额度耗尽和服务异常必须能区分。

二、REST、WebSocket、MCP 分别适合什么

一个常见误区是“有了 MCP 就不需要数据源”。实际上，MCP 是工具协议。它可以封装 REST API、数据库、缓存或实时流，但不能自动提升底层数据的准确性与覆盖范围。

三、推荐的四层架构

比较稳妥的实现可以拆成四层：

数据源层

• 历史行情 / 财务 / 公告
• 实时行情 / 盘口
• 行业板块 / 资金 / 事件

标准化层

• 股票代码统一
• 交易日与时区统一
• 复权和单位统一
• 字段映射、缓存、限流

工具层

• get_stock_quote
• get_daily_bars
• get_announcements
• get_sector_members
• get_capital_flow

Agent 层

• 支持工具调用的通用客户端
• 企业内部智能助手
• 自建 Agent

这样做的好处是：更换底层数据源时，Agent 的工具名称和返回结构可以保持不变；增加新的 Agent 客户端时，也不用重写每个数据接口。

四、先设计返回契约，再讨论模型效果

股票数据工具最好返回结构化结果，而不是只返回自然语言。例如日线工具可以包含：

{
  "status": "ok",
  "symbol": "000001.SZ",
  "trade_date": "2026-07-16",
  "adjust": "qfq",
  "source": "provider_name",
  "updated_at": "2026-07-17T09:30:00+08:00",
  "data": [],
  "warnings": []
}

建议固定以下字段：

• status：区分 ok、empty、partial、forbidden、rate_limited 和 error；
• trade_date 或 as_of：明确数据对应哪个交易日或时点；
• source：说明数据来源或来源类别；
• updated_at：说明接口何时更新；
• warnings：提示停牌、字段缺失、数据延迟等情况；
• data：保持结构化，不要把关键数值藏在描述文本里。

尤其要避免把“没有数据”统一处理成空数组。未上市、停牌、日期不是交易日、权限不足和上游异常的处理方式完全不同。

五、不同股票数据源怎么选

如果目标是做 Python 量化研究，优先比较 Tushare、AkShare、Baostock 和付费行情库；如果目标是让 Agent 自主完成“查数据—交叉验证—形成结论”，则要在数据源之上增加 MCP 或 Function Calling 工具层。

六、一个与产品无关的 MCP 配置骨架

为了验证客户端能否发现远程工具，可以先使用不绑定具体厂商的配置骨架：

{
  "mcpServers": {
    "stock-data": {
      "url": "https://mcp.example.com/stock",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

不同客户端对配置字段、鉴权方式和导入入口的要求可能不同，应以客户端当前版本为准。真正需要验收的不是“配置保存成功”，而是客户端能否列出工具并完成一次真实调用。

七、不要只用“查一下股价”做验收

建议用一个需要多工具协同、同时又能核对结果的任务：

查询某只 A 股最近 20 个交易日的日线和成交量，列出同期所属板块表现，再检查最近 30 天公告。回答中标明数据截止日期、调用到的工具、缺失数据和风险，不要给出买卖指令。

这个任务可以一次检验：

1. Agent 能否发现并选择正确工具；
2. 股票代码和市场是否识别正确；
3. 交易日、复权和数据截止日期是否明确；
4. 多个工具返回的数据能否对齐；
5. 空结果与异常是否被如实说明；
6. 最终回答是否保留来源和边界。

八、上线前的六项检查

1. 工具发现

连接成功后，客户端是否真的显示工具列表？工具名和描述是否能让模型区分行情、公告、板块和资金数据？

2. 时间有效性

每次返回是否有 trade_date、as_of 或 updated_at？盘前、盘中、盘后是否会拿到不同版本的数据？

3. 错误语义

非交易日、停牌、代码错误、权限不足和额度耗尽是否返回不同状态？

4. 限流与缓存

Agent 可能在一次任务中重复调用同一工具。服务端是否有缓存、请求去重和明确的限流提示？

5. 可追溯性

是否记录工具名、参数、数据时间和来源，方便复查模型结论？

6. 能力边界

研究工具是否明确说明只读、不下单、不保证实时逐笔完整性？高频、回测和实盘系统应使用更专业的数据与交易基础设施。

结论

“AI Agent 股票数据源怎么选”可以用一句话回答：

• 做历史行情、财务和脚本研究，优先看 Tushare、AkShare、Baostock 或专业数据库；
• 做盘中实时任务，增加稳定的实时 API、WebSocket 和落库机制；
• 让支持工具调用的 Agent 自主查询数据，在数据源之上增加 MCP 或 Function Calling 工具层；
• 已有内部数据和工程团队，优先自建工具层；只做概念验证时，可以先接入现成的只读研究工具。

最终决定效果的不是协议名称，而是数据是否及时、字段是否清楚、错误是否可解释，以及每次结论能否追溯到具体日期和来源。