Browser Use: 让 AI 真正学会操作浏览器的开源 Agent 框架

一、前言

这几年，人工智能的发展经历了一个非常明显的变化。

最开始，我们使用 AI 的方式非常简单：

用户
↓
提出问题
↓
大语言模型
↓
返回答案

例如：

用户：
帮我写一个 Java 登录接口。
AI：
直接生成 Java 代码。

这种模式本质上属于 AI Chat。

AI 可以理解我们的语言，可以生成代码，可以总结文章，可以分析数据，但是它通常只能停留在“告诉我们应该怎么做”这个阶段。

后来，AI 开始逐渐具备了调用工具的能力。

模型不再只是：

思考 → 回答

而开始变成：

思考
↓
调用工具
↓
得到结果
↓
继续思考
↓
调用工具
↓
完成任务

这就是 AI Agent 开始出现的重要原因。

但是这里又出现了一个非常现实的问题：

AI 可以调用 API，但现实世界的网站并不是都提供 API。

例如我们希望 AI 帮我们完成下面这些事情：

登录 CSDN
发布一篇文章
登录后台
创建一个商品
打开招聘网站
搜索 Java 后端岗位
打开邮箱
读取邮件
打开管理系统
导出昨天的数据
打开某个网站
填写表单
打开 GitHub
创建 Issue
打开云平台
查看服务器状态

这些操作，人类并不需要知道网站有没有 API。

我们只需要：

打开浏览器
↓
看到网页
↓
点击按钮
↓
输入内容
↓
继续点击
↓
完成任务

因此，一个非常重要的问题出现了：

如果 AI 可以像人一样使用浏览器，那么互联网几乎就变成了 AI 可以直接操作的“工具层”。

这正是 Browser Use 所关注的问题。

Browser Use 官方对项目的定位非常直接：

“Make websites accessible for AI agents.”

也就是：

让网站能够被 AI Agent 使用。

目前 Browser Use 已经发展成一个开源的 AI 浏览器自动化项目，官方文档介绍其开源版本可以连接不同的大语言模型，并在本地或自托管环境运行。官方文档目前显示其 GitHub 项目拥有 114k+ Stars。(GitHub)

本文就从 Browser Use 出发，系统理解什么是 Browser Agent，以及它为什么可能成为 AI Agent 时代非常重要的一层基础设施。

二、什么是 Browser Agent

在理解 Browser Use 之前，我们首先需要理解一个概念：

什么是 Browser Agent？

简单来说：

Browser Agent 就是能够理解自然语言任务，并通过浏览器自主完成网页操作的 AI Agent。

传统浏览器自动化通常是：

程序员
↓
编写代码
↓
定位元素
↓
点击
↓
输入
↓
等待
↓
继续点击

例如 Selenium：

driver.find_element(By.ID, "username").send_keys("admin")
driver.find_element(By.ID, "password").send_keys("123456")
driver.find_element(By.ID, "login").click()

程序员必须提前知道：

用户名在哪里
密码在哪里
登录按钮在哪里
页面接下来会出现什么

而 Browser Agent 的思路不同。

我们可以直接给它一个目标：

登录系统，然后进入用户管理页面，
找到今天注册的用户并导出数据。

Agent 自己决定：

打开网页
↓
观察页面
↓
找到登录框
↓
输入账号
↓
输入密码
↓
点击登录
↓
观察新页面
↓
找到用户管理
↓
进入页面
↓
找到筛选条件
↓
设置日期
↓
搜索
↓
导出
↓
确认任务完成

这就是：
传统自动化：
代码驱动浏览器
Browser Agent：
目标驱动浏览器

这是两种完全不同的自动化范式。

三、为什么 Browser Agent 会成为 AI Agent 的重要方向

如果我们把互联网看成一个巨大的系统，那么现在存在一个非常明显的断层。

互联网中的大量服务都是：

网站
网页
后台系统
管理平台
电商平台
内容平台
办公系统
CRM
ERP
OA

这些系统最基本的交互方式都是：

浏览器

但是传统 AI Agent 往往更擅长：

API
数据库
函数
代码工具
MCP

例如：

Agent
↓
GitHub API
↓
创建 Issue

但是如果某个平台没有 API 呢？

这时候就只能：

Agent
↓
Browser
↓
Website

这也是 Browser Agent 的重要价值。

OpenAI 在 2025 年发布 Operator 时，对这个方向给出了非常典型的解释。

