Browser-use 实战：让 AI Agent 自己上网干活，我折腾了一下午的真实体验

最近一直在搞各种 AI 编程工具，Claude Code、Cursor、Codex 这些都玩了个遍。但有个问题一直困扰我：这些工具再强，也只会在终端里写代码，真要让它们去网上查个资料、填个表单、抓个数据，还得我自己来。

之前试过用 Playwright 写脚本，但每次换个网站就得重写一堆选择器代码，烦得要死。也试过用 MCP 给 AI Agent 接浏览器，配置了一堆东西效果一般。直到我发现了 browser-use 这个项目，GitHub 60k+ stars，MIT 开源，核心思路就一句话：让 AI 像人一样操作浏览器。

我折腾了一下午，从安装到跑通第一个自动化任务，中间踩了不少坑。这篇文章就记录一下整个过程，包括怎么装、怎么用、哪些地方容易翻车。

browser-use 是什么？

browser-use 是一个 Python 库，核心功能是让 LLM 控制浏览器。你给它一个任务描述，比如"去 GitHub 搜索某个项目并返回 star 数"，它就会自己打开浏览器、找到搜索框、输入关键词、读取结果。不需要写任何选择器代码，不需要维护 XPath，LLM 自己看页面、自己判断该点哪里。

底层架构是这样的：

Python API -> Rust core -> Browser harness -> 浏览器操作

对，你没看错，0.13 版本开始用了 Rust 做核心引擎。这意味着浏览器操作的性能和稳定性比纯 Python 实现好很多。我之前用过一些纯 Python 的浏览器自动化库，页面稍微复杂一点就卡得不行，browser-use 在这方面确实好很多。

它跟 Playwright MCP 不太一样。Playwright MCP 是给 AI Agent 提供浏览器操作的"工具"，需要你自己编排 Agent 逻辑。browser-use 是一个完整的 Agent 框架，LLM 直接当大脑，浏览器当手脚，你只需要告诉它干什么就行。

跟 Selenium 之类的传统工具比，区别就更大了。传统工具是"你告诉它点哪个按钮"，browser-use 是"你告诉它要完成什么任务，它自己想办法"。这个区别听起来不大，但用起来完全是两个世界。

安装踩坑记录

安装过程看起来简单，但有几个坑我踩了才知道。

基础安装

pip install "browser-use[core]"

或者用 uv（推荐，速度快很多）：

uv add "browser-use[core]"

这里有个前提：Python 版本必须 >= 3.11。我服务器上默认是 3.10，装的时候直接报错，折腾了半天才发现是版本问题。如果你也是 3.10，可以用 pyenv 或者 uv 切换版本：

uv python install 3.11

uv venv --python 3.11

另外 [core] 这个 extra 很重要。不加的话只装了 Python 包，没有 Rust 核心运行时，跑起来会报一堆奇怪的错。我第一次就是忘了加这个，报了个 browser_use.core not found，查了半天 issue 才发现。

安装浏览器

browser-use 底层用的是 Playwright，需要安装浏览器二进制文件：

playwright install chromium

这一步会下载一个 Chromium 浏览器，大概 100-200MB。如果你在服务器上跑（没有 GUI），记得加 headless=True。

我第一次在服务器上跑没加这个参数，直接报了个 Cannot open display 错误。查了半天才知道是没 headless 模式的问题。这错误信息也太不友好了，直接说"你得加 headless=True"不行吗。

配置 API Key

browser-use 支持多种 LLM 后端。最简单的方式是用它自己的 ChatBrowserUse：

# .env 文件

BROWSER_USE_API_KEY=** 也可以用 OpenAI、Anthropic 等第三方的 Key：

```bash

OPENAI_API_KEY=*** 或者

ANTHROPIC_API_KEY=** ChatBrowserUse 试试，官方说针对浏览器场景做了优化。实际体验下来确实比直接用 GPT-5.5 快一些，但价格差不多。

## 第一个自动化任务

装好了，来跑个最简单的任务试试。

```python

from browser_use.beta import Agent, BrowserProfile, ChatBrowserUse

import asyncio

async def main():

    agent = Agent(

        task="去 GitHub 搜索 browser-use 这个项目，告诉我它有多少 stars",

        llm=ChatBrowserUse(model='openai/gpt-5.5'),

        browser_profile=BrowserProfile(

            headless=True,

            allowed_domains=["*.github.com"],

        ),

    )

    history = await agent.run()

    print(history.final_result())

if __name__ == "__main__":

    asyncio.run(main())

跑起来之后，你会看到浏览器（headless 模式下看不到窗口，但日志里能看到操作步骤）自动打开 GitHub，找到搜索框，输入关键词，读取页面内容，最后返回结果。

