一个能让你 10 分钟搞定浏览器自动化的工具，和一个让你上生产后怀疑人生的真相。

最近有款叫 browser-act 的工具在技术圈小有热度——“零代码浏览器自动化”、“AI 驱动的网页操作”、“用自然语言就能写自动化脚本”。口号听起来像是测试工程师的终极梦想：不需要写一行Playwright代码，不需要研究CSS选择器，对着 AI 说句话，浏览器就帮你把活干了。

GitHub 2.4K+ Star，主打"让 AI Agent 操控真实浏览器"。

作为一个天天跟自动化打交道的测试点工-TesterRoad，我当然坐不住。花了半天时间从安装到完整 Demo，把 SauceDemo 购物流程从头到尾跑了一遍。

结论先行：Demo 演示确实惊艳，上手体验远超预期。但如果你打算把它扔进生产环境的回归测试流水线——请先读完这篇文章。

---

一、browser-act 到底是个啥？

简单来说，browser-act 是一个AI驱动的浏览器控制工具。它由两部分组成：

1. browser-act CLI：命令行工具，负责创建并管理远程浏览器实例
2. browser-act Skill：AI Agent 的技能插件，让 AI 能理解页面结构并生成操作指令

它的核心理念是：让AI看页面，让AI做决策。你不需要告诉它"点击 CSS 选择器.btn-primary"，你只需要说"点击那个红色的登录按钮"，AI 会自己找到它。

听起来是不是很美好？我们直接上手看看。

---

二、上手实测：从安装到下单，10 分钟搞定

2.1 安装三步走

第一步，安装 AI Skill 插件：

npx skills add browser-act/skills@browser-act -g -y

第二步，安装 CLI 工具：

uv tool install browser-act-cli --python 3.12

CLI 版本 v0.1.27，连带安装了 92 个依赖包，体量不小。

第三步，配置 API Key——这步需要注册账号：

browser-act auth login          # 获取注册链接
browser-act auth set <你的Key>   # 设置密钥，作用我们后面会讲到

整个安装过程大约 3-5 分钟，体验很流畅。

2.2 创建一个"隐身"浏览器

browser-act 支持多种浏览器类型。

模式	核心关键词	登录态	指纹	典型场景
Chrome 模式	复用本地 Chrome	✅ 你的真实登录态	就是你真实的	内网、已登录 SNS、跳过 SSO
Stealth 隐私模式	每次全新、零残留	❌ 空的	🎭 每会话新伪造	批量公网抓取、反爬绕过
Stealth 固定身份	稳定假身份长期持有	登录一次后保持	🎭 固定伪造	多账号并行、长期养号操作

我们创建一个stealth类型的浏览器（反检测浏览器），我们上面创建的key正是这个用处，专门用来访问目标网站：

browser-act browser create
  --name "saucedemo-test"
  --type stealth
  --desc "用于访问 saucedemo.com 进行 UI 自动化测试"

不到 3 秒，一个云端浏览器实例就创建好了，返回唯一的browser ID。

2.3 打开页面，看看 AI 看到了什么

browser-act --session my-task browser open 100781335781772083 https://www.saucedemo.com/

再用 state 命令让 AI 输出当前页面结构：

browser-act --session my-task state

输出长这样：

[2] <input placeholder=Username>
[3] <input placeholder=Password>
[4] <input type=submit value=Login>

AI 已经把页面上的可交互元素都标上了序号。接下来要操作哪个元素，直接引用序号就行。

2.4 登录、加购、下单一条龙

输入用户名密码并登录：

browser-act --session my-task input 2 "standard_user"
browser-act --session my-task input 3 "secret_sauce"
browser-act --session my-task click 4

加三件商品到购物车：

browser-act --session my-task click 10   # Sauce Labs Backpack
browser-act --session my-task click 14   # Sauce Labs Bike Light
browser-act --session my-task click 18   # Sauce Labs Bolt T-Shirt

进入结算页，填收货信息，点击 Finish：

