Agent 改完一段前端代码，它其实不知道页面上发生了什么。源码能读，单测能跑，但页面运行时是什么状态它一概不知。按钮点下去 DOM 变成什么样，控制台有没有抛错，LCP 是不是被一张没压缩的图拖垮，这些全都超出了它的视野。绝大多数编码 Agent 走到这一步，只能靠人肉截图来回喂。
chrome-devtools-mcp 补的就是这个断点。它由 Chrome DevTools 团队自己维护，Apache-2.0 许可，TypeScript 实现，把 DevTools 的完整能力通过 MCP 协议暴露给编码 Agent。官方支持列表里有 Claude Code、Cursor、Copilot 这类主流客户端，Gemini CLI 和 Codex 也各有对应的安装入口。最新版本 1.8.0 发布于 2026 年 8 月 25 日。
更有意思的是 Smithery 上那个页面本身。它收录的不是 MCP server，而是一份叫 Chrome DevTools Agent 的 SKILL.md，页面热度计数 20589，实际安装 42。围观的人极多，真正把它装进 agent 配置里的少得可怜，这个反差本身就说明了很多事情。
一句话概括它的架构取向：它没打算给 Agent 造一个”浏览器”，而是让 Agent 接管一个开着 DevTools 面板的真实 Chrome。这个取舍在后面会反复出现。
架构解析
整条链路是四层。MCP 客户端走 stdio 起一个 Node 子进程，进程内部用 puppeteer-core 驱动本机 Chrome，通信靠 CDP 协议，最底下是真实的浏览器实例。没有中间抽象层，也没有自研的浏览器内核，每一层都是现成的成熟组件。
选 puppeteer-core 而不是 puppeteer 是个很实在的决定。core 版本不捆绑 Chromium，直接复用你机器上装好的 Chrome，省掉几百 MB 下载和一次冷启动。代价是这个 server 对环境的假设变强了，没装 Chrome 就跑不起来，而且官方只承诺支持 Google Chrome 和 Chrome for Testing。
工具集按类目划分，README 里那份清单是自动生成的。默认打开的类目如下：
-
输入自动化 10 个（click、fill、press_key 等） -
导航与页面管理 6 个 -
模拟 2 个 -
性能 3 个 -
网络 2 个 -
调试 8 个，含 lighthouse_audit 与 take_snapshot
加起来三十出头。另外还有几块默认不露出来，要么需要显式开 flag，要么还挂着 experimental 前缀：内存分析 13 个、扩展 5 个、PWA 4 个，以及 WebMCP 与第三方开发者工具各 2 个。
有个容易被忽略的细节值得单独说：几乎所有类目都能整块摘掉。--category-emulation=false 关掉模拟，--category-performance=false 关掉性能，--slim 更狠，只剩 navigate_page、evaluate_script、take_screenshot 三个。这不是功能裁剪，是上下文预算管理，每个工具的定义都要占 Agent 的 prompt。
还有个 --page-id-routing 默认就是 true，页面级工具必须带 pageId，请求按 ID 路由。从设计推断，这是在给多个 Agent 会话并发操作同一个浏览器做准备，这类细节通常要真踩过坑才会加。
连接浏览器有三种姿势，适用场景差得很远：
| 方式 | 参数 | 适用场景 |
|---|---|---|
| 自启动 | 默认 | 本地开发，需要看见窗口 |
| 连已有实例 | --browser-url=http://127.0.0.1:9222 |
保留登录态，复用已有标签页 |
| WebSocket | --ws-endpoint=... --ws-headers=... |
远程或容器内的 Chrome |
这四层的边界划得很干净，越往上越”AI 友好”，越往下越”浏览器真实”。所有工具调用最终都会落到 CDP 的某个 Domain 上，Puppeteer 只是把这层协议包装成了 Promise。
工作流分析
真正决定使用体感的不是工具数量，是它规定的三种工作流模式。SKILL.md 里写得很直白，分别是快照优先找元素、排障看控制台加网络、性能剖析三段式。这三种模式基本覆盖了一个前端工程师日常在做的事。
第一种模式是整个交互的地基。take_snapshot 返回一棵带 uid 的可访问性树，click、fill、hover 全靠 uid 定位元素，不靠 CSS 选择器，也不靠视觉模型去猜坐标。代价是 uid 不稳定，DOM 一变就得重新快照。
第二种模式对应排障。list_console_messages 看报错，list_network_requests 找 4xx 和 5xx，evaluate_script 直接查运行时变量。这三板斧跟人在 DevTools 里干的事情一模一样，只是操作者换成了 Agent。
第三种模式最特别，也是这套工具最难被替代的地方，整个流程只有三步：
# 1. 开录，重载页面并自动结束
performance_start_trace(reload=true, autoStop=true)
# 2. 等页面加载完、trace 收完
# 3. 读洞察
performance_analyze_insight()
录 trace 这件事以前必须人手动点，现在 Agent 能自己走完整个闭环：先录一遍，读洞察，改源码，再录第二遍确认改动是否真的生效。也正因为这样，社区讨论里被反复提到的用例几乎都跟性能有关。
成本也必须讲清楚。第三方基准（OpenBrowser 发布于 2026 年 2 月的对比测试）拿同一套 5 步 Wikipedia 流程测了三个 MCP server，chrome-devtools-mcp 的响应量约 13.5 万 tokens，Playwright MCP 约 24.8 万，而走代码执行路线的 OpenBrowser 只有 283。
使用场景
把这个基准画出来，量级差距非常直观。
需要说明的是，这份基准由竞品自己发布，数字一定带有倾向性，但量级差异不太可能是编出来的。原因很清晰，take_snapshot 会把整棵可访问性树一次性返回，页面越复杂越贵，而每次导航、每次交互都可能触发一次快照。
所以它的甜蜜区相当明确，凡是依赖真实浏览器运行时信号的场景它都占优：
-
性能剖析与 Core Web Vitals 定位 -
内存泄漏定位 -
控制台报错追溯 -
只在真机上才复现的交互 bug
这些恰好是静态分析和单元测试够不着的地方。换个说法，如果你要的只是”把页面打开、点两下、截个图”，那这套工具的重量明显超标了。
反过来说，有几个场景它并不合适，跟主流替代品放在一起看更清楚：
| 维度 | chrome-devtools-mcp | playwright-mcp | puppeteer-mcp |
|---|---|---|---|
| 引擎 | Puppeteer + CDP | Playwright 驱动 | Puppeteer |
| 浏览器覆盖 | 仅 Chrome / Chrome for Testing | Chromium / Firefox / WebKit | 仅 Chromium |
| 元素定位 | a11y 树 uid | AI 快照 ref | 截图加坐标 |
| 独有优势 | 性能 trace、CrUX 真实用户数据、内存快照 | 跨浏览器、网络 mock、存储管理 | 工具面最小，适合当参考实现 |
| 许可 | Apache-2.0 | Apache-2.0 | 参考实现 |
长时无人值守的任务别开有头模式，操作系统迟早会锁屏或休眠把你的 Chrome 带走。跨浏览器兼容性测试也别用它，官方明确不保证其他 Chromium 内核的浏览器能正常工作。
洞察与反思
从设计上看，snapshot-first 最大的价值是把对视觉模型的依赖摘掉了。Agent 不需要”看懂”截图就能操作页面，这让整套流程变得确定、可复现、可审计。这是它比截图路线高明的地方，也是它敢不默认启用坐标类工具的原因。
但默认配置里有三件事需要你主动处理。使用统计默认开启，性能工具会把 trace 的 URL 发给 Google CrUX API 拉真实用户数据，npm 更新检查也默认在跑。企业环境里这几条都得显式关掉：
npx chrome-devtools-mcp@latest \
--no-usage-statistics \
--no-performance-crux
安全边界上，README 的免责声明写得毫不含糊：server 会把浏览器实例的全部内容暴露给 MCP 客户端，可以被读取、调试、修改。护栏是有的，--blocked-url-pattern 和 --allowed-url-pattern 能按 URLPattern 限制网络访问，文件写入默认被限制在系统临时目录，除非显式加 --allow-unrestricted-paths。
回头看 Smithery 上那份 SKILL.md，它的价值不在信息量，那些工具列表翻 README 也能拿到。真正有用的是它把三种工作流固化成了触发规则：什么时候该快照，什么时候该看网络，什么时候该录 trace。这份经验才是从“能调用”到“会用”之间的距离。
顺带说回开头那个 42。热度两万、安装四十二，这种比例在技能市场里并不罕见，它衡量的是好奇心和真实需求之间的落差。装一个浏览器 MCP 意味着要接受一个常驻的 Chrome 进程、一次权限放行和一堆上下文开销，多数人看完文档就走了，这很正常。
资源地址
总结
这套东西的核心特征可以概括成一句：不做浏览器抽象，只做能力搬运。Puppeteer 管驱动，CDP 管通信，Chrome 管真实，MCP 只负责把这一切翻译成 Agent 能调用的工具。
适合谁很清楚。做前端性能优化、要在真机上复现交互 bug、希望 Agent 能自己闭环验证改动的人，它目前没有像样的对手。不适合谁同样清楚：
-
要跨浏览器覆盖的测试团队 -
要跑几小时无人值守的长任务 -
对数据外发有硬性合规要求的环境
往前看，工具面还在快速扩张，1.7.0 之后紧接着 8 月底发了 1.8.0，内存分析那一整块 13 个工具也已经成形，PWA、WebMCP、第三方开发者工具还挂在 flag 后面。这种扩张速度带来的隐患是上下文预算会越来越紧张，我会更关注它后续在工具裁剪和上下文压缩上的动作，而不是又多了几个工具。