整个过程大概 20-30 秒，取决于网络速度和 LLM 响应时间。第一次跑的时候我有点紧张，看着日志里一行行刷出来，感觉像在看一个机器人替你干活。

代码解读

几个关键参数：

• task：自然语言描述的任务。写得越具体越好，别写"帮我查点东西"，写"去 xxx 网站搜索 xxx 关键词，返回前 5 条结果的标题和链接"。模糊的任务描述会导致 Agent 反复试探，浪费 token。
• llm：用哪个大模型。ChatBrowserUse 是 browser-use 自己优化过的模型，专门针对浏览器操作场景训练的，官方说比通用模型快 3-5 倍。你也可以用 ChatOpenAI、ChatAnthropic 等。
• browser_profile：浏览器配置。headless=True 在服务器上必加，allowed_domains 限制浏览器只能访问指定域名，安全起见建议加上。不加的话 Agent 可能会跑到不相关的网站去。

进阶用法：自定义工具

browser-use 最强的地方在于可以给 Agent 添加自定义工具。比如你想让它在抓到数据后保存到本地文件：

from browser_use import Tools

tools = Tools()

@tools.action(description='将抓取到的数据保存到本地文件')

def save_to_file(filename: str, content: str) -> str:

    with open(filename, 'w', encoding='utf-8') as f:

        f.write(content)

    return f"已保存到 {filename}"

agent = Agent(

    task="去 Hacker News 首页抓取前 10 条新闻标题，保存到 hn_titles.txt",

    llm=llm,

    tools=tools,

)

这样 Agent 就能在浏览器操作和本地文件操作之间无缝切换。你甚至可以接入数据库、发邮件、调 API，只要你能写成 Python 函数，都能变成 Agent 的"手"。

我目前在用这个功能做竞品监控：让 Agent 定期去几个网站抓内容，保存到本地，然后用另一个脚本做分析。整个流程全自动，我只需要看结果。

真实场景：自动填表单

browser-use 的官方 demo 里有个自动填写求职申请表的例子，我觉得挺有代表性。实际场景中，自动填表、自动下单、自动提交这类需求特别多。

核心思路就是：

agent = Agent(

    task="""

    去 xxx.com 的注册页面，填写以下信息：

    - 用户名：testuser

    - 邮箱：test@example.com

    - 密码：TestPass123!

    填完后不要提交，等我确认

    """,

    llm=llm,

    browser_profile=BrowserProfile(headless=False),  # 建议先不开 headless，看着它操作

)

注意最后那个"不要提交"。在调试阶段，一定要加上这种安全约束。我有一次忘了加，Agent 直接帮我提交了一个测试表单，还得去后台手动删。

踩坑大全

折腾一下午，踩的坑比写的文章还多。列一下关键的：

坑1：allowed_domains 设太窄

我一开始把 allowed_domains 设成了 ["github.com"]，结果 Agent 搜东西的时候需要跳转到 api.github.com，被拦住了。后来改成 ["*.github.com"] 才解决。这个通配符的写法文档里没说清楚，我试了好几次。

坑2：页面加载太慢

有些网站加载特别慢（特别是国内的网站），Agent 等不及就开始操作了，结果点到了错误的元素。browser-use 有个 wait_for_page_load 参数可以调，但说实话文档里写得不太清楚，我试了几次才找到合适的值。

我的经验是：国内网站设 5 秒以上，国外网站 3 秒就够了。如果网站有大量 AJAX 动态加载，可能还需要更长。

坑3：验证码和反爬

这是所有浏览器自动化工具的通病。大部分主流网站都有反爬机制，检测到是自动化浏览器就会弹验证码。browser-use 本身不解决这个问题，需要配合代理 IP 和浏览器指纹伪装。它的 Cloud 版本有这些功能，但开源版没有。

我在测试抓取某电商网站价格的时候，跑了不到 10 次就被封了 IP。后来换了 Cloud 版本的代理才搞定。

坑4：LLM 理解偏差

有时候 LLM 会"理解错"页面上的内容。比如一个按钮写着"Submit"，它可能理解成"提交搜索"而不是"提交表单"。这跟具体的 LLM 能力有关，用更强的模型（比如 Claude Opus 或 GPT-5.5）会好很多。

我在测试一个复杂的多步骤表单时，大概有 30% 的概率会在某一步搞错。后来把任务拆成更小的步骤，每步只做一件事，成功率提高了不少。

坑5：内存占用

Chromium 浏览器吃内存是出了名的。我在一台 2GB 内存的服务器上跑，直接 OOM 了。建议至少 4GB 内存，跑复杂任务的话 8GB 起步。