browser-act --session my-task input 4 "John"
browser-act --session my-task input 5 "Doe"
browser-act --session my-task input 6 "94105"
browser-act --session my-task click 8    # Continue
browser-act --session my-task scroll down --amount 500
browser-act --session my-task click 5    # Finish

订单确认页弹出：

Checkout: Complete!
Thank you for your order! Your order has been dispatched…

一个完整的电商购物流程，从登录到下单确认，总共 不到 15 条命令，全程不需要写一行选择器代码。

到这一步，我的感受是：真香。

---

三、browser-act 命令体系速览

在深入批判之前，先客观看下它到底提供了哪些能力。browser-act CLI的命令体系相当完整：

类别	核心能力
浏览器管理	创建/删除/列出浏览器，导入浏览器 Profile
页面导航	打开 URL、前进后退、刷新、多标签页管理
元素交互	点击、输入、悬停、下拉选择、滚动、文件上传
页面数据	获取标题、截图、提取 Markdown/HTML、获取元素文本
等待机制	页面稳定等待、元素状态等待
网络控制	网络请求捕获/过滤、HAR 录制、离线模式切换
高级功能	验证码辅助/自动解决、远程人工协助
轻量提取	stealth-extract 反检测页面内容抓取（无需 session）

功能覆盖确实是奔着"浏览器自动化瑞士军刀"去的。验证码处理、HAR 录制、远程协助这些甚至是一些成熟框架都不具备的能力。

但问题来了——Demo跑得通，不代表生产线扛得住。

---

四、兴奋褪去：五个让你上不了生产的致命问题

以下结论基于我在测试环境中的真实操作和代码层面分析。

问题一：元素序号定位——一颗定时炸弹

这是 browser-act 最核心的设计，也是它最致命的缺陷。

整个交互模式建立在一个假设之上：AI 给页面上每个元素分配一个序号，你通过序号来操作：

click 10   # 添加背包
click 14   # 添加车灯
input 4 "TesterRoad"  # 输入姓名

这看起来方便，但你想想：

1. 页面加一个广告位 → 下面所有元素的序号 +1，你的 15 条命令全部报废
2. 不同分辨率 → AI 分析出来的元素列表可能不同，序号对不上
3. 页面刷新 → 动态加载的内容顺序可能变化
4. A/B 测试 → 同一页面不同用户看到的元素不同

这不叫"易碎"——这是玻璃做的。

对比一下 Playwright 的定位方式：

# Playwright：定位器跟页面结构绑定，不受序号影响
page.get_by_role('button', name='Add to cart').click()
page.get_by_placeholder('First Name').fill('TesterRoad')

Playwright 的定位器是基于语义角色、文本内容、属性值——这些都是页面本身的特征，不受元素顺序影响。一个前端加点东西就让你回归测试全挂的工具，凭什么上生产？

问题二：每一步spawn子进程——性能灾难

browser-act 的每一步操作，底层都是这样跑的：

for step in steps:           # 假设 10 个步骤
    result = subprocess.run( # 每次都启动一个新的 CLI 进程
        ['browser-act', '--session', 'my-task', step.command]
    )
    # 每次 2-4 秒起步

一个 10 步的购物场景：

1. browser-act: 30-40 秒
2. Playwright: 3-5 秒

差了 10 倍。如果你有 100 个测试用例，browser-act 要跑 50 分钟，Playwright 可能 5 分钟搞定。

这不是优化的问题，这是架构层面的设计选择——基于 CLI 子进程的交互模式，注定了它不可能快。

问题三：缺乏企业级测试能力——对比表说话

我把 browser-act 和一个成熟的自动化测试框架放到一起对比，差距一目了然：

能力	browser-act	Playwright / Selenium
数据驱动测试	无法参数化	@pytest.mark.parametrize
并行执行	单 session 串行	多 worker 分片并行
CI/CD 集成	无	GitHub Actions 一键接入
测试报告	简单日志	HTML 报告 + 截图 + Trace
等待机制	无显式等待	自动等待 + 自定义超时
元素定位稳定性	AI 序号（极其脆弱）	CSS / XPath / Role / TestID
错误重试	不支持	支持 flaky retry
多环境管理	不支持	多配置文件
版本控制	步骤存 DB	代码文件（Git 友好）