OpenAI 将 Operator 描述为一个可以使用自己的浏览器来执行任务的 Agent，它能够查看网页，并通过输入、点击和滚动等方式与网页交互。OpenAI 同时介绍了 Computer-Using Agent（CUA），让模型可以通过 GUI 与数字世界交互，而不完全依赖网站或操作系统专用 API。(OpenAI)

这实际上说明了一个非常重要的趋势：

AI
不再只是调用互联网的信息
而是开始
直接操作互联网

四、Browser Use 是什么

Browser Use 是一个开源的 AI Browser Automation 项目。

它的目标不是简单替代 Selenium，也不是简单封装 Playwright。

它更关注：

LLM
+
Browser
+
Agent
+
Task Planning
+
Tool Calling
+
Memory
+
Automation

最终形成：

自然语言任务
↓
Agent
↓
理解任务
↓
观察网页
↓
选择操作
↓
执行操作
↓
观察结果
↓
继续推理
↓
完成任务

Browser Use 官方 GitHub 将项目描述为：

让 AI Agent 像人一样使用 Web Browser，可以打开页面、点击按钮、输入内容以及填写表单。(GitHub)

这句话其实已经非常准确地概括了 Browser Use 的核心。

五、Browser Use 和 Selenium、Playwright 有什么区别

很多开发者第一次看到 Browser Use，都会产生一个疑问：

这不就是 Selenium / Playwright 吗？

严格来说，不是。

它们解决的问题并不完全相同。

5.1 Selenium / Playwright

传统浏览器自动化通常属于：

确定性自动化

例如：

await page.goto("https://example.com")
await page.locator("#username").fill("admin")
await page.locator("#password").fill("123456")
await page.locator("#login").click()

程序员已经知道：

URL
元素
选择器
操作顺序

所以流程基本是：

代码
↓
浏览器
↓
固定操作

5.2 Browser Use

Browser Use 更接近：

目标
↓
Agent
↓
观察
↓
推理
↓
执行
↓
再次观察

例如：

agent = Agent(
task="""
打开 Hacker News，
找到当前排名第一的文章，
返回文章标题和链接。
""",
llm=llm,
)

程序员不需要告诉 Agent：

第几个元素
CSS Selector 是什么
XPath 是什么
按钮具体在哪里

Agent 会根据当前网页状态决定下一步。

Browser Use 官方文档当前的基础 Agent API 就是通过 Agent(task=…, llm=…) 定义任务，再通过异步 run() 执行。(Browser Use)

六、Browser Use 的核心工作流程

Browser Use 最值得理解的其实不是 API，而是它背后的 Agent Loop。

可以把整个过程简化成：

用户任务
↓
┌───────────────┐
│ Agent │
└───────┬───────┘
↓
获取浏览器状态
↓
理解页面内容
↓
判断下一步动作
↓
执行 Browser Action
↓
获取新的页面状态
↓
是否完成？
/ \\
否 是
↓ ↓
继续循环 返回结果

这就是典型的：

Observe
↓
Think
↓
Act
↓
Observe
↓
Think
↓
Act

也就是：

观察 → 思考 → 行动

不断循环。

七、第一步：安装 Browser Use

Browser Use 官方目前提供 Python 开源版本。

官方文档建议使用 Python 环境，并提供了基于 uv 的快速安装方式。(Browser Use)

例如：

pip install uv

创建 Python 3.12 虚拟环境：

uv venv –python 3.12

激活环境：

source .venv/bin/activate

Windows：

.venv\\Scripts\\activate

安装 Browser Use：

uv pip install browser-use

安装浏览器：

uvx browser-use install

也可以根据自己的项目管理方式直接使用：

pip install browser-use

八、第二步：准备大语言模型

Browser Use 本身并不是一个大语言模型。

它更像一个：

Agent Runtime

因此需要一个 LLM 来负责：

理解任务
分析页面
决定下一步动作

Browser Use 官方文档目前提供了多个模型接入方式，包括 Browser Use 自己的模型，以及 Google、OpenAI、Anthropic 等模型。(Browser Use)

例如环境变量：

OPENAI_API_KEY=your_api_key

或者使用 Browser Use 官方模型：

BROWSER_USE_API_KEY=your_api_key

实际项目中，可以根据自己的成本、速度和任务复杂度选择模型。

九、第三步：创建第一个 Browser Agent

下面来看一个最简单的例子。

import asyncio
from browser_use import Agent, ChatBrowserUse
async def main():
llm = ChatBrowserUse()
agent = Agent(
task="Find the number 1 post on Show HN",
llm=llm,
)
await agent.run()
if __name__ == "__main__":
asyncio.run(main())

