BrowserAct Skills：AI Agent 的浏览器自动化技能库

前言

BrowserAct Logo

如果说传统浏览器自动化工具主要服务“人写脚本”，那 BrowserAct 的定位更明确：它服务的是 AI Agent。

它不是简单把 Playwright、Puppeteer 的能力再包一层，而是围绕 Agent 的真实工作方式重做了一套浏览器操作接口：页面状态要能被模型低成本理解，点击和输入要能用索引完成，多账号并行不能互相污染，遇到验证码和真人校验时也要能逐级升级。

换句话说，BrowserAct 想解决的不是“怎么打开一个网页”，而是：

当 Agent 需要长期、并发、可恢复地操作真实网页时，浏览器应该长什么样？

本文整理自 browser-act/skills 仓库当前 main 分支。

这个项目到底是什么

BrowserAct Skills 仓库主要包含两类内容。

第一类是 browser-act 入口 Skill。它把 BrowserAct CLI 暴露给 Claude Code、Cursor、OpenClaw、Codex、Gemini CLI 等可以执行 shell 命令并加载 Skill 的 Agent。Agent 在执行浏览器任务前，会先运行：

class="language-bash">browser-act get-skills core --skill-version 2.0.2

这一步不是普通帮助文档，而是运行时说明：它会返回环境状态、浏览器列表、命令规则、会话约束和安全提示。BrowserAct 的文档特别强调，Agent 不应该跳过这一步。

第二类是 browser-act-skill-forge。它不是一次性抓网页的工具，而是“技能生成器”：让 Agent 先探索一个网站的 API 或 DOM 结构，再生成可复用的 SKILL.md + scripts 包。以后同类任务不必重新探索，直接调用生成后的 Skill。

仓库里还放了一个 Solutions Catalog，也就是已经由 Skill Forge 生成好的预置技能目录。按当前 README 统计，它覆盖了 78 个方案，主要分布在电商、获客、搜索研究、社媒监听和视频平台几个方向。

为什么 AI Agent 需要专门的浏览器

README 里给出的判断很直接：Agent 需要的浏览器，和人类写自动化脚本需要的浏览器不完全一样。

人写脚本时，通常关心选择器、DOM、网络请求、浏览器驱动和异常重试。Agent 操作网页时，问题会变成另一组：

•页面状态能不能用很少的 token 看懂？

•Agent 能不能不用 XPath 和 CSS selector，也能点击正确元素？

•多个 Agent 同时执行任务时，会不会抢同一个浏览器状态？

•已登录账号、指纹、IP、cookie 能不能隔离？

•遇到反爬、验证码、登录校验时，能否自动处理，或交给人接管？

•一次探索出的网页结构，能否沉淀成下一次可复用的 Skill？

BrowserAct 的设计几乎都围绕这些问题展开。

核心能力一：三层反封锁体系

BrowserAct 把反封锁能力分成三层：环境层、执行层、人工层。

环境层的目标是尽量让验证不要触发。它包含浏览器指纹伪装、TLS 指纹轮换、代理切换、隐私模式、headless 隐藏等能力。README 的说法是，大多数阻断应该在这一层被吸收掉。

执行层处理已经触发的验证。例如：

class="language-bash">browser-act --session s1 solve-captcha

以及更偏读取场景的：

class="language-bash">browser-act stealth-extract https://example.com

stealth-extract 可以理解成更强的 WebFetch 替代：给它一个 URL，它启动具备反检测能力的浏览器，等待 JS 渲染，返回 Markdown 或 HTML，然后关闭临时上下文。它不要求你管理浏览器实例和 session。

人工层用于自动化解决不了的情况。remote-assist 会生成一个远程接管链接，用户可以从任意设备打开，手动处理登录、验证码或复杂交互；处理完之后，Agent 再继续执行。

这个设计的重点不是“无脑绕过所有限制”，而是分层升级：普通任务先用普通浏览器，触发反爬再切 stealth，需要验证码再尝试自动处理，自动处理失败才交给人。

