AI Agent 操作浏览器太难了?browser-act skill实测报告

作为 AI 工程师，我每天都在跟浏览器打交道——爬数据、测前端、自动化各种任务。最近发现一个叫 browser-act 的工具，专门给 AI Agent 设计的浏览器自动化 CLI。

花了半天时间测了一下，说几句真话。

一、browser-act 是什么

先说官方定义：

Browser automation CLI built for AI agents. Break through anti-bot walls, hand off to humans across platforms when stuck. Parallel multi-task execution, independent multi-session operation, isolated multi-account browsing.

翻译一下：这是一个专为 AI Agent 设计的浏览器自动化工具，主打四个卖点：

突破反爬虫：三层防护——环境层（指纹伪装、TLS 轮换）、执行层（自动解验证码）、人工层（远程协助）
三种浏览器模式：Chrome 复用登录态、隐身模式批量抓取、固定身份养号
零干扰并发：多浏览器并行，独立 Cookie、指纹、代理，互不干扰
为 AI 设计：索引式交互（click 3）、紧凑输出、语义记忆

二、我为什么关注它

之前用 Playwright、Selenium 写自动化脚本，最烦的是两件事：

选择器维护：页面一改版，XPath 就废了，每次都要重新调试
AI 集成：想让 AI Agent 操作浏览器，得写一堆封装代码，把 DOM 转成 AI 能理解的格式

browser-act 的思路不一样——它直接给 AI 提供"索引式交互"。你不用写 XPath，AI 说"点击第 3 个元素"就行。

以前让 Agent 操作一个按钮，我得写 page.locator("//button[@class='submit']").click() 这种选择器。现在直接 click 3，省掉了整个封装层。

三、我测了什么

测试环境：WSL (Ubuntu)，browser-act v0.1.26。

我设计了 3 类测试场景：

测试 1：基础抓取（stealth-extract）

这是最轻量的功能，不需要创建浏览器，直接抓取页面内容。

测试网站	页面类型	耗时	结果
example.com	简单静态页	3.45s	✅
httpbin.org/html	中等静态页	3.79s	✅
news.ycombinator.com	复杂列表页	4.80s	✅
react.dev	JS 渲染 SPA	5.03s	✅
simonwillison.net	技术博客	4.25s	✅
github.com	复杂 WebApp	14.73s	✅
sspai.com	中文网站	13.00s	✅
amazon.com	反爬虫严格	4.96s	❌ 被拦截

简单页面 3-5 秒搞定，复杂页面（GitHub、少数派）要 13-15 秒。Amazon 这种反爬严格的直接被拦。

测试 2：内容格式对比

同一个页面，HTML 和 Markdown 输出差异很大：

HTML 输出：3704 字节，耗时 19.98s
Markdown 输出：228 字节，耗时 32.12s

Markdown 输出更小但更慢，因为需要额外的转换处理。如果你只需要文本内容，HTML 反而更快。

测试 3：错误处理

故意访问一个返回 503 的接口（httpbin.org/ip），browser-act 正确返回了错误详情：

Error:ServerreturnedHTTP503forhttps://httpbin.org/ip.Thepagedoesnotexist,requiresauth,orisrate-limited.

错误处理做得不错，不会静默失败。

四、踩了什么坑

坑 1：反爬虫检测没那么神

browser-act 宣传有"stealth 模式"，能绕过反爬虫。但实测 Amazon 直接被拦，返回验证页面。

stealth 模式能绕过基础检测（比如简单的 User-Agent 检查），但对 Amazon、Cloudflare 这种专业反爬还是不够。需要配合代理轮换才行。

坑 2：浏览器创建需要额外配置

stealth-extract 能直接用，但完整的浏览器自动化（点击、输入、表单提交）需要先创建浏览器。创建过程需要用户确认，首次使用还有额外配置。

如果你只需要抓取内容，stealth-extract 够用。如果需要交互操作，配置成本不低。

坑 3：性能波动大

简单页面 3 秒，复杂页面 15 秒，差异 5 倍。GitHub 首页要 14.73 秒，这个速度对于批量抓取来说不太理想。

单次抓取可以接受，批量场景需要考虑并发和超时策略。

五、它的核心优点

虽然有坑，但 browser-act 确实有几个真正的优势：

优点 1：AI 原生集成

传统工具（Playwright/Selenium）是给人写的脚本，AI 要用得写封装层。browser-act 直接为 AI 设计：

索引式交互：state 返回元素列表，click 3 点击第 3 个，不用写 XPath
紧凑输出：比 JSON/HTML 省几倍 token
语义记忆：每个浏览器有 desc 描述，AI 能根据任务匹配

优点 2：轻量级抓取

stealth-extract 不需要创建浏览器，直接抓取，启动快。

对比：

curl：快但不支持 JS 渲染
Playwright：支持 JS 渲染但要启动浏览器
browser-act：支持 JS 渲染且不需要启动浏览器（stealth-extract 模式）

优点 3：人机协作设计

当 AI 遇到验证码或复杂操作时，可以生成一个链接让人类接手。操作完后 AI 继续执行。

场景：AI 自动化注册流程，遇到短信验证码，生成链接让用户扫码，完成后 AI 继续填表单。

优点 4：并发隔离

多浏览器并行，每个浏览器独立的 Cookie、指纹、代理。这对多账号场景很重要。

场景：同时管理 5 个小红书账号，每个账号独立浏览器，互不干扰。

六、跟现有工具对比

特性	browser-act	Playwright	Selenium	curl/wget
JS 渲染	✅	✅	✅	❌
反爬虫	⚠️ 中等	⚠️ 中等	❌ 弱	❌ 弱
启动速度	快	中等	慢	最快
资源消耗	中等	中等	高	最低
AI 集成	✅ 原生	❌ 需封装	❌ 需封装	❌ 需封装
人机协作	✅ 原生	❌ 需开发	❌ 需开发	❌ 无
并发隔离	✅ 原生	⚠️ 需配置	⚠️ 需配置	❌ 无

browser-act 的优势是 AI 原生集成 + 人机协作。你不用写选择器，直接用索引号操作元素。

七、我的判断

如果你是 AI 工程师，需要让 Agent 能"看"网页，browser-act 值得试试。

它解决了 AI 操作浏览器的核心痛点——选择器维护和 AI 集成。

以前的方案：

Playwright + 封装层：写 100 行代码，维护成本高
curl + 解析：不支持 JS 渲染，SPA 直接废了
Selenium：太重，资源消耗大

browser-act 的方案：

一行命令：browser-act stealth-extract https://example.com
索引交互：click 3、input 2 "text"
人机协作：遇到验证码生成链接让人接手

但它替代不了 Playwright 做复杂的浏览器自动化。把它当成 AI 工具链中的一个补充——快速获取网页内容用它，复杂交互还是用 Playwright。

八、适合什么场景

不推荐的场景

严格反爬虫网站：Amazon、电商平台，需要配合代理
需要登录的复杂交互：配置成本高
高频批量抓取：性能波动大，需要并发策略

代码：https://github.com/browser-act/skills

你在 AI 自动化方面用过什么工具？评论区聊聊。

标签：#AI工具 #浏览器自动化 #AI Agent #开发效率 #踩坑记录