这段代码非常短。

但是它背后完成的事情其实很多。

Agent
↓
读取任务
↓
打开浏览器
↓
访问网站
↓
分析网页
↓
识别文章
↓
判断排名
↓
获取结果

Browser Use 官方 Quickstart 当前就是通过类似的 Agent + ChatBrowserUse + task + run() 方式创建第一个 Browser Agent。(Browser Use)

这也是 Browser Use 非常有意思的地方：

代码非常少，但是任务执行能力很强。

十、从“执行代码”到“执行任务”

传统自动化程序通常这样写：

await page.goto("https://news.ycombinator.com")
posts = await page.locator(".athing").all()
first_post = posts[0]
title = await first_post.locator(".titleline").inner_text()

这里程序员必须知道网页结构。

而 Agent 的代码可以变成：

agent = Agent(
task="""
打开 Hacker News，
找到当前排名第一的文章，
返回文章标题。
""",
llm=llm,
)

这里最重要的变化是：

传统自动化：
How
Agent：
What

传统程序告诉浏览器：

怎么做。

Agent 告诉浏览器：

要完成什么。

十一、Browser Use 到底是怎么“看懂”网页的

这是 Browser Agent 最核心的问题之一。

LLM 本身并不能直接“点击网页”。

因此中间需要一个 Browser Runtime。

可以抽象成：

LLM
│
│ 决策
▼
Agent Layer
│
│ Action
▼
Browser Session
│
┌─────────┼─────────┐
│ │ │
DOM Screenshot URL
│ │ │
└─────────┼─────────┘
│
▼
LLM

Browser Use 会获取浏览器当前状态，并把网页信息转换成 Agent 可以理解的上下文。

官方源码可以看到 Browser Use 的 Agent Service 会获取浏览器状态，并对页面内容进行 Markdown 化处理；同时也可以根据需要获取页面截图，然后将这些内容提供给模型进行下一步推理。(GitHub)

这说明 Browser Agent 并不是简单地：

截图 → Vision Model → 点击坐标

而是会结合：

DOM
+
页面文本
+
交互元素
+
截图
+
历史操作

形成更完整的页面状态。

十二、为什么不能只使用截图

如果只使用截图：

网页
↓
截图
↓
视觉模型
↓
找到按钮
↓
点击坐标

这种方式看起来很直观。

但是实际生产环境会存在很多问题：

窗口大小变化
页面滚动
按钮位置变化
弹窗出现
字体变化
响应式布局
浏览器缩放

例如：

按钮原来：
x = 800
y = 500
窗口缩放后：
x = 650
y = 430

如果 Agent 完全依赖坐标，那么稳定性会比较差。

因此现代 Browser Agent 更倾向于：

视觉
+
DOM
+
语义
+
元素状态

而不是单纯依赖坐标。

十三、Browser Use 的“元素索引”思路

Browser Use CLI 的官方文档提供了一个非常直观的工作方式：

open
↓
state
↓
获得页面上的可交互元素编号
↓
click
↓
type

例如：

browser-use open https://example.com

查看页面状态：

browser-use state

然后：

browser-use click 5

输入：

browser-use type "Hello World"

截图：

browser-use screenshot page.png

Browser Use 官方 CLI 文档明确将核心工作流描述为：

navigate
→ state
→ interact

也就是先导航，再获取页面状态，然后根据元素索引执行交互。(Browser Use)

这种方式相比单纯 XPath 有一个很大的优势：

Agent 不需要事先知道完整的 XPath。

十四、为什么 Browser Agent 能处理动态网页

现在的网站大量使用：

React
Vue
Angular
Next.js
Nuxt
Element Plus
Ant Design

传统自动化经常会遇到：

元素还没有出现
↓
点击失败

或者：

页面更新
↓
元素重新渲染
↓
原来的元素引用失效

Browser Agent 则可以采用：

观察当前状态
↓
寻找当前可用元素
↓
执行动作

也就是说：

不是记住网页
而是不断观察网页

Browser Use 当前源码中也包含针对历史元素重新匹配、页面状态变化以及等待元素出现等处理逻辑。(GitHub)

十五、一个更实际的例子：自动搜索资料

假设我们让 Agent：

搜索最近关于 AI Agent 的热门项目，
找到 GitHub 上值得关注的项目，
整理项目名称、Stars 和简介。

代码可以类似：

