Codex 接入实时行情 MCP：从配置、鉴权到字段踩坑

TickDB Research ·

目录

一、AI 写的量化代码，行情接口全是编的

上周二下午 4 点，我在 Codex 里输入了这样一句话：

“写一个 A 股双均线策略，用贵州茅台 600519 的日线数据，5 日均线上穿 20 日均线买入，下穿卖出。”

Codex 秒回了 120 行 Python。逻辑非常漂亮：均线计算、交叉判断、仓位管理，甚至贴心地加了止损。

然后我点了 Run。

ModuleNotFoundError: No module named 'stock_data_api'

翻到代码第三行：

from stock_data_api import get_kline_data

这个 stock_data_api 模块根本不存在。AI 编了一个。

我花了接下来的 40 分钟做一件事：手动替换所有行情调用。把 get_kline_data("600519", "daily") 替换成真实的 HTTP 请求，补上鉴权 Header，处理返回 JSON 的嵌套路径。

Codex 写量化策略最大的痛点：AI 逻辑能力够了，但它不知道真实的行情 API 长什么样。 默认工具集里只有文件读写、shell 执行这些基础能力，没有行情查询工具。所以它只能编一个函数名，期待你自己实现。

这个问题在 Codex 支持 MCP 之后有了一个确定的解法——不是让 AI 变得更聪明，而是给它装上一个真实的工具目录。

二、MCP：给 Codex 装上真实的工具目录

MCP 的全称是 Model Context Protocol，可以理解为 Codex 的“插件协议”。通过配置一个 MCP Server，你可以在 Codex 的工具列表里增加外部能力——比如行情查询、K 线拉取、估值计算。

不用 MCP 时，Codex 的工具箱大概长这样：

- read_file
- write_file
- execute_command
- search_code

接入行情 MCP 后，工具箱变成：

- read_file
- write_file
- execute_command
- search_code
+ get_ticker           ← 查实时行情
+ get_kline            ← 拉 K 线
+ get_kline_latest     ← 最近一根 K 线
+ get_order_book       ← 盘口深度
+ get_recent_trades    ← 成交明细
+ get_market_metrics   ← 估值指标
+ get_capital_flow     ← 资金流向
+ get_available_symbols ← 品种列表
+ get_intraday         ← 分时数据
+ get_kline_intervals  ← 可用 K 线周期
+ get_stock_info       ← 品种基本信息
+ get_trade_days       ← 交易日历
+ get_trading_sessions ← 交易时段

这些工具不是 AI 编的，是 MCP Server 暴露的真实端点。AI 调用 get_ticker 时，背后走的是 https://api.tickdb.ai/v1/market/ticker。AI 不需要知道 URL、不需要知道鉴权方式——它只看到工具名和参数，MCP 中间层帮它完成实际的 HTTP 调用。

这就是核心区别：AI 从“编接口”变成了“调工具”。

三、配置四步走：从零到跑通第一个查询

以下步骤基于 codex-cli 0.131.0-alpha.9 实测。版本不同时字段名可能有差异，以 codex mcp add --help 输出为准。

第一步：确认 Codex CLI 已安装

codex --version
# 输出版本号即表示已安装

第二步：添加 MCP Server

codex mcp add tickdb --url https://mcp.tickdb.ai/

执行成功后，Codex 会在 ~/.codex/config.toml 中写入 MCP Server 条目。

确认配置文件中包含以下三项（不要直接 cat 整个文件，密钥会暴露）：

grep -E "\[mcp_servers.tickdb\]|url|http_headers" ~/.codex/config.toml

期望看到：

[mcp_servers.tickdb]
url = "https://mcp.tickdb.ai/"
http_headers = { "X-TickDB-Key" = "***" }

第三步：配置 API Key

打开 ~/.codex/config.toml，确认 MCP 段格式如下：

[mcp_servers.tickdb]
url = "https://mcp.tickdb.ai/"
http_headers = { "X-TickDB-Key" = "你的API_KEY" }

两个高频配置错误：

正确错误后果
文件路径：~/.codex/config.toml~/.codex/mcp.json（Claude Code 的路径）配了不生效
Header 字段名：X-TickDB-KeyAuthorization: Bearer鉴权失败，返回 1001
配置键名：http_headersheaders（旧版或文档差异）不同版本字段名可能不同，以当前版本 --help 为准

关于 config.toml vs mcp.json：Codex 的 MCP 配置存储在 ~/.codex/config.toml 中，不是 .codex/mcp.json。这是 Codex 与 Claude Code（使用 .mcp.json）的关键差异。照 Claude Code 的教程配 Codex，会卡在第一步。

第四步：验证工具已加载

在 Codex 对话中输入：

请列出你当前可用的所有 MCP 工具

如果配置成功，Codex 会列出以 get_ 开头的 13 个工具。看到这个列表，说明 AI 已经“知道”这些工具的存在了。

四、三个验证示例

配置完成后，用三个最小化示例确认每个工具都能正常返回数据。

示例 1：查实时行情

在 Codex 中输入：

