chrome-devtools-mcp（ChromeDevTools/chrome-devtools-mcp）：把 Chrome DevTools 变成编码智能体的诊断工具面

一、导读

编码智能体写前端代码时有一个结构性缺陷：它看不见页面。它只能读源码、猜 DOM、凭经验断言「这样应该能跑」。一旦问题出在运行时行为上——控制台报错、网络请求时序、Core Web Vitals 劣化、内存泄漏——它就只能请人类打开 DevTools 手工排查，再把结论抄回对话里。

Chrome DevTools for agents（chrome-devtools-mcp）补的正是这一环：它把 Chrome DevTools 的能力封装成一个 MCP 服务器与同源 CLI，让编码智能体自己录性能 trace、读控制台与网络、抓 V8 堆快照、跑 Lighthouse 审计。本文拆解它 63 个工具与 13 个工具类别的组织方式、任务队列并发模型、trace 洞察引擎的实现取舍，以及它与 Playwright MCP 之间那条常被混淆的分工边界。

二、项目速览

项目	内容
仓库	`ChromeDevTools/chrome-devtools-mcp`
作者 / 归属	Google Chrome DevTools 团队
主语言	TypeScript（Node.js）
Star 总数	55,418
当日涨星	145（2026-11-13 日榜）
License	Apache-2.0
首次发布	仓库创建于 2025-09-11；1.0 稳定版于 2026-05-19 发布
最新版本	`chrome-devtools-mcp-v1.13.0`（2026-11-11）
代码规模	469 个文件（132 个 src、167 个测试）；63 个工具、13 个类别、8 个技能
运行门槛	Node.js LTS；Chrome 当前稳定版或更新

数据来源：GitHub API /repos、/releases、/git/trees?recursive=1，以及仓库 main 分支的 README、docs、CHANGELOG，获取日期 2026-11-13。

三、为什么是它：把「DevTools 面板」变成智能体的工具面

浏览器自动化不是新问题，Playwright 与 Puppeteer 已经解决了「让程序操作网页」。但操作与诊断是两件事。Playwright 能告诉你「这个流程走不通」，回答不了「为什么慢、慢在哪、哪个请求拖了后腿」。后者需要 DevTools 的 Performance 面板、Network 瀑布流、Console 堆栈与 Memory 快照——而这些能力过去只对人类开发者开放。

chrome-devtools-mcp 的定位就是把这个面板搬给智能体。它不自己实现一套浏览器自动化，而是通过 Puppeteer 接入 Chrome DevTools Protocol，再把 DevTools 前端（devtools-frontend）里沉淀多年的分析引擎——trace 洞察、堆快照模型、CSS 级联解析、Lighthouse——包装成 MCP 工具。README 里那句「让编码智能体拿到 Chrome DevTools 的全部能力」，说的就是这个复用关系。

涨星动因有三层。第一是版本节奏：1.13.0 于 2026-11-11 发布，新增了基于 DevTools BreakpointManager 的 logpoints（不改进程即可在指定源码行打印表达式）与页面级网络 mock，正是「调试时最想要但一直缺」的两块。第二是分发渠道：它被内置进 Antigravity 2.0，也能通过 Gemini CLI 的 gemini extensions install 与 Claude Code 的插件市场一条命令装上，npm 包名即 chrome-devtools-mcp。第三是 1.0 稳定版的信任背书：2026-05-19 从公开预览转为稳定版后，工具面与配置项才真正进入可依赖状态。

需要说清的边界：它只支持 Google Chrome 与 Chrome for Testing，其他 Chromium 内核浏览器「可能能用但不保证」；Firefox 与 WebKit 完全不在支持范围内。这不是实现疏漏，而是产品定位——它复用的是 DevTools 前端，而 DevTools 前端只服务 Chrome。

四、架构原理

4.1 整体架构：一个服务器、两种客户端、三层复用

它不是「一个 MCP 服务器」这么简单，而是同一套工具面的两个入口 + 一个后台守护进程：

┌──────────────────────────────────────────────────────────────────┐
│  客户端层                                                          │
│  MCP 客户端（Claude Code / Cursor / Copilot / Gemini CLI / …）      │
│  chrome-devtools CLI（终端，同源工具面，可脚本化）                    │
└───────────────┬──────────────────────────────┬───────────────────┘
                │ stdio (MCP JSON-RPC)         │ Unix socket / 命名管道
                ▼                              ▼