import asyncio
from browser_use import Agent, ChatBrowserUse
async def main():
llm = ChatBrowserUse()
task = """
搜索 GitHub 上最近比较热门的 AI Agent 项目。
找出 5 个值得关注的项目，并整理：
1. 项目名称
2. GitHub Stars
3. 项目简介
4. 主要技术方向
5. GitHub 地址
最后以 Markdown 表格输出。
"""
agent = Agent(
task=task,
llm=llm,
)
history = await agent.run(
max_steps=50
)
print(history)
if __name__ == "__main__":
asyncio.run(main())

这里已经开始接近真正的：

Research Agent

而不是简单的：

Browser Automation

十六、Agent 为什么需要 max_steps

Agent 并不是执行一次动作就结束。

它可能需要：

第 1 步：打开网站
第 2 步：搜索
第 3 步：点击结果
第 4 步：读取页面
第 5 步：返回上一页
第 6 步：打开另一个结果
第 7 步：提取数据

所以 Browser Use 提供了：

await agent.run(
max_steps=50
)

max_steps 用于限制 Agent 最大执行步数，官方文档当前默认值为 100。(Browser Use)

这个参数非常重要。

因为 Agent 越自由：

能力越强

同时：

成本越高
风险越大
执行时间越长

因此生产环境必须限制：

最大步骤
最大时间
最大 Token
最大费用

十七、让 Agent 使用自己的浏览器

Browser Use 也支持对 Browser 进行配置。

例如：

from browser_use import Agent, Browser, ChatBrowserUse
browser = Browser(
headless=False,
window_size={
"width": 1000,
"height": 700
}
)
agent = Agent(
task="Search for Browser Use",
browser=browser,
llm=ChatBrowserUse(),
)

其中：

headless=False

表示显示浏览器窗口。

这样开发阶段就非常方便。

因为你可以直接看到：

Agent 正在做什么

例如：

打开网页
↓
点击按钮
↓
输入关键词
↓
跳转页面
↓
继续操作

Browser Use 官方 Browser Configuration 文档目前也提供了 Browser(headless=False, window_size=…) 这样的配置方式。(Browser Use)

十八、Browser Agent 最有价值的地方：它可以处理没有 API 的网站

这是 Browser Agent 非常重要的价值。

假设：

系统 A
有 API

我们可以：

Agent
↓
API
↓
系统 A

但是：

系统 B
没有 API

传统 AI Agent 就比较麻烦。

而 Browser Agent 可以：

Agent
↓
Browser
↓
系统 B

因此：

API Agent

和：

Browser Agent

并不是互相替代。

未来更可能是：

AI Agent
│
┌───────────┼───────────┐
│ │ │
API MCP Browser
│ │ │
服务 Tool Web

Agent 会根据任务选择最合适的执行方式。

十九、Browser Use 与 MCP 的结合

AI Agent 生态正在越来越强调 Tool。

例如：

GitHub Tool
Database Tool
Filesystem Tool
Browser Tool
Search Tool
Email Tool

Browser Use 也可以作为 Agent 的浏览器能力。

甚至可以通过 MCP 方式让其他 Agent 使用浏览器。

例如社区项目中已经出现了将 Browser Use 作为 MCP Server，让 Claude Desktop 等客户端获得浏览器自动化能力的实践。(GitHub)

这意味着未来可能出现这样的结构：

AI Agent
│
MCP
│
┌───────────┼───────────┐
│ │ │
GitHub Browser Database
│ │ │
MCP Browser Use MCP

Browser 本身也开始成为 Agent Tool。

二十、Browser Use 的自定义 Tool

如果只让 Agent 使用浏览器，能力已经很强。

但真正进入业务系统后，我们往往还需要：

查询数据库
发送消息
调用内部 API
读取文件
执行代码
操作服务器

Browser Use 官方文档支持自定义 Tools。(Browser Use)

例如：

from browser_use import Tools, ActionResult
tools = Tools()
@tools.action("询问用户")
async def ask_human(
question: str,
browser_session
) –> ActionResult:
answer = input(
f"{question} > "
)
return ActionResult(
extracted_content=answer
)

然后：

agent = Agent(
task="Ask human for help",
llm=llm,
tools=tools,
)

这样 Agent 就不再只是：浏览器 Agent
而逐渐变成：业务 Agent

二十一、为什么自定义 Tool 非常重要

假设我们正在开发一个：

CSDN AI 助手

我们可以给 Agent 增加：

读取文章 Tool
生成文章 Tool
查询文章状态 Tool
浏览器 Tool
发布文章 Tool
统计 Tool

于是：

