我在GitHub trending上刷到BrowserAct的时候，它已经攒了2400多个star。点进去看了两分钟README，直接在自己机器上装了一个。装完跑了一遍之后我只能说，这个东西把AI Agent浏览器自动化这件事想明白了，也做出来了。

Agent读网页这件事，市面上大部分方案烂得千篇一律。curl和web_fetch碰到JS渲染的页面直接哑火，更别提登录态和网站防护了。Playwright和Puppeteer虽然能跑浏览器，但WebDriver痕迹太明显，一进受保护页面就被风控系统揪出来。agent-browser能做基础操作，但反检测、隐身浏览器、人机协作这些真正卡脖子的东西它一样都没有。

BrowserAct解决的就是这个问题。它不是又一个浏览器自动化工具，它是专门给AI Agent设计的真实浏览器执行层。

最重要的是：BrowserAct 开源、免费！

功能详情

1. 让Agent稳定进入真实网页，不是只发个HTTP请求

Agent读网页最大的问题不是它不会读，是它进不去。curl和web_fetch只能拿静态HTML，碰到JS渲染、动态加载的页面直接哑火。Playwright能启动浏览器，但很多网站对自动化工具有基础的风控，一进去就被限制，什么都干不了。

BrowserAct的思路不一样，它让Agent控制一个真实的浏览器环境，正常加载JS、处理动态渲染、保持登录态。Agent看到的是和人打开浏览器一样的页面，不是一段残缺的HTML源码。

更关键的是，BrowserAct把Agent在网页里做事这件事分成了三层来保证推进：

• • 第一层是工作环境： 给Agent提供一个干净、独立的浏览器实例，每次任务有自己的Cookie、Profile和网络出口，互不污染。
• • 第二层是自动处理： 遇到页面上的常见障碍（动态加载、弹窗、表单验证），Agent能自己处理掉，不用人盯着。
• • 第三层是人工兜底： 碰到短信验证码、企业SSO、硬件UKey这类必须人来的步骤，Agent停下来叫你一声，你处理完它接着跑。

三层组合在一起，Agent在真实网页环境里能把事情推进下去，不用每次遇到一个障碍就整个任务废掉。

2. 卡住时人机接力，但不是说「做不了就报错」，是「叫你一声帮我点一下」

Agent在真实网站里做事，最让人崩溃的不是它不会点按钮，是它遇到验证码就停了，整个任务链断掉。

我以前用Claude Code做网页自动化的时候，每次碰到Cloudflare验证都要自己坐到电脑前手动解决。更难受的是，手动处理完之后，Agent的上下文已经烂了，得重新告诉它做到哪了、刚才干了什么、接下来要干什么。

BrowserAct的remote-assist解决了这个断档问题。Agent执行到需要人工操作的步骤时，发一条命令：

browser-act --session my-task remote-assist --objective "完成短信验证码"

命令返回一个URL，把这个链接发到手机上，打开，直接看到Agent正在操作的浏览器画面。输入验证码，点确认，关掉页面，Agent从刚才的浏览器状态无缝继续。

不需要装任何软件，不需要跟Agent在同一台机器上，不需要VNC、RDP、屏幕共享。跨设备、跨平台，一个链接搞定。

这个设计把「人机协作」变成了一个可操作的CLI命令。它的价值不是让人帮Agent做事，而是让Agent在遇到必须人工处理的步骤时不至于废掉整个工作流。 人的一次操作只是流程里的一个节点，不是断点。

3. 多Session并行，一个Agent就可以管起多个浏览器环境

传统Agent做浏览器自动化有个硬伤：一次只能盯一个浏览器上下文。让Claude Code去查A店铺后台的数据，它就没办法同时盯着B店铺的客服消息，这个不是Agent不会，是工具架构不支持。

BrowserAct的Session模型把这件事解耦了，浏览器管身份，Session管任务。同一个Agent可以同时开着好几个浏览器实例，每个浏览器里跑着独立的Session，互不抢焦点，互不串状态。

我举个例子：

一个Agent开着三个stealth浏览器：浏览器A绑着店铺A的账号和静态代理，Session在导出订单报表；浏览器B绑着店铺B的账号和静态代理，Session在检查客服消息；浏览器C用动态代理临时开了一个Session在巡检竞品价格。三个浏览器、三种身份、三个任务，一个Agent全管了。

Session命名不重名，Agent不会用别人创建的Session，8小时无操作的自动回收。这套机制保证多Agent并发时不会互相踩脚。

4. 两种代理模式，动态+stealth隐私模式 跑量、静态+ stealth 固定身份，多账号长期运营

BrowserAct把代理和隐身浏览器拆成了两种组合，对应两种完全不同的场景。

• • 动态代理 + stealth 隐私模式，适合需要大量数据提取的场景。每次请求自动换IP，任务跑完就走，不留长期身份绑定。临时巡检、地区测试、一次性内容采集，用这个模式。灵活、轻量、用完即弃。
• • 静态代理 + stealth 标准模式，适合需要稳定环境管理的场景。每个账号配一个固定浏览器环境加一个固定IP出口，Agent每次登录都在同一个网络身份下操作。多店铺运营、多社媒账号管理、长期数据看板巡检，用这个模式。身份稳定、登录态保持。

5. Skill Forge，这玩意把跑通的流程锻造成可复用Skill

这是我觉得整个项目里最有想象力的部分。

BrowserAct不只是帮Agent完成一次浏览器任务，它配套了一个叫Skill Forge的工具，能把在某个网站上跑通的流程分析、提炼、打包成一个独立的Skill文件。

Skill Forge做的事不复杂，先摸一遍目标网站的操作流程，看哪些地方能直接调API，哪些地方得走DOM，然后把整个流程打包成一个Agent能直接用的Skill文件。生成之后，Agent再做同类任务直接调Skill，不用每次从头摸索页面结构。

