Browserbase:AI Agent 的“云浏览器”
前言
在 AI Agent 的发展过程中,一个非常现实的问题逐渐暴露出来:
大模型知道很多知识,但不会真正操作网页。
例如,你告诉 ChatGPT:
"帮我登录携程,预订一张明天北京到上海的机票。"
ChatGPT 可能会告诉你:
"可以按照以下步骤……"
但是,它并不会真的:
- 打开浏览器
- 输入用户名
- 点击搜索按钮
- 选择航班
- 提交订单
原因很简单:
LLM 会思考,但不会操作浏览器。
Browserbase 正是为了解决这个问题而诞生。
一句话来说:
Browserbase 是一个专门为 AI Agent 提供浏览器执行环境(Browser Infrastructure)的云平台。
一个真实案例
假设我们开发一个旅游 Agent。
用户输入:
帮我看看下周北京飞上海最便宜的机票。
Agent 的思考过程可能是:
Plan
↓
打开携程
↓
输入出发地
↓
输入目的地
↓
选择日期
↓
搜索
↓
读取价格
↓
比较价格
↓
返回结果
注意:
这里不是 API。
Agent 要做的是:
真正打开网页。
如果没有 Browserbase
很多开发者第一反应:
用 Playwright 就行。
例如:
browser = playwright.chromium.launch()
page.goto("https://ctrip.com")
page.fill(...)
page.click(...)
可以。
但是生产环境马上出现很多问题。
例如:
浏览器运行在哪里?
如果:
1000 个用户:
1000 Browser
↓
1000 Chrome
↓
CPU 爆了
如果:
浏览器崩溃:
怎么办?
如果:
登录状态丢失:
怎么办?
如果:
浏览器需要代理:
怎么办?
如果:
网站检测自动化:
怎么办?
如果:
需要录像:
怎么办?
如果:
需要截图:
怎么办?
这些问题:
都不是 Playwright 解决的。
而是 Browserbase 解决的。
Browserbase 到底是什么?
可以理解成:
Browserbase = Browser Cloud(浏览器云)
Agent:
不用自己运行 Chrome。
而是:
Agent
↓
Browserbase API
↓
Cloud Browser
↓
Chrome
Browserbase 帮你管理:
- Chrome
- Playwright
- Session
- Cookie
- Proxy
- Recording
- Screenshot
- Scaling
Browserbase 在 Agent 中的位置
一个完整 Agent:
User
│
▼
LLM
│
Tool Calling
│
▼
Browser Tool
│
▼
Browserbase
│
Cloud Chrome
│
▼
Real Website
Browserbase:
就是:
Agent 的眼睛。
也是:
Agent 的手。
一个完整实例
假设:
用户:
帮我登录 GitHub,看看今天有没有新的 Pull Request。
Agent:
首先:
Plan:
① 打开 GitHub
② 登录
③ 进入 Repository
④ 查看 Pull Request
⑤ 总结内容
然后:
调用:
Browserbase:
创建:
Browser Session
例如:
browser = browserbase.create_browser()
Browserbase:
返回:
Chrome
Agent:
开始控制:
page.goto(...)
page.fill(...)
page.click(...)
整个浏览器:
运行在 Browserbase。
不是:
你的服务器。
Browser Session(浏览器会话)
这是 Browserbase 最重要的概念。
例如:
用户今天:
登录:
GitHub。
明天:
Agent:
继续:
查看 Issue。
如果没有 Session:
Agent:
每天:
都要:
输入账号
↓
输入密码
↓
登录
Browserbase:
可以保存:
Cookies
Session
Local Storage
Agent:
直接继续。
像:
真人一样。
一个 AI 电商助手案例
用户:
帮我买一双 Nike Pegasus 41,42 码,价格低于 800 元就下单。
Agent:
Plan:
打开京东
↓
搜索 Pegasus 41
↓
筛选 42 码
↓
读取价格
↓
价格低于800
↓
加入购物车
↓
提交订单
整个过程中:
Agent:
不断:
Observe
↓
网页变化
↓
继续点击
Browserbase:
负责:
真正执行:
这些动作。
Browser Automation 为什么这么难?
很多人觉得:
就是:
click()
fill()
goto()
其实:
不是。
例如:
网页:
突然:
弹出:
验证码
或者:
Cookie Banner
或者:
广告弹窗
Agent:
必须:
重新规划。
例如:
关闭弹窗
↓
继续搜索
Browserbase:
提供:
稳定:
浏览器环境。
LLM:
负责:
重新思考。
Browserbase 与 Playwright 的关系
很多人误认为:
Browserbase:
就是:
Playwright。
其实:
不是。
Playwright:
只是:
浏览器控制库。
例如:
page.click()
Browserbase:
则负责:
Browser Lifecycle
Session
Scaling
Cloud Chrome
Recording
Proxy
Storage
可以理解:
Playwright
↓
控制浏览器
Browserbase
↓
管理浏览器
Browserbase 与 Selenium 的区别
Selenium:
主要面向:
自动化测试。
Browserbase:
主要面向:
AI Agent。
例如:
Agent:
需要:
边思考
↓
边点击
↓
边观察
↓
边调整
Browserbase:
支持:
长生命周期:
Browser Session。
这正适合:
Agent。
Browserbase 与 E2B 的区别
很多新人:
第一次:
容易混。
实际上:
它们负责:
完全不同。
E2B:
负责:
Python
Shell
Git
文件
Terminal
Browserbase:
负责:
Chrome
网页
点击
输入
截图
录像
举一个完整例子。
用户:
登录 GitHub,把 Star 数量统计出来,画图后发邮件。
Agent:
执行:
Browserbase
↓
登录 GitHub
↓
读取 Star
↓
E2B
↓
Python
↓
画图
↓
Composio
↓
Gmail
↓
发送邮件
三者:
各司其职。
Browserbase 与 Composio 的区别
很多人:
也容易混。
例如:
读取 GitHub。
其实:
有两种方式。
第一种:
GitHub API。
Agent
↓
Composio
↓
GitHub API
第二种:
网页。
Agent
↓
Browserbase
↓
github.com
什么时候:
用:
Composio?
有:
API。
什么时候:
用:
Browserbase?
没有 API。
或者:
只能:
网页操作。
例如:
很多:
企业后台。
没有:
API。
只能:
浏览器。
一个企业 Agent 的完整例子
假设:
公司:
ERP:
没有:
开放 API。
用户:
帮我下载昨天所有订单。
Agent:
流程:
LLM
↓
Browserbase
↓
登录 ERP
↓
输入日期
↓
点击查询
↓
下载 Excel
↓
E2B
↓
Python
↓
统计销售额
↓
Composio
↓
发送企业微信
整个:
Agent:
真正:
完成了:
一个:
真实:
办公流程。
总结
可以把现代 AI Agent 的基础设施理解成一家公司中的不同角色:
| 组件 | 类比 | 职责 |
|---|---|---|
| LLM | 大脑 | 思考、规划、推理 |
| MCP | 通用接口标准 | 定义模型与工具如何通信 |
| Composio | 行政前台 | 连接 GitHub、Slack、Gmail 等各种 SaaS 服务 |
| Browserbase | 员工的浏览器 | 打开网页、登录系统、点击按钮、获取页面内容 |
| E2B | 员工的电脑 | 执行 Python、运行终端命令、处理文件 |
| Runtime | 项目经理 | 管理 Agent 的执行流程、状态和异常恢复 |
Browserbase 的价值在于:它不是教 Agent 如何点击网页,而是为 Agent 提供一个稳定、可扩展、云端托管的浏览器运行环境。
在现代 AI Agent 系统中,很多业务并没有开放 API,或者需要像真人一样完成登录、搜索、点击、下载、上传等操作。这时,Browserbase 就成为 Agent 与 Web 世界交互的重要基础设施,让 Agent 不再只是"会聊天",而是真正能够"操作互联网"。
如果这篇文章帮助到了你,你可以请作者喝一杯咖啡

浙公网安备 33010602011771号