拆解｜AI 是怎么「看见」图表的：CDP 桥接与 84 工具的分层设计-开发者社区

拆解｜AI 是怎么「看见」图表的：CDP 桥接与 84 工具的分层设计

【免费下载链接】tradingview-mcpAI-assisted TradingView chart analysis — connect Claude Code to your TradingView Desktop for personal workflow automation项目地址: https://gitcode.com/GitHub_Trending/tra/tradingview-mcp

大模型最擅长处理文字与代码，却对「图表」这种状态密集、信息藏在像素与内部对象模型里的专业软件几乎无计可施。当交易员想用 Claude 帮自己看一眼图上的支撑阻力位、改一段 Pine 脚本、复盘一段 K 线回放时，摆在面前的第一道墙是：AI 根本没有「手」和「眼」去操作那个运行在本地、渲染在 Canvas 上的 TradingView Desktop。

tradingview-mcp 给出的答案是——不给 AI 一个「API」，而是给 AI 一副「眼睛和双手」：通过 Chrome DevTools Protocol 直接接管本地 TradingView 的页面上下文，再以 84 个 MCP 工具把这些底层能力组织成一套分层清晰的操作语义。本文从源码出发，拆解这条「AI 看见图表」的完整链路：CDP 桥接的原理、84 个工具的分层逻辑，以及上下文压缩与流式监控背后的 Token 成本控制。

一、桥接：为什么选 CDP，而不是去连 TradingView 的服务器

TradingView Desktop 本质是一个 Electron 应用，而 Electron 的内核是 Chromium。任何 Chromium 应用都内置了 Chrome DevTools Protocol——这是谷歌为调试器设计的标准协议，VS Code、Slack、Discord 用的都是同一套机制。项目在 README.md 中明确强调了这一点：它不连接 TradingView 服务器、不修改任何 TradingView 文件、不拦截网络流量，只与本机运行的 Desktop 实例通信。

关键在于，调试端口默认是关闭的，必须由用户显式用标准 Chromium 参数打开。三个平台的启动脚本都做了同一件事，例如 scripts/launch_tv_debug_linux.sh 会依次探测/opt/TradingView、snap、flatpak 等安装位置，然后以--remote-debugging-port=9222拉起应用，并轮询http://localhost:9222/json/version确认 CDP 就绪。这一步「用户主动开窗」的设计，正是整个方案安全性的根基。

连接层的实现集中在 src/connection.js，几个细节值得注意：

目标发现：通过fetch('http://127.0.0.1:9222/json/list')拿到所有可调试页面，优先匹配 URL 含tradingview.com/chart的页面目标（findChartTarget）。这里刻意用127.0.0.1而不是localhost——注释解释得很清楚：部分 Windows 机器上localhost会先解析到::1，而 Electron 的调试端口只监听 IPv4。
重连与退避：连接失败按指数退避重试（500ms 起步、最长 30s、最多 5 次）；reconnectTo()支持切换到指定 tab 的 target，保证tab_switch之后的读取、截图跟随新激活的标签页。
表达式求值：一切能力最终收敛为Runtime.evaluate在页面上下文中执行 JavaScript。项目把探测到的内部 API 路径集中维护在KNOWN_PATHS常量里，例如window.TradingViewApi._activeChartWidgetWV.value()、window.TradingView.bottomWidgetBar、window.TradingViewApi._alertService、window.TradingViewApi._replayApi等，且每次使用前都会用typeof探针验证路径仍存在（verifyAndReturn）。这正是 README 警示的「undocumented internal API，可能随版本变动而失效」的直接体现。

桥接之后是状态同步的工程细节。切品种、换周期这类操作不是发一条指令就结束，图表需要时间重新加载数据。项目为此实现了两层等待：waitForChartReady（轮询 loading spinner 消失、symbol 匹配、bar 数量连续两次稳定）和waitForChartRender（截图前要求 symbol/resolution/canvas 尺寸组合连续三次不变，防止切图后截到旧帧）。参见 src/wait.js 与 src/core/capture.js。

