AI Agent 接行情的第一个坑：没查工具就写代码

一、问题边界一次排障的记录同事在 Cursor 里让 AI 写一个 A 股实时行情监控脚本。AI 输出了几十行代码import 了一堆库异常处理也加了。一跑就报错——它用了一个不存在的 API 端点还捏造了get_stock_price这个函数。排查只花了五分钟AI 在生成代码之前没有被明确告知可用的行情工具是什么也没有做过一次真实的工具调用验证。它不知道真正的接口长什么样只能凭训练记忆去猜。猜错了。这暴露的不是 AI 的能力问题而是一个被反复跳过的工程步骤在让 AI 生成任何依赖外部数据的代码之前必须先确认数据入口真实存在、能调通、返回结构符合预期。跳了这一步后面所有的代码生成、异常处理、告警逻辑都建立在不可靠的基础上。本文只覆盖这个过程的第一步——确认工具可用、完成一次可复核的查询、核对关键字段。后续的持续监控、WebSocket 推送、生产级部署不在范围内。这一步跑通了脚本骨架才是长在土里的不是飘在天上的。二、接入边界AI 不是行情源工具入口才是AI Agent 不能凭空知道当前价格。训练记忆是历史快照不是实时数据。让它获取当前行情的唯一可靠方式是接上一个真实的外部工具。TickDB 的 MCP 接口就是为这个场景设计的——把行情查询封装成 AI 编程工具可调用的函数。在 Cursor 或 Claude Code 中配置完成后AI 环境中会多出一组可被 Agent 直接调用的行情工具包括get_ticker、get_kline等。这些不是 AI 自己编造的函数名而是指向真实行情服务的入口。配置方式通过远端 HTTP 端点接入Header 为X-TickDB-Key官方远端地址https://mcp.tickdb.ai/。配置成功后AI 对话中就能直接调用行情工具。MCP 工具调用是单次查询不是持续推送。一次get_ticker成功只证明当前这次查询可用不等于后续每次都会成功也不等于数据是实时推送的。需要持续监控的场景应另行评估 WebSocket 方案。三、查询边界用真实 symbol 做一次最小调用工具接入后第一步不是写脚本是做一次最小查询——用get_ticker查一个真实品种验证整个链路是通的。选600519.SH作为首次查询对象是因为它常见且在已有的 TickDB MCP 测试中查询成功返回code0symbol、type、last_price、timestamp等字段均可见。这个已知可复核的结果是你判断工具是否正常工作的基准。把下面这个自然语言任务模板直接复制给 AI Agent你现在可以访问 TickDB MCP 的行情工具。首先列出当前可用的工具名称和描述确认 get_ticker 已存在。 然后用 get_ticker 查询 600519.SH。 如果调用成功按顺序回答 1. 返回的 symbol 是否与请求一致 2. last_price 是否存在且为可用数值 3. timestamp 是否存在且为正整数 不要补充建议不要发散解释只回答这三个问题的结果。这个模板刻意限制了 AI 的回答范围——三个问题不多不少。目的是把首次查询变成一个精确的、可复核的检查点而不是让 AI 拿着一知半解的成功结果开始发挥。四、契约边界三个字段与失败分支查询返回后先核对三个关键字段再进入代码生成环节核对项为什么重要如果缺失symbol与请求一致防止返回了错误品种的价格后续监控盯错了对象last_price存在且为合法数值价格监控的核心字段监控没有意义timestamp为正整数标记行情时间判断数据新旧无法判断行情时效三个字段全部确认后再让 AI 生成脚本骨架。下面是可用的任务模板基于刚才 get_ticker 的成功调用帮我生成一个 Python 监控脚本的框架要求 1. 使用 dict 定义待监控的 symbol 列表[600519.SH, 000001.SZ] 2. 用循环逐个调用 get_ticker 3. 对每个返回结果检查symbol 是否匹配、last_price 是否存在且可转为数值、timestamp 是否为正整数 4. 成功的结果放入 results 列表失败的结果放入 errors 列表并记录 symbol 和失败原因 5. 最后输出一个状态表包含 symbol、状态成功/失败、last_price仅成功时显示 不要写假的 API 调用直接用 get_ticker 的真实调用方式。AI 生成的脚本骨架应包含以下核心逻辑。任何校验失败都进 errors 列表不补默认值不静默跳过——价格缺失就是缺失timestamp 非法就是非法不能让不可信数据流入下游。# 监控脚本骨架——基于 TickDB MCP get_ticker 工具的实际调用方式生成 # 非生产级代码需补充日志、重试、告警和持久化逻辑 from decimal import Decimal, InvalidOperation SYMBOLS [600519.SH, 000001.SZ] results [] errors [] for sym in SYMBOLS: try: # 调用 get_ticker 工具此处为 MCP 工具调用 resp call_tool(get_ticker, symbolssym) # 检查返回码 if resp.get(code) ! 0: errors.append({symbol: sym, reason: f业务码异常: {resp.get(code)}}) continue # 提取 data 第一条 items resp.get(data, []) if not items: errors.append({symbol: sym, reason: data 为空}) continue item items[0] if item.get(symbol) ! sym: errors.append({symbol: sym, reason: symbol 不匹配}) continue # last_price 校验必须存在、可转为有限 Decimal price_raw item.get(last_price) if not isinstance(price_raw, str) or not price_raw.strip(): errors.append({symbol: sym, reason: last_price 缺失或为空}) continue try: price Decimal(price_raw) except (InvalidOperation, ValueError): errors.append({symbol: sym, reason: flast_price 无法解析: {price_raw}}) continue if not price.is_finite(): errors.append({symbol: sym, reason: flast_price 非有限数: {price_raw}}) continue # timestamp 校验必须为正整数且非 bool ts item.get(timestamp) if isinstance(ts, bool) or not isinstance(ts, int) or ts 0: errors.append({symbol: sym, reason: timestamp 无效}) continue results.append({symbol: sym, last_price: str(price), timestamp: ts}) except Exception as e: errors.append({symbol: sym, reason: str(e)}) # 输出状态表 print( * 40) print(f{symbol:15} {status:10} {last_price:12}) print(- * 40) for r in results: print(f{r[symbol]:15} {成功:10} {r[last_price]:12}) for e in errors: print(f{e[symbol]:15} {失败:10} {e[reason]:12}) print( * 40)这是骨架不是生产级代码。需要你自己补充日志记录、重试逻辑、告警阈值和持久化存储。骨架的任务是让你确认 AI 理解了工具的真实调用方式——调用路径、返回结构、失败分支——而不是直接把输出部署上线。五、检查卡每一步都可复核工具可见AI 能列出可用工具get_ticker在列表中单次查询成功用600519.SH查询返回code0data非空symbol 匹配返回的symbol与请求一致last_price存在字段存在且可解析为有限 Decimaltimestamp存在字段为正整数且非 bool脚本骨架生成基于验证结果生成循环查询和状态表逻辑失败分支包含 symbol 不匹配、data 为空、字段缺失、数值解析失败等异常处理六、能做什么 / 不能做什么本文覆盖的范围AI 工具链首次接入行情数据验证工具可用性和返回结构用最少步骤跑通一次get_ticker查询并核对关键字段基于已验证的工具调用方式生成监控脚本骨架本文不覆盖的范围WebSocket 持续推送——MCPget_ticker是单次查询不是流式推送。持续监控场景应另行评估 WebSocket 方案生产级低延迟监控——本文只验证字段可读性和工具可用性不验证延迟、稳定性或 SLA交易执行——本文不涉及下单、撤单、仓位管理REST 或 WebSocket 的接入方式——本文只讨论 MCP 工具调用这一种入口七、下一步工具调通了字段核对了骨架生成了。接下来三件事用自己的 symbol 列表跑一次完整循环不要只依赖一个600519.SH的验证结果——品种不同返回行为可能不同。补充业务逻辑阈值告警、数据库写入、定时触发——这些是骨架之外的业务层需要你自己设计。评估其他接入方式单次查询 MCP 足够需要持续推送时再评估 WebSocket。TickDB 的官方文档提供了完整工具列表和多入口配置说明可搜索查阅。