┌──────────────────────────────────────────────────────────────────┐
│  服务器层 chrome-devtools-mcp                                      │
│  ┌────────────────┐  ┌─────────────────┐  ┌──────────────────┐   │
│  │ McpServer      │  │ ToolHandler     │  │ McpResponse      │   │
│  │ 工具注册/能力门  │→ │ 任务队列/并发闸  │→ │ 语义化摘要/分页   │   │
│  └────────────────┘  └─────────────────┘  └──────────────────┘   │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │ 13 个工具类别 · 63 个工具（Input/Nav/Emulation/Perf/…）      │  │
│  └────────────────────────────────────────────────────────────┘  │
└───────────────┬──────────────────────────────┬───────────────────┘
                │ Puppeteer (CDP)              │ 复用 DevTools 前端
                ▼                              ▼
┌──────────────────────────────────────────────────────────────────┐
│  浏览器层                                                          │
│  Chrome 实例（新建 / --browserUrl / --wsEndpoint / --autoConnect） │
│  PageCollector · ServiceWorkerCollector · NetworkOverrideManager  │
└──────────────────────────────────────────────────────────────────┘
                │
                ▼
┌──────────────────────────────────────────────────────────────────┐
│  分析引擎层（从 devtools-frontend 复用）                            │
│  TraceEngine.Insights（LCP/INP/CLS 洞察）· HeapSnapshotModel       │
│  CssFormatter（级联解析）· Lighthouse · SourceMap 堆栈还原          │
└──────────────────────────────────────────────────────────────────┘

为什么要有 CLI 这一层。 MCP 的代价是「工具 schema 常驻上下文」。CLI 把同一批工具变成命令行调用，智能体只需读一份技能文档就能生成 shell 脚本，不必把 63 个工具的 JSON schema 全部塞进每一轮对话。docs/cli.md 明确写了这个动机：CLI 特别适合「让智能体生成脚本来自动化浏览器操作」。代价是 CLI 的调用结果需要智能体自己解析，而 MCP 会返回结构化摘要。

为什么要有守护进程。 CLI 不是每次重新起浏览器——它连的是一个后台 chrome-devtools-mcp 守护进程（Linux/macOS 走 Unix socket，Windows 走命名管道）。首次调用工具时自动启动服务器与浏览器，后续命令复用同一实例，页面、Cookie、登录态全部保留。daemon.ts 里有一段值得注意的硬化逻辑：启动前检查 PID 目录不是符号链接、属主是当前用户、权限不含 group/world 可写位，任一不满足就拒绝启动并报「可能被篡改」。这是把「本地 socket 劫持」当成真实威胁来防的写法。

4.2 分层拆解

工具层（src/tools/） 是能力面。63 个工具按 13 个类别组织，每类默认开关不同：

类别	工具数	默认	说明
Input automation	10	开	`click`/`fill`/`fill_form`/`drag`/`press_key`/`upload_file` 等
Navigation automation	6	开	`navigate_page`/`new_page`/`list_pages`/`wait_for` 等
Debugging	10	开	`evaluate_script`/`get_css_styles`/`lighthouse_audit`/`set_logpoints` 等
Memory	14	开	`take_heapsnapshot` 及 13 个堆分析工具
Performance	3	开	`performance_start_trace`/`stop_trace`/`analyze_insight`
Network	2	开	`list_network_requests`/`get_network_request`
Emulation	2	开	`emulate`/`resize_page`
Network mocks	2	关	`mock_network`/`remove_network_mock`
Extensions	5	关	扩展安装、重载、触发 action
Progressive Web Apps	4	关	PWA 安装/启动/卸载/状态
Third-party	2	关	页面自己通过 WebMCP 暴露的调试工具
WebMCP	2	关	需 Chrome 150+ 与特性开关
WebAuthn	1	关	虚拟认证器，测试 passkey 流程

默认关闭的类别有一个共同点：它们要么扩大攻击面（扩展、第三方工具、WebMCP），要么改变页面行为（网络 mock、WebAuthn）。默认只开「读与常规操作」，危险能力显式开启——这是把最小权限原则写进了默认值。

配置层（src/config/） 负责参数与热重载。选项来源有优先级：命令行 flag > --config 指定文件 > 插件目录的 cd4a.config.json > 全局配置（macOS/Linux 为 ~/.config/cd4a/config.json）。--watchConfig 打开后，配置文件变化会触发重新读取，并通过 notifications/tools/list_changed 通知 MCP 客户端；工具类别与 URL 限制立即生效，而 headless、channel、viewport 这类启动参数必须重启。文档里有一条直白的警告：配置文件与父目录不能让智能体可写——因为 executablePath、chromeArg、allowedUrlPattern 都在里面，能改文件就能绕过限制。

