卸载掉的 playwright-cli，我又安装回来了

上篇推文才说不出意外的话上篇就是 AI 操作浏览器的最后一期了，打脸来得那么快。上周写了一篇《Kimi WebBridge，AI 操作浏览器更好的一把铲子》，核心观点是：Playwright CLI 太重了，登录态管理太烦，不如用 Kimi WebBridge 这把"轻铲子"。

文章发出去之后，有读者留言指出：playwright-cli 也可以通过 CDP 连接你已有的浏览器，不需要每次启动新实例。

我当时的第一反应是——真的吗？如果真是这样，我之前说的"登录态丢失"就不成立了。

于是，我把卸载掉的 playwright-cli 又装了回来，经过测试，结论是：我之前的判断确实有偏差，playwright-cli 的 CDP 连接能力，让它从"笨重的自动化工具"变成了"AI 操作用户真实浏览器的利器"。

今天就把这段"打脸"经历完整分享出来。

CDP 连接：playwright-cli 的隐藏技能

先解释一下 CDP。CDP 全称 Chrome DevTools Protocol，是 Chrome 浏览器内置的调试协议。你按 F12 打开的开发者工具，底层就是通过 CDP 和浏览器通信的。

playwright-cli 从 v0.1.5 开始支持 attach 命令，可以通过 CDP 连接到你已经在用的浏览器，而不是启动一个全新的空浏览器。

三种连接方式：

方式一：attach --cdp=chrome

最简单的方式。只要你的 Chrome 开启了远程调试（在地址栏输入 chrome://inspect/#remote-debugging，勾选"允许此浏览器实例进行远程调试"），一行命令就能连上：

连上之后，你浏览器里的登录态、Cookie、扩展，全部自动继承。之前那篇《给 AI 装上"眼睛和手"》里说的"登录态丢失"问题，在这种模式下根本不存在。

方式二：attach --cdp=<url>

手动指定调试端口。适合 Chrome 以外的 Chromium 浏览器（比如 Brave），或者需要连接远程浏览器：

方式三：attach --extension

通过安装 Playwright 浏览器扩展来连接。好处是不需要命令行启动浏览器，扩展在后台建立连接，你正常使用浏览器就行。

三种方式各有适用场景，但核心效果一样：AI 操作的是你日常使用的浏览器，不是什么沙箱环境。

Brave 用户踩坑指南

因为我日常用的是 Brave 浏览器，所以重点测了 Brave 的连接。这里有几个坑，如果你也用非 Chrome 浏览器，大概率会遇到。

坑一：--cdp=chrome 找不到 Brave

playwright-cli 硬编码了 Chrome 的路径，直接运行会报 chrome executable not found。有两种解法：

第一种是创建符号链接，让 playwright-cli 在 Chrome 路径下找到 Brave 的扩展。但说实话，这个方案有点 hack。

第二种是设置环境变量，直接告诉 playwright-cli 用 Brave：

坑二：代理环境导致连接失败

如果你本地有 HTTP 代理（比如 clash），CDP 的 WebSocket 连接会被路由到代理，导致 ECONNREFUSED。解决方法是在运行 playwright-cli 时清空代理变量：

我推荐的方案：CDP 直连

经过实测，最省心的方式是方案二——用 --remote-debugging-port 启动 Brave，然后 attach --cdp=<url> 直连。不需要符号链接，不需要环境变量，只需要在启动浏览器时加一个参数。

重新对比：playwright-cli vs Kimi WebBridge

既然 playwright-cli 也能操作已有浏览器了，那之前和 Kimi WebBridge 的对比结论就需要更新。

测试方法说明：我在同一台机器上（macOS，Brave 浏览器），用同一个测试页面 example.com，分别用 playwright-cli（CDP attach 模式）和 Kimi WebBridge 执行相同的操作——导航、获取 HTML、获取快照、提取页面标题、点击链接、填写表单、截图，记录每次操作的响应时间和输出大小。playwright-cli 使用 --raw 模式剥离元数据，Kimi WebBridge 使用默认输出格式。两者都连接到同一个 Brave 浏览器实例，共享相同的登录态和网络环境。

响应速度：Kimi WebBridge 更快

Kimi WebBridge 的守护进程是常驻的，响应在毫秒级。playwright-cli 每次命令都有约 1 秒的 Node.js 进程启动开销。在小数据提取场景下，Kimi 快了 60 多倍。

图：响应速度与 Token 效率实测对比

playwright-cli 的"慢"不是浏览器操作慢，而是每次命令都有约 1s 的 Node.js CLI 启动开销。如果用 Python API 编写脚本一次运行多步操作，这个开销只出现一次。

Token 效率：playwright-cli 更省

playwright-cli 的快照用 YAML 格式输出，比 Kimi 的 JSON 封装紧凑 30%。还有 --raw 模式可以剥离所有元数据，只返回纯值。对于频繁操作的场景，Token 成本差距明显。

功能丰富度：playwright-cli 完胜

图：功能覆盖对比

图：playwright-cli CDP Attach 与 Kimi WebBridge 的架构对比

安装体积与易用性

图：安装体积与易用性综合对比

playwright-cli 需要 Node.js + playwright-core，加起来约 200MB。Kimi WebBridge 的守护进程只有约 20MB，浏览器扩展几十 KB。如果你不想装 Node.js 环境，Kimi 是更好的选择。

总结建议

测试完一圈，我的结论是：两者不是替代关系，是互补关系。

日常轻量操作 → Kimi WebBridge

随手让 AI 帮你查个东西、快速抓一批数据、不需要复杂操作的场景。响应快、安装轻、零配置。它就是一把"轻铲子"，放在手边随时能用。

复杂自动化 → playwright-cli

需要网络拦截、Cookie 管理、状态保存、视频录制、多 Tab 操作等高级功能时，playwright-cli 的 50+ 命令集是碾压级优势。特别是 --raw 模式在批量操作时能显著省 Token。

两者可以共存。 日常用 Kimi WebBridge，需要重量级操作时切换到 playwright-cli。我的 Brave 浏览器上同时装着 Kimi 扩展和 Playwright 扩展，按需选用，互不冲突。

写在最后

这篇文章的起因，是读者的批评指正。我之前对 playwright-cli 的判断确实有失偏颇——只看到了它"启动新浏览器实例"的笨重一面，没有注意到 CDP attach 这个关键能力。

技术认知需要不断修正，感谢指出问题的朋友。