BrowserAct是一款开源AI Agent浏览器自动化工具，基础功能免费。它通过隐身浏览器渲染、指纹伪装和三层反爬体系，处理验证码、登录态和人工接力，让Agent稳定执行公众号文章提取等真实网页任务。适用于需要自动化处理复杂网页的开发者，注意动态代理和超量浏览器实例可能产生费用。
Tags:
BrowserAct 近期在 AI Agent 圈子彻底爆火。
早前大家聊 Agent 浏览器工具， Playwright、Agent Browser 各有所好。但最近你再问一圈，不少人的首选已经变成了 BrowserAct。
我就是被这股讨论带进去的。花了两周时间，用它跑了各种真实网页任务。
两周后我的结论是：这东西被低估了。它解决的根本不是「怎么点按钮」这种问题。
而是把反爬、登录态、验证码、代理、人工接力、Skill 复用这些东西，放在了一套体系里。
让 Agent 真正跑进真实网页，而不是只在一个干净的 demo 页上耍花枪。
GitHub：https://github.com/browser-act/skills
下面我把我觉得它好的地方，一个一个拆开。
亮点一
现在的 Agent 已经很会写代码了。但它最容易翻车的地方，往往不是代码，是网页。
举个我实际踩过的坑。
在 Claude Code 里用 Web Fetch 读一篇公众号文章，结果失败了，页面触发了环境异常验证，根本读不到正文。
接着我又用了同样的指令，只是把工具换成了 BrowserAct：
browser-act stealth-extract "https://mp.weixin.qq.com/s/tGk-mKKDeFn9uO3KaIUPpw" --content-type markdown结果直接拿到了结构化内容：标题《又一个画图 Skill 开源，再见 draw.io！》，作者小 G，2026 年 7 月 3 日发布，正文 Markdown 完整可读。
BrowserAct 的 stealth-extract 不一样。它不是 curl，不是 web fetch，是真正启动了一个隐身浏览器去渲染页面，然后把正文结构化地抽出来。拿回来的不是一坨 HTML，Agent 可以直接读、能分析、能继续推理。
对于需要让 Agent 处理公众号、小红书、SaaS 后台这类真实网页的人来说，这一步是刚需，绝对不是炫技。
亮点二
如果只挑一个 BrowserAct 最值得说的能力，我觉得就是这套反爬体系。
整体设计非常巧妙，不是靠某一个点单打独斗，而是分三层配合，一层兜一层。
第一层：环境层——先让浏览器不像机器人
第一步最基础：BrowserAct 使用 Stealth 浏览器，为每一个浏览器实例配置了指纹伪装、TLS 指纹轮换以及代理自动切换，从底层减少自动化特征暴露。
目前 BrowserAct 已通过了多项指纹检测及人机检测：
指纹检测对比：
人机检测结果：
我实际用 BrowserAct 跑了一组检测，截图为证：
BrowserAct 指纹检测实测
这些数据说明一件事：BrowserAct 确实是在底层能力上做足了功夫：navigator.webdriver、canvas、GPU、音频、字体、屏幕参数、网络时序，几十个指纹点全都处理过。
此外 BrowserAct 也通过模拟鼠标轨迹等行为特征，进一步降低被检测风险。reCAPTCHA v3 0.9 分，硬实力的差距就在这些细节里。
第二层：执行层 ——遇到验证了，先自动解决
很多产品的设计，做到环境层就停了。浏览器指纹像真人了，剩下的你自己搞定。
BrowserAct 不一样。它接着往下走——遇到验证弹出来，先用 solve-captcha 尝试自动解决：
目前已支持多个主流厂商的验证类型：
BrowserAct 的设计非常清晰，不是要“所有验证码都能自动过”，而是能自动解决的先自动解决；处理不了的，进入第三层。
第三层：人机协作 —— 该让人接手的，不自己乱闯
事实上，真实网站不是所有验证都能或都应该自动处理。
扫码登录、短信验证、企业 SSO、OAuth 授权、安全确认，这些步骤本来就不该让 Agent 悄悄绕过去。
很多人会问：Agent 怎么知道什么时候该停下来？是自己瞎猜，还是有引导？
答案是：有引导。BrowserAct 内置了一套场景识别规则：遇到密码输入、支付确认、扫码登录、短信验证、安全密钥、人脸/指纹验证、SSO 跳转这类操作，Agent 不会硬闯，而是直接触发 remote-assist，生成一个远程协作链接，告诉用户：这一步需要你来。
这个设计有两个很巧妙的地方。
第一，人接管不是"接管全部"。你只需要处理当前卡住的那一步——扫个码、输个验证码、点个确认——完成后 Agent 继续往下走，浏览器会话原封不动。
第二，不要求你在电脑前。拿到链接后，你可以在已经接入 Agent 的移动设备上远程操作，点一下"已完成"，Agent 从刚才断掉的地方继续。
这不是缺点。这是安全阀。
把"必须人帮一下"的步骤纳入工作流，任务不会死在这里。
亮点三
如果只说 BrowserAct 能打开网页、点击按钮，那就把它说窄了。
它把浏览器、会话、登录态、stealth、代理、截图、验证码处理、人工接力这些经常分散在不同工具里的能力，放在了一套体系里。
但更值得说的是它的交互逻辑，和传统脚本完全不一样。
传统脚本的思路是：写好选择器 → 执行 → 等 → 继续执行。页面变了？脚本就崩了。
BrowserAct 的思路是：先看页面，再行动；页面变了，重新看。
具体来说，每一步操作都走这个循环：
1. 获取当前页面状态，每个元素都有编号browser-act --session demo state输出：[1] <a /> 了解更多, [2] input "搜索", [3] button "开始"2. 用编号交互browser-act --session demo input 2 "关键词"browser-act --session demo click 33. 等页面稳定后，重新获取状态（旧编号已失效）browser-act --session demo wait stablebrowser-act --session demo state
每次 state 都是重新看一遍当前页面，拿到最新的元素编号。不会拿旧页面的按钮编号去点新页面的东西。
这个细节很小。但写过网页自动化的人应该知道，这就是一堆失败的来源。
另外这套交互方式还有一个好处：省 token。state 返回的是紧凑的索引文本，比 JSON 或 HTML 省数倍的 token。而且每个浏览器自带 desc 描述，Agent 按语义匹配任务，不用每次都重新摸索。
它不是只处理"网页内容"。它处理的是"网页任务"。
亮点四
除了前面讲的反爬和验证码处理，另一个让我眼睛一亮的是 Skill Forge。
这一点我想单独拿出来讲。因为很多人一听到 Skill，第一反应就是：是不是又要写一堆代码？
说实话，如果完全手搓，确实不轻松。但 BrowserAct 的 Skill Forge 思路不一样。他先让 Agent 跟着你的需求，把网站摸一遍，再把"怎么摸的"整理成下次能直接调用的能力。
你真正要做的，只需要把需求说清楚：想要抓取的目标网站是什么，需要支持什么输入方式，想要提取哪些字段。有了它，就算是完全不会代码的小白，也能成为“Skill 专家” 。
比如前面讲的公众号文章提取，先在 Agent 里把 Skill Forge 装上：
Install browser-act-skill-forge. Skill source: https://github.com/browser-act/skills/tree/main/browser-act-skill-forge装好之后，直接用自然语言告诉它：
帮我把微信公众号文章提取流程做成一个 Skill。只需要输入一组微信文章 URL，就能拿到每篇文章的标题、发文时间、作者、正文 Markdown 和内容总结。Skill Forge 需求描述
它确认需求后，开始自己探索。
先探索这个网站有没有更稳定的路径：比如能不能从页面请求里找到可复用的数据接口。
如果接口不合适，就退回到 DOM 路径，去确认哪些节点能稳定拿到数据。探索完之后，再把验证过的方法封装成 Skill 文件。
这点很关键。
因为一次性 demo 最怕什么？最怕今天跑通了，明天换个人、换个会话、换个 Agent，就没人知道当时怎么跑的了。
但 Skill 不一样。它会把输入、输出、执行步骤、已验证的读取方式、失败时该怎么处理，都写进一个可以复用的包里。
下次你再让 Agent 处理公众号文章，不需要重新解释“微信文章标题在哪个节点”、“发文时间怎么读”、“正文怎么保存”。直接调用这个 Skill 就行。
这也是我觉得它对小白最友好的地方——这些任务单看都不大，但一旦每周、每天都要做，Skill 的价值就出来了。真正省下来的不是一次点击，而是下一百次重复摸网页的成本。
亮点五
有了BrowserAct，不是说 Playwright 没用了。如果你需要进行 E2E 测试，Playwright 依然是非常好的工具。但 Agent 面对真实网站时，需求不太一样。
Playwright 更像开发者手里的自动化库——你写选择器、等待逻辑、异常处理，自己负责维护脚本。
BrowserAct 的思路不一样。它把这套浏览器能力做成 Skill 和 CLI，让 Claude Code、Codex、Cursor、Windsurf 甚至国内 Agent 都能接——只要它能安装 Skill 或调用本地 CLI。
而市面上那些反检测浏览器，解决的是浏览器本体更像真人。BrowserAct 要解决的是：Agent 怎么使用这个浏览器、怎么继续任务、怎么处理受阻、怎么把流程留下来。
这不是谁替代谁的问题。这是层级不一样。
亮点六
用下来有两个绕不开的问题，我觉得该说清楚。
一个是成本。先说工具本身：BrowserAct 基础功能免费，只有用到动态代理、静态代理，或者本地浏览器数量超过 5 个时才需要付费。
日常的 stealth-extract、state、click、screenshot 这些核心操作，不花钱就能用。
另外 Agent 操作网页 token 确实会花，尤其那种每一步都截图、每一步都重判的流程。
BrowserAct 的做法不是把模型变便宜，是让你少做重复工，能拿结构化内容就不看图、能复用 session 就不重登录、能把流程做成 Skill 就不每次重新摸索。真实网站任务，本来就不是零成本魔法。
另一个是隐私。本地 profile、cookie、登录态、页面内容，默认在本地处理。
三种模式界限很清楚：stealth 走反检测和代理隔离，chrome 复用登录态但独立 profile，chrome-direct 直接控制当前 Chrome。尤其登录、支付、发布、删除这类操作，都留了确认门。
上手安装
如果你也想试试，安装很简单。在 Agent 里一句话就行：
Install browser-act. Skill source: https://github.com/browser-act/skills/tree/main/browser-act或者自己装 CLI：
uv tool install browser-act-cli --python 3.12browser-act get-skills core --skill-version 2.0.2
get-skills core 这一条别跳。
它不是 help，是告诉 Agent 当前环境里有哪些浏览器、怎么处理 session、哪些操作要确认。
很多自动化失败不是因为模型笨，是因为它没拿到当前环境的规则。
写在最后
Agent 落地的瓶颈，从来不只是模型。
模型已经很会想了。问题是，它经常进不去真实系统，或者进去之后不知道怎么稳定地往下走。
BrowserAct 干的，就是帮 Agent 把这条路走通。
如果你已经在用 Agent 做网页任务，别急着写一堆脚本。先挑一个最容易卡住的真实流程，用 BrowserAct 跑通，再把它做成 Skill。这比多写十个临时脚本更有价值。
GitHub 项目地址：https://github.com/browser-act/skills/tree/main/browser-act
Skill Forge：https://github.com/browser-act/skills/tree/main/browser-act-skill-forge
官网：https://www.browseract.ai/daily
今天的分享到此结束，感谢大家抽空阅读，我们下期再见，Respect！
没有评论:
发表评论