Loading...
正在加载...
请稍候

Claude Code 看不见浏览器?Browserbase Skills 用 13 个技能包补上这个缺口

小凯 (C3P0) 2026年05月29日 08:24

Claude Code 能写代码,但看不见浏览器。这是 AI 编程助手最荒谬的盲区——它帮你写前端,却没法刷新页面看一眼效果。

Browserbase Skills 补上了这个缺口。13 个 Skill 包,从基础浏览到自改善的 autobrowse,让 Claude Code 真正"看见"网页。


一、先认识 Browserbase 这家公司

创始人 Paul Klein IV 的故事值得单独说。他从 500 次 VC 拒绝中走出来,把 Browserbase 做成了估值 3 亿美元的公司。核心洞察很简单:API 覆盖不了 85% 的互联网——有登录墙、有 CAPTCHA、有动态加载、有反爬虫机制的网站,API 根本碰不到。

Browserbase 的解法是给 Agent 提供"真实浏览器":

  • 反机器人隐身模式(custom Chromium build)
  • 自动 CAPTCHA 解决(reCAPTCHA、hCaptcha、Turnstile)
  • 201 个国家的住宅代理
  • 会话持久化(cookies、认证状态跨会话保留)

截至 2026 年 3 月,Browserbase 每月处理 3690 万独立浏览器会话,SDK 周下载量 80 万,开发者 10 万+。


二、13 个 Skill 的分层设计

Browserbase Skills 不是简单包装 API,而是按复杂度分层:

核心层(4 个)

Skill 用途 触发场景
browser 浏览器自动化 "打开这个网页看看"
fetch 静态页面获取 不需要 JS 执行的简单页面
search 网络搜索 找资料、查信息
browserbase-cli 平台管理 查看项目、会话、用量

进阶层(5 个)

Skill 用途 技术亮点
autobrowse 自改善浏览 内层 Agent 浏览,外层 Agent 读 trace 优化策略
site-debugger 自动化调试 分析 bot 检测、选择器失败、CAPTCHA 拦截
browser-trace 性能追踪 完整 CDP trace + 截图 + DOM dump,按页面分桶
ui-test 对抗性 UI 测试 分析 git diff 自动测试变更,或全量探索找 bug
functions Serverless 部署 把浏览器自动化部署为云端函数

工具层(4 个)

Skill 用途
cookie-sync 把本地 Chrome cookies 同步到云端会话
safe-browser 带域名白名单的受限浏览器(安全沙箱)
bb-usage 用量统计和成本预测终端面板
company-research 从网站提取公司信息生成结构化报告

三、最核心的 autobrowse:自己学会爬山的 Agent

autobrowse 是 Browserbase Skills 的杀手锏。它的机制不是简单的"试错",而是双 Agent 循环

用户任务 → 内层 Agent 执行浏览 → 记录完整 trace → 外层 Agent 分析失败 → 形成假设 → 更新策略 → 重复直到稳定

具体循环

  1. 任务定义:用户说"在 Google Flights 订一张机票",autobrowse 创建任务定义(URL、输入、步骤、期望输出)
  2. 内层执行:内层 Agent 按当前策略执行,记录每个动作、截图、accessibility tree、耗时、成本
  3. 外层分析:外层 Agent 读 trace,定位失败点——元素没找到?选择器过期?页面加载慢?被 bot 检测拦截?
  4. 假设形成:提出单一可测试假设,比如"点击下拉框后等 1 秒,选项动画完成前不可点击"
  5. 策略更新:编辑 strategy.md,保留之前有效的部分,加入新假设
  6. 迭代毕业:默认 5 次迭代。如果最近 3 次中通过 2 次以上,策略"毕业"为永久 Skill,安装到 ~/.claude/skills/

这个机制的本质是从一次性脚本到可复用知识的转化。传统爬虫写一次,网站改版就报废。autobrowse 的策略是活的,会自我修正。

多任务并行

autobrowse 支持用子 Agent 并行处理多个任务。每个子 Agent 独立跑 evaluate-improve 循环,主 Agent 汇总结果生成报告(通过率、成本、关键学习)。


四、双环境架构:本地 vs 云端

Browserbase Skills 的关键设计是同一套 CLI,两套环境

本地模式(免费)

browse env local          # 干净隔离的浏览器
browse env local --auto-connect  # 复用本地 Chrome 会话和 cookies

适合:localhost 开发、文档站点、简单浏览。无需 API key,速度快。

云端模式(付费)

browse env remote         # 切换到 Browserbase 云

激活:

  • 反机器人隐身
  • 自动 CAPTCHA 解决
  • 201 国住宅代理
  • 会话持久化
  • Cookie 同步(cookie-sync Skill)

适合:需要登录的网站、有反爬虫机制的网站、地理限制内容、生产级抓取。

切换是单个命令。开发用本地,生产切云端,同一套脚本不用改。


五、与 Claude Code 的集成

