Browserbase Skills：让 Claude Code 具备浏览器自动化能力的开源框架

最近，Browserbase 开源了一个值得关注的项目：Browserbase Skills。

开源地址：

https://github.com/browserbase/skills

这个项目面向的是 Claude Code 这类 AI Coding Agent。它的核心目标不是让模型简单“看网页”，而是让模型能够通过 Browserbase、浏览器自动化能力和相关 CLI 工具，在真实网页环境中完成任务。

这件事值得测试开发、前端工程、AI Agent 工程方向的人重点关注。

因为它背后代表的趋势是：

AI Agent 正在从“文本生成能力”，进入“真实系统操作能力”。

过去我们说 AI 能“上网”，很多时候指的是搜索、读取、总结。

但真实网页不是静态文档。

它有登录态、按钮、弹窗、表单、异步加载、前端路由、权限校验和各种交互状态。

所以，真正难的不是让 AI “看到网页”，而是让 AI 能够像用户一样进入网页系统，完成一个具体任务。

Browserbase Skills 的价值，就在这里。

它不是简单给 Claude Code 加一个“联网搜索”能力，而是把浏览器操作、页面抓取、搜索、UI 测试、调试追踪、安全边界等能力，封装成 Claude Code 可以调用的 Skills。

换句话说，它解决的是一个更工程化的问题：

如何让 AI Agent 不只是理解网页，而是能进入真实网页环境完成任务。

目录

1. Browserbase Skills 是什么

2. 它和普通网页搜索有什么区别

3. 为什么 Agent 一定需要浏览器能力

4. Browserbase Skills 的核心能力拆解

5. 它和 Playwright、Selenium 的关系

6. Agent 浏览器自动化的工程架构

7. 企业落地时必须关注的风险边界

8. 对测试开发人员意味着什么

9. AI Agent 正在进入真实操作层

01 Browserbase Skills 是什么

Browserbase Skills 可以理解为一组面向 Claude Code 的浏览器自动化技能包。

它把网页相关能力拆成多个 Skill，例如：

从这个设计可以看出来，它不是一个单点工具，而是一套围绕 Agent 浏览器操作的工程化能力组合。

它解决的问题不是：

AI 怎么搜索网页？

而是：

AI 怎么在真实网页里完成一个可追踪、可调试、可约束的任务？

这也是 Browserbase Skills 值得关注的核心原因。

很多 AI 工具都在强调“会联网”“会搜索”“会总结”，但这些能力更多还停留在信息获取层。

而 Browserbase Skills 更进一步，它把 Agent 带到了网页操作层。

这意味着 Claude Code 这类工具不再只是根据代码和文档给建议，而是可以进入网页页面，结合真实运行状态完成验证、调试、测试和分析。

02 它和普通网页搜索有什么区别

很多人看到“Claude 能浏览网页”，第一反应可能是： 这不就是联网搜索吗？

其实不是。

网页搜索主要解决的是信息获取问题：

搜索关键词 → 获取结果 → 总结内容

但浏览器自动化解决的是任务执行问题：

打开页面 → 登录系统 → 点击按钮 → 填写表单 → 触发交互 → 观察结果 → 生成报告

这两者的能力边界完全不同。

举个例子。

如果你让 AI 分析一个招聘网站上的测试开发岗位要求。

普通搜索只能做到：

• 找到相关网页

• 读取岗位描述

• 总结技能关键词

但浏览器自动化可以做到：

• 打开招聘网站

• 输入岗位关键词

• 筛选城市、经验、薪资

• 翻页读取多个岗位

• 对 JD 进行分类

• 汇总能力模型

• 输出岗位画像报告

再举一个更贴近研发和测试的例子。

如果你让 AI 检查一个后台管理系统的新增用户功能。

普通搜索没有意义，因为这个页面可能是内网系统，也可能需要登录态。

但浏览器自动化可以进入页面：

• 打开本地服务或测试环境

• 登录后台系统

• 点击用户管理菜单

• 填写新增用户表单

• 输入异常数据

• 观察前端提示

• 检查控制台报错

• 截图并生成 Bug 复现步骤

这就是从“读网页”到“操作网页”的区别。

搜索是获取信息。 浏览器自动化是完成任务。

03 为什么 Agent 一定需要浏览器能力

Agent 要真正进入业务工作流，绕不开浏览器。

因为大量企业系统都运行在 Web 页面里：

• OA 系统

• CRM 系统

• ERP 系统

• 测试平台

• 工单系统

• 数据看板

