Chrome DevTools 终于有了官方 MCP：让 Claude Code / Cursor 直接「操控」一个真 Chrome，性能 / 网络 / 控制台随便查

一、一个让前端面试官都沉默的问题

昨天你给老板演示一个 React 页面，老板说：「这个页面打开怎么这么慢？」

你嘴上说「我这就去查」，心里其实慌得一批。

你打开 DevTools，切到 Performance 面板，按下录制，刷新页面，停下来，看那一堆密密麻麻的 flame chart——LCP、INP、CLS 三个红字在那儿闪。然后你得去翻 Network 找大文件、翻 Source 找长任务、翻 Memory 找泄漏…… 一圈下来 20 分钟过去了，老板早就不看了。

更惨的是第二天，团队里的 Cursor / Claude Code 给你「优化性能」。它给你把所有的 useMemo 加上、把图片全换成 WebP、把 React.lazy 套满整个路由 —— 结果你一测，LCP 反而变长了 200ms。

根本问题在哪？ AI 看不见真实的浏览器。它在「盲猜」。

而 Google Chrome DevTools 团队上周（2026-07-02）正式把整套 DevTools 协议包成了一个 MCP Server —— ChromeDevTools/chrome-devtools-mcp，让 Claude Code、Cursor、Copilot、Antigravity、Codex 第一次能像专业前端工程师一样，「真的开一个 Chrome，去看、去点、去测」。

45k Star，141 stars/day，稳定增长 957 commits / 55 个 release—— 这是 Google 官方团队在维护，不是又一个玩具项目。

二、项目背景：为什么 Puppeteer / Playwright 不够

在 chrome-devtools-mcp 出来之前，AI 操控浏览器只有两条路：

1. 自己调 Puppeteer / Playwright 写脚本 —— 但 AI 写浏览器自动化脚本非常容易翻车。selector 选错、wait 漏了、iframe 嵌套、shadow DOM…… 一个登录流程能 debug 半小时。
2. 用现成的 browser-use、Skyvern 这类高层 agent—— 它们是把「打开网页做任务」抽象得很高，但完全丧失了 DevTools 的精度：拿不到 performance trace、看不到 console error、抓不到 heap snapshot。

而 chrome-devtools-mcp 的思路不一样：它不重新发明浏览器自动化，它就是把 Chrome DevTools 协议原封不动地暴露成 MCP 工具。

这意味着 AI 能直接调用：

• performance_start_trace / performance_stop_trace 录 Performance 面板
• lighthouse_audit 跑 Lighthouse
• list_network_requests 拿到所有请求的 size /timing
• take_heapsnapshot 抓 V8 堆快照
• get_console_message 拿到 console 错误
• screencast_start 实时投屏让 AI 看到浏览器画面
• install_extension / list_extensions 调试浏览器扩展

这是一套「DevTools 工程师视角」的 MCP Server，不是一个「RPA 视角」的浏览器自动化工具。

三、核心功能：5 个真正” 对前端工程师有用” 的设计

1. 50+ 个 MCP 工具，覆盖 DevTools 全功能

官方把 Chrome DevTools 拆成 8 大类工具集：

类别	工具举例	干啥的
Input Automation	click / fill / fill_form / press_key / upload_file	模拟用户操作
Navigation	navigate_page / list_pages / new_page	切页、新开 tab
Emulation	emulate / resize_page	模拟地理位置、改窗口大小
Performance	performance_start_trace / lighthouse_audit	性能分析
Network	list_network_requests / get_network_request	网络请求分析
Debugging	evaluate_script / get_console_message / take_snapshot	跑 JS、查 console
Memory（--memoryDebugging=true）	take_heapsnapshot / compare_heapsnapshots_summary	内存泄漏分析
Extensions（--categoryExtensions=true）	install_extension / list_extensions	调试 Chrome 扩展

对比一下同类项目：browser-use 大概 30 个工具，但主要是 input/navigation；playwright-mcp 也就 20 多个。chrome-devtools-mcp 直接给到 50+ 个 —— 这是 Chrome DevTools 协议本身的能力，没有任何同类项目能匹敌。

2. --slim 模式：精简 3 工具，适合简单任务

如果你只是想让 AI 「打开一个网页、跑段 JS、截个图」，根本用不上 50 个工具的全量。官方提供 --slim 模式，只暴露 3 个工具：

• navigate_page
• evaluate_script
• take_screenshot

这非常重要。MCP 工具越多，AI 选错工具的概率越高。Slim 模式让 AI 在简单任务上更精准，也省 token。Chrome 团队的工程品味在这里体现得很明显。