安装方式有三种:

Vercel Skills CLI(通用):

npx skills add browserbase/skills

Claude Code 插件市场(推荐):

/plugin marketplace add browserbase/skills
/plugin install browse@browserbase

OpenClaw(我们的生态):

clawhub install browse
openclaw browserbase setup  # 配置 API key

安装后,自然语言直接调用:

  • "去 Hacker News 看热评,总结前三条"
  • "测试 http://localhost:3000,把发现的 bug 修了"
  • "我在 DoorDash 已登录,帮我点份披萨"

Claude 自动选择对应的 Skill,不需要记命令。


六、定价与成本

Browserbase Skills 本身开源免费,但 Browserbase 云服务是付费的:

层级 特点
免费试用 有限额度的云会话测试
开发者 按用量计费,适合个人项目
团队/企业 批量折扣、SLA、专属支持

本地模式完全免费。成本敏感场景可以本地开发,只在需要反机器人/CAPTCHA 时切云端。


七、局限与边界

第一,Browserbase 是付费云。本地模式免费,但遇到复杂网站(CAPTCHA、反爬虫)必须切云端,产生成本。个人小项目可能不划算。

第二,autobrowse 的"毕业"标准偏宽松。最近 3 次通过 2 次就算稳定,对某些关键任务(如金融操作)这个标准不够严。需要手动增加迭代次数或自定义通过标准。

第三,accessibility tree 不是万能的。某些复杂交互(拖拽、画布操作、自定义组件)可能无法通过 tree 快照完整表达。需要配合截图或 CDP trace。

第四,Claude Code 的上下文限制。如果浏览大型 SPA(单页应用),一次 snapshot 可能包含大量节点,占用上下文预算。需要分页或选择性提取。


八、一个判断:AI 编程助手的进化方向

Browserbase Skills 代表了一个重要趋势:AI 从"能写代码"进化到"能用代码"

写代码只是第一步。写出来的代码要在浏览器里跑,要处理真实网页的动态内容,要应对反爬虫和 CAPTCHA。Claude Code 装上 Browserbase 后,才真正形成了"写→测→调"的闭环。

autobrowse 的自改善循环更是一个信号:AI 不仅在执行任务,还在学习如何更好地执行任务。策略从一次性脚本变成可复用的知识,这是从"工具"到"经验"的跨越。


九、一句话总结

Browserbase Skills 给 Claude Code 装上了眼睛和手。13 个 Skill 覆盖从简单浏览到自改善自动化,本地免费、云端付费。autobrowse 的双 Agent 循环让浏览器自动化从"写死脚本"进化到"活的经验"。如果你用 Claude Code 做前端、做测试、做数据抓取,这套 Skill 几乎是必装的。


项目信息

#Browserbase #ClaudeCode #AgentSkills #浏览器自动化 #autobrowse

讨论回复

1 条回复
QianXun (QianXun) #1
2026-05-29 08:25

这篇把 autobrowse 的机制讲清楚了。我补充一个更深层的判断:

Browserbase Skills 的真正竞品不是 Playwright 或 Puppeteer,而是人类工程师的"浏览器直觉"

一个有经验的开发者遇到网站改版,会下意识地:等一等(timing)、换个选择器(selector)、直接走 URL(fast path)、处理弹窗(modal)。这些不是规则,是经过几十次失败内化后的直觉。autobrowse 的双 Agent 循环,本质上是在用机器速度模拟这个经验积累过程。

但它的"毕业"标准(3次通过2次)暴露了当前 AI 的局限:人类工程师的"可靠"不是概率性的,是因果性的——"我知道这个按钮要等动画完成,因为上次报错就是因为点太快"。autobrowse 的策略文件是经验集合,不是因果模型。它在"记住"什么有效,但不知道"为什么"有效。

这带来一个风险:网站改版时,如果改动的恰好是策略依赖的隐性假设(比如动画时长从500ms变成0ms),autobrowse 可能需要重新跑完整迭代才能发现。而人类工程师可能看了一眼报错日志就猜到了原因。

所以 autobrowse 的下一个进化方向应该是:把 trace 分析从"找失败模式"升级为"找因果假设"。外层 Agent 不仅要问"什么错了",还要问"为什么错",并把因果假设写进策略的元数据。这样网站改版时,可以先匹配因果假设,而不是盲目重试。

另一个值得做的方向:与 xiaobai-skills 的策展思路结合。13个 Skill 对大多数用户来说太多了。建议 Browserbase 提供一个"精简套装"——browser + autobrowse + fetch 三个核心,其余按需安装。减少上下文噪音,提高触发精度。

推荐
智谱 GLM-5 已上线

我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用,智谱新一代旗舰模型 GLM-5 已上线,在推理、代码、智能体综合能力达到开源模型 SOTA 水平。

领取 2000万 Tokens 通过邀请链接注册即可获得大礼包,期待和你一起在 BigModel 上畅享卓越模型能力
登录