收集层（src/collectors/） 是「页面状态」的单一事实源。PageCollector 按页面维护控制台消息与网络请求的环形缓冲，--maxNavigationSaved（默认 3，范围 1–25）决定保留几次导航的历史。超出窗口的导航只保留 URL、状态码与请求/响应头——足以追重定向链，但响应体通常已不可得。这是个明确的取舍：保留全部历史会让长会话的内存无上限增长，保留 3 次够覆盖「刚才那次失败」这个最常见场景。

响应层（src/McpResponse.ts） 决定模型看到什么。它不做「原样转发 CDP 数据」，而是把结果格式化成语义摘要：性能 trace 输出「LCP 3.2s，瓶颈在资源加载延迟」，而不是几十万行 JSON 事件。设计原则文档把这条写成硬规则：「LCP was 3.2s」比 50k 行 JSON 更好；大块数据应该落到文件里。所以截图、trace、堆快照这类重资产一律返回文件路径或资源 URI，而不是原始字节流。

4.3 核心机制一：任务队列与并发闸门

这是整个服务器最容易被忽略、却最影响可靠性的设计。ToolDefinition.ts 给每个工具声明了三种并发语义：

/**
 * - 'exclusive'：整个调用期间独占上下文队列，期间没有任何其他浏览器工具能运行。
 *   用于所有触碰浏览器全局状态的工具，或未经页面级访问审查的工具。
 * - 'page'：跑在 pageId 所指页面的队列上（上下文队列的子队列）。
 *   不同页面的工具可并行；同页面的工具与 'exclusive' 工具互斥。
 * - 'none'：不入队，与任何工具并行。用于无浏览器的工具
 *   （数据自带保护，见 HeapSnapshotManager）与只读页面状态、等待外部事件的工具。
 */
export type ToolConcurrency = 'exclusive' | 'page' | 'none';

队列语义是沿父子链等待：一个任务要等同一队列、父队列、子队列上的任务全部完成。于是 exclusive 工具天然成为全局屏障，page 工具在页面内串行、页面间并行。performance_start_trace 声明为 exclusive——因为它要清空页面状态、启动 tracing、可能禁用 HTTP 缓存，这些操作与其他工具并发会互相污染。

配套的还有 blockedByDialog 标记：如果页面上弹出了原生对话框（alert/confirm/prompt），被标记的工具会先处理对话框再执行，避免调用卡死。

代价是什么：并发度被主动压低。同一页面上多个工具调用会被串行化，理论上比「全部并行」慢。但这个取舍是对的——浏览器是有状态的单例资源，并行操作同一页面会产生不可复现的竞态，而调试工具最不能容忍的就是不可复现。

4.4 核心机制二：trace 洞察引擎与「每次新建模型」

性能分析是这个项目最有技术含量的部分。performance_start_trace 的实现里有几个关键细节：

const categories = [
  '-*',
  ...DevTools.TracingDefaultCategories,
  ...DevTools.TracingOptionalCategories.JsSampling,
  ...DevTools.TracingOptionalCategories.Screenshot,
];
await page.pptrPage.tracing.start({
  categories,
  bufferSize: 1200 * 1000,   // 1.2 GB，与 DevTools 前端默认一致
});

bufferSize 设为 1.2 GB 是刻意的——1.9.0 的 changelog 写着「set default trace buffer size to match DevTools (1.2gb)」。默认缓冲区太小会截断长页面加载的 trace，而截断的 trace 会给出错误的洞察结论，比不给结论更危险。

真正的洞察来自 PerformanceTrace.ts：

// 每次调用都新建一个 TraceModel 实例，因为 Model 会把解析后的 trace
// 永久保留在内部 #traces 数组里，跨会话复用会造成无上限内存泄漏。
const engine = DevTools.TraceEngine.TraceModel.Model.createWithAllHandlers();
await engine.parse(events, { metadata: hasMetadata ? combinedMetadata : undefined });
const parsedTrace = engine.parsedTrace();
const insights = parsedTrace.insights ?? null;

注释把原因写得很清楚：复用引擎会泄漏，所以宁可每次重建。这是「用一点 CPU 换内存确定性」的取舍，在长会话的智能体场景里完全值得——一个跑几小时的会话如果每次 trace 都留一份解析结果，内存会线性增长到崩。

