30 Mar 2026 15 min read 折腾日记

Browser Use CLI 完整教程（2026）：不用 MCP，也能让 AI 自己打开网页干活

最近不少人在聊 Browser Use CLI。我专门去翻了官方文档和 GitHub，发现它不是单纯的 Skill，而是一套真正能让 AI 操作网页的软件和命令行工具。这篇我把它到底是什么、怎么装、怎么用讲明白。

最近我连续看到两拨人在聊 Browser Use。

一拨是在 GitHub 和官方文档那边，定位说得很直接：这是一个拿来做 AI 浏览器自动化 的项目；另一拨是在中文社区，大家关心的则更现实：它到底是不是个 Skill、能不能直接拿来用、和 MCP 有什么关系、值不值得折腾。

我一开始也有点懵。

因为现在很多新工具都喜欢把自己包装成“Agent”、“自动化”、“Browser AI”，但真正落到手上，往往不是安装麻烦，就是只能演示，真要做点网页任务时还是卡住。

所以我把 Browser Use 的 官方 GitHub README、官方 CLI README、官方 docs 都翻了一遍。先说结论：

Browser Use CLI 不是一个“只有 Agent 能用的 Skill”，它本质上是一套软件和命令行工具；Skill 只是它的一种接入方式。

如果你现在最关心的是：

Browser Use CLI 到底是什么
它能干什么，不能干什么
它和 OpenClaw / MCP / Playwright 有什么区别
新手怎么装，怎么跑第一个网页任务

Browser Use CLI 到底是什么？

先别急着把它理解成“又一个大模型玩具”。

按官方文档的说法，Browser Use 的开源部分本质上是一个 Python library for AI browser automation。翻成正常中文，就是：

一个专门让 AI 去操作浏览器、完成网页任务的 Python 项目。

它的 CLI README 写得更直白：

Fast, persistent browser automation from the command line.

也就是：

一套可以在命令行里直接操作浏览器、而且会保持浏览器会话持续存在的工具。

这里有三个层次，最好分开看。

第一层：它是软件本体

最底层的 Browser Use，是一个浏览器自动化项目。你可以把它装到自己的机器上，让它去：

打开网页
获取页面状态
找到可点击元素
点击、输入、滚动、切标签页
截图
连接现有浏览器会话

这部分，和“有没有 Agent”没关系。

第二层：它有 CLI

Browser Use CLI 是这个项目给人的第一入口。

你不一定要先写 Python 代码，也不一定要先接 Claude Code、Cursor、OpenClaw。只要装好，它就能直接通过命令行去控制浏览器。

官方 README 里给出的最小上手流程就是：

browser-use open https://example.com
browser-use state
browser-use click 5
browser-use type "Hello World"
browser-use screenshot output.png
browser-use close

这个思路非常像“浏览器控制台 + 命令行遥控器”。

你可以先打开页面，再看当前有哪些可点击元素，然后根据索引点进去，继续输入和截图。因为浏览器会话会保留，所以它不是每条命令都重新开一个干净浏览器，这点很重要。

第三层：它还能被 Agent 调用

这也是很多人容易混淆的地方。

Browser Use 官方文档里明确提到，它可以和不同的 LLM、不同的 Agent 框架一起工作，还专门列了 OpenClaw 集成页面。官方 docs 里甚至直接写到：

可以通过 CDP 方式接入
也可以通过 CLI skill 的方式接入

所以它当然可以“变成某个 Agent 的能力”，但那是接入方式，不是它的全部。

更准确的说法是：Browser Use 本身是软件，同时提供 CLI，还能被包装成 Skill 或 Agent 能力。

它到底能拿来干什么？

如果你以前接触的是纯爬虫、Selenium 或 Playwright，你可能会问一句：

“这玩意不就是自动打开网页吗？”

还真不完全一样。

Browser Use 适合的是那种 更像人类在网页里干活 的任务。

