browser-use让AI操作浏览器，Chrome DevTools MCP让AI接入浏览器的眼睛——这件事把AI编程彻底变了

浏览器自动化工具我用过不少，今天 Chrome DevTools MCP 这条路线让我把「AI 能看见什么」这件事彻底想清楚了——不是 AI 自己操作浏览器，是 AI 直接接入了 Chrome 的眼睛，让它把浏览器内部正在发生的事全部告诉你。

三代工具在做的事根本不是一回事。browser-use 让 AI 操作浏览器，agent-browser 让 AI 通过 Chrome 扩展操作浏览器，而 Chrome DevTools MCP 让 AI 接入 Chrome 的眼睛。浏览器不是被 AI 指挥去做什么，而是把内部正在发生的事全部呈现出来——网络请求、控制台日志、DOM 状态、性能指标，AI 都可以直接读取。这个能力是前两代工具没有的。

Chrome DevTools MCP 走的是 Chrome DevTools Protocol。这条协议是 Chrome 团队给开发者调试用的，平时你打开 Chrome DevTools F12 看见的所有东西——Network 面板、Console、Performance、Elements——底层全是这条协议在跑。现在 MCP 把这条路直接交给 AI 了。

AI 拿到这条通道之后，能做的事变了。不再是「截图→AI 判断→指令→执行」这个循环，而是 AI 真的能看见浏览器内部。Network 面板里这个请求返回了什么、Console 里有没有报错、某个元素的 computed styles 是什么——AI 直接读，不需要靠猜。

这条路的安装方式也干净。一行命令：

npx chrome-devtools-mcp@latest

然后在 Claude Code 或者 Cursor 的 MCP 配置里加一个条目，连接已有的 Chrome 实例。它不需要单独起浏览器，不需要给 AI 新建一个带登录态的 Profile，AI 直接用你正在用的 Chrome——你登录过的网站、存过的 cookie、填过的表单，AI 全都能看见。

这条路的核心能力有五类。截图和元素检查是基础的，但真正的区别在于后四个：读 Console 日志让 AI 能看见 JS 运行时的输出，不需要靠 console.log 再重现一遍；抓 Network 请求让 AI 能看见接口返回了什么数据；拿 Performance 记录让 AI 知道页面渲染各阶段花了多少时间；最后是直接读 DOM 结构，AI 能看见页面当前的真实 HTML，不需要靠渲染后的截图猜。

这三代工具放在一起看，区别很清楚。browser-use 用的是 Playwright，AI 拿到的是截图，靠视觉判断页面状态再决定下一步。agent-browser 通过 Chrome 扩展注入脚本，做的事和 browser-use 差不多但不需要 Playwright。Chrome DevTools MCP 直接走 DevTools Protocol，AI 拿到的是浏览器内部状态，不是截图，是真实数据。

三代工具的分工也跟着清晰了。browser-use 适合端到端测试和复杂多步骤任务自动化；chrome-devtools-mcp 适合调试、性能分析、状态验证；browser-harness 适合高频小操作批量跑。现在我把三个工具组合起来用，比单独用一个工具顺手得多。

chrome-devtools-mcp 真正改变的是 AI 在前端开发里的角色。它不再只是执行指令的工具，而是变成了能观察浏览器状态的协作者。以前 AI 生成一段 CSS，你得自己打开浏览器看效果对不对；现在 AI 能自己打开 DevTools，检查生成的 DOM 结构、验证样式是否生效、读 Console 确认有没有报错。这个变化看起来不大，但它把 AI 从「盲目操作」升级到了「理解执行」。

chrome-devtools-mcp 不是万能的浏览器自动化工具。它的定位是调试感知，不是自动化控制——它不擅长连续执行多步操作，更适合和 browser-use 配合，一个跑自动化，一个跑调试。

如果你现在已经在用 Claude Code 或者 Cursor，装这个 MCP 基本上是零成本。只要机器上有 Chrome 就能用，不需要额外的 API Key，不需要额外部署服务。对于前端团队来说，这个工具让 AI 真正能帮上忙的地方又多了一个。