CSDN Agent
│
├── read_article()
├── generate_summary()
├── browser()
├── publish()
└── statistics()

这就开始进入真正的 Agent Engineering。

二十二、Browser Use 的 Skill 概念

Browser Use 当前还提供了 Skill 能力。

官方文档将 Skill 描述为：

“your API for anything”

也就是把某种复杂能力封装成可以重复调用的能力。(Browser Use)

例如：

CSDN 发布 Skill

内部可能包含：

打开 CSDN
↓
进入创作中心
↓
创建文章
↓
填写标题
↓
填写正文
↓
设置分类
↓
设置标签
↓
上传封面
↓
发布

以后 Agent 只需要：

调用 CSDN Publish Skill

而不用每次重新学习整个流程。

这其实非常接近：

Agent Skills

正在逐渐成为 AI Agent 生态的重要基础设施。

二十三、Browser Use 的登录态问题

实际开发 Browser Agent 时，一个非常重要的问题就是：

登录怎么办？

例如：

CSDN
GitHub
Gmail
企业微信
飞书
后台系统

这些网站通常需要登录。

如果每一次运行 Agent 都重新：

输入账号
输入密码
验证码

显然是不现实的。

所以生产环境需要：

Browser Profile
+
Cookie
+
Session
+
Authentication

Browser Use 的云端能力提供了持久化 Profile 等能力，可以复用保存的 Cookies 和认证状态。官方文档也展示了使用 cloud_profile_id 执行需要认证状态的任务。(Browser Use)

因此可以形成：

User
↓
Browser Profile
↓
Cookies
↓
Authenticated Browser
↓
Agent

这也是 Browser Agent 从 Demo 走向生产环境必须解决的问题。

二十四、为什么登录态也是安全风险

但是这里也必须特别注意。

如果你把自己的：

GitHub Cookie
CSDN Cookie
邮箱 Session
后台 Session

交给 Agent，那么 Agent 实际上就拥有了对应账号的操作能力。

这和普通聊天完全不同。

例如：

普通 AI：
知道你的 GitHub Token
Browser Agent：
可能直接操作你的 GitHub

所以 Browser Agent 的安全模型必须更加严格。

建议：

开发环境：
独立测试账号
生产环境：
最小权限账号
高风险操作：
人工确认
支付：
禁止自动执行
删除：
人工确认
账号设置：
人工确认

二十五、OpenAI Operator 为什么要求用户接管

这个问题非常值得参考。

OpenAI 在介绍 Operator 时明确提到，当任务涉及登录凭据、支付信息或验证码等情况时，Operator 会让用户接管浏览器控制权。(OpenAI)

这说明：

真正成熟的 Browser Agent 并不是“完全自动化一切”。

而应该是：

低风险操作
↓
AI 自动完成
高风险操作
↓
AI 暂停
↓
用户确认
↓
AI 继续

也就是：

Human in the Loop

二十六、Browser Agent 的安全边界

可以把任务分成三个等级。

第一等级：低风险

例如：

搜索网页
读取文章
整理数据
查询公开信息

可以：

Agent 自动完成

第二等级：中风险

例如：

发布文章
发送普通邮件
修改公开内容
创建 Issue

可以：

Agent 执行
+
最终确认

第三等级：高风险

例如：

付款
转账
删除数据库
修改账号密码
删除 GitHub Repository

建议：

Agent 执行到关键节点
↓
暂停
↓
用户确认
↓
继续执行

这是未来 Agent 产品非常重要的一种设计模式。

二十七、Browser Use 不等于“万能自动化”

这里也需要理性看待。

Browser Agent 虽然非常强，但是目前仍然不是：

100% 成功率

网页环境非常复杂：

验证码
登录
反爬
Cloudflare
动态页面
弹窗
iframe
WebSocket
文件上传
拖拽
复杂编辑器
多标签页
支付流程

都可能导致 Agent 失败。

Browser Use 官方也明确区分了开源 Agent 和 Cloud 方案，并在 Cloud 侧提供浏览器基础设施、代理、验证码处理以及更适合规模化运行的能力。(GitHub)

因此生产环境不能简单理解成：

装好 Browser Use
=
自动化一切

真正的工程实践应该是：

Agent
+
规则
+
工具
+
重试
+
状态机
+
人工接管
+
日志
+
监控

二十八、Browser Agent 为什么需要状态机

假设我们开发一个：

自动发布 CSDN 文章

任务不能简单写成：

发布文章

更合理的方式是：

