AI Agent 浏览器自动化革命：Browser Use 让大模型接管网页操作

GitHub Trending 前排最近几乎成了 AI 项目的包场，每天刷一眼都能看到新面孔。但 Browser Use 这个项目连续挂榜的时候，我盯着它的标题看了好几秒——AI 浏览器自动化？这不就是 RPA 套壳吗？点进仓库仔细翻了 README 和源码之后才发现，事情没那么简单。

Browser Use 做的事情一句话就能讲清楚：它让 AI Agent 像人一样操作浏览器。不是那种预先把每个按钮坐标写死的脚本，而是给大模型接上眼睛和手，让模型自己“看”页面、“决定”点哪里、“判断”下一步做什么。这种思路在 GitHub 上其实不算新鲜，但能把体验做到这种程度的开源项目，确实不多。这篇文章就把我实际用过之后的理解、踩过的坑、以及它背后的设计思路，一次说透。如果你正打算用 AI 做网页自动采集、表单填写、跨平台数据对比，或者就是想研究 AI Agent 到底怎么操作真实网页，这项目值得花半小时了解。

1. 先搞清楚它到底解决了什么问题

1.1 传统自动化脚本的硬伤在哪里

过去我们做浏览器自动化，基本绕不开 Selenium 和 Playwright 这两套东西。它们的核心逻辑是“写死流程”：用 CSS 选择器或者 XPath 锁定元素，用显式等待卡时间点，用 try-except 处理偶发弹层。这套方案跑得通，但维护成本极高。页面改一个 class 名，脚本就废；多了一个引导弹窗，点击坐标全部偏移；目标网站上了反爬策略，那更是一场持久战。我见过不少同学把时间花在调选择器、调等待策略上，真正业务逻辑反而没时间优化。

RPA 工具同样有这个问题。它通过界面录制把“鼠标轨迹”保存下来，播放时像一个没有记忆的机器人，遇到任何偏离预期的情况就直接崩溃。这种工具适合流程极其固定的场景，比如每天上班打卡、定时导出报表。但一旦任务需要临场判断——“如果价格低于预期就买，否则跳过”“先把新的弹窗关掉再继续”，传统方案就只能提前把所有分支全部分支写进代码，人肉穷举所有可能性。

1.2 Browser Use 换了个思路：让模型当大脑

Browser Use 把决策权交给了大语言模型。它不再要求开发者用一个选择器去精确锁定页面元素，而是给模型提供了一个“观察 + 操作”的循环：模型先看到当前页面的结构信息，然后通过一组工具函数去执行点击、输入、滚动、翻页等动作，执行完之后再观察新的页面状态，继续决策。整个过程就像你在远程指挥一个坐在电脑前的人类员工，“你看看页面上有什么，然后点那个蓝色的按钮，把订单金额记下来”。

这个思路把自动化从“规则驱动”变成了“意图驱动”。你告诉 Agent 最终要达成的目标，它自己规划步骤、自己处理异常、自己根据页面反馈修正路径。也因为这一点，Browser Use 不是只能处理单一网站，它对没有预先适配过的站点也有一定通用性。我第一次用的时候，是让它去一个从没见过的电商网站筛选商品并把结果整理成表格。它在页面里找筛选条件、点下拉框、记录价格，整个过程基本没出大差错。

这个项目对三类人最有价值：一是需要频繁采集网页数据但不想写爬虫的人，二是研究 AI Agent 落地场景的开发者，三是想把手动操作的重复工作交给自动化工具的运营和产品人员。它的学习曲线不像传统爬虫那么陡峭，但对模型的依赖程度比较高——这句话在后面讲成本控制的时候会再次提到，别忽视。

2. 核心设计拆解：AI 是怎么“看懂”网页并动手操作的

2.1 Agent 循环：观察、决策、行动、再观察

Browser Use 的整个工作流是基于一个循环来运转的。很多人第一次看它的运行日志会以为这只是“调用模型生成文字”，实际上每一轮它都在执行真实的浏览器操作。我把这个循环拆开讲一下。

首先是观察阶段，Agent 需要知道“当前屏幕上是什么”。Browser Use 不是直接把整张截图丢给模型去“看图猜谜”，而是把网页的 DOM 结构、可交互元素、文本内容、输入框的 placeholder、按钮的文字等信息提取出来，转成结构化的文本表示。这一步很关键，它相当于把浏览器里的“视觉画面”翻译成模型容易理解的“文字描述”。然后这些信息会和用户的任务描述一起组成 prompt，交给大模型。