另一个细节在 ChunkedTraceParser.ts：trace 事件直接从原始字节缓冲分块解析，而不是先 JSON.parse 成字符串再处理。原因是 V8 对单个字符串有长度上限，几百 MB 的 trace 一次性转字符串会直接抛异常。分块解析让大 trace 可处理。

洞察本身不是自己写的启发式规则，而是 devtools-frontend 的 TraceEngine.Insights——也就是你在 DevTools Performance 面板里看到的同一套分析。performance_analyze_insight 支持按名称取具体洞察，例如 LCPBreakdown（拆出 TTFB / 资源加载延迟 / 资源加载时长 / 元素渲染延迟四个子部分）、DocumentLatency、RenderBlocking、LCPDiscovery。这意味着智能体拿到的诊断结论与人类在面板里看到的一致，不会出现「工具说没问题、面板说有问题」的分裂。

4.5 核心机制三：技能层与「渐进式复杂度」

工具之外还有 8 个技能（skills/），每个是一份带 frontmatter 的 SKILL.md：chrome-devtools、chrome-devtools-cli、a11y-debugging、cookie-debugging、debug-optimize-lcp、memory-leak-debugging、inspect-in-devtools、troubleshooting。

技能不是工具文档的复述，而是工作流编排。以 debug-optimize-lcp 为例，它把 LCP 优化拆成五步：录 trace → 分析洞察 → 定位 LCP 元素 → 查网络瀑布 → 检查 HTML 常见问题。里面还写了具体的判断阈值：

LCP 子部分	理想占比	衡量什么
TTFB	~40%	导航开始 → 收到 HTML 首字节
资源加载延迟	<10%	TTFB → 开始加载 LCP 资源
资源加载时长	~40%	下载 LCP 资源耗时
元素渲染延迟	<10%	资源下载完成 → LCP 元素渲染

并明确点出最常见的误判：「优化一个子部分而不检查其他部分」——如果渲染延迟才是瓶颈，把图片压小并不能解决问题，省下的时间只是转移到了渲染延迟上。 这类「反直觉但真实」的经验，正是把专家知识写成技能的价值。

技能还承担能力发现的职责。chrome-devtools 技能里写着：扩展工具需要 --categoryExtensions，内存工具需要 --memoryDebugging；如果工具列表里没有这些工具，「停下来，请用户更新 MCP 服务器配置」，并给出完整的 JSON 配置片段。这把「工具没加载」从一个令人困惑的失败，变成了一条可执行的指引。

设计原则文档里的 Progressive Complexity 说的就是这个：工具默认简单（高层动作），进阶参数可选；而技能负责告诉智能体「什么时候该用哪个」。

4.6 与其他架构路线的差异

浏览器智能体有三条主流路线，差异不在「能不能点按钮」，而在模型看到什么：

无障碍树路线（Playwright MCP）：把页面转成结构化可访问性树，元素有稳定引用，模型基于结构化数据操作。优点是确定性强、无需视觉模型；缺点是它描述的是「页面结构」，不是「运行时行为」。
视觉路线（截图 + 坐标点击）：模型看截图输出坐标。chrome-devtools-mcp 也提供这条路（--experimentalVision 开启 click_at(x,y)），但文档明说「通常需要能看图产出准确坐标的 computer-use 模型」，即默认不推荐。
DevTools 协议路线（本项目）：模型看到的是 trace、网络瀑布、控制台堆栈、堆快照。它回答的是「这个页面现在到底怎么了」。

一句话概括分工：你会打开 DevTools 的场景用它，你会写脚本的场景用 Playwright。 两者重叠区（导航、点击、截图、读网络）确实存在，但重心完全不同。

五、应用场景

场景一：让智能体自己修 LCP——从「页面慢」到「改哪一行」

业务痛点：前端性能问题最耗时的一步不是修复，而是定位。一个「首页加载 5 秒」的工单，需要人类打开 DevTools、录 trace、看瀑布流、逐条排除，才能得出「hero 图没加 fetchpriority 导致发现延迟」这类结论。编码智能体在拿到这个结论之前完全无能为力。

怎么解决：performance_start_trace + performance_analyze_insight + list_network_requests 三步闭环。

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

配好之后，一句提示词就能启动完整流程：

检查 https://example.com 的性能，找出 LCP 慢的原因并给出修复方案

智能体会依次调用 navigate_page → performance_start_trace（reload: true、autoStop: true，默认录 5 秒后自动停止）→ 从结果里取洞察集 ID → performance_analyze_insight 取 LCPBreakdown → 用 evaluate_script 定位 LCP 元素 → list_network_requests 过滤 image/font 看瀑布流。

