TickDB 博客：市场数据分析、API 接入教程与 AI 行情工具实践。按市场和主题查找文章。
> 你把智谱开放平台的 Function Calling 示例从“查天气”改成“查行情”。在多次测试中，GLM-4-Flash 不仅调对了工具，还能把用户说的“茅台”映射成 ——这是中文模型在 A 股数据上的天然优势。但当三个行情工具同时注册时，同一个 query 在第三轮对话里突然调错了函数。优势区和暗坑区，只隔着一套工具描述的写法。 一、GLM-4 的中文红利，在金融场景下是双刃剑 GLM-4
TickDB Research ·
这是 TickDB 实时行情接入系列的第 4 篇。前一篇解决“REST 第一次查询”，本文解决“API 接入 FAQ”。 【摘要】 接入 TickDB API 时，失败往往不在一行代码，而在鉴权、endpoint、参数、symbol、响应码、字段路径和 timestamp 之间。本文整理一张七层排错图、一张 FAQ 表和一份脱敏证据清单，帮助开发者用最小验证动作定位问题，同时避免空数据补造、字段路
TickDB Research ·
> 这是 TickDB 实时行情接入系列的第 3 篇。前一篇解决“接入路径怎么选”，本文解决“REST 第一次查询”。 很多开发者第一次接行情数据，卡住的不是“有没有 API”，而是另一个更实际的问题： 先说结论：第一次验证，只跑通一条 REST 快照请求 第一次使用 TickDB REST API，不需要先搭复杂工程。你可以先完成一个可核验闭环：准备 API Key，向 传入真实 ，再确认响应
TickDB Research ·
> 你把 从 改成 ，代码跑通了。但当你给 Agent 配了两个金融数据工具，同一个 query 在两个模型上的行为开始分化——这才是需要关注的地方。 一、当“全面兼容”遇上金融数据 DeepSeek API 全面兼容 OpenAI SDK。改一行 ，换个 参数，你的 Function Calling 代码就能在两个模型上跑通。 但“跑通”和“跑对”之间，隔着一整套金融数据接入场景下才会暴露
TickDB Research ·
> 同一只股票，同一时刻，两个主流数据源的价格差了0.01元，时间戳差了3毫秒，成交量差了200股。不是谁错了——是“精确到Tick”这件事本身，就没有统一标准。 一、一个你必须面对的事实 你用Tick级数据跑回测，夏普比率漂亮得让自己都有点不好意思。但切换到实盘，曲线开始变得陌生。你查过程序，没问题；查过网络，没问题；最后怀疑数据——但你无从查起，因为你手里只有这一份数据。 多数量化开发者默认“
TickDB Research ·
> 你在通义千问开发者后台定义了两个工具，一个查实时行情，一个查历史 K 线。description 都写了“获取市场数据”。Agent 上线第一天，用户问“茅台现在多少钱”，模型调了 K 线工具，返回了昨天的收盘价——因为两个描述在模型眼里没有区别。 !image.png --- 一、当通用教程遇上金融数据 阿里云 DashScope 的 Function Calling 文档里，示例通常是“获
TickDB Research ·
> 这是 TickDB 实时行情接入系列的第 2 篇。前一篇解决“TickDB 是什么”，本文解决“接入路径怎么选”。 很多开发者第一次接行情数据，卡住的不是“有没有 API”，而是另一个更实际的问题： 摘要： TickDB 有 REST、WebSocket、MCP、Skill、CLI 多种接入入口，但它们不是同一种 API 的五个名字。本文用选择表说明：REST 适合首次查询验证，WebSo
TickDB Research ·
> 本文不是框架排名，而是一份金融行情数据接入前的工程风险清单。每个风险点都附了检查方法和修正示例。 --- 一、不同框架，同一个坑 假设你用三个不同的 Agent 框架跑同一个任务——“每 30 分钟查一次价格，超过阈值时汇总分析”。 其中一个 Agent 把 ticker 快照的 （24 小时成交量）当成了单根 K 线的成交量，量级差了几千倍。另一个在 API 限流后陷入重试死循环，两分钟烧掉
TickDB Research ·
想给自己的应用加一块行情看板，或者让 AI Agent 在回答前先读取当前数据，很多人第一反应是先找一个 API，然后立刻写代码。 但真正容易走错的一步在更前面：你需要的是一次查询、持续订阅、AI 工具调用，还是终端里的自动化任务？入口选错了，后面即使代码能运行，也可能一直在用不适合的方式解决问题。 先给简短答案： > TickDB 是一个支持 REST、WebSocket 和 AI 工具调用的统
TickDB Research ·
摘要： Qwen 返回 ，不代表行情查询已经成功。本文从掘金开发者常见排错场景出发，拆解“触发工具、应用执行、结果校验、工具回填、最终回答”的最小可信链路，并给出未触发工具、查询失败或空结果、回填错误三个必须阻断价格回答的失败分支。TickDB 仅作为应用端只读行情数据路径示例出现。 你在日志里看到了这样的返回： 这只能说明一件事：模型提出了一个工具调用请求。 它不等于应用程序已经拿到行情，不
TickDB Research ·
摘要：面向开发者的美股盘前盘后数据接入核验清单：先查交易窗口，再验证真实样本与 ，最后保留限流和空返回等失败分支，避免把一次成功查询误写成行情覆盖或策略有效性证明。 接入美股盘前盘后数据时，最容易写错的不是请求语法，而是验证顺序：先假定“有盘前盘后”，再默认“这些时段持续有可用行情”，最后直接拿样本讨论研究或策略。 更稳妥的工程顺序是：先确认查询到的交易窗口，再检查真实样本是否返回，然后统一
TickDB Research ·
摘要： 想让扣子 / Coze 工作流查询外部行情数据，最先要证明的不是流程画布能否搭出来，而是四类证据是否成立：能否请求外部服务、能否安全传递密钥、能否解析可核对的返回、失败时能否停止生成结论。本文仅写验证清单，不把尚未取得官方配置证据的能力写成教程。 很多人想做的事情很自然：让一个工作流接入外部行情数据，再让 AI 根据查询结果回答问题。 但这种题目也最容易被写成一种“看起来已经跑通”的教
TickDB Research ·