二、84 个工具的分层：读图、操控、Pine、告警

桥接只是「管道」，AI 真正要用的是管道上的「阀门」。打开 src/server.js 可以看到工具注册的完整图谱：14 个模块依次挂载到 MCP Server 上，health、chart、pine、data、capture、drawing、alert、batch、replay、indicator、watchlist、ui、pane、tab——共 84 个工具。README 的架构节给出了简洁的链路：Claude Code ←→ MCP Server (stdio) ←→ CDP (localhost:9222) ←→ TradingView Desktop (Electron)。

这 84 个工具可以按职责划成四层，每一层解决一类问题：

第一层：读图——把图表翻译成 AI 能理解的文字。这是「看见」的核心。chart_get_state负责拿到品种、周期和全部指标的 entity ID（约 500B）；data_get_study_values读取所有可见指标的当前数值；quote_get取实时报价；真正巧妙的是data_get_pine_lines / data_get_pine_labels / data_get_pine_tables / data_get_pine_boxes这四件套——它们能读取自定义 Pine 指标用line.new()、label.new()、table.new()、box.new()画出的图形对象。这在技术上并不平凡：普通的指标读取工具看不到这些图形，因为它们的入口藏在指标内部对象study._graphics._primitivesCollection之下（这条路径被直接写进了 CLAUDE.md 的架构说明）。于是 AI 能回答「图上有哪些关键价位」「那个 Profiler 表格里写的什么」这类真正依赖视觉内容的问题。

第二层：操控——给 AI 一双手。chart_set_symbol / chart_set_timeframe / chart_set_type / chart_scroll_to_date负责导航；draw_shape支持画水平线、趋势线、矩形、文本；pane_*系列管理多图表网格（2x2、2h、4、6、8 等布局）；tab_*管理标签页；ui_*系列甚至能点击按钮、敲键盘、移动鼠标——ui_evaluate允许执行任意 JavaScript，是底层能力的逃生舱。配合 src/core/chart.js 可以看到一个工程细节：chart_manage_indicator要求全名（"Relative Strength Index" 而非 "RSI"），且createStudy的 inputs 参数在不同构建下不可靠，代码会先建指标再通过getInputValues/setInputValues二次应用参数并回读确认（见注释中的 issue #249）。

第三层：Pine 开发——完整的编辑闭环。Pine 编辑器基于 Monaco（VS Code 同款编辑器），项目通过 React fiber 内部属性定位到编辑器实例，再调用setValue注入代码、读取 markers 获取编译错误。这个「黑科技」完整地写在 scripts/pine_push.js 和 scripts/pine_pull.js 里：向上遍历 DOM 找__reactFiber$属性、在memoizedProps.value.monacoEnv里挖出editor.getEditors()。对应到 MCP 工具就是pine_set_source → pine_smart_compile → pine_get_errors → pine_get_console → pine_save的流水线。值得一提的是pine_analyze是纯离线静态分析——用正则追踪array.new/array.from的数组大小、检查array.get/set的下标越界和隐式布尔转换，不需要连接图表就能报错，等于在编译前多了一道免费 lint。

第四层：告警、回放与批量。alert_create / alert_list / alert_delete管理价格告警；replay_*系列驱动 K 线回放（replay_start → replay_step → replay_trade → replay_status），src/core/replay.js 里特别处理了一个坑：selectDate()是异步的，必须在页面上下文中 await，否则回放状态显示「已开始」但步进无效（issue #26）；batch_run则支持跨品种跨周期批量执行截图或 OHLCV 拉取（src/core/batch.js）。

分层之外，还有一个容易被忽略的工程决策：每一个 MCP 工具同时也是tvCLI 命令，JSON 输出、可管道。这意味着同一套核心逻辑（src/core/）被 MCP 和 CLI 双通道复用，AI 能做的事，终端用户通过tv quote | jq '.close'也能做——两条使用路径共享同一份能力。

