browser-use：让 AI 代理像人一样操作浏览器的开源库，但别忽略它的云端依赖

它解决什么问题，给谁用

browser-use 解决的是 AI 代理无法操作网页的问题。多数 LLM 只能处理文本，碰到需要点击、输入、翻页的真实网站就无能为力。这个库让代理像人一样使用浏览器，打开页面、按按钮、填表单，最后完成任务。适用对象很明确：一是已有编码代理（Claude Code、Codex、Cursor 等）的开发者，想让代理顺手把网页任务也做了；二是要构建网页自动化产品的工程师，需要在代码里调度大量任务。README 给出的例子包括填写求职申请表、提取关注者数据并导出 CSV。它不是给普通用户用的，需要写代码或至少能操作命令行代理。

工作方式：从任务描述到浏览器操作

核心机制是把自然语言任务交给一个 Agent 对象，由 LLM 决定下一步操作。README 示例中，Agent 接收 task 字符串，llm 参数指定模型，然后 agent.run() 执行。底层会调用浏览器自动化，但文档没有公开 DOM 解析、动作生成的具体流程。从代码结构看，它依赖 Playwright 或类似工具控制浏览器，但 README 没有明确列出底层依赖。值得注意，它提供了 ChatBrowserUse 这个封装，专门针对浏览器任务优化，README 声称比通用模型快 3 到 5 倍。这意味着默认路径下，LLM 的调用是经过厂商服务的，不是纯本地推理。数据流大致是：任务文本进 Agent，LLM 产出动作序列，浏览器执行，结果反馈给 LLM 循环，直到任务完成。这个循环的具体实现细节在 README 里没有展开。

两种用法：CLI 技能与 Python 库

README 明确区分了两种使用场景。CLI 方式是给已有代理用的，你只需要把一段提示词粘贴给 Claude Code 或 Codex，代理会自己安装 browser-use、运行 browser-use skill install 注册技能，然后连接浏览器。这适合一次性任务，比如上传视频到 YouTube、比较三款笔记本电脑价格。Python 库则面向可重复的自动化，安装命令是 uv add browser-use 或 pip install browser-use，要求 Python 3.11 以上。之后在 .env 里配置 API 密钥，可以选 BROWSER_USE_API_KEY（云端密钥）或 GOOGLE_API_KEY、ANTHROPIC_API_KEY 等自带密钥。代码里用 Agent 类，llm 参数可以传 ChatBrowserUse(model='openai/gpt-5.5')，也可以换成 ChatOpenAI 或 ChatAnthropic。规则很简单：一次性任务走 CLI，重复自动化走 Python 库。

开源版与云端版的真实差距

README 用一张准确率对比图展示开源版和云端版的差异，但没给出具体数字。它承认云端代理明显更强大，适合复杂任务，并且有代理轮换、验证码破解、1000+ 集成、持久文件系统和内存。开源版则强调免费、本地运行、可深度定制。这里有个明显的取舍：开源版虽然代码是 MIT 许可，但 README 推荐配合云端浏览器使用，理由是更好的隐身性和扩展性。也就是说，如果你想要生产级的反检测能力，大概率要付费。此外，开源版的能力上限取决于你选的 LLM，而 ChatBrowserUse 模型本身是云端服务。所以开源版更像是一个入口，而不是一个完全独立的替代品。

模型选择是最大的变量

browser-use 的性能高度依赖 LLM 的选择。README 示例中列出了多个选项：ChatBrowserUse 的默认模型 openai/gpt-5.5，以及 bu-2-0-mini-preview（被描述为优化模型），还有 ChatOpenAI 和 ChatAnthropic。它声称 ChatBrowserUse 平均比其他模型快 3 到 5 倍，且准确率领先，但这个数据来自厂商自己的基准，没有第三方独立验证。如果你自带 API 密钥，可以用通用模型，但效果可能打折扣。另一个限制是，你必须在 .env 里至少配置一个密钥，否则 Agent 无法运行。对于想完全离线使用的人，这个库目前没有提供本地模型选项，README 里只提到云端或商业 API。

安装与上手：命令和配置

安装步骤很简单。先安装库：uv add browser-use 或 pip install browser-use。然后在项目根目录创建 .env 文件，写入 BROWSER_USE_API_KEY 或你自己的提供商密钥，比如 GOOGLE_API_KEY 或 ANTHROPIC_API_KEY。接着写一个异步脚本，导入 Agent 和 ChatBrowserUse，定义任务和模型，调用 agent.run()。README 还提供了一个 CLI 安装路径：在代理里粘贴一段提示词，代理会自动执行 browser-use skill install 并连接浏览器。如果失败，文档指向 browser-harness 的 install.md。注意，Python 版本要求是 3.11 或更高，README 在 CLI 提示中特别提到用 Python 3.12。

局限与失败模式

最大的局限是它依赖外部 LLM 服务，这意味着每次任务都会产生 API 费用，而且响应延迟受网络影响。如果任务涉及登录、验证码或复杂反爬机制，开源版可能失败，README 暗示这些场景需要云端服务。另一个问题是，README 没有说明错误处理机制，比如页面加载超时、元素找不到时 Agent 会怎么重试。对于需要高可靠性的生产环境，这可能是隐患。此外，CLI 技能依赖代理本身的能力，如果代理无法正确执行安装步骤，用户得手动排查。最后，MIT 许可只覆盖代码，不覆盖云端服务，商业使用时需要单独考虑 API 费用和条款。

替代方案与对比

直接替代品是 OpenAI 的 computer-use 代理或 Anthropic 的 computer use 功能，它们也试图让模型操作浏览器。区别在于，这些是封闭的 API，你无法看到内部动作生成逻辑，也无法自定义浏览器控制粒度。browser-use 的开源库允许你换任何 LLM，甚至自定义系统提示词，这对需要深度集成的人更有吸引力。另一个替代是传统的浏览器自动化框架如 Playwright 或 Selenium，它们不依赖 LLM，执行确定性脚本，但无法理解自然语言任务。browser-use 的定位是介于两者之间：用 LLM 做决策，用浏览器库做执行。如果你的任务固定且不需要理解语义，传统框架更便宜更稳定；如果需要灵活应对未知网站，browser-use 这类方案才有优势。

编辑结论

browser-use 适合两类人：一是已经在用 Claude Code、Codex 或 Cursor 等编码代理，想让它顺手完成浏览器任务的开发者，直接粘贴 README 里的安装提示即可；二是需要把网页自动化嵌入自己产品的工程师，Python 库提供了自定义 LLM 和细粒度控制。不建议把它当作完全自托管的免费方案，因为 README 明确推荐配合云端浏览器使用，且 ChatBrowserUse 模型和 1000+ 集成都在云端。在采用前，先验证三件事：你的 LLM API 密钥是否支持你选用的模型，任务是否涉及需要代理轮换或验证码破解的反爬场景，以及你是否接受 MIT 许可下但核心能力部分依赖商业服务的架构。如果只是偶尔跑几个任务，CLI 技能足够；若要大规模并行执行，先确认云端 API 的计费方式。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes