让 AI 帮你写一个 Pine Script 策略最痛苦的是什么不是它不懂语法而是它根本看不到行情。你让它写一个“RSI 超卖反弹进场、突破 20 日均线加仓、ATR 止损”的策略它写出来的代码框架通常没问题可一旦涉及具体标的和当前市场状态它就只能靠你手动粘贴数据。数据一贴不仅效率低而且 AI 拿到的是片面的历史快照很容易一本正经地胡说八道。我最近一直在折腾 tradingview-mcp 这个方向把 TradingView 的实时行情、历史 K 线、技术指标封装成 MCP 工具让 Claude、Cursor、Codex 这类 AI 编码助手像调用本地函数一样去读行情数据。一句话说清楚它是什么它就是一个让 AI 自己打开行情终端看盘的中间层。这篇文章我会把从零搭建、配置、使用和踩坑的完整过程写下来适合想用 AI 辅助量化研究、但又受够了手动喂数据的交易者和开发者。1. 痛点复盘AI 写量化策略时最缺的不是“会写代码”是“看得见实时数据”1.1 每次手动贴数据进对话框的日子早期我用 AI 辅助做交易研究流程大概是这样的先在 TradingView 上打开某个币种的 4 小时图手动记录收盘价、成交量、关键均线位置然后粘到对话窗口里再让它分析。麻烦的地方在于K 线数据是动态的你贴进去的只是一个时间截面的快照。AI 基于这份快照给出的判断放到下一根 K 线走出来之后可能就完全不成立了。更尴尬的是写策略回测。让 AI 生成 Pine Script它往往会写出语法正确的代码但如果你需要它根据最近一段行情的波动率去动态调整参数它根本没数据可用。你只能继续手动复制几十行 OHLCV 数据。复制的过程里只要漏一行或者错一个逗号AI 就会基于错误数据给出一个看似合理、实则完全跑偏的策略。1.2 MCP 到底改变了什么从“你喂数据”到“AI 自己取数据”Model Context Protocol 是 2024 年底开始火起来的一个开放协议。它本质上定义了一套标准化的“工具调用”方式让 AI 应用通过 MCP Client 去连接 MCP Server再调用 Server 暴露出来的工具和数据资源。你不需要为每一个 AI 产品单独写一套 API 对接逻辑只要把数据服务包装成一个 MCP Server各大支持 MCP 的客户端都能直接使用。落到 tradingview-mcp 上这个交互逻辑就变成了你让 AI “看一下 BTCUSDT 当前的 RSI”AI 会自己调用一个叫 get_realtime_quote 或 get_historical_candles 的工具拿到数据之后再完成计算和分析。整个过程中你不需要复制任何数据AI 拿到的也是刚刚发生的实时数据。这个体验上的差异本质上是从“把鱼递给 AI”变成了“教会 AI 钓鱼”。1.3 为什么选 TradingView 作为数据底座市面上行情源其实不少但 TradingView 有它不可替代的优势覆盖面极广股票、加密货币、外汇、期货都有统一代码格式自带大量社区指标和策略生态成熟图表交互能力强后续甚至可以进一步接入画线、警报等能力。虽然 TradingView 没有开放官方 REST 行情 API 给普通用户但它的 WebSocket 数据流在社区里已经被研究得比较透彻配合本地指标计算完全可以支撑个人研究和策略开发。1.4 什么样的人适合用这个方案如果你是下面这几种人这个项目大概率对你有用经常用 Claude 或 Cursor 写 Pine Script、希望 AI 能直接基于实时行情感知市场状态的量化爱好者觉得反复复制粘贴数据太痛苦、想要一个统一数据中间层的开发者想研究 MCP Server 怎么写、需要一个足够真实的落地场景的技术学习者。反过来如果你只需要偶尔看一眼行情那直接用 TradingView 网页端就够了没必要搭一套服务。2. 架构拆解一个 tradingview-mcp Server 由哪几块拼起来2.1 MCP 三件套Host、Client、Server 分别是什么角色要理解 tradingview-mcp先得把 MCP 的几个角色分清。最上面是 MCP Host也就是 Claude Desktop、Cursor、Codex CLI 这类 AI 应用它们负责理解用户指令、决定是否调用工具。Host 内部会运行一个 MCP Client负责和 Server 建立通信。最下面是 MCP Server也就是我们写的服务进程它向外暴露工具列表实际执行行情拉取、指标计算等操作。我画过一张图给朋友解释最简单版本是这样AI 应用Host - MCP Client - MCP Server我们的 tradingview-mcp 进程 - TradingView WebSocket 数据流AI 应用收到用户指令后判断“我需要行情数据”然后通过 MCP 协议把工具调用请求发给 ServerServer 执行完数据操作把结构化结果返回给 AIAI 再基于这些数据继续推理、写代码、给出判断。2.2 数据链路从 WebSocket 裸数据到 AI 能看懂的工具结果整个项目最核心的数据链路分三层第一层是接入层。实时报价通过 TradingView 的 WebSocket 通道订阅我主要订阅 quote报价快照和 klineK 线两类数据。第二层是计算层。由于 TradingView 图表上显示的指标不是标准 REST 接口能直接取的我选择把 K 线拉到本地用 pandas 计算指标这样既能保证指标口径可控后续还能扩展自定义策略信号。第三层是服务层。用 FastMCP 把数据能力封装成一个个工具函数AI 只需要按函数签名传参。选 FastMCP 而不是直接用官方 MCP SDK是因为它把很多样板代码收掉了。你只需要定义一个普通 Python 函数加上 mcp.tool() 装饰器工具就会被自动注册。FastMCP 底层还帮你处理了 JSON-RPC 通信、stdio/SSE 传输模式切换这些细节对快速迭代一个个人项目来说非常舒服。2.3 工具清单这个 Server 到底暴露了哪些能力我在项目里最先实现了下面这几个工具覆盖了日常研究中最常用的场景工具名输入返回内容典型用途get_realtime_quotesymbol最新价、涨跌幅、成交量、买卖盘快照让 AI 知道当前价格和盘口状态get_historical_candlessymbol、timeframe、limitOHLCV 列表让 AI 分析最近走势、计算指标compute_indicatorsklines、indicator、periodRSI/MACD/MA/BOLL/ATR 值让 AI 拿到可量化的技术指标get_market_overviewsymbols 数组多品种统一快照让 AI 对比多个品种强弱这几个工具的设计原则是让 AI 在单次对话中尽量少调用工具但每个工具返回的信息密度要高。比如 compute_indicators 一次性返回指标的最新值和最近几期的变化方向AI 不需要再拿原始数据二次计算。2.4 为什么指标要在本地算而不是直接问 TradingView这是最开始踩过的一个误区。我原本打算直接从 TradingView 图表上“读”出 RSI、MACD 这些已经画好的指标值但后来发现这条路很别扭一是 TradingView 页面上展示的指标是前端渲染的结果不是稳定的后端接口二是如果 AI 想调整 RSI 的计算周期你没法让 TradingView 动态改图。所以最终方案改成WebSocket 只负责原始 OHLCV所有指标计算都在本地完成。这样 AI 想算什么、想用什么参数完全是我们说了算而且计算逻辑透明、可审计。2.5 项目目录结构项目结构并不复杂核心文件就几个tradingview-mcp/ ├── pyproject.toml ├── server.py # FastMCP 服务入口定义所有工具 ├── tv_client.py # TradingView WebSocket 封装 ├── indicators.py # 指标计算库 └── data_cache.py # 本地缓存避免重复拉数据这个结构刻意保持精简。对于个人项目我不建议一开始就引入复杂的分层架构。先把数据能跑通、AI 能调起来再考虑扩展。3. 从零跑通本地部署 tradingview-mcp 的代码与配置3.1 环境准备与依赖安装我的环境是 Python 3.11 uv。选 uv 是因为它管理虚拟环境和依赖都快而且 Claude Desktop 配置 MCP Server 时可以直接用 uv run 拉起服务其他用户复现起来也方便。uv init tradingview-mcp cd tradingview-mcp uv add fastmcp websockets pandas依赖只有三个fastmcp 负责 MCP 服务框架websockets 负责连接 TradingView 数据流pandas 负责 K 线处理和指标计算。3.2 实现 TradingView 数据客户端TradingView 的 WebSocket 接口是社区逆向出来的协议字段可能随着官方更新而变化所以我在代码里把协议细节全部收敛到 tv_client.py 一个文件里。下面是核心部分import asyncio import json import time import websockets class TVDataClient: def __init__(self): self.ws_url wss://data.tradingview.com/socket.io/websocket self.session ftvmcp_{int(time.time() * 1000)} self.ws None self._seq 1 async def connect(self): self.ws await websockets.connect(self.ws_url) # socket.io 握手包type1 表示连接建立 await self.ws.send(~m~25~m~{type:1}) async def _send(self, payload): body json.dumps(payload) # 关键socket.io 消息需要进行长度前缀编码漏掉会被静默丢弃 await self.ws.send(f~m~{len(body)}~m~{body}) async def subscribe_quote(self, symbol: str): await self._send({ m: quote_add_symbols, p: [symbol, {flags: [force_permission]}], uid: self.session, }) def parse_message(self, raw: str): # 处理 ~m~ 前缀和 ~h~ 心跳返回结构化数据 pass这里容易踩的坑是 socket.io 的消息格式。不是简单发一个 JSON 字符串就行而是要带上消息体长度前缀。我第一次跑的时候忽略了这一点连接看起来建立了但服务端完全不回数据排查了很久才发现是消息格式的问题。3.3 用 FastMCP 封装工具Server 入口的代码非常直接import json import pandas as pd from fastmcp import FastMCP from tv_client import TVDataClient from indicators import compute_rsi, compute_macd mcp FastMCP(tradingview-mcp) tv TVDataClient() mcp.tool() async def get_realtime_quote(symbol: str) - str: 获取 TradingView 指定品种的实时报价symbol 格式如 BINANCE:BTCUSDT。 await tv.connect() await tv.subscribe_quote(symbol) raw await tv.receive_quote() return json.dumps(raw, ensure_asciiFalse) mcp.tool() def compute_indicators(klines: list, indicator: str rsi, period: int 14) - dict: 计算技术指标支持 rsi/macd/ma/boll/atr。klines 为 OHLCV 列表。 df pd.DataFrame(klines) if indicator rsi: value compute_rsi(df[close], period) elif indicator macd: value compute_macd(df[close]) else: raise ValueError(funsupported indicator: {indicator}) return {indicator: indicator, latest: round(float(value.iloc[-1]), 4)}FastMCP 工具函数的 docstring 会被当作工具说明交给 AI 模型AI 会根据这个说明决定是否调用以及怎么传参。所以 docstring 一定要写清楚输入格式和返回结构。我一开始写得比较随意结果 AI 经常传错 symbol 格式后来源码里把示例格式写进 docstring 之后问题立刻少了很多。3.4 用 MCP Inspector 验证服务连通性写完 Server 后不需要先去接任何 AI 客户端可以先本地验证工具是否能正常调用fastmcp inspect server.py这个命令会启动一个本地调试页面你可以在里面调用 get_realtime_quote(BINANCE:BTCUSDT)直接看到返回的行情数据。这一步能帮你把问题边界切干净如果 Inspector 里工具都返回正常说明问题出在后续客户端配置如果 Inspector 里就报错说明是 Server 代码的问题。3.5 接入 Claude Desktop、Cursor 和 Codex CLIClaude Desktop 的配置写在 claude_desktop_config.json 里指向项目目录即可{ mcpServers: { tradingview-mcp: { command: uv, args: [run, --directory, /path/to/tradingview-mcp, server.py] } } }Cursor 里的配置类似。如果你只想在当前项目里生效在项目根目录创建 .cursor/mcp.json{ mcpServers: { tradingview-mcp: { command: uv, args: [run, --directory, /path/to/tradingview-mcp, server.py] } } }Codex CLI 对 MCP 的支持在不同版本里配置格式不太一样我当时是直接看官方文档确认的。整体思路相同在配置里声明一个 mcpServercommand 用 uv 把 server.py 拉起来。配置完成后在 AI 对话里直接问一句“你现在能拿到哪些工具”如果 AI 能正确列出 get_realtime_quote 和 get_historical_candles说明接入成功。3.6 跑一次完整的调用链接入完成后我习惯先用这样一条 prompt 做冒烟测试“请调用 get_historical_candles 获取 BINANCE:BTCUSDT 最近 100 根 4 小时 K 线计算 RSI(14) 和 MACD然后告诉我当前短周期动量的方向。”AI 会自动完成工具调用、指标计算、结果解读三个步骤。如果你看到 AI 真的发起了工具调用、拿到了数据、并且给出的判断里引用了具体数值而不是含糊地说“根据当前市场情况”说明整条链路已经通了。4. 真实使用场景从“看盘”到“交给 AI 写策略”的完整链路4.1 场景一让 AI 基于实时行情做多周期分析接入之后我使用频率最高的场景是让 AI 做多周期趋势判断。以前我需要在 15 分钟、1 小时、4 小时三个周期之间来回切换看盘现在只需要一句话“请依次获取 BINANCE:ETHUSDT 的 15 分钟、1 小时、4 小时 K 线分别计算 MA20、MA60 和 RSI(14)对比三个周期里均线排列和 RSI 是否共振给出当前多空倾向。”AI 会连续调用多次工具然后输出类似这样的结论“4 小时级别 MA20 上穿 MA60RSI 位于 58偏多趋势未破坏1 小时级别 RSI 接近 70短期有超买迹象15 分钟级别出现顶背离短线有回调风险。”这种多周期交叉验证的分析靠手动贴数据很难做到因为每个周期都要重新贴一次。4.2 场景二让 AI 生成带资金管理的 Pine Script 策略另一个高频场景是写 Pine Script。我常用的 prompt 是“基于 ETHUSDT 的 1 小时数据帮我写一个策略当 RSI(14) 跌破 30 后重新上穿 30 时开多ATR(14) 的 1.5 倍作为止损盈亏比达到 2 时止盈仓位不超过总资金 2%。先用 get_historical_candles 确认数据可用再输出完整代码。”因为 AI 已经通过 MCP 拿到了真实 K 线它能根据实际数据估算 ATR 的量级写出的止损止盈参数就更贴近市场波动水平。而且它能直接把指标逻辑翻译成 Pine Script 语法我只需要在 TradingView 上做回测验证就行。以前这个过程需要我在 AI、TradingView、行情数据三个窗口之间来回切换现在基本可以在一段对话里完成。4.3 场景三多品种横向对比扫描做资产轮动研究时经常需要快速对比多个品种的强弱。我写了一个批量扫描的 prompt“获取 BTCUSDT、ETHUSDT、SOLUSDT、BNBUSDT 的 4 小时 K 线计算各自过去 20 根 K 线的涨跌幅和 RSI(14)按涨幅排序并标出哪些品种处于 RSI 超买区间。”这个场景特别能体现 MCP 的价值不是让 AI 凭记忆回答而是让它实时拉数据后做结构化对比。而且输出的是一张可直接读的对比表省掉了自己开多个图表逐个看的功夫。4.4 一个必须强调的教训不要让 AI 脱离数据做判断我用下来的最大教训是AI 在没有数据时会非常流畅地生成一个“听起来很专业但没法验证”的答案。比如你问“BTC 最近走势如何”它可能会给出一种四平八稳的模板回答不犯错但也没有信息量。接入 MCP 之后正确的用法是强制 AI 先调用工具再回答。我在系统提示词里加了一句“凡涉及行情、指标、价格的问题必须先调用 tradingview-mcp 工具获取数据禁止基于训练记忆作答。”这句话效果立竿见影明显减少了幻觉。5. 上线一周后我踩过的一些坑从断连到指标不一致5.1 socket.io 的~m~长度前缀漏写会静默断连这是第一个拦路虎。TradingView 的 WebSocket 用的是 socket.io 协议消息格式是~m~消息体长度~m~实际消息。我一开始直接ws.send(json.dumps(payload))连接正常建立服务端也不报错但就是没有数据返回。后来对照社区的 Python 实现才发现消息必须带上长度前缀否则服务端解析不了。这个问题最大的迷惑性在于“连接成功但无响应”你很容易怀疑是网络原因或者订阅参数错了实际只是消息格式不对。5.2 连接空闲会被服务端踢掉必须用心跳保活WebSocket 长时间没有数据交互服务端会主动断开连接。表现是代码跑了一个多小时突然收不到行情了也不报异常就是死了一样。解决方案是在客户端增加定时心跳每隔 25 秒发送一次 ping 包保持连接活跃。这也是我自己重新实现客户端而不是直接用现成第三方库的原因之一第三方库的内部机制不透明出了问题不好定位。5.3 订阅过量触发限流需要分批订阅做多品种扫描时我一次性订阅了三四十个 symbol结果连接直接被服务端切断。后来确认是订阅频率过高触发了限流。调整策略是把订阅改成串行每次只订阅几个收到确认后再继续下一批同时加上指数退避重连逻辑。现在即使偶尔被断客户端也会在 1 秒、2 秒、4 秒的退避节奏里自动恢复。5.4 RSI 等指标与 TradingView 图表不一致Wilder 平滑的坑这是指标计算里最容易翻车的地方。TradingView 的 ta.rsi 默认使用 Wilder 平滑算法也就是 RMAWilder 移动平均而很多 Python 库默认用简单平均去算。数据量足够大时两者会收敛但小样本下差异明显。如果你拿本地算出的 RSI 去和 TradingView 图表的 RSI 对比发现总是对不上别怀疑代码先检查平滑算法是否一致。我在 indicators.py 里专门实现了一套和 Pine Script 对齐的 RMA 逻辑并用 TradingView 图表做了多组回归校验。5.5 时区与时间片闭合问题K 线数据的时间戳需要统一处理。TradingView 不同品种返回的时间基准可能不同有的是 UTC有的是交易所时区。如果你直接用本地时间区参与计算日线级别的分析在跨时区品种上会出错。我的处理方式是在数据进入缓存前统一转换成 UTC 时间戳并记录每个 K 线的交易所时区字段展示层再按需转换。这套逻辑虽然简单但不处理的话每天凌晨收盘的那根 K 线经常会对不上。5.6 非官方接口随时可能变化必须保留降级方案TradingView 的 WebSocket 数据流毕竟是社区逆向的TradingView 官方并不承诺稳定提供随时可能调整协议。所以我在架构上做了通道抽象实时行情优先走 TradingView一旦连续重连失败或者返回数据异常自动降级到备用的行情源。这样 AI 至少还能基于相对新鲜的数据工作而不是整个服务直接躺平。6. 从 tradingview-mcp 继续长出来的一些想法6.1 给 MCP Server 增加记忆能力让 AI 记住你的交易规则用完一段时间后我发现 AI 每次对话都不记得我之前的风险偏好。于是我引入了一层轻量的规则记忆把“最大仓位 2%”“主要交易 BTCUSDT 和 ETHUSDT”“周线方向不明确时不做多”“止损不超过入场价的 1.5%”这类规则写进一个规则文件作为额外上下文注入给 AI。效果是 AI 在生成策略建议时会主动把这些约束纳入考虑不会再给出明显超出风险偏好的方案。这种玩法本质上接近热词里的 skill 和 memory给一个普通 MCP Server 加上了个性化能力。6.2 叠加信号通知从“问 AI”变成“AI 主动提醒”另一个扩展方向是把 MCP Server 里的扫描能力接到消息推送上。我在 Server 里加了一个定时任务每隔 15 分钟运行一次多品种指标扫描一旦命中预设条件比如“RSI 低于 30 且 MA20 上翘”就通过推送接口把信号发给自己的手机。这样 tradingview-mcp 就不再只是一个 AI 调用工具而是变成了一个半自动的盯盘机器人。6.3 把回测数据通过 MCP 回传给 AI形成迭代闭环我的远期计划是把 TradingView 的 Pine Script 回测结果也接进来。AI 生成策略后我把策略代码放到 TradingView 上跑回测再把回测报告中的最大回撤、胜率、盈利因子等指标通过 MCP 工具回传给 AI让 AI 基于真实回测数据继续优化策略。这个闭环如果真的跑通它能显著缩短策略迭代周期。目前这个模块还在完善中主要难点是回测结果的结构化解析和参数自动调整的稳定性。6.4 我个人在实际运行中的体会跑了几个星期之后我最大的感受是tradingview-mcp 解决的核心问题不是“让 AI 看盘”而是把那些反复消耗我精力的数据搬运工作自动化。AI 仍然会犯错仍然需要人工复核但至少我不用再做复制粘贴这种事了。后续我会继续完善数据缓存、增加更多品种的扫描模板并把策略回测结果接入进来。如果你也在做类似的方向建议从小工具集开始先让 AI 能稳定拿到实时行情再逐步叠加复杂能力。交易决策这件事最终仍要由你自己拍板AI 能做的是把数据、信号和策略草案准备好。