ChromeDevTools/chrome-devtools-mcp

它要解决的是很具体的一个断点：Agent 只能读代码，看不到浏览器里发生了什么。接上这个 MCP 服务或 CLI 后，Agent 可以自己打开页面、触发操作、录制性能 trace、读取带 source map 的控制台堆栈并检查网络请求，于是「页面为什么慢」这类问题从反复贴日志变成了 Agent 能自己取证的任务。

解决什么问题

你想让 Agent 诊断一个真实页面：它需要先进入页面、复现慢的交互，然后再看证据而不是只看 HTML。没有浏览器权限时，Agent 只能根据你提供的文件和截图推理，每观察一步都要回到你这里。使用这个项目后，Agent 调用的工具作用于一个活的 Chrome 会话，直接拿回 trace、控制台和网络数据。结果是 Agent 能在同一次会话里把用户可见的症状和具体的网络或性能发现对上。

有什么不同

设计上有两点值得注意。第一，浏览器操作由 Puppeteer 执行，并且会自动等待操作结果，Agent 不必为常规交互自己写等待和重试逻辑 项目说明。第二，性能分析直接来自 Chrome DevTools：它录制 trace 并提取可操作的结论，而不是把原始 JSON 丢给 Agent 自己解读 项目说明，输出更接近 Performance 面板给出的判断。

项目同时提供 MCP 服务、CLI 和可安装的 skills 项目说明。这种广度有实际意义：支持插件的 Agent 一条命令就能装好整套配置，不支持的 Agent 则需要手动复制 skill 目录，而且 CLI 对应的 skill 还要求先全局安装包。代价是暴露面。README 明确写到，该服务会把浏览器实例的内容暴露给 MCP 客户端，客户端可以查看和修改浏览器里的数据。它适合专门用来调试、可以随时丢弃的会话，不适合直接连到存有个人数据的已登录配置上。

谁值得试

第一类合适的人是已经在用 Agent 写代码、但卡在「页面有点慢」或「这个请求只在浏览器里失败」上的 Web 开发者，trace 和控制台工具正好补上缺失的证据。第二类是需要可复现自动化的人：点击由 Puppeteer 处理，Agent 拿到的是结构化结果而不是脆弱的脚本。不合适的是想在日常浏览中让 Agent 参与、或者需要 Firefox/Safari 一致支持的人，因为官方只支持 Google Chrome 和 Chrome for Testing 项目说明。对数据管理有严格要求的团队也要先停下：调用成功率、延迟和环境信息等使用统计默认开启，需要手动退出 项目说明。

使用条件与边界

你需要 Node.js LTS、当前稳定版或更新的 Chrome，以及 npm 项目说明。MCP 客户端用一条 npx 命令即可配置，浏览器只在一个工具需要时才会启动，所以配置好但闲置的服务不会一直占着一个浏览器。编辑器相关的配置有单独说明，可参考客户端配置指南 项目说明。

有两个边界值得在安装前想清楚。浏览器兼容性实际上只有 Chrome：其他 Chromium 浏览器可能能跑，但不在支持范围内，不要把跨浏览器调试流程建立在这上面。数据披露是双向的：连到真实配置意味着其中的 cookie、登录态和页面内容都会对 MCP 客户端可见；使用统计和更新检查也默认开启，并且各有独立的环境变量可以关闭。需要预留时间决定用哪个浏览器配置、关掉哪些默认项，而不只是完成初始配置。

HotRepo 点评

从 2026-05-22 到 2026-10-27，该项目在 HotRepo 日榜上出现了 16 个记录日，2026-10-27 时为 54,246 星，记录到的单日增量从 2026-05-23 的 +437 降到 2026-10-27 的 +70 HotRepo 榜单记录。这说明它长期出现在榜上，而不是只露面一天，但记录样本稀疏，无法证明增长趋势稳定。采用前真正要确认的是连到哪个浏览器配置：先看关于持久化配置和连接已有 Chrome 实例的高级用法说明。对于只支持 Chrome 这一点，Chrome for Testing 下载是文档给出的受支持途径 Chrome for Testing。