如果你同时跑多个 Agent，每个 Agent 都会启动一个浏览器实例，内存占用会翻倍增长。我目前的做法是用一个队列控制并发数，最多同时跑 2 个 Agent。

坑6：异步编程的坑

browser-use 的 API 全是异步的，用 asyncio。如果你的主程序是同步的，需要在事件循环里跑：

import asyncio

async def my_task():

    agent = Agent(...)

    return await agent.run()

# 在同步代码中调用

result = asyncio.run(my_task())

别在已经运行的事件循环里再调 asyncio.run()，会报错。如果你在 Jupyter Notebook 里跑，用 await 直接调用就行，Notebook 本身就有事件循环。

多步骤任务编排

browser-use 支持多步骤任务编排。你可以把一个复杂任务拆成多个小步骤，每步做一件事：

from browser_use.beta import Agent, BrowserProfile, ChatBrowserUse

import asyncio

async def main():

    llm = ChatBrowserUse(model='openai/gpt-5.5')

    profile = BrowserProfile(headless=True, allowed_domains=["*.github.com"])

    # 第一步：搜索

    agent1 = Agent(

        task="去 GitHub 搜索 browser-use 项目",

        llm=llm,

        browser_profile=profile,

    )

    history1 = await agent1.run()

    # 第二步：获取详情

    agent2 = Agent(

        task="打开 browser-use 仓库的 README，找到安装命令",

        llm=llm,

        browser_profile=profile,

    )

    history2 = await agent2.run()

    print(history2.final_result())

if __name__ == "__main__":

    asyncio.run(main())

这样每步都能拿到上一步的结果，逻辑更清晰，出错也好定位。

我之前试过一步到位的复杂任务，Agent 经常在中途迷路。拆成小步骤之后，成功率提高了不少。

错误恢复和调试技巧

browser-use 的 Agent 内置了错误恢复机制。如果某一步操作失败（比如元素找不到、页面加载超时），它会自动重试几次。但有时候重试也救不了，需要你手动介入。

调试的时候，建议先不开 headless 模式，看着浏览器窗口操作。这样你能直观地看到 Agent 在干什么，哪里搞错了。

另外，history 对象里有完整的操作记录，包括每一步的截图和 LLM 的决策过程。出错的时候可以回溯：

history = await agent.run()

# 查看每一步的操作

for step in history.steps():

    print(step.action)      # 做了什么

    print(step.screenshot)  # 截图路径

    print(step.llm_output)  # LLM 的决策

这个功能在调试复杂任务的时候特别有用。我有一次 Agent 在一个表单页面卡住了，看了操作记录才发现是它把"省份"下拉框理解成了"城市"。

跟 Playwright MCP 的区别

之前写过 MCP 相关的文章，有人问 browser-use 跟 Playwright MCP 有什么区别。简单说：

Playwright MCP 是一个 MCP 服务器，它给 AI Agent 提供浏览器操作的工具（点击、输入、截图等）。你需要自己写 Agent 逻辑来编排这些工具。适合已经在用 MCP 生态的场景。

browser-use 是一个完整的浏览器 Agent 框架。它内置了 Agent 逻辑、任务规划、错误恢复等。你只需要给任务描述，它自己搞定一切。适合快速实现浏览器自动化。

两者不冲突，甚至可以配合使用。比如你可以在 Claude Code 里通过 MCP 调用 Playwright，也可以用 browser-use 做独立的自动化脚本。

选哪个？看你的场景：

• 如果你已经在用 Claude Code / Cursor 这类工具，想给它们加浏览器能力 → Playwright MCP
• 如果你想做一个独立的浏览器自动化脚本 → browser-use
• 如果你想快速验证一个想法 → browser-use（上手更快）
• 如果你需要精细控制每一步操作 → Playwright MCP（更灵活）

CLI 模式：不用写代码也能用

browser-use 还有个 CLI 模式，不用写 Python 代码就能操作浏览器：

browser-use open https://github.com    # 打开网页

browser-use state                       # 查看页面元素

browser-use click 5                     # 点击第 5 个元素

browser-use type "Hello"                # 输入文字

browser-use screenshot page.png         # 截图

browser-use close                       # 关闭浏览器

CLI 模式会保持浏览器在命令之间持续运行，不用每次都重新启动。调试的时候特别方便。

我个人更喜欢用 Python API，因为可以写更复杂的逻辑。但 CLI 模式适合快速测试，比如你想看看 Agent 对某个页面的理解对不对，用 state 命令一目了然。

跟 Claude Code 集成

browser-use 还提供了 Claude Code 的 Skill，可以直接在 Claude Code 里用浏览器：

