前两天让我的AI助手去某电商后台导一份上个月的订单数据，它答应得挺痛快，结果卡在了登录页。账号密码填进去，弹出来个滑块验证码，它对着那个滑块来回试了好几次，最后跟我说：“这一步得你来。”

我盯着屏幕愣了三秒。说实话，这种感觉挺微妙的——明明平时它整理文件、读表格、写文档都麻溜得很，一双“手”灵活得不行。可这双手真要伸到互联网上去干活，那条腿其实是瘸的。

后来我给它接了个东西，这条腿才算真正补上。

一、Agent上网，到底卡在哪了？

你有没有发现一个现象：现在的AI Agent，本地文件玩得转，一上网就容易掉链子。

要登录的网站进不去，遇到验证码就停，反爬一拦就报错，多个账号切来切去还会串号。明明都是抓网页、抓内容，为什么别人的Agent可以干活干到天亮，你的Agent不是告诉你获取不到网页信息，就是告诉你遇到了反爬动不了？

说白了，不是它不聪明，是它面对的那个真实互联网环境，从一开始就不是为机器人准备的——网站们花了很多力气，专门用来挡自动化程序。

AI Agent时代最贵的资源是什么？信息。别人的Agent能抓到的信息你抓不到，那再好的模型也只能停在“训练截止日期”。

我一直在找解决方案，直到最近在GitHub上刷到一个升星特别快的项目——BrowserAct。目前GitHub Star已经突破2.4K，发展速度相当快。

二、它不是什么花架子，是真能干活

说实话，一开始我也没当回事。浏览器自动化工具这些年见的多了，Playwright、Puppeteer哪个不是大名鼎鼎？但仔细研究了一下，发现这玩意儿还真有点不一样。

它不是那种“装个插件就能用”的简单货色。它真正把浏览器指纹伪装、TLS轮换、代理切换、验证码处理、受保护页面提取、远程人工接管、会话隔离、多账号身份隔离、并发任务管理这些东西，全都整合到了一起。

它解决的不是“能不能打开网页”这么浅的问题，而是Agent在真实互联网环境里持续干活时很容易遇到的几个痛点：打不开、进不去、看不懂、登录态不能复用、不能并发、遇到风控、遇到验证、遇到问题不会主动找人无缝接管。

我觉得它的设计思路特别聪明——它不是让AI自己搞定一切，而是承认AI有解决不了的问题，把人类作为最后一层安全网融入到了自动化流程里。

怎么理解？它搞了个三层的防御体系：

第一层，环境层。 指纹伪装加TLS轮换加代理切换，让90%以上的反爬检测压根不触发。你的Agent在网站上看起来就像个正常人在浏览。

第二层，执行层。 真遇到验证码了怎么办？它有自动破解的能力，零配置就能提取受保护页面的内容。

第三层，人类层。 如果AI实在搞不定，它会生成一个可访问链接，让你用手机扫码或者手动操作，操作完Agent无缝继续往下跑。

这个三层设计我特别喜欢——不硬撑，不假装，该叫人就叫人，但叫完人还能接着干。

三、装上之后，我实测了一把

我把它接进了WorkBuddy。安装过程比想象中简单，就两步：把GitHub仓库地址丢给Agent，它自己去拉去配；再填一个API key。搞定这两步，WorkBuddy就不只是“能打开浏览器”了，它能在一个真实浏览器环境里接着往下干活。

先说抓取能力。我让白板的WorkBuddy去抓小红书的内容，结果直接抓瞎——小红书的搜索页需要登录，反爬严格，站外基本接不到完整笔记。

装了BrowserAct之后再试，同样抓取小红书，分分钟拿下，每一篇的标题、作者、互动数、日期全都抓到了。

我翻看了一下它执行的过程，发现是两层配合：先尝试用stealth-extract自动提取受保护页面，如果撞墙了（比如小红书必须有登录态），就启动第二层——本地Chrome浏览器模拟人为操作和搜索。

这里有个细节我特别想夸：它跑到需要登录那一步的时候，没有硬闯，也没有报错退出，而是停下来，把浏览器亮给我，等我扫码登进去。我登完，它接着往下跑，整个任务从头到尾没断。

除了小红书，我还试了几个有校验的网站。BrowserAct的solve-captcha云端服务直接上场，滑杆验证码被顺利解决。

四、三种模式，对应三种活

装好之后我发现它内置了三种浏览器模式，不是摆设，是真对着不同场景来的。

第一种是chrome模式，直接复用你本地Chrome已经登录好的状态。你自己浏览器里登过的公司后台、各种SaaS、带SSO的内网，它借着现成的cookie就进去了，不用再啃登录那道墙。我那个导订单的活，卡就卡在这儿，换这个模式立马通。

第二种是stealth隐私模式，每次会话给你一套全新指纹，配上代理轮换。抓那些反爬凶的公开数据用它——身份一次一换，不容易被盯上。

第三种是stealth固定身份模式，稳定指纹、稳定IP、稳定账号，适合需要长期维持一个身份去登录、去操作的场景。

三种模式换着用，基本覆盖了“上网干活”的大部分情况。

五、批量并发，才是真正见功力的时候

单条抓取只是开胃菜。我真正想测的是批量并发。

我让WorkBuddy分别从知乎、什么值得买、公众号、小红书上搜索NAS和Docker相关的教程，并且汇总。

整个过程分三个阶段：先用stealth-extract并行抓取知乎和什么值得买的数据，然后启动本地Chrome浏览器抓取公众号和小红书。数据返回后WorkBuddy第一时间整理成了规范的Markdown格式，列出了表格、做了排序，比单独看文字丰满很多。

普通Agent一遇到大批量并发数据抓取就容易出问题——难的不在于工具不支持并发，而在于高频下的浏览器校验、限定，以及大模型本身的决策可靠性上。BrowserAct把这层也考虑进去了，每个浏览器配了独立的Cookie、指纹和代理，网站没法把它们关联起来。

还有一个细节我挺在意——传统工具动不动甩一大坨HTML给你，Token消耗瞬间几十刀就没了。BrowserAct换成了索引化的文本，能显著降低Token消耗。操作也省心，通过state列出能点的元素，直接click 3、input 2，不用费劲解析DOM。

六、比“能抓”更重要的是“可复用”

踩过坑的人都知道：很多抓取方案第一次灵、过几天就废，因为结果不稳定。

BrowserAct提供了一个叫skill-forge的模块——让Agent先把一个网站摸一遍，自动摸清背后的API和数据规律，再打包成一份可直接部署的Skill。只需要摸一遍，往后就不用每次重新探路。

之后同类任务直接复用，稳定、可审计、可交接。这才是Agent浏览器自动化真正进生产环境的关键。

团队还备了30多个现成方案，Amazon、Google Maps、YouTube、Reddit等主流平台拿来就能跑。

说两句实在的

Agent的瓶颈正在从“脑子”悄悄挪到“动手”能力。模型越来越聪明了，可真落到干活上，卡的往往是执行的那一层。

谁能先把这层啃下来，谁就能打通Agent干实事的最后一公里。而BrowserAct把它开源了，等于把这份能力重新交回开发者手里。

当然，能力越强越要守边界。把浏览器的操作权交给Agent，效率上来了，但也伴有风险。刚上手的时候建议先在测试环境里跑，盯住那道需要确认权限的闸门。

但不管怎么说，至少我的Agent现在能自己登录、自己过验证、自己批量抓数据了——而我要做的，只是在它实在搞不定的时候，扫个码而已。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。