接下来是决策阶段，模型基于任务目标和当前页面状态，输出下一步动作。这个动作不是“点击坐标为 (x, y)”这种底层指令，而是“点击 id 为 search-btn 的按钮”“在 input 控件里输入机械键盘”“滚动到页面底部”这类语义化操作指令。Browser Use 把这些指令映射到一组预先定义好的函数上，比如click_element、input_text、scroll_down、go_back、switch_tab等等。

然后是执行阶段，框架调用底层 Playwright 去驱动真实浏览器完成这些动作。这里有一个非常值得称赞的设计——它通过索引编号来引用页面元素，而不是直接传 DOM 选择器串。什么意思？就是模型在“看到”的列表里选第 3 个按钮，代码就去执行第 3 个按钮的点击。这种方式大幅度减少了模型生成无效选择器的概率，也降低了 prompt 复杂度。我看源码的时候发现这个设计其实花了很多心思，索引引用比自由文本引用稳定得多。

最后是再观察阶段，页面状态发生变化后，Agent 会提取新的 DOM 信息，判断任务是否完成；没完成就继续循环，完成了就输出结果。整个循环的终止条件有两个：模型自己判断完成了，或者达到设置的最大步数上限。默认跑个几十步没问题，但如果你不设上限，遇到某个页面反复跳转，token 消耗会让你肉疼。

2.2 为什么选 DOM 文本而不是纯视觉截图

你可能想问：现在多模态模型不是很强吗，为什么不直接截图给 GPT-4V 看，让模型识别图片里的按钮位置？这个方向确实有人在做，Browser Use 也支持视觉输入作为补充，但主力信息源仍然是 DOM 提取的文本结构。

原因是成本、速度和稳定性。一张截图传给多模态模型的 token 成本远高于文本，而且模型对图像中按钮具体坐标的猜测精度不稳定。页面缩放比例一变、屏幕分辨率不同、弹窗挡住按钮，视觉方案就全靠猜。DOM 文本则保留了一切语义信息：这个按钮叫什么、那个输入框期望什么格式、链接指向哪里。这些都是模型最擅长处理的结构化信息。文本方案推理更快，也更省钱，还能配合aria-label、placeholder这类属性去做更精确的动作定位。

当然，纯 DOM 也有盲区。比如 Canvas 画布里的内容、iframe 内嵌页面、某些阴影 DOM 场景，文本提取会丢失信息。这类场景下 Browser Use 会结合截图让模型补充判断。我对这套混合方案的看法是：主流场景够用，边缘场景勉强能补。

2.3 模型选型直接影响成败

Browser Use 本身不内置模型，它是接各大 LLM 的 API。你用什么模型跑 Agent，体验区别非常大。我在实测中的感受是，推理能力强的模型（比如 Claude 系列、GPT-4 系列）“看懂”页面的能力明显更强，面对模糊指令时的容错率更高。便宜的小模型不是不能用，但容易在“点击前先思考直接干”和“遇到意外就乱猜”这两端摇摆。

我的建议是，从性价比出发，优先考虑 Claude 的 Haiku 系列或者 GPT-4o-mini 这类轻量级模型，它们在 DOM 文本理解上的表现足够好，成本也低。如果任务涉及复杂推理、长链路操作、多条件判断，升级到更强的模型，整体成功率提升也会非常明显。简单任务用大模型是浪费，复杂任务用太小的模型是反复试错烧钱，这个平衡点需要你自己跑几次才能找到感觉。

另外提示词也别忘了调。Browser Use 支持在 Agent 初始化时传 system prompt，你可以额外补充一些约束，比如“不要在没有把握的时候点击删除按钮”“遇到登录弹窗不要乱点，先汇报”之类的规则。模型对自然语言规则的遵从度很高，你完全可以用提示词给它上一道保险丝。

3. 快速上手：从安装到跑通第一个自动化任务

3.1 环境准备：就三步

安装这块没什么特殊门槛，Python 环境 3.10 以上基本没问题。先创建一个虚拟环境，然后装 Browser Use 和浏览器驱动：

python -m venv .venv source .venv/bin/activate # Windows 上是 .venv\Scripts\activate pip install browser-use playwright install chromium

