趣研小栈

技术研究与兴趣分享

autobrowser 实测:Bun + 浏览器扩展的 CLI 自动化,和 Playwright 有什么不同

2026-08-02工具测评浏览器自动化Bun

autobrowser 是一个受 v-browser 启发、基于 Bun 的浏览器自动化工具。和 Playwright 这类「代码驱动一个全新浏览器实例」的方案不同,它的思路是:用一个 CLI + 浏览器扩展,直接控制你正在日常使用的 Chrome / Edge——包括里面已登录的会话、cookie 和已装的扩展。

架构:三件套

┌─────────────┐   IPC    ┌──────────────┐  token  ┌──────────────────┐
│ CLI (Bun)   │ ───────► │ relay 服务    │ ◄─────► │ Chrome/Edge 扩展  │
│ autobrowser │          │ 端口 57978    │         │ (未打包加载)      │
└─────────────┘          │ CLI API 57979 │         └──────────────────┘
                         └──────────────┘                    │
                                                              ▼
                                                     你真实的浏览器标签页
  • CLI:命令行入口,所有操作的起点(bun run src/cli.ts 或全局 autobrowser)
  • 本地中继服务:relay(57978)+ CLI API(57979),server 命令管理,常驻后台
  • 浏览器扩展:构建后未打包加载到 Chromium 系浏览器,通过 token 与 relay 建立连接

扩展拿到的是浏览器原生的调试能力(底层对应 CDP),因此它能操作的是你眼前这个浏览器,而不是另起一个干净的自动化实例。

安装

要求 Bun ≥ 1.3.13。

git clone https://github.com/whiter001/autobrowser.git
cd autobrowser
bun install

# 构建 Chrome 扩展
bun run build:chrome
# 在 chrome://extensions 打开「开发者模式」,把生成的 chrome/ 目录作为未打包扩展加载

# (可选)全局安装 CLI
bun run build:cli    # 产出 autobrowser 二进制;Windows 用 autobrowser.cmd 转发器

连接配置(扩展 id、浏览器路径)持久化在 ~/.autobrowser/config.json,一次配置后续复用。

基本使用

最短上手流程:

autobrowser server     # 启动 relay + IPC 服务(stop 可停止)
autobrowser connect    # 打开扩展连接页,自动保存 token 和端口
autobrowser status     # 确认服务与扩展均已连接

autobrowser open https://www.example.com
autobrowser wait load 10000
autobrowser snapshot   # 输出带 @e1/@e2 稳定引用的页面结构
autobrowser click @e2
autobrowser fill @e5 "test@example.com"

几个我常用到的能力:

# 语义化查找:不用猜 CSS 选择器
autobrowser find role button click --name "Submit"
autobrowser find text "Sign in" text --exact

# 网络拦截与 mock
autobrowser network route "**/api/user" --body '{"name":"mock"}'
autobrowser network har start && autobrowser network har stop out.har

# 初始化脚本:导航后、页面脚本前注入(对齐 Playwright 的 init script)
autobrowser script add 'Object.defineProperty(navigator, "webdriver", { get: () => undefined })'

# 登录态保存/恢复
autobrowser state save default && autobrowser state load default

# 机器可读输出,方便接 agent / 脚本
autobrowser --json eval '({title: document.title, links: document.querySelectorAll("a").length})'

完整命令树以 autobrowser help 为准(README 也声明 help 输出是权威来源)。

和 Playwright、Chrome DevTools 对比

维度 autobrowser Playwright Chrome DevTools
驱动对象 你日常的浏览器(含登录态/扩展) 全新干净实例(或 attach CDP) 当前打开的浏览器
使用方式 CLI 单命令,shell 可组合 代码库(Node/Python/Java),需写脚本 手动 GUI 操作
浏览器支持 Chromium 系(Chrome/Edge) Chromium / Firefox / WebKit Chrome/Edge
Headless / CI 不适合(依赖真实浏览器窗口) 原生支持,测试生态成熟 不适用
反检测 天然优势:真实浏览器+真实指纹 自动化实例特征明显,需额外对抗 无自动化特征
接入 agent 为 agent 设计:@eN 引用、--json、find role/text 需自行封装(如 playwright-mcp) 不适用
上手成本 一行命令一个动作,零代码 需要写代码、管理浏览器生命周期 零门槛但不可编程
成熟度 早期项目(0.1.0) 非常成熟,社区大 官方工具

autobrowser 的核心优势

  1. 真实浏览器、真实会话。这是和 Playwright 最本质的区别:不用导出 cookie、不用折腾扫码登录,扩展直接接管你当前已登录的浏览器。抓需要登录的页面时省掉一大半工作量。
  2. CLI 即 API。每个动作都是一条 shell 命令,可以直接拼进脚本、Makefile、crontab,也天然适合 AI agent 调用——不需要像 Playwright 那样先起一个 JS/Python 工程。
  3. 面向 agent 的交互设计。snapshot 输出稳定的 @eN 元素引用和 @fN frame 引用,find 支持 role/text/label 语义查找,--json 机器可读输出;agent 可以「先 snapshot 再按句柄操作」,而不是猜选择器。
  4. 反爬亲和。跑在真实浏览器里,没有 navigator.webdriver 之类的自动化特征;配合 script add 还能在页面脚本执行前做进一步抹平。
  5. 轻量无侵入。不需要 --remote-debugging-port 重启浏览器,不要求专用 profile;装个扩展、跑个 relay 就能用。

也要说清楚局限

  • 只适合 Chromium 系,且依赖真实浏览器窗口——CI 里跑大规模 headless 测试仍然是 Playwright 的领地
  • 项目还在早期(0.1.0),命令面和稳定性在快速演进
  • 没有 Playwright 的自动等待、codegen、trace viewer、并行 test runner 这些测试向能力

一句话总结

写测试、跑 CI、跨浏览器回归——选 Playwright;让 AI agent 或脚本直接操作你日常浏览器里已登录的页面、快速抓取和排障——autobrowser 更顺手。 两者不是替代关系,而是互补:我的用法是自动化测试走 Playwright,agent 日常操作走 autobrowser。

项目地址:github.com/whiter001/autobrowser,详细文档见仓库 docs/ 目录。

← 返回首页