用 get_ticker 查询贵州茅台 600519.SH 和腾讯控股 700.HK 的实时行情

期望返回：两个品种的 last_price、volume_24h、high_24h、low_24h、timestamp。

实测发现：get_ticker 同时查询多个品种时可能触发 3001 限流。如果遇到限流，拆成单品种逐个查询，间隔 1 秒以上。这个坑在第五节细说。

示例 2：拉 K 线

在 Codex 中输入：

用 get_kline 拉取腾讯控股 700.HK 的日线数据，最近 10 根，interval 用 1d

期望返回：10 根 K 线的数组，每根含 time、open、high、low、close、volume。

字段提醒：K 线用 close，ticker 用 last_price，两个接口不可混用。

示例 3：估值对比

在 Codex 中输入：

用 get_market_metrics 查询 AAPL.US 和 600519.SH 的估值指标，对比 PE 和 PB

期望返回：两个品种的 pe_ttm_ratio、pb_ratio 等字段。

字段提醒：字段名是 pe_ttm_ratio 不是 pe_ttm，是 pb_ratio 不是 pb。

五、踩坑实录

以下是我在配置和验证过程中实测遇到的问题。每个都能让新手卡住一段时间。

坑现象原因正确处理
限流 3001get_ticker 查多个品种报 Rate limitTickDB 对 ticker 端点有频率限制拆成单品种查询，间隔 ≥ 1 秒；或改用 WebSocket 订阅
K 线字段错用在 K 线返回里取 last_price 报 KeyErrorK 线用 close，ticker 用 last_price不同接口字段名不同，对照速查表使用
时间单位不一致recent_trades 的 timestamp 是秒，K 线的 time 是毫秒不同接口返回的时间字段粒度不同使用前确认单位，不要假设所有 timestamp 都是毫秒
配置文件路径错误配了 mcp.json 不生效Codex 用 config.toml 不是 mcp.json确认路径为 ~/.codex/config.toml
Header 键名写错鉴权失败 1001必须用 X-TickDB-Key，不是 Authorization: Bearer对照第三步配置示例
港股代码前导零0700.HK 个别情况下可能查不到标准格式为 700.HK，部分接口可能容错但不建议依赖统一使用 700.HK 无前导零格式

六、13 个 MCP 工具速查

以下为 codex-cli 0.131.0-alpha.9 环境中实测可用的 13 个工具。工具名和参数以当前版本为准。

工具名功能关键参数
get_ticker实时行情快照symbols（逗号分隔）
get_kline历史 K 线symbol, interval（1m/5m/15m/30m/1h/4h/1d/1w）, limit
get_kline_latest最近一根 K 线symbols
get_intraday分时数据symbol
get_order_book盘口深度symbol
get_recent_trades成交明细symbol, limit
get_market_metrics估值指标（PE/PB）symbols
get_capital_flow资金流向symbol
get_available_symbols品种列表market（CN/HK/US/GLOBAL）, type
get_stock_info品种基本信息symbol
get_trade_days交易日历market, start_date, end_date
get_trading_sessions交易时段market
get_kline_intervals可用 K 线周期无

七、进阶：让 AI 写一个双均线策略

三个示例跑通后，可以回到最初的需求——让 Codex 写出能真正运行的双均线策略。

在 Codex 中输入：

写一个 A 股双均线策略：
- 品种：600519.SH（贵州茅台）
- 日线数据，5 日均线上穿 20 日均线金叉买入，死叉卖出
- 用 get_kline 拉取最近 120 个交易日的日线
- 初始资金 10 万，每次满仓进出
- 输出最终收益率和最大回撤
- 注意：get_kline 返回的收盘价字段是 close 不是 last_price
- 注意：get_kline 的 time 是毫秒级，get_recent_trades 的 timestamp 是秒级，处理时区分单位

Codex 应该能做到：

  1. 调用 get_kline(symbol="600519.SH", interval="1d", limit=120) 拉数据
  2. 用 pandas 计算 5 日和 20 日均线
  3. 判断金叉死叉，生成交易信号
  4. 输出收益率曲线和回撤

验证清单（逐项确认）：

  • 均线计算是否正确（df['close'].rolling(5).mean()）
  • 字段名是否用了 close 而非 last_price
  • 时间戳单位是否处理正确
  • 是否处理了空数据或限流重试

八、配置前 vs 配置后

配置 MCP 之前

问题具体表现
AI 虚构 API生成 from stock_data_api import get_kline_data 等不存在的模块
无真实行情策略脚本用随机数模拟价格走势
重复劳动每次让 AI 写策略，都要手动替换行情调用代码
无法验证不确定 AI 写的交易逻辑在真实数据上是否成立

配置 MCP 之后

变化效果
AI 自动发现 13 个行情工具不再编造函数名，直接调用 get_kline
真实数据驱动策略跑在贵州茅台的真实日线上
一次配置，跨会话共享所有 Codex 会话共用同一 MCP 配置
跨市场覆盖同一套工具查 A 股、港股、美股、加密

