Browser4 实战：一条 SQL 抽取网页数据，零 Token 成本

做 AI Agent 的都知道一个痛：让模型读网页，一次两次的成本感觉不到，一到批量抽取，Token 账单直接随页数线性放大。今天要实测的 Browser4 走的是另一条路——数据抽取在本地完成，全程不经过 LLM。

这篇文章是我实际安装并跑通后的记录，包含真实终端输出、一个 Intel Mac 用户必踩的安装坑（官方压根没出预编译包），以及我实测成功的 X-SQL 查询结果。

一、Browser4 是什么

一句话：一个 Rust CLI + Spring Boot 后端的 AI 原生浏览器引擎，通过 CDP 直驱 Chrome，把网页变成可查询的数据源。

架构很短：

browser4-cli (Rust) ──MCP over HTTP──▶ browser4-rest (Kotlin/Spring) ──▶ PulsarWebDriver (Kotlin/CDP)

核心卖点是三个模块：

项目是 Apache 2.0 开源，GitHub 仓库 platonai/Browser4，npm 包名 browser4-cli。实测时间点仓库 1114 star，59 个 release，最新版本 v4.13.11，npm 已发 52 个版本。

关于竞品：browser-use 约 11.1 万星、Playwright 约 9.5 万星，Browser4 属于第二梯队。它不是要取代 Playwright，而是在"批量抽取 + 零 Token"这个特定位置做了差异化。

二、安装：先说 Intel Mac 的坑

官方 README 给的命令就两行：

npm install -g browser4-cli
browser4-cli install

npm install -g browser4-cli 没问题。但第二步 browser4-cli install 在我这台 Intel Mac 上失败了，报的是：

