简介

做 AI Web Agent 或大规模采集，绕不开“浏览器底座”选型：
有人把浏览器做成 平台（任务调度/代理池/账号池），有人做成 服务（远程连接/HTTP API），也有人把它做成 工具（给 LLM 用的稳定操作 CLI），还有人直接重写了一个更轻量的 headless 内核。

本文把我最近收集的项目按几个关键维度整理：产品定位、协议/接入方式、反爬能力、部署形态、隔离能力（多租户）、AI 接入难度、二开/API 成本，并给出一套能落地的选型建议。

一句话理解这些项目（先对号入座）

  • BrowserCluster：偏“采集平台/调度系统”的分布式浏览器集群，强调反爬工程化（代理池、Cookie 池、频控、针对 Cloudflare 等优化）。
  • browserless：把 headless 浏览器做成 Docker 服务，对外暴露 WS 端点，Playwright/Puppeteer 直接 connect。
  • Ant-Browser：桌面端指纹浏览器，多账号隔离、代理绑定、内核管理（更像运营/环境管理工具）。
  • Lightpanda：为 AI/自动化设计的轻量 headless 浏览器内核（CDP 兼容），主打低内存/快启动。
  • agent-browser（Vercel）：给 AI agent 用的浏览器自动化 CLI，核心是“无障碍树 snapshot + refs”减少 selector 脆弱性。
  • steel-browser：面向 AI 应用的 Browser API/沙箱平台，提供 session/page 生命周期管理、代理/stealth 等（API-first）。

补充的通用底座（很多项目底层仍会和它们发生关系）：

  • Playwright / Puppeteer / chromedp / Selenium Grid：分别是自动化 API、CDP 生态、Go CDP 客户端、传统分布式测试执行。

对比表（定位 / 协议 / 反爬 / 部署 / 隔离 / 接入）

说明：反爬能力很多取决于你如何组合代理、指纹、账号池与行为策略。这里按“项目是否内置/工程化支持”来评估强弱。

项目 产品定位 协议/接入 反爬内置 部署形态 隔离能力（多租户） AI 接入难度 二开/API 成本
BrowserCluster 采集平台/调度系统 平台 API + 内部双引擎（Playwright/DrissionPage） 强 容器 + 集群（队列/缓存/DB） 中-强：任务/Worker 粒度可做隔离（取决于租户/权限模型） 中-高 中
browserless Browser-as-a-Service WS（Playwright/Puppeteer connect） 中（偏基础设施） Docker 单机/可横向扩 中：并发/队列/超时强，多租户权限/配额通常要你外层做 中 低-中
Ant-Browser 指纹浏览器（桌面） GUI 为主（少量接口能力） 中-强（指纹/代理/隔离） 桌面应用 强（本地隔离）/弱（SaaS）：适合本地账号隔离，不适合直接做服务多租户 高 高
Lightpanda 轻量 headless 内核 CDP（兼容 PW/Puppeteer/chromedp） 弱-中 二进制/容器（nightly/Docker） 弱-中：更像“浏览器进程”，隔离/配额靠外层容器与调度 中 中
agent-browser AI 友好自动化 CLI CLI + a11y refs（snapshot/click @e2） 弱-中 本地/CI/容器都可 中：任务隔离好做；多租户需你封装成服务并做会话/权限 低 低
steel-browser 浏览器沙箱 + Browser API 平台 HTTP API/Swagger + CDP/Puppeteer 中-强 服务化容器 强：session/page 生命周期、调试与资源管理更像平台底座 中 中
Playwright（补） 自动化基座 Playwright API 弱-中 本地/容器/runner 中：context 隔离不错；配额/审计/队列要自建 中 中
Puppeteer（补） CDP 基座 Puppeteer + CDP 弱-中 同上 中 中 中
chromedp（补） Go CDP 客户端 CDP 弱-中 本地/容器 中（靠外层） 中 中
Selenium Grid（补） 分布式测试执行 WebDriver 弱 标准集群 中-强（测试维度成熟） 中-高 中

