bb-browser，更像一层给 AI Agent 用的真实浏览器接口

DreamWear
6 阅读10分钟

bb-browser，更像一层给 AI Agent 用的真实浏览器接口

这几个月看各种 Agent 工具，我越来越有一种感觉：大家补的其实是同一个洞。

模型会推理，会规划，厉害一点的还会现场写代码。但只要任务落到真实网站上，老问题马上全回来了：没有 API、登录态麻烦、反爬严格、页面逻辑埋得很深。很多 Agent 不是不会想，而是最后根本碰不到真实互联网。

bb-browser 走的是另一条路。既然互联网本来就是给浏览器用的，那就别再要求网站额外提供一套机器接口了，直接让 Agent 用你已经登录好的浏览器。

这不是一句包装出来的口号，基本就是这个项目的核心判断：Your browser is the API。

它到底是什么

bb-browser 现在更像一层面向 Agent 的浏览器工具层：有 CLI，有 MCP Server，也有一套围绕真实浏览器运行的命令系统。项目首页给它的定义很直白：CLI + MCP server for AI agents to control Chrome with your login state。

你可以把它理解成“给 Agent 用的浏览器接口”，但重点不在于它又造了一套云端 API，而在于它尽量贴着你本地浏览器已经存在的状态工作。

比如下面这些命令，就是它最典型的用法：

bb-browser site twitter/search "AI agent"
bb-browser site zhihu/hot
bb-browser site youtube/transcript VIDEO_ID
bb-browser site boss/search "AI 工程师"

关键不在“它能搜 Twitter”或者“它能读知乎”，而在于这些命令默认是在一个已经登录、已经带着 Cookie、已经有真实用户上下文的浏览器里执行。它和传统的 headless 自动化，也和单纯的 HTTP 抓取，不是一回事。

截至 2026-05-13，这个仓库在 GitHub 上已经有 5k+ stars，npm 最新版本是 0.11.6。从 2026-01-31 的首个公开版本到 2026-05-11 的 0.11.6，更新非常快，基本一直在边跑边扩能力。

它真正抓住的问题，不是“自动化”，而是“接口错位”

很多人第一次看到 bb-browser，会顺手把它归到 Playwright、Puppeteer、Selenium 一类里。这个归类不算错，但也不算准。

它盯住的不是“怎么模拟点击和输入”这么小的问题，而是另一个更根本的问题：为什么 AI Agent 一碰到真实互联网，经常就像突然断网了一样。

原因其实很现实：

  1. 大量网站根本没有公开 API。
  2. 就算有 API，文档也常常不完整，或者权限门槛很高。
  3. 登录态、验证码、CSRF、站内状态、前端缓存、Webpack 模块、Pinia store，这些关键东西都在浏览器里，不在接口文档里。
  4. 不是每个模型都适合临场逆向一个网站。

我觉得 bb-browser 有意思，就在这里。它不是在赌“模型以后会更强，所以让模型现场写爬虫就行”，而是在反过来降难度：

  • 少数强模型负责构建站点适配器。
  • 更多普通模型负责调用这些适配器。

这一点在它的相关项目 bb-agent 里说得更直接：前沿模型把网站变成命令，其他模型只要会调命令、读 JSON，也能接进真实网站。

这个判断我挺认同。很多 Agent 的问题，不是推理不够，而是最后一公里根本没打通。bb-browser 做的事，本质上就是把这最后一公里做成基础设施。

它最值钱的地方，其实是那套 site adapter 体系

如果只看浏览器控制，bb-browser 当然也能做不少事：

bb-browser open https://example.com
bb-browser snapshot -i
bb-browser click @3
bb-browser fill @5 "hello"
bb-browser eval "document.title"
bb-browser network requests --with-body --json

但这个项目真正拉开差距的，不是这些基础命令，而是 site 系统。

它配套有一个社区仓库 bb-sites。当前 README 写的是 102 个 adapters，覆盖 36 个平台；bb-browser 主 README 写的是 103 个命令，覆盖 36 个平台。两个数字有一点点出入，我反而觉得这挺正常，说明这套生态还在持续变化，不是一个静态清单。

这套 adapter 的做法也很直接：一个网站能力，对应一个 JS 文件；这个文件直接在页面上下文里跑。

也就是说，它不是统一去“抓 HTML 再解析”，而是允许不同网站用不同办法：

  • 最简单的是拿现成 Cookie 直接 fetch
  • 再复杂一点的是补 Bearer Token、CSRF Token
  • 更复杂的可以直接调用页面自己的模块、状态树，甚至做 Webpack 注入

项目 README 还把这件事分成了三个复杂度层级：

  • Tier 1：Cookie 直取，像 Reddit、GitHub、V2EX
  • Tier 2：Bearer + CSRF，像 Twitter、知乎
  • Tier 3：Webpack 注入 / Pinia store，像 Twitter 搜索、小红书

这个设计最现实的一点在于：它不追求一套“万能抓取框架”吃掉所有网站，而是承认每个站都有自己的脾气。

对 Agent 来说，这比一套漂亮但脆弱的通用抽象更有用。通用框架常常是 demo 很顺，一碰复杂网站就开始漏水。bb-browser 这里的态度更像是在说：互联网本来就不整齐，那就别假装它整齐，直接把这些差异编码进 adapter 里。

它和 Playwright 最大的区别，是“你自己的浏览器”

如果只用一句话说清 bb-browser 和 Playwright 的差异，我会这么总结：

Playwright 想给你一个可控的浏览器环境；bb-browser 想直接复用你已经在用的浏览器现实。

这两个方向没有谁替代谁，但适用场景确实不一样。

Playwright 的优势是确定性、隔离性、测试友好，也更适合 CI 和标准化回归。你要稳定复现一个流程，它通常是更自然的选择。