核心能力二：三种浏览器模式

BrowserAct 的浏览器模式不是按技术名词堆出来的，而是按真实使用场景切分。

第一种是 chrome。它适合复用本地 Chrome 登录态，比如 Gmail、GitHub、Jira 或企业内部系统。它有两种子模式：一种是导入本地 Profile，把 cookies、localStorage、IndexedDB 等复制到独立 Chromium 实例；另一种是 chrome-direct，通过 CDP 直接接管正在运行的本地 Chrome。

第二种是 stealth 隐私模式。它适合不需要登录的批量采集任务。每个 session 都使用新的指纹和空 profile，结合动态代理，可以减少状态残留和指纹积累。

第三种是 stealth 固定身份。它适合长期登录、多账号并行和多店铺运营。每个浏览器拥有稳定指纹、稳定 IP、独立 cookies 和独立登录状态，让不同账号之间不互相污染。

这背后的架构判断很重要：浏览器就是身份，session 是工作空间。

一个浏览器可以承载多个 session，同一浏览器下的 session 共享登录态，但执行互相独立；不同浏览器则拥有独立 cookies、指纹、代理和 profile。

核心能力三：零干扰并发

在普通自动化里，并发经常只是“开多个页面”。BrowserAct 更强调并发时的身份隔离。

它提供三种并发模型。

•跨浏览器并行：每个浏览器都是独立身份，适合多账号、多店铺、多身份任务。

•同浏览器多 session：共享同一账号登录态，但任务各跑各的，适合同一账号下的多个子任务。

•隐私模式零残留：每次从空 profile 和新指纹开始，适合一次性采集。

session 名称必须显式指定，而且在并发环境中需要全局唯一。这样做看似麻烦，但对多 Agent 协作很关键：它让每个会话都有明确所有权，避免不同 Agent 抢同一页面、误点同一账号、复用别人留下的临时上下文。

核心能力四：为模型推理设计的交互接口

BrowserAct 最有意思的地方，是它没有把网页状态直接丢给模型做 DOM 解析。

它提供的是紧凑的索引化文本输出。state 返回当前页面中可交互元素的索引，Agent 可以直接用：

class="language-bash">browser-act --session login input 2 "user6a9955">#c586c0">@example.com"
browser-act --session login click 4

这对 LLM 很友好。模型不需要猜 CSS selector，也不需要从大段 HTML 中寻找按钮。它只需要看见 [2] 是邮箱输入框、[4] 是提交按钮，然后按索引操作。

页面变化之后，旧索引会失效，所以需要重新运行 state 获取新状态。这个循环在 Quick Start 中被概括为：

class="language-text">Open → State → Interact → State → ... → Close

这也是 BrowserAct 和传统脚本型自动化的关键差异：它的接口首先服务“模型如何行动”，而不是“程序员如何写选择器”。

核心能力五：desc 语义记忆

每个浏览器都有一个 desc 字段，用自然语言描述它的用途。例如：

class="language-text">Taobao shopping account, logged in as user123. Used for price monitoring.

Agent 在新对话中不必记住某个浏览器 ID，而是按语义匹配任务。比如用户说“检查淘宝价格”，Agent 可以从浏览器列表中找到描述里最匹配的 Taobao 浏览器。

官方文档给出的选择优先级是：

•如果 desc 明确匹配任务，就直接使用。

•如果只有一个浏览器，就直接使用。

•如果多个浏览器都不明确，就列出候选让用户选择。

完成新任务后，Agent 还可以用 --desc-append 补充描述，让这个浏览器的用途记忆越来越完整。

Skill Forge：把一次探索变成长期复用

如果只是偶尔读一个页面，stealth-extract 就够了。如果要长期抓同一个网站、批量跑几百个关键词、每天监控库存或价格，BrowserAct 推荐使用 Skill Forge。

Skill Forge 的核心思想是：探索一次，复用很多次。

它的流程可以拆成四步：