START
↓
检查登录状态
↓
登录成功？
├── No → 登录
└── Yes
↓
打开创作中心
↓
创建文章
↓
填写标题
↓
填写正文
↓
填写标签
↓
上传封面
↓
保存草稿
↓
检查内容
↓
发布
↓
验证发布成功
↓
END

这样即使某一步失败，也可以：

重新执行当前节点

而不是整个任务全部重新开始。

二十九、Agent + Workflow 才是生产级方案

因此未来成熟的 Agent 系统，我认为更可能是：

Workflow
│
├── Agent
│
├── Tool
│
├── Browser
│
├── Memory
│
├── Human Approval
│
└── Retry

而不是：

一个 Prompt
+
一个 LLM

这也是现在 AI Agent Engineering 和普通 AI Chat 最大的区别。

三十、Browser Use 的 CLI

除了 Python SDK，Browser Use 当前还提供 CLI。

例如：

browser-use open https://example.com

查看页面状态：

browser-use state

点击：

browser-use click 5

输入：

browser-use type "Hello"

截图：

browser-use screenshot page.png

关闭：

browser-use close

官方 CLI 文档目前将其定位为快速、持久化的浏览器自动化命令行工具。(Browser Use)

这其实也意味着 Browser Use 正在逐渐从：

Python Library

向：

Agent Tool
+
CLI
+
Browser Infrastructure
+
Cloud

扩展。

三十一、Browser Use 当前生态已经不只是一个 Python 库

从现在的项目形态来看，可以把 Browser Use 理解成一个生态：

Browser Use
│
├── Open Source Agent
│
├── Browser Runtime
│
├── CLI
│
├── Cloud Browser
│
├── Models
│
├── Skills
│
├── Custom Tools
│
├── MCP
│
└── Production Infrastructure

官方首页目前也将其产品方向扩展到了 Web Agents、Stealth Browsers、Custom Models 和 Skills 等多个部分。(浏览器使用)

这说明 Browser Use 正在尝试解决的并不是：

“怎么让 Python 点击网页？”

而是：

“怎么让 AI Agent 在真实互联网环境中可靠地完成任务？”

这是两个完全不同的目标。

三十二、Browser Use 最适合哪些场景

例如：

搜索 20 个 AI Agent 项目
比较 GitHub Stars
分析技术栈
整理成表格

例如：

招聘网站
政府网站
企业内部系统
CRM
OA
ERP

例如：

打开 100 个网页
提取商品名称
价格
库存
评价

Browser Use 官方 Cloud Agent 文档也将数据提取、多步骤流程、研究、监控、测试等列为典型用途。(Browser Use)

例如：

打开登录页面
输入账号
登录
进入订单页面
创建订单
检查订单状态

这已经开始接近：

AI QA Agent

例如：

CSDN
掘金
知乎
公众号后台
WordPress
博客系统

例如：

OA
ERP
MES
CRM
后台管理系统
数据平台

尤其是那些：

没有 API
或者 API 不完整

的系统。

三十三、Browser Use 对开发者意味着什么

对于程序员来说，Browser Agent 的出现实际上改变了一个很重要的东西：

过去：

程序员
↓
API
↓
系统

未来可能变成：

程序员
↓
Agent
↓
Browser
↓
系统

这意味着：

网页本身可能成为一种 API。

以前我们需要：

REST API
GraphQL
RPC
SDK

未来某些场景下可能直接：

Website

因为 Agent 可以直接操作网站。

Browser Use 官方 Skills 文档甚至将“把网站能力封装成可以重复调用的 API”作为一个方向。(Browser Use)

三十四、这会不会取代 Selenium 和 Playwright

我认为不会。

至少短期内不会。

更合理的关系是：

Browser Automation
│
┌─────────────┴─────────────┐
│ │
Deterministic Agentic
│ │
Selenium / Playwright Browser Use
│ │
固定流程、稳定测试 非确定流程
精确控制 自然语言任务
高性能 AI 决策

如果你知道：

点击 A
↓
输入 B
↓
点击 C

那么 Playwright 往往更加可靠。

如果你只知道：

帮我完成这个业务目标

而页面路径并不固定，那么 Browser Agent 更有优势。

因此：

Playwright
+
Browser Agent

很可能是未来更合理的组合。

三十五、最值得关注的一个变化：从 RPA 到 Agent

传统 RPA：

录制流程
↓
固定执行

AI Agent：

理解任务
↓
自主规划
↓
执行
↓
观察结果
↓
动态调整

可以简单理解成：