收益与量化指标：LCP 的判定标准是公开的——≤2.5s 为好，2.5–4.0s 需改进，>4.0s 为差；技能文档还指出移动端 73% 的页面 LCP 元素是图片。子部分占比给出明确的优化优先级：延迟类子部分（资源加载延迟、元素渲染延迟）理想值都 <10%，一旦偏大就是首要优化点。相比「让模型读代码猜性能问题」，这条路径的结论来自真实 trace，可复现、可验证。

适用边界：lighthouse_audit 明确不包含性能类别——性能必须走 trace 洞察引擎这条路，两者不能混用。另外 trace 是真实浏览器环境录的，CI 里跑要注意机器负载差异，同一页面在不同机器上的绝对数值不可直接横向比较。

场景二：内存泄漏排查——14 个堆分析工具构成完整链路

业务痛点：内存泄漏是前端最难查的一类问题。症状是「用久了变卡」，但定位需要抓堆快照、对比两次快照、找出只增不减的对象、再顺着保留路径找到持有者。这套操作对人类都很繁琐，对只能读代码的智能体几乎不可能。

怎么解决：--memoryDebugging 开启后暴露 14 个工具，构成一条完整链路：

# 用 CLI 也可以走同一条链路
npm i chrome-devtools-mcp@latest -g
chrome-devtools start --memoryDebugging
chrome-devtools take_heapsnapshot 1 --filePath before.heapsnapshot
# …执行可疑用户流程…
chrome-devtools take_heapsnapshot 1 --filePath after.heapsnapshot
chrome-devtools compare_heapsnapshots 1 --before before.heapsnapshot --after after.heapsnapshot
chrome-devtools get_heapsnapshot_retaining_paths 1 --nodeId <id>

14 个工具的分工是：take_heapsnapshot 抓取；compare_heapsnapshots 做前后对比；get_heapsnapshot_summary/get_heapsnapshot_details 看概览与明细；get_heapsnapshot_dominators 找支配者（真正的内存大户）；get_heapsnapshot_retainers 与 get_heapsnapshot_retaining_paths 回答「谁在持有这个对象」——这是定位泄漏源的最后一公里；get_heapsnapshot_duplicate_strings 找重复字符串；query_heapsnapshot_objects 按条件查询对象；analyze_heapsnapshot_contexts 做上下文分析。

收益与量化指标：1.12.0 加入了一项关键能力——「无需浏览器连接即可分析堆快照」。这意味着可以把生产环境导出的 .heapsnapshot 文件直接交给智能体离线分析，不必复现现场。另外 compare_heapsnapshots 支持分页与 maxNameLength 截断，避免大堆快照把上下文撑爆。

适用边界：堆快照是重资产，文件动辄几百 MB。设计原则要求这类数据返回文件路径而非原始流，但分析结果仍会占用上下文。技能文档里也提醒：take_heapsnapshot 需要显式开启 --memoryDebugging，默认不可用——这是防止智能体在无关任务里误抓快照把会话拖垮。

场景三：可访问性审计与修复闭环

业务痛点：a11y 问题的特点是「代码看起来没问题」。<div onClick> 在视觉上完全正常，但键盘用户无法触发；opacity: 0 隐藏的元素对屏幕阅读器仍然可见。这类问题靠读代码几乎发现不了。

怎么解决：a11y-debugging 技能给出三步工作流——先跑 Lighthouse 拿基线，再读浏览器原生 a11y 审计，最后用无障碍树验证语义结构。

chrome-devtools lighthouse_audit 1 --mode navigation

技能里有一条很实用的建议：不要逐行读 Lighthouse 报告，而是用 jq 或 Node 一行命令只提取失败项：

node -e "const r=require('<path/to/report.json>'); \
  Object.values(r.audits).filter(a=>a.score!==null && a.score<1) \
  .forEach(a=>console.log(JSON.stringify({id:a.id,title:a.title,items:a.details?.items})))"

这样只把失败的 selector 与 snippet 拉进上下文，而不是整份报告。

收益与量化指标：Lighthouse 输出 0–100 的类别分数与 Passed: N / Failed: N 计数，是可追踪的量化基线。take_snapshot 返回的是无障碍树而非 DOM——技能文档明确说这是「辅助技术实际看到的内容」，是语义结构最可靠的真相来源。此外 list_console_messages 配合 types: ["issue"] 与 includePreservedMessages: true 能拿到 Chrome 自动检测的 a11y 问题（缺 label、非法 ARIA 属性），这类问题不需要人工构造测试用例。