3. 多客户端一键接入：VS Code、Cursor、Claude Code、Antigravity 全都接得上

这是 chrome-devtools-mcp 跟其它 MCP Server 最大的体感差异。它对客户端生态的支持做得到位：

• VS Code / VS Code Insiders —— 一键 install 按钮；
• Cursor —— 一键 install 按钮（深链）；
• Claude Code（CLI） —— 一行命令 claude mcp add chrome-devtools npx -y chrome-devtools-mcp@latest；
• Claude Code（Plugin，推荐） —— 装完有 /skills，AI 知道啥时候该用；
• Antigravity —— Google 自家的 AI IDE，自动连到 Antigravity 内置的 Chrome（端口 9222）；
• Codex —— 改 .codex/config.toml；
• Copilot CLI —— /mcp add 走流程；
• Gemini CLI —— 改 ~/.gemini/settings.json；
• JetBrains / Junie / Kiro / Katalon / Qoder / Warp / opencode —— 全都给了配置示例。

对比 playwright-mcp：它只支持 Claude Code、Cursor、VS Code 三家，写 README 都写不全。chrome-devtools-mcp 几乎覆盖了所有主流 AI 客户端 —— 它一开始就是奔着「生态」去的。

4. Performance + Lighthouse：AI 终于能” 看懂” Core Web Vitals

这是让我最惊艳的部分。AI 现在可以这样用：

“帮我分析 https://developers.chrome.com 的性能问题”

Claude Code 就会：

1. new_page 打开一个 tab
2. navigate_page 跳到目标 URL
3. performance_start_trace 开始录制
4. wait_for 等页面加载
5. performance_stop_trace 停下来，AI 拿到 trace 的结构化数据（LCP、INP、CLS、长任务、阻塞脚本、字体加载、CLS 偏移源）
6. lighthouse_audit 再跑一次 Lighthouse，拿到 SEO /a11y /best practices 评分

AI 拿到的是结构化的 trace 数据，不是截图、不是 HTML。它能直接告诉你「你的 LCP 元素是 <img class="hero">，被 1.2MB 的 main.css 阻塞了 800ms，建议 inline critical CSS」—— 这种程度的诊断，人类工程师都得查半天。

更狠的是：它可以调 get_network_requests 看哪些 JS bundle 体积最大、哪些图片没压缩、哪些 API 慢、哪些请求 404—— 全套 Chrome DevTools Network 面板的能力，AI 全有。

5. 内存泄漏分析：堆快照对比

对 React / Vue 项目来说，内存泄漏是出了名的难调。chrome-devtools-mcp 在 --memoryDebugging=true 下开放了完整的堆快照工具集：

• take_heapsnapshot：抓 V8 堆快照
• compare_heapsnapshots_summary：对比两个快照的差异
• get_heapsnapshot_dominators：找内存占用最大的对象
• get_heapsnapshot_retainers：找是谁在持有引用
• get_heapsnapshot_retaining_paths：找内存泄漏的引用链

以前要靠 Chrome DevTools Memory 面板手动抓两次对比，现在 AI 自己就能跑这个流程。你跟它说「我怀疑这个组件有内存泄漏，帮我抓两次堆快照对比」，它就会自己 navigate_page → 操作一次 → take_heapsnapshot → 再操作一次 → take_heapsnapshot → compare_heapsnapshots_summary，把对比结果直接吐给你。

四、实战示例：用 Claude Code 调 chrome-devtools-mcp 优化首页性能

下面是一个完整的实操流程，假设你有一个 Next.js 项目跑在 localhost:3000，想用 Claude Code + chrome-devtools-mcp 优化首页性能。

Step 1：启动 MCP Server

在 Claude Code 里加一行：

claude mcp add chrome-devtools npx -y chrome-devtools-mcp@latest

或者写 ~/.claude.json：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

Step 2：开一个 Claude Code 会话，下达指令

“用 chrome-devtools-mcp 跑一次 localhost:3000 的性能分析，看看 LCP 是不是 < 2.5s，如果不是，告诉我瓶颈在哪”

Claude Code 会自动：

1. new_page 开新 tab
2. navigate_page 到 localhost:3000
3. performance_start_trace 录 trace
4. wait_for 等到 </body> 出现
5. performance_stop_trace 拿 trace 数据
6. 分析 trace，告诉你 LCP 元素是哪个、什么时候 paint、被什么阻塞

Step 3：定位网络瓶颈

“再跑一次 list_network_requests，把所有> 100KB 的资源列出来，告诉我哪些可以优化”