场景 1：先打开网页，再按页面情况一步步操作

比如我想让它：

打开某个官网
点进定价页
看几个套餐差异
截图或者整理结果

这种任务的难点不是“会不会请求一个接口”，而是页面结构经常变，用户真正做事的时候也不是写死一步到位，而是：

先看，再点，再判断下一步。

Browser Use CLI 的设计就很适合这种节奏。

你先 open，再 state 看当前页面元素，再 click 或 input 继续走。

场景 2：复用真实浏览器登录态

这个是它比较实用的一点。

官方 CLI README 明确写了几种浏览器模式：

默认 headless Chromium
--headed 可视化浏览器
--profile "Default" 使用你真实 Chrome 的默认用户配置
--connect 自动发现并连接正在运行的 Chrome
--cdp-url 连接现有 CDP 浏览器会话

这意味着什么？

意味着它不是只能在一个“干净到什么都没登录过”的浏览器里工作。你完全可以让它去接你已经登录过账号的 Chrome，复用 cookie 和已有会话。

这一点对真实任务特别关键。

因为现实世界里很多网页自动化，最麻烦的不是“点按钮”，而是：

登录态、浏览器环境、风控、历史会话。

Browser Use 至少在工具层面，把这一步做得比很多“只会从头开一个沙盒浏览器”的方案更接地气。

场景 3：给更大的 Agent 工作流当“手”

如果你已经在用 OpenClaw、Claude Code、Cursor 这类东西，那 Browser Use 的价值就更容易理解了。

我自己的理解是：

OpenClaw / Claude Code 这类工具更像大脑，负责理解任务、安排步骤、调用能力
Browser Use 更像网页操作的手，负责在浏览器里真正去做动作

比如你让一个 Agent 帮你做信息整理，它很可能需要：

打开多个网页
点不同页面
搜索
切 tab
抓取文本
截图或导出

这时候 Browser Use 就很像一个专门负责网页执行的子模块。

它不是万能的：哪些情况别神化

说到这里，也得泼点冷水。

Browser Use 不是拿来替代一切网页自动化的。

第一，不是所有场景都适合它

如果你只是要：

抓固定页面 HTML
调一个现成 API
批量爬一堆结构稳定的数据

那很多时候直接用爬虫、接口脚本、Playwright 脚本会更省。

Browser Use 的优势不在“最便宜地跑一万个页面”，而在：

更像人类那样处理网页任务。

第二，风控、验证码、支付这些麻烦并不会凭空消失

官方 Cloud 版确实一直在强调 stealth、CAPTCHA solving、proxy、managed infrastructure，这些说明他们自己也知道，真实网页自动化绕不开这些问题。

但你要明白：

工具再强，也不代表任何网站都能稳定、无感、无限制地自动操作。

尤其是登录、验证码、支付确认、风控网站，这些还是要现实一点看。

第三，它也不是“万能 Skill”

很多人听到“可以接到 Agent”以后，会误以为它像装个插件那样，一切网页任务就自动丝滑了。

没这么简单。

接入 Agent 只是让它更好用，不代表网页本身的复杂度突然消失。

所以我更愿意把 Browser Use 看成：

一个把网页操作这件事做得更 Agent 化、更任务化的工具，而不是神奇魔法。

Browser Use CLI 怎么安装？

这里我只写官方文档里已经明确给出的方式。

根据官方 CLI README，前置要求是：

macOS / Linux：Python 3.11+
Windows：Git for Windows + Python 3.11+

官方推荐的安装方式分两类。

方法一：一行安装脚本

macOS / Linux：

curl -fsSL https://browser-use.com/cli/install.sh | bash

Windows PowerShell：

& "C:\Program Files\Git\bin\bash.exe" -c 'curl -fsSL https://browser-use.com/cli/install.sh | bash'

装完以后，官方建议先跑：

browser-use doctor
browser-use setup

