一个能让你 10 分钟搞定浏览器自动化的工具，和一个让你上生产后怀疑人生的真相。
最近有款叫 browser-act 的工具在技术圈小有热度——“零代码浏览器自动化”、“AI 驱动的网页操作”、“用自然语言就能写自动化脚本”。口号听起来像是测试工程师的终极梦想：不需要写一行Playwright代码，不需要研究CSS选择器，对着 AI 说句话，浏览器就帮你把活干了。
GitHub 2.4K+ Star，主打"让 AI Agent 操控真实浏览器"。
作为一个天天跟自动化打交道的测试点工-TesterRoad，我当然坐不住。花了半天时间从安装到完整 Demo，把 SauceDemo 购物流程从头到尾跑了一遍。
结论先行：Demo 演示确实惊艳，上手体验远超预期。但如果你打算把它扔进生产环境的回归测试流水线——请先读完这篇文章。
一、browser-act 到底是个啥？
简单来说，browser-act 是一个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" # 输入姓名
这看起来方便，但你想想：
这不叫"易碎"——这是玻璃做的。
对比一下 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 步的购物场景：
差了 10 倍。如果你有 100 个测试用例，browser-act 要跑 50 分钟，Playwright 可能 5 分钟搞定。
这不是优化的问题，这是架构层面的设计选择——基于 CLI 子进程的交互模式，注定了它不可能快。
问题三：缺乏企业级测试能力——对比表说话
我把 browser-act 和一个成熟的自动化测试框架放到一起对比，差距一目了然：
| 数据驱动测试 | 无法参数化 | @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 里。这意味着：
在一个正经的工程团队里，测试用例跟业务代码一样，是需要版本管理的资产。把它锁在 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 的过程，我的心情经历了三个阶段：
browser-act 的团队显然在"AI + 浏览器"这个方向上做了很多扎实的工作——stealth 反检测、验证码处理、HAR 录制、远程协助，这些都是真实场景下的痛点。但他们选择了一个在自动化测试领域最难走的路：牺牲稳定性换易用性。
如果你是个人开发者，想快速验证一个网页流程——browser-act 绝对值得一试。
如果你是测试团队负责人，想引入一个自动化测试平台——请带着这篇文章去做技术选型评审。
毕竟，一个上线第一天就让你 80% 用例挂掉的工具，再香也不能用。