选型流程图（3 个问题快速落地）

如果你的 Hexo 没开 Mermaid，可以直接用下面“纯文本版”。

Mermaid 版

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
flowchart TD
  A[你的目标是什么？] --> B{是否要做“采集平台/长期跑任务”？}
  B -- 是 --> BC[BrowserCluster<br/>（代理池/账号池/调度/反爬工程化）]
  B -- 否 --> C{是否要对外提供服务（多租户/SaaS）？}

  C -- 是 --> D{你更想要哪种接入形态？}
  D -- HTTP API / 平台化 --> STEEL[steel-browser<br/>（API-first + session 生命周期）]
  D -- 标准 WS 端点（Playwright/Puppeteer connect） --> BL[browserless<br/>（BaaS，自己做鉴权/配额）]

  C -- 否 --> E{是否要让 LLM 直接“稳定点网页/填表”？}
  E -- 是 --> AB[agent-browser<br/>（a11y snapshot + refs，最适合给模型当工具）]
  E -- 否 --> F{是否极度在意成本/吞吐/启动速度？}
  F -- 是 --> LP[Lightpanda<br/>（CDP 兼容，性能优先，注意兼容性评估）]
  F -- 否 --> PW[Playwright / Puppeteer / chromedp<br/>（通用底座，自行工程化反爬/队列/隔离）]

  A --> G{是否需要“本地多账号指纹环境管理”？}
  G -- 是 --> ANT[Ant-Browser<br/>（桌面指纹浏览器，偏运营/环境隔离）]
  G -- 否 --> A

纯文本版（不依赖 Mermaid）

  • 你要“采集平台/代理池/账号池/调度/反爬工程化” → BrowserCluster
  • 你要“对外提供浏览器服务（多租户）”
    • 更偏 HTTP API/平台化 → steel-browser
    • 更偏标准 WS 端点、自己做网关 → browserless
  • 你要“LLM 稳定操作网页（少写 selector）” → agent-browser
  • 你要“极致成本/吞吐/快启动” → Lightpanda（但要做兼容性评估）
  • 你要“本地多账号指纹环境管理” → Ant-Browser
  • 其他通用自动化底座 → Playwright/Puppeteer/chromedp（工程化部分自己补）

选型建议（按目标倒推）

1）你要的是“采集系统/反爬工程化”

优先：BrowserCluster
理由：它更像“自带代理池/账号池/调度/缓存/监控”的平台。你不是在选一个自动化库，而是在选一套生产系统。

2）你要的是“对外提供浏览器能力（SaaS/多租户）”

优先：steel-browser（API-first）
备选：browserless（标准 WS 端点，但多租户能力多在你网关层）

3）你要的是“让 LLM 稳定地操作网页（少写 selector）”

优先：agent-browser
理由：a11y snapshot + refs 对 LLM 很友好，能显著降低 selector 漂移导致的失败率。

4）你要的是“成本/吞吐/启动速度极致优化”

关注：Lightpanda
理由：路线是“重写 headless 浏览器内核 + CDP 兼容”。注意它的兼容性需要你用真实站点做回归。

我个人推荐的“组合拳”（最实用）

按常见的“逆向/抓取/反爬/自动化”工作，一般不会单选，而是组合：

  • 执行器（给 AI 用）：agent-browser（稳定操作层）
  • 浏览器服务层（规模化/资源池）：browserless 或 steel-browser（二选一）
  • 反爬工程化（代理池/账号池/频控）：你自己的中间层或直接上 BrowserCluster（看你是否要平台化）

一句话：

  • 想“快”：agent-browser + browserless
  • 想“产品化”：agent-browser + steel-browser
  • 想“采集平台”：BrowserCluster（必要时再用 agent-browser 做可控 UI 节点）

参考项目（链接）