doctor 是检查安装状态，setup 是跑一遍初始化向导。

方法二：手动安装

如果你不想直接跑一行脚本，官方也给了手动方案：

uv pip install browser-use
browser-use install
browser-use doctor

这里 browser-use install 的作用是安装 Chromium。

方法三：把它当 Python 项目来用

如果你更偏开发者用法，官方 README 里写的是：

uv init && uv add browser-use && uv sync

然后可以直接写 Python 代码，用 Agent、Browser 和不同的模型类去跑任务。

这一层已经不只是 CLI 了，而是直接用 Browser Use 的开源库。

Browser Use CLI 最小上手流程

如果你第一次接触这个工具，我建议别一上来就想着接 OpenClaw、接云浏览器、搞复杂任务。

先跑通最小流程。

第一步：打开网页

browser-use open https://example.com

这一步会自动拉起浏览器。

第二步：看页面当前状态

browser-use state

官方文档说明，这个命令会返回当前 URL、标题，以及可点击元素。

你可以把它理解成：

先看看页面上现在到底能点什么。

第三步：点击元素

browser-use click 5

这里的 5 是元素索引。不是 CSS selector，也不是 XPath，而是 CLI 当前识别出来的页面元素编号。

第四步：输入内容

如果当前焦点已经在输入框上：

browser-use type "Hello World"

如果你想直接点某个输入框再输入：

browser-use input 3 "john@example.com"

这个对登录页、搜索框很实用。

第五步：截图

browser-use screenshot output.png

第六步：关闭浏览器

browser-use close

你把这六步跑通，基本就已经理解 Browser Use CLI 的核心思路了。

还有哪些命令比较实用？

我翻官方 CLI README 的时候，觉得下面这些其实也挺关键。

导航相关

browser-use back
browser-use scroll down
browser-use scroll up
browser-use scroll down --amount 1000

键盘和表单相关

browser-use keys "Enter"
browser-use keys "Control+a"
browser-use select 4 "value"
browser-use upload 6 ./resume.pdf

信息读取相关

browser-use get title
browser-use get html
browser-use get text 7
browser-use get value 3
browser-use get attributes 5
browser-use get bbox 5

等待页面变化

browser-use wait selector "h1"
browser-use wait text "Success"
browser-use wait selector ".loading" --state hidden

如果你以前用过 Playwright，你会发现这些命令不复杂，但把它们揉到一个“持续存在的浏览器会话 + 命令行操作”框架里，体验会直观很多。

Browser Use CLI 的几个关键模式

我觉得这部分反而是很多教程最容易写漏的。

因为它决定了你到底是在一个“纯测试环境”里操作，还是已经开始接近真实任务了。

`--headed`

browser-use --headed open https://example.com

用可视化浏览器窗口，适合第一次调试。

`--profile`

browser-use --profile "Default" open https://gmail.com

这个模式会使用你真实 Chrome 的用户配置。

如果你已经登录过一些网站，这一招非常香，因为它能复用登录态和 cookie。

`--connect`

browser-use --connect open https://example.com

官方说明里写的是自动发现并连接正在运行的 Chrome。

`--cdp-url`

browser-use --cdp-url http://localhost:9222 open https://example.com

这就更适合进阶用法了。比如你已经有一个浏览器实例在跑，或者你要把 Browser Use 接到别的工作流上，就能通过 CDP 去接现成浏览器。

它和 MCP、OpenClaw、Playwright 到底什么关系？

这个问题很适合单独讲清，不然读到这里还是会乱。

它和 Skill 的关系

它不是单纯一个 Skill。

官方文档已经给出了很清楚的结构：

有开源库
有 CLI
有 Cloud SDK
有 OpenClaw 集成
有 MCP Server 集成

所以 Skill 只是它的接入层之一。

它和 MCP 的关系

MCP 更像一种“把能力暴露给外部 Agent 调用的协议/接入方式”。