说白了，browser-act 现在只做到了"能跑"，但测试工程师真正需要的"跑得稳、跑得快、能追溯、能集成"，它一个都没解决。

问题四：用例存数据库——团队协作噩梦

browser-act 平台把测试用例存在 SQLite 里。这意味着：

1. 无法 Code Review——你看不到同事改了什么
2. 无法 Git 追溯——谁改的、什么时候改的、为什么改，全不知道
3. 无法分支管理——开发环境和新功能分支怎么隔离？
4. 多人协作冲突——两个人同时编辑，数据库文件直接打架

在一个正经的工程团队里，测试用例跟业务代码一样，是需要版本管理的资产。把它锁在 SQLite 里，等于放弃了所有现代软件工程的协作能力。

问题五：断言能力严重不足

当前 browser-act 不支持断言，对于一个生产级自动化测试来说，无断言，简直是灾难！

你的自动化测试只能验证"页面有没有某个字"，但验证不了"这个按钮在特定条件下是否应该被禁用"——这叫什么自动化测试？

---

五、那它到底适合谁？

客观地说，browser-act 并非一无是处。搞清楚它的定位，你才知道该不该用它：

场景	适合度	说明
快速 Demo / POC	非常合适	10 分钟搭一个能跑的通路，演示效果满分
临时页面验证	合适	快速 state 看一眼页面结构，$ browser-act 比开 DevTools 快
简单冒烟测试（≤5 步）	勉强能用	页面不常变的场景，偶尔跑一下还行
回归测试**	别用	一次改版全部用例重写，维护成本远大于收益
大规模自动化**	别用	子进程架构决定了批量跑不通
CI/CD 流水线**	别用	零集成能力，报告也看不了

一句话总结：browser-act 是一个优秀的 AI 辅助浏览器交互工具，但它不是一个自动化测试框架。

---

六、如果非要落地，我的建议

假如你真的想基于 browser-act 的"低代码"理念做一个能落地的自动化测试平台，以下是演进路线：

1. 底层引擎换成 Playwright

这是最关键的一步。保留 browser-act 的低代码管理层（可视化编排步骤），但执行引擎从 CLI 子进程换成 Playwright。让 Playwright 用稳定的 Role/TestID 定位器替代 AI 序号。

2. 测试用例代码化

支持将可视化编排的步骤导出为 Python / JavaScript 代码文件。代码存 Git，支持 Code Review、分支管理、冲突合并。

3. 补齐数据驱动能力

支持 CSV / Excel 参数化，同一套步骤跑多组数据——这是回归测试的基本功。

4. 加上并行执行

多 session 并行跑不同场景，别让 CI 排队等一个 50 分钟的串行任务。

5. 完善测试报告

Allure 或 Playwright HTML Report，失败截图 + Trace + 录屏，出了问题能快速定位。

---

七、写在最后

坦白说，体验 browser-act 的过程，我的心情经历了三个阶段：

1. 安装阶段：“这个安装体验不错啊，比 Playwright 配环境舒服多了”
2. Demo 跑通：“卧槽，15 条命令就完成了一个完整购物流程，有点东西”
3. 冷静分析后：“这东西上生产就是灾难”

browser-act 的团队显然在"AI + 浏览器"这个方向上做了很多扎实的工作——stealth 反检测、验证码处理、HAR 录制、远程协助，这些都是真实场景下的痛点。但他们选择了一个在自动化测试领域最难走的路：牺牲稳定性换易用性。

如果你是个人开发者，想快速验证一个网页流程——browser-act 绝对值得一试。

如果你是测试团队负责人，想引入一个自动化测试平台——请带着这篇文章去做技术选型评审。

毕竟，一个上线第一天就让你 80% 用例挂掉的工具，再香也不能用。