RPA：
知道步骤，所以执行。
Agent：
知道目标，所以寻找步骤。

这也是为什么 Browser Agent 可能成为下一代 RPA 的重要技术路线。

三十六、从 Browser Agent 到 Computer Agent

Browser Agent 其实只是第一步。

现在：

Browser Agent

主要操作：

网页

进一步发展就是：

Computer Agent

可以操作：

浏览器
文件
终端
IDE
桌面软件
系统设置

OpenAI 的 Computer-Using Agent 就是这种方向的代表之一。OpenAI 将 CUA 描述为能够通过视觉理解和推理与 GUI 进行交互的模型，使 Agent 可以处理按钮、菜单和文本字段等人类界面。(OpenAI)

于是未来可能变成：

User
↓
Computer Agent
├── Browser
├── Terminal
├── IDE
├── Files
├── Office
└── Desktop Apps

这时候 Agent 才真正开始接近：

数字员工

三十七、Browser Agent 的未来可能是什么

我认为未来 Browser Agent 会沿着几个方向继续发展。

方向一：更强的模型

现在 Agent 最大的问题之一：

理解错误

模型越强：

规划能力
页面理解能力
错误恢复能力

都会提升。

方向二：更强的 Browser Runtime

未来 Browser 不只是：

Chrome

而可能具备：

隔离环境
持久化 Profile
Proxy
Captcha Handling
Recording
Sandbox
Storage
Network Control

Browser Use 当前 Cloud 产品已经明显朝这个方向发展。(Browser Use)

方向三：Agent Memory

例如：

第一次：
学习怎么登录 CSDN
第二次：
直接使用已有流程
第三次：
发现页面变化
第四次：
自动修复流程

最终 Agent 不只是：

执行

而是：

学习
+
记忆
+
优化

方向四：Skills

把复杂流程封装成：

Skill

例如：

publish_csdn_article
create_github_issue
deploy_server
send_email
submit_expense

以后 Agent 只需要：

调用 Skill

而不需要每次重新规划完整流程。

方向五：多 Agent 协作

未来可能出现：

Research Agent
↓
Browser Agent
↓
Coding Agent
↓
Testing Agent
↓
Deploy Agent

例如：

用户：
帮我开发一个博客系统并部署。
Research Agent
↓
搜索技术方案
Coding Agent
↓
写代码
Browser Agent
↓
测试网页
Testing Agent
↓
执行测试
Deploy Agent
↓
部署服务器
Browser Agent
↓
检查线上页面

这才是真正意义上的：

AI Software Engineer

三十八、如果我是一个 Java 后端开发者，应该怎么学 Browser Use

如果你本身主要是 Java 开发，我不建议你因为 Browser Use 是 Python 项目，就把自己的技术栈全部换掉。

可以采用：

Java
↓
主业务系统
Python
↓
AI Agent
Browser Use
↓
Browser Agent
Redis
↓
Session / Task State
MySQL
↓
业务数据
WebSocket
↓
实时任务状态

整体架构：

前端
│
▼
Java Gateway
│
┌──────┴──────┐
│ │
Business AI Service
│ │
│ Python Agent
│ │
│ Browser Use
│ │
│ Browser
│ │
└─────────────┘

这其实非常适合微服务架构。

三十九、如果把 Browser Use 接入自己的 Personal AI

如果你正在开发一个个人 AI 系统，那么 Browser Use 会非常有价值。

例如：

Juno AI
│
├── Chat Agent
│
├── Browser Agent
│
├── Coding Agent
│
├── Server Agent
│
├── File Agent
│
└── IoT Agent

用户可以直接说：

帮我看看 GitHub 最近有什么值得关注的项目。

Agent：

Browser Agent
↓
GitHub
↓
搜索
↓
分析
↓
返回

或者：

帮我把这篇文章发布到 CSDN。

Agent：

读取文章
↓
Browser Use
↓
CSDN
↓
填写
↓
发布
↓
返回结果

这已经不再是：

AI Chatbot

而是：

Personal Agent

四十、一个完整的 Personal Browser Agent 架构

如果自己从零设计，我会倾向于：

User
│
▼
AI Gateway
│
▼
Agent Runtime
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
Planner Memory Tools
│ │ │
└────────────┼────────────┘
│
▼
Browser Agent
│
┌───────┼───────┐
│ │ │
Browser Browser Browser
│ │ │
CSDN GitHub Google

再增加：

Task Queue
│
▼
Redis
│
▼
Worker
│
▼
Browser Session

这样就可以实现：