三、上下文压缩：把一次「分析图表」从 80KB 压到 5-10KB

桥接和工具决定了 AI「能不能」操作图表，上下文管理则决定它「能用多久」。图表数据动辄数百根 K 线、几十个指标、上千个图形对象，如果全部原样塞进模型上下文，一次分析就能烧掉几十 KB token。项目的对策写得很直白（README）：对典型「分析我的图表」工作流，总上下文约 5-10KB，而非 80KB。

压缩策略在 CLAUDE.md 里被归纳为一条条强约束规则，源码层面则落实为默认行为：

summary 模式：src/tools/data.js 的data_get_ohlcv把summary=true作为推荐项，只返回统计量（高、低、区间、涨跌幅、均量、最近 5 根 bar，约 500B）而非全部 bar（100 根约 8KB）。README 明确「ALWAYS use summary=true」。
去重与截断：data_get_pine_lines返回去重后的价位集合而不是每个 line 对象（约 1-3KB）；data_get_pine_labels默认每指标上限 50 条、只取文本+价格；data_get_pine_boxes只返回{high, low}区间。在 src/core/stream.js 的fetchLines里可以看到具体实现：遍历图形集合，用seen哈希表对价格去重后再降序排序。
study_filter 定向读取：所有 pine 图形工具都接受study_filter参数，按指标名子串过滤，避免全量扫描。
实体 ID 复用：chart_get_state只在开始时调用一次，之后用拿到的 entity ID 直接引用，不重复调用。
用截图代替大数据集：需要视觉上下文时优先capture_screenshot——返回的只是本地文件路径（约 300B），而非图像二进制；图像由 AI 侧直接读取文件。

这些规则不仅写在 README 里，还被固化进了 MCP 服务器的 instructions 字段（src/server.js 的注册描述）和 CLAUDE.md 的「Context Management Rules」，等于把「省 token」编码进了工具契约本身。

四、流式监控：poll-and-diff，只在变化时发声

实时监控是另一个 Token 成本陷阱。如果每秒把整张图的状态推给模型，上下文会迅速失控。项目的解法是「轮询 + 去重」：以固定间隔（报价 300ms、K 线 500ms、表格 2s）通过 CDP 抓取状态，用JSON.stringify生成哈希与上次比较，只在数据变化时输出一行 JSONL（src/core/stream.js 的pollLoop）。输出的每一行还附带_ts时间戳和_stream标签，方便下游脚本按行解析。

这套机制同时服务于两个场景：CLI 侧，tv stream quote | jq '.close'可以充当轻量行情监控管道；对 LLM Agent 而言，流式输出本身就是「按需订阅」——变化才推送，静止即静默，从根本上避免把无变化的状态反复塞进对话上下文。

五、能力边界：为什么它是「研究工具」而非「交易机器人」

拆解到最后，必须说清这个项目的边界，因为这与桥接方案同源：它操控的是你本机的 TradingView Desktop，因此不联网、不上传、不绕付费墙、不执行真实交易。README 的警告栏与免责声明（README.md）逐条列明了禁止事项：不得分发转售行情数据、不得绕过订阅限制、不得用提取的数据做自动化交易决策、不得连接 TradingView 服务器。REPLAY 模式中的replay_trade交易的是回放数据而非真实订单。它访问的是未公开的内部接口，任何 TradingView 更新都可能使其失效——README 给出的务实建议是：如果稳定性重要，固定 Desktop 版本。

这恰恰是它作为开源研究项目的价值所在：把「LLM Agent 如何操作有状态的桌面金融应用」这个开放问题，落地成了一段可运行、可审计、可复现的工程代码。AI「看见」图表，本质上不是让模型理解像素，而是通过一条受控的本地通道，把图表的内部状态翻译成结构化的、可推理的文字世界——CDP 是通道，84 个工具是语义层，上下文压缩与流式去重则是让这条通道在经济上可持续的工程保障。三者合起来，才构成完整的答案。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考