bb-browser 的优势则完全是另一边：

  • 你已经登录了
  • 网站已经信任你这个浏览器了
  • 很多复杂权限和站内状态已经在那儿了
  • Agent 不需要重新模拟“成为一个用户”的过程

所以它特别适合这类任务：

  • 跨平台调研
  • 登录态下的信息读取
  • 社交平台、社区平台、内容平台的结构化访问
  • 原本没有公开 API 的网站能力封装

如果目标是做端到端测试，我大概率还是先选 Playwright。

但如果目标是给 Agent 接一层“真实互联网接口”，bb-browser 这一套就很对症。

架构上，它已经不只是一个小脚本了

从仓库里的 AGENTS.md、README 和最近几个版本的发布记录看，bb-browser 现在已经有比较清楚的分层：

CLI / MCP → Daemon → CDP WebSocket → Chrome

这里面有几个点我觉得挺关键。

1. 它不是把浏览器命令随手包一下，而是在做协议层

AGENTS.md 里能看到一些很明确的设计不变量，比如：

  • 所有操作响应都要带 tab 和 seq
  • 观察类响应要带 cursor
  • 无效 tab ID 必须显式报错
  • per-tab 事件必须严格隔离

这说明它不是“做一组能跑的命令”就完事了，而是在认真做一套可以被 Agent 稳定消费的协议。

2. 它很重视观察能力，不只是执行能力

bb-browser 不只是能 click、fill、eval。它还维护 per-tab 事件缓冲，把 network / console / errors 按 tab 隔离起来，并且用 seq、since、cursor 做增量读取。

这件事挺重要。它等于把浏览器从“一个能点页面的工具”，往“一个带状态、带观察窗口的运行时”推了一步。

对 Agent 来说，这很关键。因为 Agent 不只是要动手，还要回看：刚才发生了什么、哪个请求报错了、页面是不是跑偏了、这次点击到底有没有生效。

3. 它明显在往 MCP / Agent 原生工具演化

从发布记录能看出来，这几个月它一直在补 Agent 相关体验：

  • 增加 --mcp
  • 补 MCP 指引
  • 统一 CLI / MCP / Provider 的命令注册
  • 自动启动 daemon
  • 给错误加 hint 和 action
  • 用 --jq 直接在命令行里筛 JSON

这些都不是传统浏览器自动化项目最先会做的事情。它的前提很明确：调用者不一定是人，也可能是另一个模型。

这个项目最有产品感的一点，是它在认真设计“Agent 怎么理解输出”

我读 AGENTS.md 时，印象最深的不是架构图，而是它对输出文案和 JSON 结构的约束。

比如它要求：

  • site list 的描述要让 Agent 能按任务匹配
  • JSON 字段要用完整英文单词，不要缩写
  • 大数字尽量做成可读格式
  • 错误结构里最好同时有 error、hint、action

这说明作者在意的不只是“功能能不能跑”，而是功能跑出来之后，另一个 Agent 能不能顺畅接上。

很多项目做到工具层就停了，bb-browser 明显还往前走了一步，开始认真处理“面向 Agent 的 UX”。

所以我会觉得，它不只是一个浏览器自动化工具，更像一个 Agent Browser Interface。

这个项目也留下了很明显的快速演化痕迹

bb-browser 现在很活跃，但它也还不是那种已经被打磨到边角都平的产品。

从仓库信息里能看到几个很典型的信号。

1. 架构迁移很快，文档里偶尔还能看到过渡期痕迹

README 和多个 release 都已经明确写了，项目现在走的是 CDP 直连 / 托管 Chrome / 无需扩展 这条路；但 PRIVACY.md 里还保留着对 Chrome extension 的描述。

我不觉得这是什么严重问题，反而很像一个真实快速迭代项目的正常状态：架构已经往前走了，文档还在一点点补。

2. 最近的 Issue / PR 很贴地

最近打开的 Issue 和 PR，很多都不是那种空泛的功能愿景，而是非常具体的边界问题：

  • Claude Code 集成里 tools fetch failed
  • Windows / WSL2 的 Chrome 连接问题
  • open --tab 返回的 tab ID 复用问题
  • 后台 tab 接收鼠标事件前需要先激活

这类问题说明项目已经过了“只能演示”的阶段，开始真正进入复杂工作流，开始被真实用户拿去硬接各种场景。

换句话说，它已经不是玩具了；但也因为不是玩具，粗糙边缘会更早暴露出来。

我会怎么评价 bb-browser

如果只从“浏览器自动化”这个标签去看，bb-browser 不算最标准，也不算最稳。

但如果从“AI Agent 怎么进入真实互联网”这个问题去看，它切得其实很准。

它做对了三件事：

  1. 不再执着于 API 优先，而是承认浏览器才是互联网的原生接口。
  2. 不强迫模型临场逆向一切，而是把站点能力沉淀成可复用的 adapter。
  3. 不只考虑人类用户，也在认真设计 Agent 能稳定消费的命令和输出。

所以我觉得，bb-browser 最值得看的地方，不是它今天已经覆盖了多少网站，而是它证明了一条挺务实的路：

如果 API 稀缺、页面复杂、登录态又很重要，那与其让 Agent 一次次重造爬虫，不如直接给它一层真实浏览器接口。

这条路当然不适合所有场景，但对研究型 Agent、内容型 Agent、信息采集型 Agent 来说，它很可能比“再造一套 Web API”更现实。

在这个意义上，bb-browser 不是在做另一个浏览器工具。

它其实在回答一个更大的问题：当互联网主要还是给人用的时候，Agent 到底该怎么进去。

至少现在看，bb-browser 给出的答案，值得继续盯着看。

参考链接

avatar
文章
阅读
粉丝