Browser Use 底层调用 Playwright，所以在装完库之后还需要拉一个 Chromium 内核。这一步很容易被忽略，我第一次跑的时候就是忘了装浏览器，报了莫名的连接错误。装上之后，去你的 LLM 服务商后台拿到 API Key，配置好环境变量就可以开始写了。我用的是 OpenAI 兼容接口，但 Anthropic、本地 Ollama 也都支持，如果你有本地模型想试，走 Ollama 也能接上，只是推理速度会比较捉急。

3.2 第一个 Demo：让 Agent 自己去查商品比价

我们直接写一个最简单的示例，让 Agent 打开某个电商页面、搜索商品、提取价格信息。这个任务不用提前知道网站的具体结构，Agent 会自己摸索。

import asyncio from browser_use import Agent, Browser, BrowserConfig from langchain_openai import ChatOpenAI async def main(): llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) browser = Browser(config=BrowserConfig(headless=False)) agent = Agent( task="打开京东首页，搜索‘机械键盘’，把搜索结果中销量前3的商品名称和价格整理成列表返回", llm=llm, browser=browser, ) result = await agent.run(max_steps=25) print("最终结果：") print(result.extracted_content()) await browser.close() asyncio.run(main())

这段代码核心就两个对象：Agent 和 Browser。Browser 负责真实的浏览器实例，Agent 负责调用模型决策。我习惯把headless设为 False，也就是有头模式，因为第一次跑你最好亲眼看着 AI 操作，它点错的地方你会立刻发现。等流程稳定了再切无头模式节省资源。

max_steps参数要重点说，它代表 Agent 最多循环多少轮。设太小任务可能跑不完，设太大又会浪费 token。我的经验是先设 15 到 20 步跑一次看日志，如果 Agent 在任务快完成时因为步数限制被截断，再加到 30 步。这个参数相当于给 Agent 一个“路程预算”，让它知道不能无限摸索。

3.3 配置细节和成本控制的一些体会

很多人上手之后第一个感觉是“跑是能跑，但 token 费用飞得快”。这里分享几个我实测有效的省钱技巧。

第一，任务描述越具体，越省钱。你让 Agent“查几个商品的价格”和“打开京东，搜索机械键盘，按销量排序，把前三名的名称、价格、评价数整理成 Markdown 表格”是两种完全不同的成本。后者模型不需要反复猜测你的意图，可能 5 步就完成了；前者它会在页面上东看西看，尝试理解你到底想要什么。

第二，把大任务拆成多个小 Agent 串起来跑。比如要采集多个品类的商品数据，不要让它一口气跑完，容易超出上下文窗口。我一般会让每个 Agent 负责一个品类，采集完把数据写入 JSON，再用下一个 Agent 做汇总。拆出来的每个 Agent 都带一个非常明确的任务指令，这样每一步的上下文都短，成本可控，还更容易排查是哪一步出了问题。

第三，合理使用浏览器缓存和登录态。如果任务需要登录，不要每次从头登录一次，那样既浪费步骤，还可能触发风控。先手动登录一次，记录下用户数据目录，后续的新任务直接复用。这个在配置里可以指定 user data dir，实际效果比我预想的要稳。后面我会单独讲这个操作。

4. 进阶实践：登录态复用、多步骤跨站任务与稳定性调优

4.1 登录态复用：别让 Agent 每次都重新登录

只要是涉及个人账号信息的任务，比如导出订单、查看收藏夹、管理后台数据，登录这一步几乎是绕不开的。如果每个新任务都从登录开始，Agent 至少要额外花 3 到 5 步在账号密码输入上，还可能遇到验证码、短信验证这类它搞不定的环节。

我的做法是手动启动一次浏览器并登录，然后把浏览器的用户数据目录保存下来，后续 Agent 启动时直接复用这个目录。Browser Use 的 BrowserConfig 支持自定义用户数据目录，设置之后，浏览器里保存的 Cookie 和登录状态就会被复用：

browser = Browser(config=BrowserConfig( headless=False, user_data_dir="./my_profile", ))

第一次运行的时候这个目录还不存在，浏览器会以全新状态启动，我手动登录目标网站，完成登录之后关掉任务。之后的每个 Agent 任务都指向同一个./my_profile目录，登录态自动带上。这比在代码里硬编码账号密码安全得多，也比每次走验证码流程稳定得多。

4.2 跨站任务：让多个 Agent 各干各的，再汇总

Browser Use 的一个特色是 Agent 之间可以相互传递结果，这让你可以把一个复杂的跨站任务拆成三步：数据采集 Agent A、数据采集 Agent B、汇总 Agent C。A 和 B 分别跑不同网站，把结果写成 JSON 文件，C 读文件做合并对比。这样每个 Agent 的上下文都很短，模型的注意力更集中，整体成功率高出很多。

