在之前的文章中，我们介绍过多种浏览器AI自动化工具，比如Playwright-mcp、browser-use、midsceneJs等，每种工具都能较好地基于AI大模型驱动浏览器完成自动化任务的执行。
而近期，Google官方推出了chrome浏览器的devtools mcp，更进一步丰富了通过AI驱动浏览器完成智能任务，包括执行自动化测试脚本的工具选择。
简而言之，DevTools MCP 就是 google 将 Chrome 浏览器的 devtools 底层方法，基于MCP（Model Context Protocol）标准，通过服务的方式暴露给AI大语言模型（LLM）使用，使AI大模型具备调用chrome浏览器底层调试工具的能力。
关于MCP的详细介绍，可以参见我之前的文章 【】
该工具使用分层架构，主要包含以下模块：
- MCP Server 层：负责接收来自 LLM/代理的 MCP 请求，进行会话管理与权限控制。
- 工具适配层：将 MCP 的高层请求映射到 Chrome DevTools Protocol（CDP）或 Puppeteer API，并管理长任务（如 recording/tracing）。
- Chrome 运行时：真实的 Chrome/Chromium 实例（headful 或 headless），执行所有底层操作并产生 trace、performance、console 等数据。
- 数据采集与传输：将采集到的 trace、堆栈、HAR、快照等数据序列化，通过 MCP 返回给调用方。
具体的调用过程如下图：
目前DevTools MCP开放的底层方法，主要包含如下六大类：
| 类别 | 数量 | 主要功能 |
|---|
| 输入自动化 | 7 | click、drag、fill、fill_form、handle_dialog、hover、upload_file |
| 导航自动化 | 7 | close_page、list_pages、navigate_page、navigate_page_history、new_page、select_page、wait_for |
| 性能 | 3 | performance_analyze_insight、performance_start_trace、performance_stop_trace |
| 调试 | 4 | evaluate_script、list_console_messages、take_screenshot、take_snapshot |
| 网络 | 2 | get_network_request、list_network_requests |
| 仿真 | 3 | emulate_cpu、emulate_network、resize_page |
安装和使用
该工具已在 Github 开源，地址：
https://github.com/ChromeDevTools/chrome-devtools-mcp
相对其他工具而言，配置安装极为简单，主页上也提供了各种主流AI终端的配置快捷方式。
以 Cursor 为例，在其MCP配置页面中，添加如下配置：
1
2
3
4
5
6
7
8
9
|
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}
|
确保本机已安装node.js且可以链接node包管理服务器即可。
配置完成后等待成功加载dev tools，显示支持的方法，如下图。
执行自动化测试
用一个典型的自动化任务测试一下，Cursor中输入提示词：
1
2
|
访问www.saucedemo.com并测试该网站standard_user登录时的主要功能，记录完成的测试用例和结果
|
Cursor会调用默认大模型制定执行计划，并自动通过devtools mcp打开浏览器并完成后续执行
启动浏览器并执行
首次执行，得到如下结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
| ### 测试范围
- 站点: https://www.saucedemo.com/
- 账号: standard_user / secret_sauce
- 浏览器: 桌面端（真实站点交互）
### 测试用例与结果
- 登录成功
- 步骤: 输入用户名standard_user与密码secret_sauce，点击登录
- 期望: 进入商品列表页
- 结果: 通过（进入“Products”列表页）
- 商品列表加载与详情页
- 步骤: 在列表页查看商品卡片，点击Sauce Labs Backpack进入详情
- 期望: 显示名称、描述、价格与操作按钮
- 结果: 通过（详情页展示完整，返回列表正常）
- 加入购物车与移除
- 步骤:
- 在详情页对Backpack执行“Add to cart/Remove”
- 在列表页对Bolt T-Shirt执行“Add to cart/Remove”
- 期望: 购物车角标数量正确变更；购物车页显示条目、可移除
- 结果: 通过（角标数量变更正确；购物车页显示两件商品且可移除）
- 结账流程（从购物车至下单完成）
- 步骤: 购物车→Checkout→填写First/Last/Zip→Overview→Finish
- 校验点: 金额汇总(小计/税费/总额)展示；完成页显示“Thank you for your order!”
- 结果: 通过（完成页成功展示，返回首页正常）
- 排序功能（待完成）
- 目标: 将筛选下拉从“Name (A to Z)”切到“Price (low to high)”，校验商品价格从低到高排序
- 当前状态: 下拉已展开但交互操作超时，未完成最终校验
- 结果: 待执行
- 登出功能（待完成）
- 目标: 通过左上角“Open Menu”→“Logout”
- 当前状态: 尚未执行
- 结果: 待执行
### 结论
- 已通过: 登录、列表与详情、购物车增删、完整结账。
- 待完成: 排序校验、登出。
|
可以看到，顺利完成预期执行任务。
相对Playwright-mcp等其他上层工具而言，Chrome DevTools因为直接从浏览器底层调用，执行速度，准确性上应该都更好，在和大模型的交互上，对Token的消耗应该也更为友好。
页面性能评估
而除了调用浏览器进行页面访问之外，DevTools MCP 因为直接调用底层方法，所以还可以提供其他AI浏览器工具较难直接采集的如性能数据、控制台信息等，为AI更全面操作浏览器和我们完成更底层任务提供了很大方便。
比如我们可以完成一个页面性能评估的测试任务，以评估我的博客为例：
1
| 访问@https://chengxiaqiucao.github.io/ 并评估该网站的性能
|
执行后，可以看到可以调用DevTools 提供的底层性能评估相关方法并完成执行。
最终得到如下结果：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
| ### 评估对象
- 站点: https://chengxiaqiucao.github.io/（Hugo + Stack 主题）
- 参考源: 站点公开内容与本次采样结果
- 主页内容参考: 秋草观“测”台
### 关键指标（Lab）
- 桌面环境（未限速/未降速）
- LCP: 477 ms（最大内容绘制为首页大图，IMG）
- CLS: 0.00
- 模拟移动（Fast 3G + CPU 4x 降速）
- LCP: 918 ms
- CLS: 0.00
- LCP分解（桌面样本）
- TTFB: 6 ms
- 资源发现/加载: 29 ms（发现 24 ms，下载 5 ms）
- 渲染延迟: 442 ms（占比 ~92.6%）
- LCP元素: post/123-markitdown/Pasted-20250907_...png（非阻塞加载，h2，200）
以上数据源自本次实验室采样；实测无CrUX字段数据。参考页面与内容来自站点首页导航与文章卡片等元素展示，见站点首页内容快照与链接：站点首页。
### 结论
- 指标优秀：LCP < 1s（桌面/移动），CLS=0，整体加载链路简单（静态站点，CDN缓存有效，h2）。
- 主要瓶颈在“渲染延迟”（Render delay），而非网络或资源下载。说明首屏主要消耗在样式计算/布局/绘制阶段，而非请求链路。
### 建议优化方向（按优先级）
- 关键渲染路径优化
- 优化首屏 DOM 体量与样式复杂度，减少重排重绘开销（列表卡片、图片容器阴影/圆角/滤镜等效果可审视）。
- 若使用 web 字体，确保 font-display: swap，避免首屏文字延迟绘制导致的渲染延迟。
- 图片策略
- 保持 LCP 图像“可及性”与非延迟加载；若尺寸偏大，可考虑 width/height 明确尺寸与 priority 提示（对支持的框架）。
- 为非首屏图片启用懒加载 loading="lazy" 与 decoding="async"，减轻首屏解码与布局压力。
- CSS 与第三方
- 合理分割 CSS，确保首屏关键样式内联或首屏优先引入，减少渲染阻塞。
- 审视第三方脚本与统计，延后非关键脚本执行或使用 defer/async，保证主线程用于首屏绘制。
- 缓存与交付
- 静态资源继续维持长缓存（已见 cache-control: max-age=600 等）；若内容稳定可延长并配合指纹。
- 确认图片经由适配格式（如 WebP/AVIF）与合适的分辨率/压缩率交付。
### 建议的后续验证
- 在真实移动设备上用 Lighthouse 分别对“冷启动/二次访问”测试，关注 FCP、INP 与 LCP 波动。
- 针对不同文章页（含大量图片/代码块）重复采样，观察 LCP 元素是否变化与渲染延迟是否上升。
- 引入性能预算（Performance Budget），对图片体积、CSS/JS 体积与请求数设定阈值，在 CI 中自动检查。
### 参考
- 站点: chengxiaqiucao.github.io
- 站点内容概览: 秋草观“测”台
- LCP 优化: Optimize LCP
- 关键渲染路径: Understanding the critical path
|
总结
通过以上的尝试，可以看到 Chrome DevTools MCP 在通过AI驱动浏览器执行方面，不但具备了之前我们强调的自动化智能执行能力，更加具备了更底层的“调试”和“诊断”能力，在我们进行AI自动化工具选型时，建议可以作为一个优选方向。