异步 Agent Task

四十一、为什么 Browser Agent 可能成为“AI 时代的 RPA”

过去企业自动化主要依赖：

RPA

现在可能逐渐变成：

RPA
+
LLM
+
Agent
+
Browser

传统 RPA 的优势：

稳定
确定
可预测

Agent 的优势：

灵活
理解自然语言
适应页面变化
自主决策

因此未来比较合理的模式不是：

Agent 完全替代 RPA

而是：

确定性流程：
传统自动化
不确定性流程：
Agent
复杂流程：
Agent + Workflow + Browser Automation

四十二、Browser Use 最大的价值并不是“自动点击”

如果只把 Browser Use 理解成：

AI 帮我点击网页。

其实低估了它。

真正重要的是：

自然语言
↓
任务理解
↓
任务规划
↓
浏览器操作
↓
环境反馈
↓
动态调整
↓
任务完成

这意味着：

浏览器开始成为 Agent 的行动器。

LLM 负责：

Brain

Browser Use 负责：

Hands

Browser 负责：

Environment

三者组合：

LLM
+
Browser Use
+
Web

就形成了一个能够在数字世界中行动的 Agent。

四十三、我们应该如何正确理解 Browser Use

如果只从 Python 库的角度理解：

Browser Use

一个浏览器自动化框架

这个理解并不完整。

更准确的理解应该是：

Browser Use

AI Agent 与 Web 世界之间的执行层

也可以进一步理解成：

LLM
负责思考
Browser Use
负责行动
Browser
负责提供数字世界
Website
负责提供真实业务环境

因此：

LLM 是大脑
Browser Use 是手
Browser 是眼前的数字世界

四十四、总结

从 Selenium 到 Playwright，再到 Browser Agent，我们实际上经历了一个非常明显的变化。

第一阶段：

程序员告诉浏览器怎么做

第二阶段：

程序员编写自动化流程

第三阶段：

程序员告诉 Agent 要完成什么

第四阶段：

Agent 自己理解页面
自己规划步骤
自己操作浏览器
自己处理异常
自己完成任务

这也是 Browser Use 最值得关注的地方。

它并不是简单地：

AI + Selenium

而是在尝试建立：

LLM
↓
Agent
↓
Browser
↓
Internet

之间的执行链路。

OpenAI 在 Operator / Computer-Using Agent 上的探索，以及 Browser Use 本身不断扩展的 Agent、Cloud Browser、Skills、CLI 和工具体系，都说明一个趋势正在越来越明显：

AI 正在从“理解信息”逐渐走向“操作信息”。

过去我们问 AI：

“告诉我怎么做。”

未来我们可能直接告诉 AI：

“帮我做。”

而浏览器，恰恰是 AI 进入真实数字世界最重要的入口之一。

对于开发者来说，真正值得学习的也不只是 Browser Use 这个项目本身，而是它背后的整个 Agent 思维：

Task
↓
Agent
↓
Observe
↓
Think
↓
Act
↓
Observe
↓
Retry
↓
Human Approval
↓
Memory
↓
完成任务

当 AI Agent 能够操作浏览器、终端、代码、服务器、数据库以及各种业务系统之后，软件的交互方式也会发生变化。

我们过去开发软件，是：

人 → 软件

未来越来越多的场景可能变成：

人
↓
AI Agent
↓
软件

而 Browser Agent，可能就是这个变化过程中非常关键的一层。

四十五、参考资料与官方出处

本文主要参考以下官方资料：

四十六、写在最后

如果把过去十年的软件发展简单总结一下：

Web
↓
Mobile
↓
Cloud
↓
AI
↓
AI Agent

那么 AI Agent 下一步要解决的问题，就是：

AI 如何真正进入现实的软件世界？

答案不会只有 API。

因为现实世界存在大量：

网页
后台
管理系统
桌面软件
内部系统
老旧系统
没有 API 的系统

Browser Agent 提供了一种非常直接的解决方案：

不要求系统重新开发 API
让 AI 像人一样使用现有的软件。

这可能正是 Browser Use 这类项目最值得关注的地方。

对于开发者而言，未来真正值得掌握的能力，也许不再只是：

Java
Python
Go
React
Vue
Spring Boot

而是进一步理解：

LLM
+
Agent
+
Tool
+
Browser
+
Memory
+
Workflow
+
MCP
+
Human in the Loop

因为当这些东西真正组合起来之后，AI 才开始从一个“回答问题的模型”，逐渐变成一个“可以替你完成工作的数字执行者”。