我在做一个“对比多平台商品价格”的需求时就是这种架构。三个 Agent 并行跑不同的电商网站（注意并行要自己写并发控制），每个 Agent 内部大约执行 10 到 15 步，各花各的时间，最后汇总成一个表格。成本上比单 Agent 跑长链路便宜不少，因为上下文窗口不会越滚越长；调试体验也更好，哪个平台采集失败就单独重跑那个 Agent，不用整个流程从头再来。

如果你愿意折腾，Browser Use 还支持 custom agent 和自定义 action，比如通过添加自定义工具函数让 Agent 可以直接读写数据库、调用内部 API。我把它理解成给 AI 装了一整套“工具箱”，浏览器只是其中一个工具，理论上它还能触碰其他系统。不过这是重度玩法了，大多数人的需求用内置能力完全够。

4.3 让 Agent 更“懂事”的几条提示词技巧

在多次实测后，我发现 Browser Use 的表现和 prompt 写法强相关。同样是“登录后台导出数据”这个任务，不同写法体验天差地别。

一个是明确给出步骤顺序。你可以直接告诉 Agent“先登录，再进入订单页面，然后筛选最近 7 天，最后导出文件”，但更推荐让它自己制定步骤，你只给目标和约束。因为 Agent 自己规划的路线会更贴合页面真实结构，你给的步骤反而可能因为 UI 变更过时了。

另一个是失败重试策略要写明白。如果你不加说明，模型在遇到弹窗遮住按钮、页面加载慢这类情况时，可能会“宁死不屈”地反复尝试同一个动作，对着同一个按钮点五六次。在提示词里加一句“如果某个操作执行后页面没有变化，换一种方式尝试，不要重复点击同一个元素”，能少烧不少冤枉钱。

最后是动态结果的约束。假如你需要的是“当价格低于 500 元再下单”，那就明确说清楚触发条件，而不是让 Agent“看着办”。大模型对阈值条件非常敏感，只要你说清楚，它一般会严格遵守，不会出现自作主张的情况。

5. 踩坑记录与排查技巧

5.1 常见报错和对应处理方案

整理一下我实际使用中遇到最多的几个问题和解决办法，给后面入坑的同学省点时间：

5.2 成本波峰：最容易被忽略的隐性消耗

很多人计算成本时只看 API 单轮价格，实际上 Agent 的消耗包含“多次循环 × 每次完整页面信息”。一个复杂页面提取出来的 DOM 文本可能就有几千 token，每循环一轮都要重新传给模型，这就意味着十几轮跑下来可能已经消耗了十几万 token。如果你使用的是上下文很长的模型，这个数字还会膨胀。

我建议上线前用一个低成本小模型先跑通全流程，确认没有明显问题后再切换到效果更好的大模型。另外，一定要给max_steps设置上限，不要让它无限循环。对于采集类任务，我习惯把目标拆成小批多次跑，而不是一个巨大任务跑到底。这些细节叠加起来，成本差距可以达到数倍。

5.3 我自己踩过的两个大坑，希望你避开

第一个坑是页面跳转时 Agent 容易丢失上下文。有一次让它登录后台去导出一份数据表格，Agent 在点击“导出”按钮后页面弹了一个下载框，但新标签页把页面状态带偏了，它在错误的页面上试图继续操作，结果越走越远。后来我用方式和提示词双重约束——明确告诉它“导出完成后任务结束，不要继续做额外操作”，情况才好转。

第二个坑是可视化模式下它看起来有点“笨”，但无头模式反而更稳。我一开始总觉得看着浏览器窗口在眼前动才放心，后来发现开可视化调试时，手动鼠标移动会干扰它的操作；用无头模式跑反而没有这些意外。调试用有头，生产用无头，是我最终确定下来的节奏。

最后再分享一个小技巧：Browser Use 的结果格式非常丰富，不只是返回一句“完成了”，它可以输出表格、JSON、结构化文本。你可以在任务描述里直接指定输出格式，比如“请用 JSON 格式返回，包含 name、price、rating 三个字段”，这样下游程序接数据会非常舒服。我个人在实际使用中最大的感悟是——这类 AI Agent 工具并不万能，但把任务范围限制清楚之后，它能帮你节省大量重复劳动。把它当做一个“只领任务、不会摸鱼但偶尔犯浑的实习生”，给它明确目标和容错机制，你会收获惊喜。