编码 Agent 有一个天生的盲区：它能读你的代码，却看不见页面跑起来之后发生了什么。控制台报了什么错、哪个请求慢了 3 秒、LCP 卡在哪一张图上，这些它只能靠你贴日志。
Chrome DevTools 团队做的 chrome-devtools-mcp，就是给 Agent 接一双 DevTools 的眼睛。它不是又一个浏览器自动化脚本，而是把 DevTools 自己的分析能力暴露成 MCP 工具——Agent 拿到的不是一个能被点击的页面，而是一份能读懂的性能报告。
仓库 5.55 万星（2026-11-14 用 GitHub API 核对），最后一次提交是 11 月 13 日，还在活跃开发。
装起来只要一段配置
它是个 npm 包，任何支持 MCP 的客户端都能接：
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}官方给的第一个验证提示词很直接：Check the performance of https://developers.chrome.com。正常的话，客户端会自己打开 Chrome、录一段 trace、把结论读回来。
同一套能力还有命令行版。装完全局包就能在终端里直接控制浏览器：
npm i chrome-devtools-mcp@latest -g
chrome-devtools navigate_page 1 --url "https://developers.chrome.com"
chrome-devtools take_screenshot 1 --filePath screenshot.png
chrome-devtools stop对写脚本或 CI 的场景，CLI 比 MCP 更顺手。
它到底给了 Agent 哪些能力
按官方工具参考分组，大致是六类：
| 组 | 代表工具 | 用来做什么 |
|---|---|---|
| 页面操作 | click、fill_form、press_key、upload_file、handle_dialog | 像人一样操作页面，包括处理弹窗和文件上传 |
| 导航 | navigate_page、new_page、list_pages、wait_for | 多标签管理、等待条件成立 |
| 性能 | performance_start_trace、performance_analyze_insight | 录 trace、看 Core Web Vitals、深挖具体问题 |
| 网络 | list_network_requests、get_network_request | 找出慢请求和失败请求 |
| 调试 | list_console_messages、evaluate_script、set_logpoints、lighthouse_audit | 读控制台、执行脚本、埋日志点、跑 Lighthouse |
| 内存 | take_heapsnapshot、compare_heapsnapshots、get_heapsnapshot_dominators | 抓堆快照、比对两次快照找泄漏 |
有两个工具值得单独说，因为它们不是"包装一下 puppeteer"能做到的。
一是 set_logpoints。它对应 DevTools Sources 面板里的日志点：在源码某一行挂一个表达式，那行每次执行就打印一次，不暂停、不改代码。支持 source map，所以你可以直接写 src/cart.ts:42 'cart total:', cart.total 这样的位置，Agent 在原始源码的行号上埋点。日志点还会跨刷新和导航存活，直到被移除或页面关闭。这对"偶发 bug"是刚需——你没法让 Agent 反复手动打断点。
二是性能那组。performance_start_trace 可以选是否重载页面、是否绕过缓存，把原始 trace 存成文件；录完给出的是一组 insight（比如 DocumentLatency、LCPBreakdown），再让 Agent 用 performance_analyze_insight 逐个深挖。也就是说，Agent 不是拿到一堆数字自己猜，而是拿到 DevTools 已经分析好的结论。
另外，性能工具会把 trace 的 URL 发给 Google 的 CrUX API，换回真实用户的体验数据（field data），和实验室数据并排看。这一步是联网的，介意的话加 --no-performance-crux 关掉。
两个默认值，装之前先知道
使用统计默认开着。Google 会收集工具调用成功率、延迟、环境信息。要关就在启动参数里加 --no-usage-statistics；设置 CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS 或 CI 环境变量也会关掉。注意它和 Chrome 浏览器自己的统计是两回事，关一个不等于关另一个。
它会把浏览器内容暴露给 MCP 客户端。官方在 README 里写得很直白：客户端可以查看、调试、修改浏览器里的任何数据。所以不要拿它去连你日常登录着银行和邮箱的那个 Chrome 用户目录。要隔离就用 --isolated，要用一次性环境就配 --headless。
还有一条容易踩的：官方只支持 Google Chrome 和 Chrome for Testing。Edge、Brave、Arc 这些 Chromium 系浏览器可能能用，但不在支持范围内。
为什么它比"自己写个 Puppeteer 脚本"强
差别在抽象层次。Puppeteer 给你的是"点这个元素、等这个选择器"，Agent 得自己决定点哪里、等多久、怎么判断成功。这个项目在 Puppeteer 之上包了一层"等动作结果"的逻辑，更重要的是把 DevTools 的分析能力接了出来：trace 解读、insight 归因、Lighthouse 审计、堆快照比对。
换句话说，它让 Agent 从"能操作浏览器"升级到"能诊断浏览器里的问题"。前者是手，后者是眼睛加判断。
它还带了 7 个技能
包里不止有服务端，还有一组教 Agent 怎么用这些工具的技能文件：
chrome-devtools：用 MCP 工具调试和自动化页面；chrome-devtools-cli：用 CLI 写 shell 脚本（需要先全局装包）；a11y-debugging：审计并修无障碍问题；cookie-debugging：排查 cookie、会话和登录态；debug-optimize-lcp：专攻 Largest Contentful Paint；memory-leak-debugging：找内存泄漏；troubleshooting：修 MCP 与 Chrome 之间的连接问题。
Claude Code、Copilot / VS Code、Gemini CLI 都能一次装插件（服务端加全部技能）；不支持的客户端就手动把技能目录拷进自己的 skills 文件夹。有一点官方特意提醒：技能描述的是特定版本的工具，升级服务端后要同步更新技能，否则 Agent 会照着旧参数调用已经不存在的工具。
该信多少
- 本文只读了官方 README、工具参考和配置文档，没有实际安装、没有跑通，所以不构成"推荐使用"的实测结论。
- 星数是 GitHub API 在 2026-11-14 读取的，会变。
- 工具清单以官方 tool-reference 为准，本文只列了代表项，不是全集；
--slim模式下只暴露精简工具集，具体差哪些要看 slim 参考文档。 - 性能结论的质量取决于 trace 录制方式（是否重载、是否绕缓存），同一页面不同录法给出的数字不可直接比较。
一句话判断
MCP 生态里"浏览器工具"已经很多，多数解决的是"Agent 能不能点"。这个项目解决的是"Agent 点完之后能不能判断好坏"。对一个正在被性能问题折磨的编码 Agent 来说，后者才是真正缺的那一块——但它也把浏览器里的一切都摊给了模型，用之前先想清楚你愿意让它看见什么。
来源
- ChromeDevTools/chrome-devtools-mcp（README、工具参考、技能目录；55,547 星，最后提交 2026-11-13）
- Tool reference（工具参数与行为说明）
说明：星数由 GitHub API 于 2026-11-14 读取；本文未安装或运行该工具，内容为官方文档解读。