•Describe：用自然语言描述你要的数据或操作。

•Explore：优先探索 API，找不到稳定 API 再 fallback 到 DOM。

•Generate：把业务参数变成命令行参数，生成 SKILL.md 和脚本。

•Self-Test：用子 Agent 做端到端测试，不通过就修复。

例如你可以告诉 Agent：

class="language-text">Forge a Skill that extracts job listings from LinkedIn: title, company, salary, URL.
I'll run 300 keywords later.

Skill Forge 会先探索 LinkedIn 的数据加载方式，再沉淀成可部署的 Skill。之后你要跑 300 个关键词，不需要让 Agent 每次重新摸索页面结构。

这类模式对团队尤其有价值：工程师不必为每个采集需求手写 scraper，而是维护一套“让 Agent 自助生成 Skill”的平台能力。

Solutions Catalog：已经准备好的 78 个方案

仓库的 solutions/README.md 提供了已经生成好的预置技能目录。按当前快照，主要包括五类。

电商类有 19 个，例如 Amazon 商品详情、搜索结果、评论、Buy Box 监控、竞品分析，以及淘宝、闲鱼、通用电商 listing、商品详情和评论提取。

获客类有 13 个，例如 Google Maps 商户数据、联系方式提取、LinkedIn 职位、Indeed 职位、YouTube 频道商业邮箱、GitHub 贡献者联系方式、Product Hunt 榜单等。

搜索与研究类有 6 个，例如 Google 搜索结果、新闻、图片、网页研究助手、深度爬取和通用网页 Markdown 提取。

社媒监听类有 26 个，覆盖 Facebook Ads Library、Facebook 群组和主页、Instagram、Reddit、Trustpilot、微信公众号文章搜索、X/Twitter、小红书、知乎等。

视频平台类有 14 个，覆盖 TikTok、YouTube 搜索、频道、评论、转录、视频详情和竞品分析。

这部分说明 BrowserAct 不只是底层 CLI，它还在尝试建立一个“浏览器自动化 Skill 市场”：通用底座 + 自动生成器 + 预置方案。

安装与快速开始

官方推荐方式是让你的 AI Agent 安装：

class="language-text">Install browser-act.
Skill source: https://github.com/browser-act/skills/tree/main/browser-act .
Verify it works after installation.

手动安装 CLI 的命令是：

class="language-bash">uv tool install browser-act-cli --python 3.12
browser-act --version

如果要使用 stealth 浏览器、stealth-extract、动态代理或 solve-captcha，需要配置 API Key：

class="language-bash">browser-act auth login
browser-act auth poll

或者直接设置：

class="language-bash">browser-act auth set <your-api-key>

普通 chrome 和 chrome-direct 模式不要求认证；高级 stealth、代理和验证码能力则依赖 BrowserAct 的托管服务。

安全边界：能力强，但不是无约束

BrowserAct 在 README 和 docs 中反复强调 confirmation gating，也就是敏感操作必须经过明确确认。

需要确认的操作包括：

•创建或删除浏览器。

•导入本地 Profile。

•修改代理配置。

•修改隐私模式。

•修改安全确认开关。

•对标记为 confirm_before_use 的浏览器执行打开操作。

这不是 CLI 层面的绝对硬阻断，而是 Skill 层面的对话协议：Agent 必须先说明它要做什么、会影响哪些状态、为什么需要做，然后等待用户明确同意。

这点很重要。让 Agent 控制真实浏览器，本质上是在赋予它访问账号、页面、表单、文件上传、网络请求和登录态的能力。BrowserAct 的安全策略不是假装风险不存在，而是让每一个高风险动作都被人类看见。

另外，文档中也说明了数据隐私边界：cookies、登录 session、页面内容、截图、网络捕获、浏览器 profile 都保存在本地；唯一例外是调用 solve-captcha 时，会把验证码挑战图片发送到 BrowserAct 云服务，但不上传 cookies、页面内容或 URL。