mkdir -p ~/.claude/skills/browser-use

curl -o ~/.claude/skills/browser-use/SKILL.md \

  https://raw.githubusercontent.com/browser-use/browser-use/main/skills/browser-use/SKILL.md

装完之后，Claude Code 就能直接调用浏览器了。写前端代码的时候让它自己打开浏览器验证效果，挺爽的。

我试过让它帮我检查一个网页的 CSS 布局问题，它自己打开浏览器、截图、分析、给出修改建议，整个过程全自动。比我自己开 DevTools 一个个检查快多了。

成本考量

browser-use 本身免费开源，但 LLM 调用要花钱。一次浏览器操作任务大概需要 5-20 次 LLM 调用（取决于任务复杂度），按 GPT-5.5 的价格算，一次任务大概 $0.01-$0.1。

如果你的任务量大（比如每天跑几百次自动化），建议用 browser-use 自己的 bu-* 模型，官方说性价比更高。或者用本地模型（Ollama），但效果会差一些。

我目前每天大概跑 20-30 次自动化任务，用 ChatBrowserUse 的 bu-2-0 模型，一个月下来大概 $10-15。比我之前用 GPT-5.5 便宜了差不多一半。

常见问题

Q：browser-use 跟 Selenium 有什么区别？

Selenium 是传统的浏览器自动化工具，你需要写 CSS 选择器、XPath 来定位元素。browser-use 用 LLM 看页面，自然语言描述任务就行。Selenium 更适合结构化、稳定的自动化测试；browser-use 更适合多变的、需要"理解"的场景。

Q：能用免费的 LLM 吗？

可以用 Ollama 跑本地模型，但效果会差很多。browser-use 的操作依赖 LLM 对页面的理解能力，小模型容易搞错。建议至少用 Claude Sonnet 或 GPT-4o 级别的模型。说实话，省那点 API 费用，换来的是任务频繁失败和大量重试，算下来不一定划算。

Q：支持哪些浏览器？

默认用 Chromium（通过 Playwright）。理论上支持所有 Playwright 支持的浏览器，但 Chromium 是测试最充分的。

Q：能处理 iframe 吗？

可以。browser-use 会自动识别页面中的 iframe，并在 iframe 内部操作。但如果 iframe 有跨域限制，可能会有问题。

Q：任务失败了怎么办？

browser-use 内置了重试机制。如果连续失败，建议把任务拆小，或者加更详细的约束条件。调试时用 headless=False 看着它操作最直观。

我的实际使用场景

折腾了一下午之后，我目前在用 browser-use 做这些事：

1. 自动检查文章排名：定时去 Google 搜索我的文章关键词，看看排在第几页。之前都是手动查，现在写了个脚本自动跑。每天早上跑一次，结果发到 Telegram。
2. 竞品监控：定期抓取几个竞品网站的更新内容，保存到本地做分析。这个之前试过用 requests + BeautifulSoup，但很多网站有动态加载，抓不到内容。browser-use 直接用浏览器渲染，什么都能看到。
3. 批量注册测试账号：开发的时候需要大量测试账号，之前手动注册累得要死，现在让 Agent 代劳。不过要注意验证码问题，有些网站会弹验证码，Agent 处理不了。

说实话，最爽的不是省了多少时间，而是那种"终于不用自己干这些破事了"的感觉。以前这种重复性的网页操作，要么手动做，要么写一堆 Selenium 脚本维护。现在一句自然语言描述搞定。

后续计划

后面打算继续折腾几个方向：

• 把 browser-use 跟 n8n 接起来，做一个完整的自动化工作流。n8n 负责调度，browser-use 负责浏览器操作。这个组合应该能覆盖大部分自动化场景。
• 试试用本地模型（Qwen 3 或 DeepSeek）替代 GPT，看看效果能不能接受。本地模型最大的好处是没有 API 费用，但速度和准确性可能会差一些。
• 研究一下怎么绕过常见的反爬机制。这个比较敏感，但有些合法场景确实需要，比如监控自己网站的排名变化。

有啥问题评论区聊。browser-use 这个项目更新挺快的，建议关注 GitHub 的 release notes，新版本经常加新功能。如果这篇文章帮到了你，或者你也在折腾浏览器自动化，欢迎在评论区分享你的经验和踩过的坑。一个人踩坑太孤单，大家一起踩才热闹。

• 本文写于 2026 年 6 月 16 日，browser-use 版本 0.13.x。如果版本更新导致某些 API 变了，以官方文档为准。浏览器自动化这个领域变化很快，半年前的教程现在可能就过时了，所以以最新文档为准是最稳妥的。*