MCP 在这里提供的是一个工具目录——它让 Codex 知道“行情数据可以这样获取”，并且这个获取方式是真实可执行的，不是文档里的示例 URL。接入后 AI 从“我能写策略但数据你自己搞定”变成了“我能写策略，数据也可以直接调”。

你在用 Codex 写量化代码时，AI 编过什么离谱的接口？配置 MCP 时卡在哪一步？评论区聊。

📡 行情数据由 TickDB.ai 提供

  • MCP 端点：https://mcp.tickdb.ai
  • 文档：https://docs.tickdb.ai

排错清单

问题检查项
配置不生效确认路径为 ~/.codex/config.toml（非 mcp.json）
鉴权失败 1001确认 Header 名为 X-TickDB-Key（非 Authorization: Bearer）
工具未加载在 Codex 中执行“列出当前可用的所有 MCP 工具”确认 13 个可见
限流 3001多品种查询拆成单次请求，间隔 ≥ 1 秒
K 线字段报 KeyError用 close 而非 last_price
时间戳对不上K 线 time 毫秒级，成交明细 timestamp 秒级，分别处理

修订对照表

问题修改前修改后
API Key 暴露让读者 cat config.toml改为 grep 脱敏命令
配置字段headers + type = "http"http_headers（以 Codex 0.131 实测为准）
13 个工具名含 get_depth/get_calc_index/search_symbols 等不存在工具替换为实测工具名
踩坑表3 个坑新增“限流 3001”“时间单位不一致”共 6 个坑
0700.HK 表述“格式错误”“建议无前导零，不依赖兼容行为”
时间戳表述“所有时间字段均为毫秒 UTC”“不同接口粒度不同，使用前确认”
文末自检/验证提示含营销 checklist + “贴给我”导流语删除，改为排错清单 + 自主验证引导
域名露出4 处精简为 MCP 端点 + 文档各一次

文章已按 Codex 审核意见完成大修。是否 A) 继续下一篇 B) 进一步审查修正 C) 提取沸点文案？

相关文章

AI Agent 框架接金融行情数据前，先检查这 7 个工程风险

> 本文不是框架排名，而是一份金融行情数据接入前的工程风险清单。每个风险点都附了检查方法和修正示例。 --- 一、不同框架，同一个坑 假设你用三个不同的 Agent 框架跑同一个任务——“每 30 分钟查一次价格，超过阈值时汇总分析”。 其中一个 Agent 把 ticker 快照的 （24 小时成交量）当成了单根 K 线的成交量，量级差了几千倍。另一个在 API 限流后陷入重试死循环，两分钟烧掉

TickDB Research ·

Qwen 已返回 `tool_calls`，为什么你的行情回答仍可能不可信？

摘要： Qwen 返回 ，不代表行情查询已经成功。本文从掘金开发者常见排错场景出发，拆解“触发工具、应用执行、结果校验、工具回填、最终回答”的最小可信链路，并给出未触发工具、查询失败或空结果、回填错误三个必须阻断价格回答的失败分支。TickDB 仅作为应用端只读行情数据路径示例出现。 你在日志里看到了这样的返回： 这只能说明一件事：模型提出了一个工具调用请求。 它不等于应用程序已经拿到行情，不

TickDB Research ·

Kimi 金融数据接入避坑：用 `tool_calls` 查询实时行情，而不是让模型猜价格

> Kimi 可以判断用户何时需要查询行情，但当前价格不能依靠模型猜测。本文基于 Moonshot 官方 流程，以 TickDB REST 为示例，拆解模型协议、本地工具函数与行情 API 的三层边界，并提供字段速查、最小 Python 实现和发布前验证清单。如果你让一个大模型回答“ 现在多少钱”，最危险的情况不是它报错，而是它给出一个语气非常确定、却没有实时数据来源的答案。 对于使用 Kim

TickDB Research ·

LangGraph 多 Agent 行情接入：节点之间传递实时数据的 3 种姿势

目录 - 一、当你的金融 Agent 节点“各说各话” - 二、姿势 1：State 共享——最简单，但 reducer 行为容易忽略 - 三、姿势 2：Tool 封装——最灵活，但 API 调用量是隐藏成本 - 四、姿势 3：Subgraph 组合——最工程，但状态映射是调试重点 - 五、三种姿势权衡矩阵与数据一致性策略 - 六、完整示例：盘前-盘中-盘后多 Agent 协同 - 七、FAQ -

TickDB Research ·

Python 全球指数监控面板：TickDB + REST + WebSocket 完整方案

目录 - 一、凌晨两点半，监控屏上的数字不动了 - 二、“最新价”在不同时区下的语义分裂 - 三、比报错更可怕的，是“看起来没问题” - 四、取值降级链：用状态机收敛四种数据时效 - 五、代码实现（含异常处理与多线程同步） - 六、从多个数据源到一个统一接口 - 七、从 4 个指数到 40,000 个品种 --- 一、凌晨两点半，监控屏上的数字不动了 去年冬天凌晨 2:37，我被叫醒。 “全球指数

TickDB Research ·