用了几个小时捣鼓了个小东西，记录一下过程。

怎么想到这个点子的

今天刷GitHub Trending，看到一个叫 chrome-devtools-mcp 的项目上了榜。点进去一看，是用MCP协议让AI助手能控制Chrome DevTools——相当于给AI装了一双"眼睛"和"手"。

第一反应：这玩意有点酷啊。

想象一个场景：你在用Claude或者Cursor写前端代码，遇到个bug，你不用再手动打开Chrome、切到控制台、输入命令看结果。直接跟AI说"帮我截图看看现在的页面"、“执行这段代码测试一下”，AI自己就能操作浏览器。

但那个项目功能太全了，网络面板、性能分析、断点调试…代码量不小。我就想：能不能搞个轻量版，先实现最基础的功能？

于是今晚就撸了这个实验项目。

📁 项目地址：https://github.com/YaBoom/chrome-devtools-mcp-lite-zyt

实现过程（和踩的坑）

第一版：直接调CDP

Chrome有个叫 Chrome DevTools Protocol (CDP) 的东西，其实就是一套WebSocket API，让外部程序能控制浏览器。

第一版代码很简单，用 chrome-remote-interface 这个库连上Chrome，调几个API试试：

const client = await CDP();
const { Page, Runtime } = client;

await Page.navigate({ url: 'https://example.com' });
// ...获取标题什么的

但马上发现一个问题：这玩意儿AI不好直接用。

CDP太底层了，AI助手需要知道 Page 域有哪些方法、Runtime 怎么用…这不符合直觉。更好的方式是封装成工具，AI只需要说"截图"、“执行代码”，不用关心底层协议。

于是决定包成MCP Server。

第二版：踩了MCP SDK的坑

这里卡了快一个小时。

按网上教程装 @modelcontextprotocol/sdk，没指定版本，结果装了 0.5.x。照着教程写代码，死活跑不通——API完全对不上。

后来才发现，MCP SDK最近出了1.x版本，API全改了，完全不兼容0.x。

说实话这个挺坑的。文档也没写清楚版本差异，npm上两个版本都还在，很容易装错。最后是直接去GitHub看源码才搞明白。

教训：对于这种快速迭代的项目，一定得装 @latest，别看旧教程。

第三版：截图时好时坏

功能基本写完了：连接Chrome、导航页面、执行JS、截图、获取DOM。但测试截图的时候发现一个问题——时好时坏。

有时候能截到图，有时候报错 “Inspector hasn’t been enabled”，有时候截到白屏。

排查了半天，发现是时序问题。CDP的 Page.navigate 返回不代表页面加载完成，这时候调用 Page.captureScreenshot 就会失败。

理想方案是监听 Page.loadEventFired 事件，确保页面真正加载完再截图。但这样代码复杂度会翻倍，而这个项目只是实验性的…

所以先搞了个简单粗暴的方案：硬延迟1秒。

await Page.navigate({ url });
await new Promise(resolve => setTimeout(resolve, 1000)); // 简单粗暴
const screenshot = await Page.captureScreenshot({ format: 'png' });

我知道这很不优雅，但先跑通再说。TODO里已经记上了，后续优化。

实现的功能

现在这个实验项目支持这些工具：

工具	功能
chrome_connect	连接Chrome远程调试端口
chrome_navigate	导航到指定URL
chrome_screenshot	截图（PNG/JPEG）
chrome_evaluate	在页面执行JS代码
chrome_get_dom	获取简化版DOM结构

用法大概是这样：

用户：帮我打开 https://example.com 并截图
AI：调用 chrome_connect → chrome_navigate → chrome_screenshot

或者：

用户：执行代码统计页面有多少个链接
AI：调用 chrome_evaluate，expression: "document.querySelectorAll('a').length"

实际能用来干啥

说实话，这个实验代码还比较粗糙，但已经能做一些有意思的事了：

前端调试辅助

• 让AI截图看页面渲染效果
• 执行JS代码测试功能
• 快速获取DOM结构分析

数据采集

• AI可以控制浏览器访问页面
• 执行代码提取数据
• 截图保存视觉信息

自动化测试

• 让AI验证页面行为
• 截图对比UI变化
• 执行测试脚本

但说实话，这些场景用传统的自动化工具（Puppeteer、Playwright）也能做。MCP的价值在于标准化——AI助手不需要知道每个工具的具体实现，只要遵循MCP协议，就能调用任何功能。

代码质量怎么样

直接说：实验性代码，别用在生产环境。

问题一大堆：

• 错误处理很粗糙，出错就崩
• 截图用硬延迟，不是正经方案
• 完全没写测试
• 有些类型用any，不够严谨

但这就是实验项目的意义——先跑通MVP，再迭代优化。

我把踩坑过程都记录在 experiments/ 目录里了，有兴趣可以看看。

后续想法

这个项目让我对MCP协议有了更深的理解。MCP的核心价值在于标准化和可组合性。

想象一个场景：

• MCP Server A 控制Chrome浏览器
• MCP Server B 操作数据库
• MCP Server C 调用AI模型

AI助手可以同时用这三个Server，组合出复杂的工作流。比如：“打开这个页面，提取数据，存到数据库，生成报告”。

这种可组合性是未来的趋势。每个MCP Server都是一个"乐高积木"，可以按需组合。

局限性

必须要说，这个项目还有不少局限：

1. 需要手动启动Chrome - 不能像Puppeteer那样自动启动浏览器
2. 只支持单个标签页 - 多标签页管理没做
3. 功能有限 - 网络监控、性能分析、断点调试都没实现
4. 仅支持本地Chrome - 远程浏览器、Headless模式没测试

但这些都在 ROADMAP.md 里了，有兴趣可以一起完善。

总结

花了一晚上捣鼓这个小项目，收获还是挺多的：

1. 对MCP协议有了实战经验 - 之前只是看文档，这次亲手实现了一个Server
2. 熟悉了Chrome DevTools Protocol - 发现CDP比想象中强大
3. 踩了一堆坑 - SDK版本兼容性、异步时序、类型定义…都是宝贵的经验

代码已经开源在 GitHub 上了：

📁 https://github.com/YaBoom/chrome-devtools-mcp-lite-zyt

如果你也在研究MCP或者Chrome自动化，欢迎交流！

---

一些问题想听听大家的想法：

1. 你觉得让AI控制浏览器这件事，最实用的场景是什么？
2. MCP协议你觉得会成标准吗？还是只是昙花一现？
3. 有没有遇到过MCP SDK版本兼容性的问题？

以上是我这几小时的探索记录，可能有理解不到位的地方，欢迎补充。