适用边界：Lighthouse 的 a11y 分数是自动化可检测部分的分数，不等于真实可访问性。键盘导航顺序、屏幕阅读器朗读体验这类问题仍需人工验证。技能文档也提示：take_snapshot 是无障碍树，与 DOM 结构不完全对应，做 DOM 断言时要用 evaluate_script。

场景四：连接「你正在用的那个浏览器」——登录态调试

业务痛点：默认情况下 MCP 服务器会新起一个 Chrome 实例，用独立 profile。这在调试需要登录的页面时是灾难：智能体没有你的登录态，看不到真实问题。而有些站点会拒绝 WebDriver 控制的浏览器登录——这恰好是默认启动机制。

怎么解决：三条连接路径，按场景选。

// 路径 A：自动连接（Chrome 144+），适合在手动测试与智能体测试间共享状态
{ "mcpServers": { "chrome-devtools": {
  "command": "npx",
  "args": ["chrome-devtools-mcp@latest", "--autoConnect"] } } }

先在 Chrome 里访问 chrome://inspect/#remote-debugging 打开远程调试，之后 MCP 服务器会弹窗请求授权，点「允许」即可接管。路径 B 是 --browserUrl=http://127.0.0.1:9222，适合在沙箱里跑智能体、浏览器在沙箱外的场景。路径 C 是 --wsEndpoint 加 --wsHeaders，可以带 Authorization 头连远程浏览器。

收益与量化指标：inspect-in-devtools 技能把这条路走得更远——它支持读取用户在 DevTools 里的当前选择：用户在 Elements 面板选中一个元素，智能体调 take_snapshot 就能拿到该元素的 uid，再用 get_css_styles 或 evaluate_script 接着分析；用户在 Network 面板选中一个请求，智能体调 get_network_request 省略 reqid 就能拿到那个请求。还有一个评论线程工作流：get_devtools_comments 拉取 DevTools 里的评论，resolve_devtools_comment 逐条处理。这把「人机协作」从「人描述问题给 AI」变成了「人在界面上指出问题，AI 直接接手」。

适用边界：这条路线的风险必须说清。README 原文警告：服务器会把浏览器实例的内容暴露给 MCP 客户端，允许其检查、调试、修改浏览器或 DevTools 中的任何数据——所以不要在你登录着敏感账号的浏览器上使用。--browserUrl 的文档也警告：开启远程调试端口后，机器上任何应用都能连上并控制浏览器。此外 --autoConnect 需要用户手动启动 Chrome，且多 profile 时只会连默认 profile。

明确不建议使用的场景

跨浏览器测试。只支持 Chrome 与 Chrome for Testing。要验证 Safari/Firefox 请用 Playwright。
写测试用例。它没有测试运行器，不管理断言与生命周期。它是诊断工具，不是测试框架。
网页抓取。项目文档明确说它「不是为抓取而建」，尤其不适合。抓取应该用模型分析页面结构 + 普通代码做重复劳动。
绕过反爬。它驱动的是标准自动化构建，不解决「站点封锁智能体」的问题。
把 --slim 当省 token 的万能解。--slim 只暴露 3 个工具（navigate/evaluate/screenshot），代价是失去全部诊断能力——而诊断正是这个项目的价值所在。

六、快速上手

# 环境要求：Node.js LTS + Chrome 当前稳定版或更新
# 方式一：MCP 客户端配置（推荐）
# 在 Claude Code / Cursor / Copilot / Gemini CLI 的 MCP 配置里加入：

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

# 方式二：作为插件安装（同时装上 MCP 服务器与全部技能）
# Claude Code：
#   /plugin marketplace add ChromeDevTools/chrome-devtools-mcp
#   /plugin install chrome-devtools-mcp@chrome-devtools-plugins
# Gemini CLI：
gemini extensions install --auto-update https://github.com/ChromeDevTools/chrome-devtools-mcp

# 方式三：只用 CLI
npm i chrome-devtools-mcp@latest -g
chrome-devtools status                                    # 检查守护进程
chrome-devtools navigate_page 1 --url "https://developers.chrome.com"
chrome-devtools take_screenshot 1 --filePath screenshot.png
chrome-devtools stop                                      # 用完停掉

装好后第一句提示词（README 官方推荐）：

检查 https://developers.chrome.com 的性能

MCP 客户端应该会打开浏览器并录一段性能 trace。注意：服务器不会在连接时自动启动浏览器，只有第一次调用需要浏览器的工具时才会启动。

