Chrome DevTools MCP 可以让 Agent 连接已有的 Chrome 会话，但自动连接并不是零配置。按照 Google 目前的安装配置要求，需要 Chrome 144 或更高版本、在运行中的浏览器里启用远程调试、加上 --autoConnect flag，并由人工点击 Chrome 的 Allow 对话框。满足这些条件后，Agent 就能继承该浏览器配置文件（Profile）中已经打开的标签页和登录态。官方自动连接指南记录了每一项前提条件以及它授予的整个浏览器配置文件（Profile）范围的访问权限。Chrome DevTools MCP 需要另外打开一个浏览器供外部控制，而 ego (lite) 本身就是那个浏览器，无需切换开关，也无需反复授权。
在 Chrome DevTools MCP 的 issue 追踪器里，呼声最高的功能从来都不是某个调试工具，而是issue #140：让 Agent 连接我正在使用的 Chrome，并带上我的登录态。本文按顺序走完整条路径，包括坑和限制。
如何安装 Chrome DevTools MCP Server？
官方服务器是一个 npm 包，所以最快的 Claude Code 安装配置就是一条命令。它通过 stdio 在本地运行，不需要托管账号或 API Key。先检查 node --version：1.9.0 版本接受 Node 20.19+、22.12+ 或 23+，会在 Chrome 启动前拒绝更旧的运行时。然后在 user 作用域注册该服务器，让它在所有 Claude Code 项目中可用。
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest添加之后，在 Claude Code 中运行 /mcp，确认列表里有 chrome-devtools。当前官方仓库还提供了一个 Claude Code 插件，把 MCP 服务器和它的 skills 打包在一起：添加 ChromeDevTools/chrome-devtools-mcp 市场，安装 chrome-devtools-mcp@chrome-devtools-plugins，重启 Claude Code，再用 /skills 验证。如果之前已经手动安装过，先删掉重复条目再装插件，避免 Claude Code 加载两份。
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins有两个隐私设置容易被忽略。MCP 工具的用量统计默认开启，与 Chrome 浏览器的指标相互独立。性能工具还可能把追踪到的页面 URL 发送到 Google CrUX API 以获取实测数据。如果策略不允许其中任何一条路径，就在服务器参数里加上 --no-usage-statistics 和 --no-performance-crux，并在客户端实际启动的配置中确认这两个参数。
在干净的本地环境中，我们验证了什么？
2026 年 9 月 10 日，我们从 npm 解析了 chrome-devtools-mcp@latest，并在 macOS 上运行。包解析到 1.9.0。在 Node 19.9.0 下，它在启动前就退出并打印了最低引擎要求。在 Node 22.12.0 和 Chrome 152.0.7977.83 下，它启动了一个隔离的浏览器，并通过 MCP 协议完成了我们的多信号调试任务。
| 检查项 | 观察到的结果 | 说明了什么 |
|---|---|---|
--version | 1.9.0 | 该日期测试的包版本 |
| Node 19.9.0 | 以 EBADENGINE 被拒绝 | 从未启动的服务器看起来可能像 MCP 连接失败 |
| Node 22.12.0 | 帮助输出正常完成 | 当前参数在受支持的运行时上可以加载 |
我们运行的复杂任务
我们搭建了一个可控的运营仪表盘，其中埋了四个互不相关的缺陷：一个同步执行的 240 ms 聚合任务、一个延迟加载的 hero 资源、一个返回 503 的订单请求，以及一个返回 500 的报表导出。Chrome DevTools MCP 1.9.0 需要记录一次重新加载的 trace，从页面快照中定位 Generate report 按钮，点击它，并把用户可见的失败与 console 中的源码位置、network 中的状态码对应起来。使用统计和 CrUX 查询被关闭，以确保本地测试 URL 不会进入可选的遥测路径。
LCP: 629 ms
LCP render delay: 627 ms
app.js:10 Orders API returned 503
app.js:18 export failed
GET /api/orders?range=30d 503
POST /api/export 500
trace 报告 LCP 为 629 ms，其中 627 ms 归因于渲染延迟，而不是服务器响应时间。对这条出问题的工作流来说更重要的是，console 和 network 工具给出的结论一致：初始数据加载在 app.js 第 10 行失败，返回 HTTP 503；点击导出后在 app.js 第 18 行失败，返回 HTTP 500。这种交叉验证正是 DevTools MCP 的实用价值：截图只能证明用户可见的状态，而 trace 和请求证据能定位到需要修复的工程层。
如何配置 Chrome DevTools MCP Server 自动连接？
三步，全部可以直接复制粘贴。前置条件：Stable 渠道的 Chrome 144 或更高版本（Canary 和 Beta 需要在配置中写明渠道），以及任意 MCP 客户端；示例使用 Claude Code。
第 1 步：启用一次远程调试。 在你正在运行的 Chrome 中打开 chrome://inspect/#remote-debugging，把远程调试打开。这是自动连接所依赖的桥梁；没有它，其他步骤都无法工作。
第 2 步：带 flag 注册服务器。
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --autoConnect或者用下面这段 JSON 配置 Cursor 和其他客户端：
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
}
}
}第 3 步：触发并授权。 让 Agent 与你已打开的 Chrome 交互（“截取我当前标签页的截图”）。Chrome 会为该会话弹出权限对话框；点击 Allow，Agent 就进入了你的实时浏览器，可以访问你的标签页、扩展程序和应用程序状态。
| 风险 | 相关控制项 | 重要限制 |
|---|---|---|
| Agent 访问到无关站点 | --allowed-url-pattern | 需要 Chrome 149+；测试重定向和子资源 |
| 敏感请求头被返回给客户端 | --redact-network-headers | 脱敏默认关闭 |
| 工具遥测 | --no-usage-statistics | 独立于 Chrome 浏览器指标 |
| 发送到 CrUX 的 Trace URL | --no-performance-crux | 只禁用字段数据查询，不影响本地 tracing |
连接成功后，先用这三条提示词验证自动连接到底能做什么：
“截取我当前标签页的截图，并描述你看到的内容”（验证连接是否生效）、“启动一次性能 trace，重新加载这个页面，告诉我是什么拖慢了 LCP”（调试收益），以及“复现我刚才看到的 bug：点击导出按钮，然后把控制台报错和来源读给我听”（实时会话诊断，这是全新配置文件的浏览器做不到的）。这三条都能跑通，说明整套工具已经可用。
会导致失败的三个常见坑是什么？
这三种情况的表现都是“连不上”，而且没有有用的报错信息。请按顺序排查。
1. 默认配置文件的锁定。 从 Chrome 136 起，针对默认 Chrome 数据目录，远程调试开关会被忽略。Google 做出这一改动，是因为观察到攻击者利用远程调试来窃取 Cookie。自动连接的权限对话框流程是官方文档给出的、进入正在运行的个人浏览器的途径；手动端口方式则必须使用非默认的 --user-data-dir，下一节会讲到。
2. 存在第二个 Chrome 实例。 手动 browserUrl 方式要求 Chrome 进程是以调试端口和自定义数据目录启动的。如果另一个 Chrome 进程占用了该配置文件，或者应用复用了已在运行的实例，这些 flag 可能不会作用到你想要的那个窗口。关闭测试实例，用一次性配置文件重新执行文档中的命令，并在启动 MCP 客户端之前先验证端点是否可用。
3. 端口实际上没有响应。 手动 browserUrl 方式要能挂载，浏览器一侧必须可达。请求 http://127.0.0.1:9222/json/version，确认它返回浏览器元数据以及一个 WebSocket 调试地址。如果是自动连接，请重新检查 chrome://inspect/#remote-debugging 和 Chrome 权限对话框。如果 Node 在启动前就报错，先修运行时；任何浏览器 flag 都修不了这一层。
扩展程序冲突也值得提一句：管理标签页或拦截脚本的扩展程序可能干扰 CDP 会话，表现看起来像随机不稳定。如果连接在任务中途断开，先禁用标签页管理类扩展再重试，然后再去提 issue。
自动连接与远程调试端口方式有什么区别？
在自动连接出现之前，标准做法是用显式调试端口和专用配置文件目录启动 Chrome：
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile"
claude mcp add --transport stdio chrome-devtools \
-- npx -y chrome-devtools-mcp@latest \
--browserUrl=http://127.0.0.1:9222取舍很清楚。自动连接让你用上真实配置文件（真实登录态、真实扩展程序、实时状态），代价是每次会话都要过一遍权限对话框；flag 方式给你一个单独的配置文件，登录一次即可，重启后依然保留，不需要对话框，而且正如记录这一做法的实践者所指出的，在沙箱环境中更稳定。在 Chrome 144 以下，flag 方式也是唯一选择。
并排对比，一眼就能选：
| 属性 | 自动连接 | 调试端口 + 专用配置文件 |
|---|---|---|
| 使用谁的登录态 | 你日常使用的真实配置文件 | 一个单独配置文件，登录一次即可 |
| Chrome 版本 | 144+ | 任意较新的 Chrome |
| 每次会话的额外操作 | 每次会话都要过权限对话框 | 用 flag 启动后无需任何操作 |
| 最适合 | 调试你此刻正在查看的应用状态 | 可重复的登录态测试、沙箱或接近 CI 的环境 |
两者都适用同样的基本卫生习惯：任何 Agent 能访问的浏览器配置文件里都不要放网银和个人邮箱，用完就关闭 Chrome，让端口随之关闭。
如何让已有的 Chrome 会话在多步任务中保持存活？
把 Chrome 进程、浏览器配置文件和 MCP 服务器视为同一个会话。先启动 Chrome，只开启一次远程调试，并在 Agent 完成各步骤期间保持同一个窗口不关；不要在导航、数据提取和校验之间重启 Chrome。自动连接会重新附着到正在运行的浏览器，而较早的 --remote-debugging-port 方式只在那个以调试模式启动的进程存活期间有效。
要做可重复的会话，请使用专用浏览器配置文件配合 --user-data-dir，在 CI 中锁定 MCP 包版本，并在第一次工具调用前加一个简单的健康检查：请求一次截图，或列出当前的目标列表。127.0.0.1:9222 有响应只能证明 CDP 端点存在，不能证明 Agent 连对了标签页。在任务记录里保留一个稳定的标签页标识，并在每次重要导航后重新核对页面 URL。
Agent 应该如何处理身份验证和登录流程？
Chrome DevTools MCP 可以在你登录之后操作页面，但它不是绕过身份验证的手段。正常登录时，先导航到已获批准的登录 URL，由真人输入密码或批准密码管理器填充，并在两步验证（2FA）、一次性验证码、验证码（CAPTCHA）或安全密钥提示处暂停。只有本人确认验证通过后，才继续执行。
遵循最小权限原则：使用测试账号、范围很窄的来源白名单，以及一个不含网银、个人邮箱和无关标签页的浏览器配置文件（Profile）。如果站点跳转到 SSO，先记录最终的来源，并在执行操作前核实账号身份。用于生产自动化时，优先使用服务方有文档的 API 或 OAuth 设备流程；不要试图绕过访问控制，也不要在所有者批准的范围之外复用私有 Token。
多个 Agent 可以安全地共用一个 DevTools MCP 会话吗？
它们可以连接到同一个 MCP 服务器，但不应该同时驱动同一个标签页。导航、焦点和点击都是共享状态，所以 Claude Code、Cursor、Gemini CLI 或 OpenCode 可能相互竞争、覆盖彼此的上下文，或批准一个并非本意的操作。请使用队列并只保留一个驱动方，或者给每个 Agent 分配单独的标签页并记录归属。
权限对话框是人的边界，不是自动批准开关。让批准保持交互式，检查来源和请求的操作，并在共享任务完成后结束会话。如果 Agent 需要并行工作，用隔离的浏览器 Space（隔离空间）可以避免焦点冲突，并让每个任务的 Cookie 和标签页各自独立。
如何从 WSL 或 Docker 连接到 Windows 上的 Chrome？
在宿主机上运行 Chrome 及其 CDP 端点，然后让运行 MCP 客户端的环境能够访问该端点。在 WSL2 中，使用从 WSL 可见的 Windows 主机地址，不要想当然地认为 127.0.0.1 是共享的；在 Docker 中，显式发布或路由该端口，并让 MCP 进程处于同一条网络路径上。启动 Agent 之前，先用 curl 请求 /json/version 测试一下。
客户端在本地运行时，把 CDP 绑定到 localhost。如果容器必须访问宿主机，请使用防火墙规则加上带认证的隧道或私有网络，而不是把 9222 暴露到局域网。检查容器里的 Node 和 npx 版本是否符合 MCP 的要求，并记住自动连接的 chrome://inspect 授权流程是在宿主机的 Chrome 里完成的，不是在无头容器里。
本地 AI Agent 能用 Chrome DevTools 协议控制 Brave 吗？
Brave 基于 Chromium，用其文档中的远程调试选项启动时会暴露 CDP，所以本地 Agent 通常可以像连接专用 Chrome 浏览器配置文件（Profile）那样，通过 --browserUrl 附着上去。但兼容性没有保证：Chrome DevTools MCP 官方只支持 Chrome，Brave 特有的 shields、浏览器配置文件路径和版本差异都可能改变行为。
先在一个一次性的 Brave 浏览器配置文件（Profile）上验证：列出目标、截图、点击一个无害的本地页面并查看控制台输出。在你评估过前面针对 Chrome 提到的 Cookie、扩展程序和权限风险之前，不要把 Agent 指向你日常使用的 Brave 浏览器配置文件。
如何用 DevTools MCP 运行 Lighthouse 性能审计？
使用 DevTools MCP 的性能工具启动一次 trace，重新加载目标页面，等待网络稳定，然后收集 Lighthouse 风格的性能证据（LCP、CLS、INP、长任务和网络请求）。让 Agent 在报告每一项指标的同时，也报告 URL、设备或限速配置、缓存状态和 trace 时长；否则分数无法复现。
一个有用的提示词是：“对当前页面跑一次性能 trace，用冷缓存重新加载一次，找出主线程上耗时最长的三个任务，并给出每个问题对应的请求或源码。”改代码之前，先在热缓存下重复一次。DevTools 的证据能解释页面为什么慢，但它不能替代在代表性设备上受控运行的 Lighthouse CI。
为什么 Chrome DevTools MCP 在 RooCode 或 AnythingLLM 中会失败？
大多数第三方工具的失败是客户端配置问题，而不是浏览器协议不同。确认客户端启动的是同一条 npx 命令，--autoConnect 或 --browserUrl 只传了一次，并且有权限启动本地进程。然后查看客户端的 MCP 日志里服务器的 stderr，并独立验证 /json/version 或 Chrome 的权限对话框。
在 RooCode 中，检查该服务器是否已对当前浏览器配置文件（Profile）启用，以及模型策略是否允许工具调用。在 AnythingLLM 或 Docker 中，检查 Node 是否可用、到宿主机的网络路由，以及 Chrome 浏览器配置文件（Profile）的文件系统权限。把客户端和 chrome-devtools-mcp 一起升级，先把问题缩小到一次截图调用，确认无误后再加入导航或 tracing。
如何把浏览器 Bug 的上下文分享给 Cursor 或 Claude Code？
在 DevTools MCP 中采集一份精简的证据包：当前 URL 和标题、一张截图、相关的 DOM 或无障碍子树、带源码位置的 console 错误，以及带状态码和耗时的失败网络请求。把这份证据包粘贴或保存下来交给 Cursor 或 Claude Code，并附上精确的复现步骤和浏览器版本。
如果想看更全面的连接模型对比，请阅读Agent 如何连接已打开的浏览器。如果优先考虑的是降低上下文占用而不是 DevTools 的调试深度，在选定控制层之前先对比Playwright MCP 与 CLI。
分享之前先脱敏：Cookie、Authorization 请求头、个人数据和隐藏表单值都要处理掉。一份确定性的交接比完整的 HAR 转储更有用：保留失败的那条请求、可见的错误，以及能证明该状态的最小 DOM 片段。接收方 Agent 就能据此提出代码修复方案，而不必接管原来的标签页。
哪个限制是任何 flag 都无法消除的？
以上安装配置全部成功之后，还有一个事实摆在那里：Agent 是在你正在用的浏览器里干活。同一个窗口、同一批标签页、同一个焦点。它导航时，那个标签页就被占着；你打字时，你又挡了它的路。自动连接本来就是为调试会话设计的，在这种场景下和 Agent 轮流操作很自然。但对于后台任务（“我写东西的时候，帮我把三个仪表盘的数字拉出来”），轮流占用恰恰就是问题所在。
ego (lite) 给 Agent 自己的 Space，你的窗口仍然归你。
任何能执行 shell 命令的 Agent 都可以通过 ego-browser skill 来驱动它；不需要手动配置调试端口，不需要 chrome://inspect 这一步，也没有每个会话都要点的权限弹窗：同一套 CDP 控制能力是内置的，指向一个天生就是用来被驱动的浏览器。
诚实的划分是：把Chrome DevTools MCP留给它真正擅长的事（性能 trace、内存快照、调试你正在用的会话），把日常需要登录态的任务交给一个不需要占用你窗口的浏览器。
这种划分有实测数据支撑，但需要附一条说明。在Real-World Bench（一套针对真实站点的 31 项任务测试，同一模型、同一位独立评审）上，这一侧被测的工具是 chrome-devtools-cli，也就是官方的 CLI 兄弟项目，而不是 MCP 服务器本身：它把 31 项任务中的 61.3% 完美完成，而 ego (lite) 在 31 项任务中达到 93.5%。这套测试是操作型任务，比如 stockanalysis.com 的筛选器任务，Agent 需要筛选到 Technology、把表格切到 Valuation 视图，再按顺序取出各项指标。诊断深度和任务完成度是两件不同的事，数据给出的分野和本文的划分一致。
下载 Mac 版 ego (lite) ，或阅读 Chrome DevTools MCP 与 Playwright MCP 如何分工。两者都免费。
FAQ
如何把 Chrome DevTools MCP 添加到 Claude Code？
运行 claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest，如果想让它连接到你的实时浏览器，就追加 --autoConnect。在 Claude Code 里用 /mcp 验证，然后让它对当前标签页截一张图。
自动连接在 Cursor 和其他 Agent 上也能用吗？
能；这是 MCP 服务器本身的特性，与客户端无关。任何能运行 npx 命令的 MCP 客户端都可以用，浏览器一侧同样需要 Chrome 144+ 和远程调试的前置条件。
把 Agent 连接到我的已登录浏览器安全吗？
这套机制比过去开放端口的老做法更安全（每个会话都有权限弹窗、服务器仅限本地、不向 Google 发送数据），但授权范围很宽：Cookie、存储，以及每一个打开的标签页。把它当成把没锁屏的笔记本借出去：对可信 Agent 执行边界明确的任务没问题，但凡涉及银行或主力邮箱就绝对不行。
Agent 使用我的 Chrome 时，我还能继续浏览吗？
技术上可以，实际上不行。你和 Agent 共用同一个窗口和同一个焦点：Agent 导航或点击时，操作的就是你正在看的那些标签页，而你敲键盘的输入可能正好落在它的操作中间。自动连接的会话最好当成结对编程来用，同一时间只有一个人操作，这对调试来说没问题，但用来跑后台任务就不合适了。
Agent 能在不占用我窗口的情况下，在我已登录的网站里工作吗？
做不到，这是 Chrome DevTools MCP 的固有限制：共享窗口是它设计的一部分。在 ego (lite) 中，Space 让 Agent 拥有自己的工作区，因此它可以在执行需要登录态的任务时，让你的窗口和标签页仍然归你所有。
DevTools 这条路线在真实场景基准测试中表现如何？
Real-World Bench（即 ego-browser-benchmark-framework 仓库）用同一个模型和同一个独立评审，通过五款工具对真实网站跑了一套 31 项任务的测试。被测工具是 chrome-devtools-cli，也就是官方的 CLI 同源工具，而不是 MCP 服务器：31 项任务中 61.3% 完美完成，平均每个任务的模型成本为 $4.95。把这笔开销只摊到完成的任务上，就是 $4.95 ÷ 61.3% = $8.08 每个完成任务，是五款被测工具里最高的。对于一个以调试为先、却用来做操作类工作的工具包来说，这个结果基本在预期之内；这也是本指南把后台任务类工作交给别处的原因。
