TickDB 博客：市场数据分析、API 接入教程与 AI 行情工具实践。按市场和主题查找文章。
目录 - 一、你的 Cursor 还在让你手动搬数据？ - 二、一段 JSON 就够了：配置拆解 - 三、复制粘贴就能用 - 四、为什么“配好”比“配上”重要得多 - 五、踩坑速查表 - 六、配合使用建议 - 七、结语 一、你的 Cursor 还在让你手动搬数据？ Cursor 的 Agent 模式能自主读项目、理解代码结构、帮你重构模块。 但你知道此时此刻的市场在发生什么吗？ 你让它写一个 BT
TickDB Research ·
> 摘要：当你的Claude Code能30秒写完一个均线交叉策略，却无法直接查询实时行情时，MCP协议提供了标准的感知层方案。然而，学术审计发现97.1%的公共MCP端点存在工具描述缺陷，66%含严重代码异味。本文不局限于“用什么端点”，而是给出一个基于腾讯云TKE容器服务 + CLS日志服务 + 云监控CM + 凭据管理系统SSM的生产级团队架构方案，并深入探讨金融数据管道最易被忽视的设计原则
TickDB Research ·
> ▍阅读导航 > > - AI 应用开发者：MCP 协议在金融场景下的工程分析——社区端点质量参差不齐，如何选择可靠的行情感知层。 > - 量化开发者：MCP 接入后回测系统的“未来函数”污染风险，以及生产级解决方案的原理与实现。 > - 架构师：在火山引擎 VKE 上部署 MCP 托管服务的参考架构——API 网关鉴权 + 容器集群多副本 + VPC 内网低延迟。 一、AI 能写策略却查不了行
TickDB Research ·
你让Claude Code写一个均线交叉策略，它30秒写完——比你手动快10倍。然后你让它跑回测，它说：“请提供BTCUSDT最近90天的1小时K线数据。” 你导出CSV，粘贴进对话框，它继续生成结果，一切正常。 但一个能写策略、能算夏普比率、能优化参数的AI，为什么偏偏不能自己查实时行情？ 不是它不够聪明。是大模型本身没有“感知实时世界”的器官。 更关键的是——接下来你会发现，即使给AI装上了感
TickDB Research ·
> 摘要：本文记录在八个主流MCP客户端中配置TickDB行情数据服务的完整踩坑过程，涵盖配置文件路径差异、Zed非标准字段名、Cherry Studio的GUI格式要求及Header鉴权变迁，附通用三步排查法。 --- 你在Claude Code里配好了TickDB MCP行情服务——JSON格式没问题，API Key也对——但AI助手就是查不了实时行情。同样的配置在Cursor里能跑，在Zed
TickDB Research ·
2026年4月，一个开源项目以每天超2000星的速度引爆GitHub——TradingAgents，多智能体LLM金融交易框架。66.5k Star，12.9k Fork，清华系创业团队，arXiv论文引用量持续攀升。 它用LangGraph构建了一条五层决策链：四个分析师并行处理数据，多头与空头研究员围绕同一标的展开辩论，交易员综合双方论点后形成判断，风控团队独立审核，基金经理最终裁定。这套架构
TickDB Research ·
目录 - 一、66.5k 星的架构，数据心脏长在纸糊的血管上 - 二、架构亮点：把量化私募的决策流程编码成了 Agent 链 - 三、数据源的致命短板：为什么免费 API 跑不起来 - 四、从 Demo 到生产，差距不在模型，在数据管道 - 五、聊聊你的 Agent 数据层 一、66.5k 星的架构，数据心脏长在纸糊的血管上 上周清华系团队的作品，架构确实巧妙——LangGraph 搭的五层决策链
TickDB Research ·
你盯着一只港股。买一挂了10万股，价格稳稳撑在那里。你心想：这支撑够厚，可以买。 3分钟后，10万股瞬间消失。股价跳水5%。你被套在山顶。 不是主力撤单太快你反应不过来。是你没意识到——港股没有做市商，那10万股可能是唯一在托盘的人。他一撤，下面全是真空区。 你在买一看盘的每一秒，都是在赌那个挂单人不会撤。 这篇文章不讲Level2数据怎么看，只讲三件事： - 为什么港股挂单量最大的位置，反而是最
TickDB Research ·
你用一个AI Agent跑美股动量策略，表现不错。想把同一套逻辑复用到国内期货。Agent发出第一个请求，拿到螺纹钢的行情数据。它看到字段，值是15000。对比记忆中AAPL的，值是15000000。两个字段在Agent眼里是同一个概念——都是“成交量”。一个是手，一个是股。螺纹钢一手10吨，AAPL一股就是一股。Agent不知道这件事。它把15000和15000000放进同一个动量加权公式，得出
TickDB Research ·
> ▍本文适合谁读？你能收获什么？ > > - 量化开发者：一份可直接运行的字段映射实现，包含成交量标准化（从“手”到“名义价值”）的完整逻辑，以及适配火山引擎函数服务的异步行情接入代码。 > - 数据工程师：国内期货行情协议与美股协议的三大冲突点（字段名、计量单位、时间戳格式），以及最小侵入式兼容方案。 > - 技术决策者：一套在火山引擎云上可落地的跨市场数据管道架构——WebSocket 长连
TickDB Research ·
阅读指南 如果你只想要代码，直接跳转第五章和第七章，字段映射与异步接入的实现可复制运行。如果你想理解为什么成交量映射值两天工时，第三章有完整的拆解，从“手”到“名义价值”的转换逻辑。如果你关心底层架构，第四章分析了 Python GIL 下回调的阻塞问题与异步长连接的降维方案。如果你正在做跨市场策略，第八章踩坑速查表覆盖了字段混用、合约切换、时间戳拼接等高频故障。 一、把美股策略复用到期货，第一个
TickDB Research ·
目录 - 一、凌晨三点，你的策略卡在字段映射第一步 - 二、CTP 的字段命名：为期货而生，不为跨市场设计 - 三、深度拆解：一个 字段如何吃掉你两天工时 - 四、底层视角：为什么字段映射只是冰山一角 - 五、统一字段映射：最小侵入式实现 - 六、时间戳对齐：交易所生成时间 vs 本地接收时间 - 七、极简接入：异步非阻塞的行情获取 - 八、踩坑速查：国内期货 Tick 接入的高频故障 - 九、
TickDB Research ·