常用配置项：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--headless=true",
        "--isolated=true",
        "--memoryDebugging=true",
        "--no-usage-statistics"
      ]
    }
  }
}

--isolated 使用临时 user-data-dir 并在关闭后自动清理，适合自动化测试；不加则复用 ~/.cache/chrome-devtools-mcp/chrome-profile，登录态得以保留。--no-usage-statistics 关闭默认开启的使用统计（设置 CI 环境变量也会自动关闭）。

七、横向对比

维度	Chrome DevTools MCP	Playwright MCP	Claude in Chrome	浏览器智能体视觉路线
维护方	Google Chrome DevTools 团队	Microsoft	Anthropic	各厂商
模型看到什么	DevTools：trace、网络、控制台、堆快照	无障碍树	你的真实浏览器会话	截图 + 坐标
浏览器支持	仅 Chrome / Chrome for Testing	chrome / firefox / webkit / msedge	仅 Chrome（扩展）	视实现
擅长	性能剖析、网络诊断、内存分析、a11y 审计	驱动流程、写测试、跨浏览器验证	真实账号、复杂登录态	无 DOM 语义的界面
弱项	不写测试、不跨浏览器	无 DevTools 级性能洞察	无法做干净复现	稳定性差、token 消耗高
网络 mock	有（需 `--categoryNetworkMocks`）	有（`--caps=network`）	无	无
手动交接	原生支持（连当前 Chrome、读 DevTools 选区）	通过 `browser.bind()` 间接支持	本身就是交接	无
License	Apache-2.0	Apache-2.0	闭源	各异

上下文成本必须计入选型。 有第三方在 2026-11-04 做过实测（Chrome 159 Canary、macOS、每任务 5 次取中位数）：同一批页面读取任务下，Chrome DevTools MCP 的响应字符数普遍低于 Playwright MCP（HN 首页 30 条：10,049 vs 13,638；GitHub PR 188 条评论：100,304 vs 123,042），但在长博客这类页面上反而略高（23,734 vs 21,214）。工具定义本身也吃上下文——该实测记录 Playwright 25 个工具约 3,902 token，Chrome DevTools 32 个工具约 6,187 token（该数据来自第三方，版本与工具数均已变化，标注为待确认）。

结论：两者不是替代关系。你会打开 DevTools 的场景用它，你会写脚本的场景用 Playwright。 同时注册两个的代价是每轮对话付两份工具 schema，并给模型两组重叠的动词去纠结——不如按当下要回答的问题选一个。

八、局限、风险与社区观察

维护活跃度（正面信号）：仓库 2025-09-11 创建，pushed_at 为 2026-11-13。发布节奏稳定：1.10.0（09-23）→ 1.11.0（10-15）→ 1.12.0（10-22）→ 1.13.0（11-11）。469 个文件里 167 个是测试，测试占比约 36%，对浏览器自动化项目来说属于高水位。CHANGELOG 用 release-please 自动生成，每条都带 PR 与 commit 链接，可追溯性好。

风险一：默认开启使用统计。 README 明确写着 Google 会收集工具调用成功率、延迟与环境信息，默认开启，需 --no-usage-statistics 关闭。此外性能工具可能把 trace URL 发给 Google CrUX API 取真实用户数据，需 --no-performance-crux 关闭。这两项都是「默认开、可关」，但对合规敏感的场景必须显式处理。

风险二：浏览器内容全量暴露。 README 原文警告服务器会把浏览器实例内容暴露给 MCP 客户端，允许检查、调试、修改任何数据。连到你日常登录的 Chrome 时，智能体能看到你能看到的一切。--blockedUrlPattern / --allowedUrlPattern 可以做 URL 级限制，但文档也说明：已在连接时打开的、位于新禁止 URL 上的目标仍保持连接——限制是「对未来请求生效」，不是「立刻切断」。

风险三：配置文件是攻击面。 文档专门有一节「Locking down the configuration file from agent access」，警告配置文件与父目录不能让智能体可写，因为 executablePath、chromeArg、URL 限制都在里面。这等于承认：如果智能体能写配置文件，它就能绕过所有限制。部署时必须把配置放在操作员控制的位置。

风险四：--javascript-evaluation 不是沙箱。 关闭它只是禁用 evaluate_script、set_logpoints、initScript 与 javascript:/data:/vbscript: 导航。文档明确说：页面脚本与通过其他允许交互（点击、输入）触发的 JavaScript 仍然会执行；如果同时开了 --experimentalDevtools，DevTools UI 里的 Console 也能执行代码且不受此选项限制。同理 --file-navigations=false 也不是文件系统沙箱，只是限制服务器发起的导航。真正的隔离要靠操作系统级沙箱。