Browser Use 则是那个真正执行网页动作的能力本体。

所以“Browser Use CLI 不用 MCP 也能自己跑”这句话是成立的；但如果你愿意，它也可以出现在 MCP 工作流里。

它和 OpenClaw 的关系

OpenClaw 是一个更完整的个人 AI 助手框架，本身包含消息、工具、记忆、自动化等能力。

Browser Use 更专注在网页操作这件事上。

官方 docs 里也有 OpenClaw 集成页面，说明这两者本来就不是竞争关系，而是很适合搭配。

如果你对这条线感兴趣，我之前那篇 OpenClaw 浏览器实战（2026）可以一起看。

它和 Playwright / Selenium 的关系

我自己的理解是：

Playwright / Selenium 更偏“脚本式浏览器自动化”
Browser Use 更偏“任务式、Agent 化的网页操作”

不是说后者一定替代前者，而是它们解决的问题重心不一样。

如果你的任务是固定页面、固定 selector、追求强确定性，那 Playwright 依然很好用。

如果你的任务更接近“像人一样在网页里做事”，Browser Use 会更顺手。

它适合谁？

我觉得最适合三类人。

第一类：已经在玩 Agent，但网页执行一直很弱的人

你会明显感觉到，很多 Agent 说得很聪明，但一遇到真实网页就开始打转。

Browser Use 刚好补的是这一块。

第二类：不想一上来就写大段浏览器脚本的人

CLI 这层很适合先快速试错。

先看看这个任务到底能不能做，再决定要不要把它写成更正式的自动化流程。

第三类：需要复用真实浏览器环境的人

像已有登录态、已有 cookie、已有本地 Chrome 环境，这些场景都比“纯无头浏览器”更贴近现实任务。

那值不值得折腾？

我的判断是：值得。

不是因为它会替你解决所有网页自动化问题，而是因为它代表了一条很清晰的新方向：

不是教 AI 看网页，而是让 AI 真能在网页里完成任务。

这条路比单纯写一个“浏览器截图 demo”要实在得多。

而 Browser Use CLI 的好处在于，它把这个方向做成了一个普通人也能直接上手的入口。你不用先写整套框架，也不用先接某个特定 Agent，先装、先跑、先点起来再说。

这也是为什么我觉得它很适合写。

它已经不只是“又一个 AI 新项目”，而是在往真正可落地的网页执行层走。

FAQ

Browser Use CLI 是 Skill 吗？

不是。更准确地说，它本身是 Browser Use 项目提供的 CLI 工具；另外它也可以被 Agent 以 Skill 或集成方式调用。

Browser Use CLI 能单独用吗？

能。官方 CLI README 里已经给出了完整的单独安装和命令行使用方式。

它一定要配 Cloud 才能用吗？

不一定。开源库和 CLI 都可以本地使用；但官方也提供 Cloud，主打更强的 stealth、代理、CAPTCHA 处理和托管基础设施。

它和 OpenClaw 冲突吗？

不冲突。官方 docs 里本来就提供了 OpenClaw 集成说明。更适合的理解是：OpenClaw 负责任务编排，Browser Use 负责网页执行。

新手最先该试什么？

我建议就从这几条开始：

browser-use open https://example.com
browser-use state
browser-use click 1
browser-use screenshot test.png
browser-use close

能把这个最小流程跑通，再去碰 profile、CDP、Cloud、Agent 集成都不迟。

如果你接下来还想继续往下折腾，我建议下一步直接看两个方向：

一是把它接到现有 Agent 工作流里
二是找一个真实网页任务，比如比价、表单填写、后台导出，拿它跑一遍

比起继续看十篇概念文章，自己让它真的点开一个网页，更能理解这东西到底值不值。

顺手贴两篇相关的，适合连着看：

本文核实来源

Browser Use 官方 GitHub README
Browser Use 官方 CLI README
Browser Use 官方文档（open-source introduction / supported models / docs index）