拿Amazon产品页举例：

让Skill Forge分析它的提取流程，探索完生成一个amazon-product-api-skill。以后Agent再需要提取Amazon产品信息，直接调这个Skill，走的是验证过的稳定路径，不用每次重新适应页面布局变化。

更狠的是，BrowserAct的GitHub仓库里已经有一个Solutions Catalog，30多个预置Skill直接能用。覆盖Amazon（产品搜索、评论抓取、竞品分析、Buy Box监控）、淘宝（关键词搜索、商品详情、店铺目录）、Google Maps（商家搜索、评论提取）、YouTube（频道数据、视频字幕、评论分析）、Instagram、TikTok、Reddit、微信、知乎、小红书。

自己做的Skill可以分享给团队成员，我把一个竞品价格监控的Skill做好，同事装上就能用。Skill文件是标准化的Markdown格式，放在GitHub上就能分发。

跟agent-browser比，差异在哪

agent-browser是目前社区里另一个常用的浏览器自动化工具，基础操作（导航、点击、输入、截图、数据提取、JS执行、多Tab、并行Session）两边都支持。但BrowserAct在几个关键维度上甩开了差距：

说白了，agent-browser能做「在普通网页上点点点」这件事，但一旦网页有访问限制、需要登录态、碰到验证码、需要人工介入，它就没办法了。BrowserAct 的差异不在基础点击能力，而在它把 stealth browser、proxy、remote-assist、session ownership、captcha handling 和 Skill 复用放进同一个 Agent 工作流里。

安装与快速上手

装这个东西不需要自己写 Playwright，不需要手动处理 Chrome 路径，也不需要先搭一套复杂的浏览器自动化框架。

最简单的方式，是直接让 Agent 帮你安装 BrowserAct：

Install browser-act. Skill source: https://github.com/browser-act/skills/tree/main/browser-act

装完后， Agent 会自动读取 BrowserAct 的运行时指引：

browser-act get-skills core --skill-version 2.0.2

这一步很重要，普通命令行工具看 --help 就够了，但 BrowserAct 是给 Agent 用的。Agent 需要先知道当前有哪些浏览器、哪些 session 正在运行、哪些操作需要确认、什么时候该接力给人、以及怎么按 open -> state -> interact -> verify -> close 的流程执行。

如果只是想快速跑一个网页任务，可以先用一条 browse 命令验证 Agent 能不能进入真实网页：

browser-act --session my-first-task browse --url "https://www.google.com"

这条命令适合快速验证：Agent 能不能拉起浏览器、访问真实网页，并围绕这个页面继续执行任务。

但 BrowserAct 真正有意思的地方，不只是“打开网页”，而是让 Agent 在一个可管理的浏览器身份里持续做事。

更完整的用法是：先创建或选择一个浏览器身份，再让 Agent 在这个身份下跑任务。

比如你想做一个长期使用的知乎研究浏览器，可以先创建一个专用浏览器：

browser-act browser create --type stealth --name "zhihu-research-demo" --desc "BrowserAct demo browser for recurring Zhihu research workflow"

然后在这个浏览器身份下启动任务：

browser-act --session zhihu-research browse --url "https://www.zhihu.com"

这样 BrowserAct 的模型就清楚了：

• • browser 负责身份： 登录态、Cookie、Profile、代理、指纹环境；
• • session 负责任务： 当前页面、操作步骤、提取内容、任务上下文；
• • remote-assist 负责接力： 遇到扫码、2FA、SSO、验证码时，让人接管一下，Agent 再继续；

典型使用场景

我们经常遇到选题焦虑、或者想要看看目前大家最关注哪些方面的内容，然后再各大平台搜索对比，这个过程非常耗时耗力。

想要交给 Codex 自动化去处理，比如每天在某几个平台找出相关热点问题，但是大多数平台都是孤岛，需要登录等各种操作，我们来对比使用 BrowserAct 的 Codex 和没有这个 skill 的 Codex 在处理这些问题上的差距：

来看对比效果：

首先我们不使用 BrowserAct，直接告诉 Codex 去帮我们在知乎获取一些有热度的提问：

我们等了五六分钟，但是 Codex 已经陷入无意义消耗 token 的局面了，直接结束。这个情况原因很简单，需要看热榜或者其他各种排序，知乎做了登录限制，Codex拉起了内置浏览器去处理，一直是未登录状态，他在一遍一遍自查各种问题，最后还是拉不下来精准数据。

我们再来看看使用 BrowserAct 操作，首先它先尝试不去登录，发现拿不到数据

然后开启人机接力，我选择生成远程控制链接方式，这样可以把链接发给别人协助完成验证。

通过链接完成验证后，很快获取到想要的数据：

这就是上面介绍的人机接力的优势，在卡住时不会一直循环消耗token，最终给出一个错误问题，需要登录或者什么操作，而是在AI操作时，需要人工干预的马上抛出来，辅助后继续执行上下文，完成后关闭拉起的浏览器，一气呵成！

总结

我在GitHub上翻了BrowserAct的issue区和commit记录，团队过去半年一直在推反检测浏览器环境、Session管理、Skill Forge这三个方向，功能拆得干净，代码写得扎实。

它的价值不是「又一个能操作浏览器的工具」，市面上操作浏览器的工具已经够多了。它的价值是把Agent在真实网页里做事这件事拆成了五块：稳定进入、受阻接力、并行隔离、身份管理、流程复用。 五块拼在一起，Agent才能从「能在Demo里点点按钮」进化成「能在真实互联网里把事情推进下去」。

Github地址：

https://github.com/browser-act/skills/tree/main

官网链接：

https://www.browseract.ai/Java