你的量化回测年化 22%，实盘只剩 6%——可能不是过拟合
!ScreenShot_2026-05-12_120824_648.png 一个朋友最近很痛苦。 回测年化 22%，实盘跑了半年，只剩 6%。第一反应是过拟合。让他截图 DataFeed 代码，第 42 行——前复权价格算信号，后复权净值算绩效。 不是策略不行。是用两把不同的尺子量了同一段行情。 更让他沉默的，是另一组数字：策略代码写了 3 天，数据接入修了 5 天。关键卡点不是代码量，是复权因子
TickDB Research ·
行情 API 怎么选，Python 如何获取实时行情，历史数据为何影响回测？阅读 TickDB 的接口教程、数据源比较与 AI 取数实践，结合代码示例检查时间戳、处理断线重连，把行情数据接入看板与研究脚本。
!ScreenShot_2026-05-12_120824_648.png 一个朋友最近很痛苦。 回测年化 22%，实盘跑了半年，只剩 6%。第一反应是过拟合。让他截图 DataFeed 代码，第 42 行——前复权价格算信号，后复权净值算绩效。 不是策略不行。是用两把不同的尺子量了同一段行情。 更让他沉默的，是另一组数字：策略代码写了 3 天，数据接入修了 5 天。关键卡点不是代码量，是复权因子
TickDB Research ·
> 6986 只 A 股做日频选股回测，策略代码写了 3 天，数据接入修了 5 天。关键问题不是代码量，是复权因子方向用反了——前复权价格算信号，后复权净值算绩效，敞口漂了 0.3%，半年累积偏离 17%。回测年化 22%，实盘只剩 6%，不是过拟合，是两把不同的尺子量了同一段行情。 > > 全市场回测最被低估的工程债：数据中间件的维护成本，远高于策略开发本身。 本文解决的核心问题 | 你的痛点
TickDB Research ·
每天早上9点15分，A股集合竞价开始。你盯着屏幕，猜今天会高开还是低开。 我不用猜。不是我有内幕消息——是港股9点就开盘了。那半小时里，港股那边发生的事，已经告诉我今天A股大概率往哪个方向走。 !image.png > 港股比A股早开半小时。这半小时，是A股当天走势的“预告片”。 这篇文章只聊一件事：每天早上那被浪费的半小时，怎么捡回来。 一、A股开盘前，港股已经“演”了半小时 大多数散户的早上是
TickDB Research ·
目录 - 一、你的 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鉴权变迁，附通用三步排查法。
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 ·