第一步：打开 Chrome 的远程调试口子#

新版 Chrome 加了一个机制，不用重启浏览器、也不用加启动参数就能开远程调试（我这边是 154.0.8037.98）。地址栏输入：

1
chrome://inspect/#remote-debugging

把那个开关打开。注意这个口子和老的 --remote-debugging-port 启动参数不是一回事——新版 Chrome 对那个端口做了限制，直接访问 /json/version 会返回 404，拿不到调试地址。所以必须走这个开关。

第二步：装 MCP 服务器#

1
npm install -g chrome-devtools-mcp@latest

我装到的版本是 1.10.1。

第三步：写配置文件#

我用的是 WorkBuddy，配置文件在 ~/.workbuddy-ai/mcp.json。其他客户端路径不一样（Claude Code 是 .mcp.json，Cursor 在设置界面里填），但格式都是标准的 MCP 配置。

1
{
2
  "mcpServers": {
3
    "chrome-devtools": {
4
      "command": "C:\\Users\\你的用户名\\.workbuddy-ai\\binaries\\node\\versions\\22.22.2-3\\node.exe",
5
      "args": [
6
        "C:\\Users\\你的用户名\\.workbuddy-ai\\binaries\\node\\versions\\22.22.2-3\\node_modules\\chrome-devtools-mcp\\build\\src\\bin\\chrome-devtools-mcp.js",
7
        "--autoConnect",
8
        "--no-usage-statistics",
9
        "--no-performance-crux"
10
      ]
11
    }
12
  }
13
}

几个参数值得说：

• --autoConnect：自动连本机正在跑的 Chrome，不用自己找调试端口
• --no-usage-statistics：关掉 Google 的用量上报
• --no-performance-crux：这个建议加上。默认它会把你访问的 URL 发到 Google 的 CrUX 接口，换取真实用户的性能数据。考虑到这是你的日常浏览器，不想让浏览记录外流就关掉

command 我直接写了 node 的绝对路径。用 npx 也能跑，但 MCP 服务器是常驻进程，绝对路径启动更稳定，也避免 npx 每次去解析包。

第四步：信任它#

这一步最容易漏。改完配置文件不会自动生效，而且应用一般只在启动时读一次 mcp.json，所以：

1. 重启客户端
2. 找到连接器管理页（WorkBuddy 里是左侧边栏「专家·技能·连接器」→「连接器」页签）
3. 点右上角的「自定义连接器」，找到 chrome-devtools，点「信任」

不点这个，AI 那边看到的工具列表里根本没有这些浏览器工具。

第五步：验证#

信任之后，让它列一下当前打开的页面。我第一次跑出来的结果是这样：

1
{
2
  "content": [
3
    {
4
      "type": "text",
5
      "text": "## Pages\n1: https://www.bilibili.com/video/BV1GHHn6NEnZ/ [selected]\n2: 首页-个性推荐-哔哩哔哩\n3: [74%][50%] SamplerCustomAdvanced (http://127.0.0.1:8188/)"
6
    }
7
  ]
8
}

看到自己真实开着的标签页那一刻还是挺爽的。

坑 1：那个弹窗，每次连接都弹#

第一次连上，Chrome 会弹一个「要允许远程调试吗？」的框，只有「取消」和「允许」两个按钮。点允许，连上了。

问题是它不是只弹一次。

我一开始写了个脚本，每次执行一批操作就起一个新的 MCP 进程——结果连着弹了四五次，我在终端这边等，那边满屏幕找弹窗，非常难受。

查了一下，这是 Chrome 较新版本的设计行为：按连接弹窗，官方没有提供「永远允许」的选项。

所以：

• 弹窗次数 = 你建立连接的次数
• 想让 AI 干活不被打断，就得让连接常驻

正确做法是让客户端托管 MCP 进程（就是上面第四步的”信任”）。客户端会启动一次 MCP 服务器并保持长连接，Chrome 只在最开头弹一次，之后所有操作复用这条连接。

如果你自己写脚本调，那就把一批操作合并进同一次连接，别一次操作起一个进程。

坑 2：Playwright 扩展看起来更优雅，但有个隐藏条件#

Playwright 也有官方扩展路线，走的是 chrome.debugger API，完全不碰调试端口，所以 Chrome 永远不会弹那个框。听起来完美。

我装上试了，结果 tab-list 只返回一个页面——扩展自己的中继页 connect.html，看不到我任何真实标签页。

翻了扩展源码才搞明白。它 v0.4.0 的代码里写着：

1
PLAYWRIGHT_GROUP_TITLE = "Playwright"
2
PLAYWRIGHT_GROUP_TITLE_PREFIX = `${PLAYWRIGHT_GROUP_TITLE} · `
3
// 只列出该组内的标签
4
tabs.query({ groupId: g.id })

它只共享处于名为 Playwright 的 Chrome 标签组里的标签。 组外的标签它一概看不见。

而且断开连接时，扩展会把这个组里的标签全部解组（源码里的状态消息是 "All controlled tabs detached"），下次连接得重新挑。

坑 3：那个 token，用错了反而更糟#

扩展的弹窗里提示可以设一个环境变量绕过连接对话框：

1
export PLAYWRIGHT_MCP_EXTENSION_TOKEN=你的token

我设了，确实不弹了，4 秒就连接成功。但一个标签页都共享不到。

原因很反直觉：那个”连接对话框”正是让你挑选要共享哪些标签的步骤。你把对话框绕过去了，就等于没挑标签，自然什么都看不到。

所以这个 token 的定位很尴尬——它省掉的恰好是你需要的那一步。想用扩展路线，就别用 token，老老实实走对话框挑标签。

坑 4：Windows 上开着代理，探测本地端口会得到假 404#

这个坑跟浏览器无关，但排查过程被它带偏了很久。

我本机设了 http_proxy，用 curl 去探测 Chrome 的调试端口时一直返回 404，我一度以为”端口没开”。实际上请求走了代理，返回的是代理给的 404。

所有本地端口的探测都要加 --noproxy '*'：

1
curl -s -D - -o /dev/null --noproxy '*' http://127.0.0.1:9222/json/version

同理，查 DNS 也一样——本机的 DNS 可能被透明代理劫持成 fake-ip（198.18.x.x），想看真实解析结果得走 DoH：

1
curl -s --noproxy '*' "https://dns.google/resolve?name=www.example.com&type=CNAME"

坑 5：会话生命周期，脚本跑完连接就断#

如果你用命令行工具（比如 playwright-cli）而不是 MCP，要注意它的守护进程会随发起命令的 shell 一起退出。

也就是说你没法”先 attach，然后下一条命令再操作”——每次都得在同一次调用里把 attach 和后续命令串起来：

1
playwright-cli attach --extension=chrome && playwright-cli -s=chrome tab-list

这个设计挺反直觉的，我一开始分成两条命令跑，第二条永远报 Browser 'chrome' is not open。