• 招聘系统

• 电商后台

• SaaS 管理后台

• 云厂商控制台

这些系统不一定都有开放 API。

即使有 API，也不一定对普通用户开放。

但网页界面几乎一定存在。

所以浏览器就成了 Agent 接入真实系统的通用入口。

这也是 Browserbase Skills 这类项目值得关注的原因。

它不是单纯让模型会“上网”，而是让模型能够进入网页系统，完成接近真实用户行为的操作。

过去的 Agent 更多停留在文本和代码层：

读需求 → 写代码 → 生成说明 → 输出建议

但真实软件工程不只需要写代码，还需要验证代码。

尤其是前端、后台管理系统、业务流程类系统，很多问题只有进入页面才能发现。

例如：

• 按钮是否能点击

• 表单校验是否正确

• 接口异常是否有提示

• 页面布局是否错位

• 权限控制是否生效

• 前端路由是否跳转正常

• 控制台是否有 JavaScript 报错

• 网络请求是否返回异常状态码

这些问题不是靠模型“想一想”就能判断的。

必须进入真实环境，执行真实操作，观察真实反馈。

这就是浏览器能力对 Agent 的意义。

04 Browserbase Skills 的核心能力拆解

从工程角度看，Browserbase Skills 至少包含四层能力。

第一层：信息获取能力

对应fetch和search。

这类任务不一定需要打开完整浏览器。

如果页面内容比较静态，直接抓取 HTML、JSON 或 Header，效率更高，成本也更低。

适合场景包括：

• 读取文档

• 获取页面标题

• 分析接口返回

• 抓取结构化内容

• 判断页面状态码

• 快速获取网页元信息

这一层能力解决的是“轻量读取”问题。

不是所有任务都需要打开浏览器。

如果只是读取一个文档页面、接口响应或者网页正文，直接 fetch 会比启动浏览器更快。

这体现了 Browserbase Skills 的一个重要设计思路：

不同任务应该使用不同能力，而不是所有问题都交给浏览器。

第二层：真实浏览器交互能力

对应browser。

这类能力用于处理真实页面交互，例如：

• 点击按钮

• 填写表单

• 上传文件

• 页面跳转

• 处理弹窗

• 截图

• 读取 DOM

• 等待异步加载

• 观察页面状态变化

这一层能力的关键在于： 它不是单纯“看页面”，而是可以模拟真实用户路径。

真实网页里的很多问题，只有交互后才会出现。

比如点击按钮后才弹出错误提示，提交表单后才触发接口请求，切换 Tab 后才加载数据，打开弹窗后才渲染组件。

如果 Agent 只能读取页面文本，它很难发现这些问题。

但如果 Agent 能操作浏览器，它就可以真正进入业务流程。

第三层：测试与调试能力

对应ui-test、site-debugger、browser-trace。

这部分对测试开发人员尤其重要。

因为浏览器自动化最常见的问题不是“不能操作”，而是：

• 为什么点不到元素？

• 为什么页面没有加载完成？

• 为什么登录态失效？

• 为什么本地能跑，云端不能跑？

• 为什么 Agent 判断错了页面状态？

• 为什么按钮文本变了，自动化就失败？

• 为什么接口返回了，但页面没有更新？

• 为什么截图和 DOM 状态不一致？

这些问题都需要调试能力。

browser-trace这类 Skill 的价值就在于，它可以把 Agent 的浏览器行为记录下来，让执行过程可观察、可复盘。

对测试来说，这非常关键。

因为自动化测试失败后，最怕的不是失败，而是不知道为什么失败。

一个可用的 Agent 浏览器系统，不能只是告诉你：

任务失败了

它还应该告诉你：

失败发生在哪一步？ 当时页面长什么样？ DOM 结构是什么？ 控制台有没有报错？ 网络请求有没有异常？ Agent 点击的是不是正确元素？

只有这些信息完整，失败才有分析价值。

第四层：安全与边界控制能力

对应safe-browser。

只要 Agent 能操作浏览器，就必须考虑安全边界。

否则它可能访问错误页面、提交错误数据，甚至在真实业务系统里执行高风险操作。

所以 Agent 浏览器自动化不能只强调“能干活”，还要强调：

• 能访问哪些域名

• 能不能提交表单

• 能不能执行删除动作

• 能不能触发支付类操作

• 能不能修改生产配置

• 是否需要人工确认

• 是否记录操作轨迹

这也是企业落地 Agent 时必须补齐的一层能力。