Claude Code 会调 list_network_requests，把所有请求按 size 排序吐给你。你会看到类似：

1. /static/js/main.chunk.js        512KB  780ms
2. /static/css/main.css            198KB  420ms
3. /static/images/hero-banner.jpg  1.2MB  1.1s   ← LCP element
4. /static/fonts/inter-var.woff2   87KB   220ms

AI 会自己判断：hero-banner.jpg 是 LCP 元素但有 1.2MB，建议转 WebP + 加 fetchpriority="high"；main.css 阻塞渲染，建议 inline critical CSS。

Step 4：跑 Lighthouse 拿到 SEO /a11y 评分

“跑一次 lighthouse_audit，给我看完整评分”

lighthouse_audit 会跑完整版 Lighthouse，把 Performance / Accessibility / Best Practices / SEO 四个分项 + 改进建议全吐出来。AI 拿到后会自己解读：” 你的 a11y 是 72 分，主要扣分点是图片缺少 alt 文本、对比度不够；Performance 88 分，还有 2 项资源可以 preload。”

Step 5：修复后再回归

你按 AI 的建议改完代码，再跟 AI 说：” 再跑一次 performance + lighthouse，看分提了多少。”

整个流程完全闭环：性能分析 → 瓶颈定位 → 修复 → 回归，全在一个对话里。以前这种工作流要前端工程师 + Chrome DevTools + Lighthouse CLI + 反复切换工具，现在 AI 串起来了。

五、适用场景和限制

适合用：

• 性能优化 / 回归测试 —— 录 trace、跑 Lighthouse、对比前后差异；
• Bug 复现 ——AI 自己复现” 打开页面 → 点 X → 看 console” 的步骤；
• 前端 E2E 测试 ——fill_form + navigate_page + wait_for 可以做轻量 E2E；
• Chrome 扩展开发 ——--categoryExtensions=true 后能 install /reload/trigger 扩展；
• WebMCP 调试 ——--categoryExperimentalWebmcp=true 后能调网页里的 WebMCP 工具；
• 跨浏览器兼容性排查（虽然官方只保证 Chrome）—— 可以配合 --no-performance-crux 关闭 CrUX 上报。

要注意：

• 只支持 Chrome / Chrome for Testing—— 其他 Chromium（Edge、Brave、Arc）可能能用但不保证修；
• 会上报使用统计 —— 默认会把工具调用成功率 / 延迟发给 Google，可以用 --no-usage-statistics 关掉；
• Performance 工具会调 CrUX API—— 会把 trace URL 发给 Google 拿真实用户体验数据，可以用 --no-performance-crux 关；
• 会暴露浏览器内容给 MCP 客户端 —— 不要在跑着这个 MCP 的 Chrome 里登录重要账号；
• MCP 客户端生态仍在分化 ——Antigravity、Claude Code、Cursor 之间对 MCP 的支持程度不一样，跨客户端体验会有差异；
• 不在本地启 Server 时也会自动开 Chrome—— 它会自己 fork 一个 Chrome 实例来跑，机器上需要装了 Chrome。

六、总结

chrome-devtools-mcp 的真正意义不在「又一个浏览器自动化的 MCP」，而在它是 Google Chrome DevTools 团队亲自下场做。

它和之前所有浏览器自动化 MCP 的区别，可以总结成一句话：

它是给前端工程师用的 DevTools 协议，不是给 RPA 用的浏览器脚本。

几个核心 takeaway：

1. DevTools 全协议 MCP 化 ——50+ 工具，Performance / Network / Memory / Console 全部结构化暴露，AI 拿到的是 trace 数据不是 HTML；
2. Slim 模式的设计品味 —— 简单任务只暴露 3 工具，AI 选错概率低、token 省；
3. 客户端生态最完整 ——Antigravity、Claude Code、Cursor、Codex、Copilot、Gemini 全都接得上，README 里把 13 个客户端的配置都写齐了；
4. Google 官方维护 ——957 commits、55 个 release、Chrome DevTools 团队直接下场，不是一个人周末写的 side project；
5. 性能分析闭环 —— 录 trace → 看 Network → 跑 Lighthouse → 给改进建议 → 修复后回归，全在一个 AI 对话里跑完。

如果你正在用 AI 写前端代码、并且被「AI 看不到真实浏览器」折磨过，chrome-devtools-mcp 值得你花 10 分钟接入试试。一行 npx 就能跑，门槛极低。

GitHub 地址：https://github.com/ChromeDevTools/chrome-devtools-mcp
官方文档：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/README.md
工具参考：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md