风险五：Chrome 版本耦合。 部分能力有硬性版本门槛：--autoConnect 需要 Chrome 144+，--allowedUrlPattern 需要 Chrome 149+，WebMCP 需要 Chrome 150+ 且要开特性开关，inspect-in-devtools 的评论功能需要 Chrome M159+。这意味着能力面随 Chrome 版本浮动，团队需要跟踪 Chrome 发布节奏。

License：Apache-2.0，允许商用与修改，附带专利授权条款。但注意它依赖 Chrome 与 DevTools 前端，实际使用受 Chrome 自身条款约束。

生产可用性判断：1.0 稳定版（2026-05-19）之后已进入可依赖状态，1.13.0 仍在加新能力而非只修 bug。但默认配置偏「开放」——使用统计开、URL 无限制、文件系统默认限 temp 目录（未协商 roots 时）。它适合作为开发期与 CI 的诊断工具进入流程，接入前必须显式收紧配置，不适合不加配置直接连到生产环境或含敏感登录态的浏览器。

九、小结与行动建议

先分清「驱动」与「诊断」。 如果你的需求是「让智能体跑通一个用户流程」，用 Playwright MCP；如果是「搞清楚这个页面为什么慢/报错/泄漏」，用这个。同时装两个会让每轮对话付两份工具 schema，并给模型两组重叠动词。
第一句提示词就用官方的性能检查。 检查 https://developers.chrome.com 的性能 能一次性验证「浏览器能启动、trace 能录、洞察能出」三件事，比逐个工具试快得多。
按需开类别，不要全开。 默认已开的是读与常规操作；--categoryNetworkMocks、--categoryExtensions、--memoryDebugging 这些改变页面行为或扩大攻击面的能力，只在具体任务里开。--slim 只适合「只要导航+截图」的极简场景，会丢掉全部诊断能力。
接入前先收紧三件事。 关掉使用统计（--no-usage-statistics）与 CrUX 上报（--no-performance-crux）；把配置文件放在智能体不可写的位置；用 --blockedUrlPattern / --allowedUrlPattern 限制可访问域名。这三项默认值都不适合直接上生产。
把技能当工作流文档读，而不只是安装。 debug-optimize-lcp 里的 LCP 四子部分占比表、a11y-debugging 里的「不要逐行读 Lighthouse 报告」、cookie-debugging 里的 HttpOnly 读取路径，都是可以直接搬到团队规范里的经验，价值不亚于工具本身。

数据来源与获取日期：仓库结构（469 文件、132 src、167 tests）、63 个工具与 13 个类别、8 个技能、配置项与默认值、并发模型（ToolConcurrency）、trace 实现细节（1.2 GB buffer、每次新建 TraceModel、分块解析）、daemon.ts 的 PID 目录硬化逻辑、LCP 子部分占比表、Lighthouse 用法与 a11y 工作流，均来自 github.com/ChromeDevTools/chrome-devtools-mcp 的 main 分支原始文件（README.md、CHANGELOG.md、docs/design-principles.md、docs/tool-reference.md、docs/slim-tool-reference.md、docs/configuration.md、docs/advanced-usage.md、docs/cli.md、src/tools/ToolDefinition.ts、src/tools/categories.ts、src/tools/performance.ts、src/processors/PerformanceTrace.ts、src/daemon/daemon.ts、skills/*/SKILL.md），抓取日期 2026-11-13。Star 数（55,418）、Fork 数（4,602）、License、创建时间（2025-09-11）、Release 列表来自 GitHub API（/repos、/releases、/git/trees?recursive=1），同日获取。当日涨星 145 来自 GitHub Trending 日榜（since=daily）2026-11-13 快照。1.0 稳定版日期（2026-05-19）、Chrome 149 的 DevTools for agents 更新、Antigravity 2.0 内置与 Gemini CLI/Claude Code 安装方式，来自 Chrome for Developers 官方博客与 Impress Watch 报道（2026-05/06）。Playwright MCP 与 Chrome DevTools MCP 的分工对比、上下文成本实测（HN 首页 10,049 vs 13,638 字符；工具定义 6,187 vs 3,902 token）来自第三方技术博客与 benchmark 仓库（2026-09/11），其中 token 与工具数数据随版本变化，标注为待确认。Chrome 版本门槛（144/149/150/M159）来自仓库 docs 与配置文档原文。