真正的企业级 Agent，不是“什么都能干”，而是：

知道自己能干什么、不能干什么，并且每一步都能被追踪。

05 从测试开发视角看 UI Test Skill 的价值

如果从测试开发角度看，Browserbase Skills 最值得关注的是ui-test。

因为它对应的是一个非常现实的问题：

AI 生成代码越来越快，但谁来验证这些代码真的能跑？

过去的前端开发流程通常是：

AI Coding 进入之后，流程可能会变成：

这里的关键变化是：

测试不再只是写用例，而是成为 Agent 工作流里的反馈闭环。

未来一个 Agent 可能会完成这样的流程：

读取需求 → 修改代码 → 启动服务 → 打开页面 → 执行核心路径 → 发现问题 → 截图留证 → 修改代码 → 再次验证

这对测试开发岗位影响很大。

测试人员的价值不会消失，但能力重心会变化。

过去很多测试工作强调：

• 写用例

• 执行用例

• 提交 Bug

• 回归验证

未来更重要的是：

• 定义验证目标

• 设计测试策略

• 构建测试环境

• 管理测试数据

• 控制 Agent 权限

• 设计失败诊断机制

• 判断 Agent 输出是否可信

也就是说，测试人员不只是执行者，而是 Agent 质量闭环的设计者。

06 它和 Playwright、Selenium 的关系

Browserbase Skills 不是要替代 Playwright 或 Selenium。

这几个工具所处的层级不一样。

Playwright 解决的是浏览器自动化能力。

Browserbase Skills 解决的是 Agent 如何使用这些能力。

所以更准确的理解是：

Browserbase Skills 是把浏览器自动化能力包装成 Agent 可调用的工程技能。

这对测试开发人员的启发是：

未来不是“不需要学自动化测试”，而是更需要理解自动化测试如何被 Agent 调用、组合和治理。

如果只会写固定脚本，确实容易被 AI 提效工具冲击。

但如果你理解：

• 浏览器自动化底层机制

• DOM 与选择器稳定性

• 等待机制与异步加载

• 网络请求与控制台日志

• 测试数据准备

• 页面状态判断

• 自动化失败归因

• Agent 工具调用逻辑

那么你反而会更容易把 AI 工具用起来。

AI 会降低写脚本的门槛，但不会降低质量工程的复杂度。

07 Agent 浏览器自动化的工程架构

可以把 Browserbase Skills 放到一个 Agent 工作流里理解：

这个架构有一个明显特点：

Agent 不只是调用浏览器，还会把浏览器执行过程转成可分析的数据。

这对测试和质量工程非常关键。

因为自动化执行结果不能只看“成功”或“失败”，还要知道：

• 页面当时是什么状态

• 失败发生在哪一步

• 控制台有没有报错

• 网络请求有没有异常

• DOM 是否发生变化

• Agent 是否操作了正确元素

• 页面截图和判断结果是否一致

• 是否存在误判或漏判

这些信息才是定位问题的依据。

从这个角度看，Browserbase Skills 不是简单的“网页操作工具”，而是把浏览器自动化放进了 Agent 工作流里。

它让 Agent 的行为从黑盒变得更接近白盒。

这对企业落地非常重要。

08 企业落地时必须关注的风险边界

浏览器 Agent 能力越强，风险也越大。

尤其是在企业系统里，不能只关注“能不能自动操作”，还要关注“能不能安全操作”。

至少要考虑五类风险。

1. 访问边界

Agent 能访问哪些域名？

是否只能访问测试环境？

是否禁止访问生产后台？

是否需要限制在指定系统内操作？

比如一个用于 UI 测试的 Agent，理论上只应该访问测试环境，而不应该访问生产管理后台。

2. 操作边界

Agent 能不能提交表单？

能不能删除数据？

能不能修改配置？

能不能触发审批、支付、发货、发布等高风险动作？

如果没有操作边界，Agent 很容易从“辅助工具”变成“风险入口”。

尤其是涉及真实业务数据时，必须有明确限制。

3. 数据边界

Agent 是否会读取敏感信息？

日志里是否会保留账号、Cookie、Token、用户数据？

截图里是否包含隐私信息？

Trace 记录是否需要脱敏？

很多团队做自动化测试时，只关注执行结果，却忽略了日志和截图里的敏感信息。

到了 Agent 时代，这个问题会更明显。

因为 Agent 会读取、分析、记录更多上下文。

4. 审计边界

Agent 每一步操作是否有记录？

失败时能不能复盘？

异常操作能不能追踪？