Mirror 'aliyun-oss' speed test failed: HTTP 404 Not Found
Mirror 'github' speed test timed out after 30s
…
Download from 'github' failed: error sending request for url
(https://github.com/platonai/Browser4/releases/latest/download/browser4-bundle-runtime-darwin-x64.tar.gz)
Failed to download from all 2 mirror(s).

我查了 v4.13.11 的 release assets，一共 11 个，运行时 bundle 只有三个平台：

browser4-bundle-runtime-darwin-arm64.tar.gz 115MB
browser4-bundle-runtime-linux-x64.tar.gz 121MB
browser4-bundle-runtime-windows-x64.zip 116MB

darwin-x64 根本没有。 官方镜像 aliyun-oss 的路径是 404，GitHub 直连在国内网络下超时——两个原因叠加，browser4-cli install 在 Intel Mac 上目前跑不通。

绕路方案：release 里有一个跨平台的 fat jar，直接用它起后端。

# 1) 拉跨平台 jar（官方 release 里就叫 Browser4.jar，89MB）
curl -sL -o ~/browser4-runtime/Browser4.jar \\
"https://gh-proxy.com/https://github.com/platonai/Browser4/releases/download/v4.13.11/Browser4.jar"

# 2) 后端要求 JDK 17+，本机如果只有 JDK 8 装一个
brew install openjdk@21

# 3) 起后端
export JAVA_HOME=/usr/local/opt/openjdk@21
export PATH="$JAVA_HOME/bin:$PATH"
java -jar ~/browser4-runtime/Browser4.jar &

后端起来后，确认状态：

$ browser4-cli status
Browser4 Status
===============
CLI version: 0.1.28
Server URL: http://localhost:8182
Server health: UP

Server health: UP 就表示 CLI 和后端已经通了。这时后端日志里会打印一批工具注册信息，大约 40 个 MCP 工具（navigate / reload / click / fill / snapshot / page_source 等）全部加载成功。

三、实测：一条 SQL 抽 8 本书

文章的核心演示就是这条查询。我把它写进 SQL 文件，跑一次：

SELECT DOM_FIRST_TEXT(DOM, 'h3') AS title,
DOM_FIRST_FLOAT(DOM, '.price_color', 0.0) AS price,
DOM_FIRST_ATTR(DOM, 'h3 a', 'href') AS path,
DOM_FIRST_ATTR(DOM, '.star-rating', 'class') AS rating
FROM LOAD_AND_SELECT('https://books.toscrape.com/', '.product_pod')
ORDER BY price ASC
LIMIT 8

执行：

browser4-cli open https://books.toscrape.com/
browser4-cli htmlsnapshot query –sql @query.sql

真实返回（截取部分）：

{"statusCode":200,"pageStatusCode":200,"pageContentBytes":63479,"isDone":true,"resultSet":[
{"title":"Starving Hearts (Triangular Trade …","price":"13.99","rating":"star-rating Two"},
{"title":"Set Me Free","price":"17.46","rating":"star-rating Five"},
{"title":"The Coming Woman: A …","price":"17.93","rating":"star-rating Three"},
{"title":"Shakespeare's Sonnets","price":"20.66","rating":"star-rating Four"},
{"title":"The Boys in the …","price":"22.6","rating":"star-rating Four"},
{"title":"The Requiem Red","price":"22.65","rating":"star-rating One"},
{"title":"Olio","price":"23.88","rating":"star-rating One"},
{"title":"The Dirty Little Secrets …","price":"33.34","rating":"star-rating Four"}
]}

这条查询一次完成了四件事：取书名、取价格并把 £51.77 这种带货币符号的字符串转成浮点数、取链接路径、取评分 class，然后按价格升序取前 8 条。全程没有调用任何 LLM，Token 消耗为 0。

换成传统方案，同样需求要拆三步：先写 Playwright 抽取原始文本，再写一段 Python 或 Node.js 清洗 £51.77 成 51.77，最后导入数据库写排序逻辑。每一步都要单独维护代码和依赖。

一个容易忽略的细节

官方文档示例的输出价格是 10.17 / 10.64 / 10.84，我跑出的是 13.99 / 17.46。这不是 Bug——books.toscrape.com 每次访问都随机生成商品页，这是站点本身的设计。

四、实测踩到的坑汇总

第四个是我一开始就栽进去的：照抄官方示例的注释，第一次执行直接 500。错误信息很明确，但得知道原因才能绕过去。

五、命令速查

# === 启动 ===
java -jar ~/browser4-runtime/Browser4.jar &
browser4-cli status # 后端健康检查 + 8182/status 面板

# === 会话 ===
browser4-cli open https://example.com # headless
browser4-cli open –headed https://example.com
browser4-cli -s work open https://site.com # 命名会话，隔离互不影响
browser4-cli list # 列所有会话

# === 交互（refs 来自 snapshot）===
browser4-cli snapshot -i –boxes
browser4-cli click e15
browser4-cli fill e16 "text" –submit

# === 静态抽取（零 LLM Token）===
browser4-cli htmlsnapshot
browser4-cli htmlsnapshot get text "h1"
browser4-cli htmlsnapshot query –sql @query.sql

# === 批量 ===
browser4-cli crawl –seed-file urls.txt –depth 0 –sql @q.sql –format csv
browser4-cli swarm create –max-browser-contexts 8
browser4-cli swarm query –seed-file urls_10k.txt –sql @q.sql
browser4-cli swarm result <task-id>

# === 定时 ===
browser4-cli loop -i 3600 — eval 'document.querySelector(".price")?.textContent'

CLI 的设计有一个挺实用的思路：交互用 snapshot（返回一次性元素 ref），取数用 htmlsnapshot（返回静态 DOM，用 CSS 选择器定位）。两者分工明确——snapshot 的 ref 在 DOM 一变就失效，所以 20 个商品页就得做 20 次快照；而 htmlsnapshot 的一个 .price 选择器能覆盖所有同类页面。这个区分是理解整个"零 Token"设计的关键。

六、适合什么场景

我的判断：

适合用的场景——批量 URL 列表抽取、结构已知或半已知的列表页、字段需要清洗和类型转换、跑定时任务持续监控某类页面。这类任务的共同点是重复度高、结构稳定，本地 SQL 路径的收益远大于 LLM。

不适合的场景——多步交互流程（登录、填表、翻页点击）、需要理解语义的开放式任务、单次性的页面理解。这些还是走 LLM 驱动的浏览器自动化框架。

需要说明的是：Swarm 模式的"单机每天 10-20 万页"是项目方自述的初步性能测试结果，官方也注明正式 benchmark 还在准备中，我没有验证这个数字。WebMiner 和 PowerCSS 的 :expr() 我这次也没有实测（WebMiner 同样需要 JDK 17+ 全套环境，PowerCSS 需要构造特定页面）。

七、总结

Browser4 的核心价值不是"又一个浏览器自动化框架"，而是把"抽取 + 清洗 + 排序"这三步压进一条 SQL，全程走本地数据库引擎，不产生 Token 费用。我实测的 books.toscrape.com 示例确实跑通了，四字段一查询、自动类型转换、ORDER BY 生效，返回 HTTP 200 和 8 行结果。

如果你的场景是批量结构化抽取，值得一试。如果你的 Mac 是 Intel 芯片，记住走 Browser4.jar 这条路，别在 browser4-cli install 上浪费时间——目前官方确实没出 darwin-x64 的运行时包。

本文所有终端输出均为实际运行结果，未做任何修饰。X-SQL 查询结果因目标站点随机生成内容，每次运行数值不同，属正常现象。Swarm 吞吐量与 WebMiner 能力未实测，相关数据均来自项目方公开说明。