适合什么场景

BrowserAct 比较适合这几类任务。

第一类是 Agent 需要读取 JS 渲染页面、反爬页面或地理限制页面。此时 stealth-extract 可以作为增强版 WebFetch。

第二类是需要真实登录态的网页操作，比如内部系统、后台管理、企业 SSO、GitHub、Jira、Gmail 等。这类任务可以用 chrome Profile 导入或 chrome-direct 接管本地 Chrome。

第三类是多账号并行，例如多店铺运营、竞品监控、社媒账号管理、商户数据采集。此时浏览器身份隔离比单纯开多标签页更重要。

第四类是重复性网页采集或操作。一次性任务用 browser-act，长期批量任务用 Skill Forge 生成可复用 Skill。

第五类是需要 Agent 和人协作的复杂流程。自动化走到验证码、风控、登录校验时，可以通过 remote assist 交给人处理，再让 Agent 接着跑。

不适合什么场景

它也不是所有场景的最佳答案。

如果目标站点已经提供稳定 API，优先用官方 API，KISS 原则更强：更简单、更可维护、更不容易触碰平台边界。

如果只是一次普通静态网页读取，curl、requests 或普通 WebFetch 足够，没必要启动完整浏览器环境，YAGNI 原则要求我们不要为了“看起来强”而引入重工具。

如果任务涉及敏感账号、支付、隐私数据或可能违反目标网站条款的操作，应先确认授权和合规边界。BrowserAct 提供能力，不等于所有能力都应该被使用。

如果团队已经有成熟的数据采集平台，BrowserAct 更适合作为 Agent 入口层或补充探索工具，而不是直接替换全部生产采集链路。

工程原则观察

从 KISS 看，BrowserAct 的索引化交互很值得借鉴。它没有让 Agent 解析整棵 DOM，而是把可操作元素压缩成模型更容易理解的文本索引，降低了行动复杂度。

从 YAGNI 看，项目把一次性读取、完整浏览器操作、长期 Skill 生成分成不同路径。只读页面用 stealth-extract，需要交互才创建 session，需要重复规模化才上 Skill Forge，这种分层避免了所有任务都走重流程。

从 SOLID 看，browser-act 入口 Skill、CLI 浏览器能力、Skill Forge 生成器、Solutions Catalog 各自职责清晰。底座负责“能操作浏览器”，Forge 负责“把操作沉淀为 Skill”，Solutions 负责“可直接安装的场景模板”。

从 DRY 看，Skill Forge 的价值就是减少重复探索。一个网站的 API 路径、参数、分页、字段映射一旦验证，就沉淀进脚本和 SKILL.md，而不是每次都让 Agent 重新观察页面。

潜在风险也在这里：如果生成的 Skill 没有良好的测试、版本记录和失败处理，它会把“重复探索成本”变成“重复维护成本”。所以 Skill Forge 的自测、自修复和重新探索机制，是它能不能长期成立的关键。

一个判断

BrowserAct Skills 的真正价值，不只是“让 Agent 打开浏览器”，而是把浏览器拆成了 Agent 能理解、能选择、能隔离、能复用的几个层次。

对个人开发者，它像一个增强版浏览器工具箱：遇到 WebFetch 抓不到、普通脚本不好写、登录态难复用的网页，可以把 Agent 接进真实浏览器。

对团队来说，它更像一个浏览器自动化能力平台：底层运行时负责身份和会话，Skill Forge 负责把探索过程产品化，Solutions Catalog 则提供可直接复用的场景入口。

如果未来 Agent 真的要承担更多网页侧工作，类似 BrowserAct 这种“面向模型设计浏览器接口”的项目会越来越重要。因为 Agent 不缺“能点网页”的能力，缺的是在真实网页世界里稳定、可控、可复用地完成任务。

声明

本文由山行整理自：browser-act/skills GitHub 仓库[1]，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～

参考链接

[1] browser-act/skills GitHub 仓库: https://github.com/browser-act/skills