是否能知道它点击了哪个按钮、输入了什么内容、访问了哪个页面？

没有审计能力，Agent 就很难进入严肃业务场景。

因为出了问题之后，团队无法判断问题来自：

• 模型理解错误

• 页面状态异常

• 自动化脚本失败

• 测试数据问题

• 权限配置问题

• 业务逻辑本身缺陷

5. 人工确认边界

涉及高风险动作时，是否需要人确认？

例如：

• 删除数据

• 提交审批

• 发布配置

• 执行付款

• 发送邮件

• 修改生产环境参数

这些动作不能完全交给 Agent 自动完成。

更合理的方式是：

Agent 分析并准备操作 → 人工确认 → Agent 执行 → 记录审计日志

这也是为什么safe-browser、browser-trace、site-debugger这些能力非常重要。

真正可落地的 Agent 系统，不是让 AI 无限制操作，而是要让 AI 在规则范围内稳定工作。

09 对测试开发人员意味着什么

Browserbase Skills 这种项目，对测试开发人员有三个直接启发。

第一，自动化测试会从脚本驱动走向 Agent 驱动

过去自动化测试主要依赖人写固定脚本：

打开页面 → 点击按钮 → 输入内容 → 提交 → 断言结果

Agent 驱动的测试更像是：

请验证这个订单页面的核心流程是否正常，并输出问题报告

Agent 会自己规划路径、操作页面、记录结果。

这不代表脚本没用了。

而是脚本会逐渐变成 Agent 生成、维护、执行和优化的对象。

测试人员要关注的，也不只是脚本本身，而是整个验证链路是否可靠。

第二，测试平台需要接入 Agent 工作流

未来测试平台可能不只是管理用例和报告，还要管理：

• Agent 技能

• 浏览器执行环境

• 测试账号

• 测试数据

• 执行轨迹

• 截图证据

• 失败归因

• 自动修复建议

• 人工审核节点

也就是说，测试平台会从“自动化执行平台”，升级为“AI 质量工程平台”。

以前测试平台重点解决的是：

用例怎么管理？ 任务怎么调度？ 报告怎么生成？

以后还要解决：

Agent 能做什么？ Agent 怎么做？ Agent 做错了怎么发现？ Agent 结果是否可信？ Agent 操作是否安全？

这会带来一批新的测试平台建设方向。

第三，测试开发能力模型会发生变化

AI 时代的测试开发，不只是会写自动化脚本。

更重要的是：

未来测试人员的价值，不是和 AI 比谁点得快、谁写脚本快。

而是要设计一套让 AI 可以稳定参与质量保障的工程体系。

这也是为什么现在测试开发人员更应该关注 Agent、浏览器自动化、AI 测试平台和质量工程。

AI 不是让测试消失，而是让低质量、重复性的测试方式被重构。

真正有价值的测试能力，会从执行层往设计层、平台层、治理层迁移。

10 总结：AI Agent 正在进入真实操作层

Browserbase Skills 开源，表面上是给 Claude Code 增加浏览器自动化能力。

但从技术趋势看，它代表的是 Agent 能力边界的一次扩展。

过去大模型主要停留在：

理解文本 → 生成内容 → 生成代码

现在它开始进入：

打开系统 → 操作页面 → 执行任务 → 记录过程 → 反馈结果

这就是从“文本智能”到“操作智能”的变化。

对开发者来说，它意味着 AI Coding 不再只是生成代码，而是可能逐步进入验证、调试、回归和部署前检查。

对测试开发人员来说，它意味着自动化测试正在进入新的阶段：

不是简单把脚本交给 AI 写，而是把测试过程变成 Agent 可以执行、可以观察、可以审计的工程闭环。

Browserbase Skills 值得关注，不是因为它让 Claude 会打开网页，而是因为它把浏览器自动化、Agent 技能、测试验证和安全边界放到了一套工程体系里。

未来，AI Agent 会越来越多地进入真实业务系统。

但越是进入真实系统，越需要质量工程能力兜底。

因为真正重要的问题不是：

AI 能不能点按钮？

而是：

AI 为什么点这个按钮？ 点完之后结果是否正确？ 失败了能不能定位？ 操作过程能不能追踪？ 风险边界能不能控制？

这才是 AI Agent 落地企业系统时必须回答的问题。

Browserbase Skills 这类项目，值得测试开发、前端工程和 Agent 工程方向持续关注。

它提醒我们：

AI 测试的下一个战场，已经从“生成用例”走向“操作系统”。