2026 最新 Browser Use 使用指南：本地开源、Hosted MCP 与 Cloud 怎么选

如果你现在还在搜“Browser Use 使用指南”，通常不是还缺一篇“它可以点击网页、填写表单”的概念介绍，而是已经准备把它接进自己的工作流，却卡在一个更现实的问题上：我应该先从本地开源库开始，还是直接在 Claude Code / Cursor 里接 Hosted MCP，或者干脆一步到位上 Browser Use Cloud。

这个判断在 2026 年尤其重要。Browser Use 官网首页现在把自己定位成 “Agents at scale. Undetectable browsers. The API for any website.”，并在首页直接展示约 81.2k GitHub stars（Browser Use 官网；GitHub 仓库，2026-03-19）。这已经不是 2025 年很多中文文章里那个“给大模型配个浏览器”的单一 Python 库语境，而是一套同时覆盖开源、本地 IDE 接入、Cloud 浏览器基础设施、认证与会话管理的产品体系。

旧教程最容易误导你的地方，不是写错某个命令，而是把“能跑通 demo”写成“适合长期使用”。官方 Open Source Quickstart 当前给出的人工起步流已经是 pip install uv、uv venv --python 3.12、uv pip install browser-use 与 uvx browser-use install；GitHub README 则补充了从空项目直接 uv init && uv add browser-use && uv sync 的快捷写法。两条路都已经转向 uv 与 ChatBrowserUse()，而不是旧文章常见的 pip install 加 ChatOpenAI(model="gpt-4o")（Browser Use Open Source Quickstart；GitHub README，2026-03-19）。如果你还按旧路线判断，很容易在登录态、MCP、认证或成本问题上越走越偏。

TL;DR

• 如果你最在意可控性、想先在本地把 agent 跑通，并愿意自己管 Python 环境和模型 key，先用 Browser Use 开源库。
• 如果你真正想做的是“在 Claude Code / Cursor 里直接让 AI 打开浏览器做事”，Hosted MCP 往往是最短路径；官方当前给出的 MCP 地址是 https://api.browser-use.com/mcp（Browser Use MCP Server，2026-03-19）。
• 如果你已经开始碰到登录态、Cloud profile、2FA、长期任务、代理或 stealth 问题，不要再硬扛本地 demo，应该尽快切到 Browser Use Cloud。Cloud 当前按 任务初始化费 + step 计费 + session 小时费 计费，browser-use-2.0 默认 step 价格约 $0.006，Browser Session 约 $0.06/小时（Browser Use Cloud Pricing，2026-03-19）。
• 这篇文章最重要的两个交付物是一张 三路线选择矩阵，以及一张 国内团队收束选择表。如果这两项都回答不了你的场景，说明你还不该急着写生产代码。

为什么 2026 年的 Browser Use 已经不是单一 Python 库

先把产品地图讲清楚，否则后面的“怎么用”都会变形。今天的 Browser Use 至少有三层路径。

第一层是你最熟悉的开源库，也就是本地 Python agent 路线。官方 Open Source Quickstart 现在还是最适合拿来做第一轮验证，因为你能最快看到环境、模型、浏览器控制之间到底是怎么配合的（Browser Use Open Source Quickstart，2026-03-19）。如果你只是想验证“这个任务 Browser Use 到底能不能做”，从这里起步没有问题。

第二层是 Hosted MCP。官方文档已经把它明确写成支持 Claude Code、Claude Desktop、Cursor、Windsurf 和 ChatGPT 的 MCP 入口，URL 是 https://api.browser-use.com/mcp（Browser Use MCP Server，2026-03-19）。这条路线的价值不在于“更炫”，而在于它把“让 AI 编辑器直接接浏览器能力”这件事做成了配置问题，而不是一段你自己维护的桥接代码。

第三层是 Browser Use Cloud。Cloud 不是简单的“远端执行”而已，官方当前首页和 Cloud 文档都把它定位成带 stealth browsers、CAPTCHA solving、residential proxies、managed infrastructure、sessions & profiles 的托管能力层（Browser Use Cloud Introduction，2026-03-19）。换句话说，本地开源库解决的是“能不能做”，Cloud 解决的是“能不能把它长期、稳定、带登录态地跑下去”。

真正危险的误判，是把这三层混成一件事。很多中文教程的问题不在于写得太浅，而在于默认用户只需要一个 demo，于是把 Browser Use 写成“装个库，选个模型，跑个例子”就结束了。但你只要稍微靠近真实业务，比如要登录后台、持续抓数据、在 Cursor 里交给 AI 助手直接操作浏览器，这套旧结构就不够用了。

先看结论：本地开源库、Hosted MCP、Cloud 三条路线怎么选

如果你不想先看一堆命令，先用这条最短判断：你主要在写代码、想理解 agent 逻辑，先从本地开源库开始；你主要在 Claude Code / Cursor 里下自然语言指令，让 AI 帮你操作网页，先看 Hosted MCP；你一旦开始碰登录态、Cloud profile、stealth 或团队协作，就别再犹豫，应该上 Cloud。

官方文档本身并没有把这个判断一次说完。Quickstart 讲安装，MCP 页面讲编辑器接入，Authentication 页面讲 cookies、1Password 和 TOTP，Pricing 页面再讲 step 与 session 计费（Browser Use Open Source Quickstart；Browser Use MCP Server；Authentication & 2FA；Browser Use Cloud Pricing，2026-03-19）。单页都很清楚，但如果你是中文读者，最缺的恰恰是把它们收束成一次性可执行判断。

下面这张矩阵可以直接作为第一轮判断：

如果你还是拿不准，可以再用一句更直接的话收束：本地开源库适合“验证”；Hosted MCP 适合“直接给 AI 编辑器用”；Cloud 适合“把浏览器自动化当成真实基础设施”。

还有一个很实用的判断角度，是看“你的瓶颈到底落在哪一层”。如果你卡在 prompt 怎么写、任务能不能做成、某个网站元素能不能识别，那还是本地验证问题；如果你卡在“我已经知道能做成，但想在 Cursor 里每天都这么用”，那是 MCP 问题；如果你卡在“这个流程需要保存登录状态、需要共享给团队、需要长时间稳定执行”，那就已经是 Cloud 问题。把瓶颈分层，比反复比较哪条路线“更先进”有效得多。

10 分钟跑起第一个本地 Browser Use agent

只要你还在“验证阶段”，本地开源库仍然是最干净的入口。官方当前 Open Source Quickstart 推荐先用 uv 建环境，再用 uv pip install browser-use 和 uvx browser-use install 完成安装；如果你本来就在一个全新的项目目录里，GitHub README 还提供了 uv init && uv add browser-use && uv sync 这条更偏项目脚手架的起步方式（Browser Use Open Source Quickstart；GitHub README，2026-03-19）。这和很多 2025 文章里的旧写法不同，最大的好处是安装路径和后续 CLI 工作流更一致。

最小起步命令可以直接照着官方路线写：

bash复制
pip install uv
uv venv --python 3.12
source .venv/bin/activate

uv pip install browser-use
uvx browser-use install

然后在 .env 里放上 Browser Use 的 key。官方当前默认示例使用 BROWSER_USE_API_KEY 配合 ChatBrowserUse()（Browser Use Open Source Quickstart，2026-03-19）：

bash复制
BROWSER_USE_API_KEY=your_key_here

第一个可运行的 Python 例子可以这样写：

python复制
from browser_use import Agent, ChatBrowserUse
from dotenv import load_dotenv
import asyncio

load_dotenv()

async def main():
    agent = Agent(
        task="打开 Hacker News，告诉我当前排名第一的帖子标题",
        llm=ChatBrowserUse(),
    )
    await agent.run()

if __name__ == "__main__":
    asyncio.run(main())

这里有两个判断值得你提前知道。第一，官方把 ChatBrowserUse() 放在默认路线，并强调它是为浏览器自动化优化过的模型路径；Quickstart 直接写它完成任务通常更快，而 Supported Models 页面给出的当前价格也比很多自备 frontier 模型温和得多（Browser Use Open Source Quickstart；Browser Use Supported Models，2026-03-19）。第二，本地跑通不代表你以后就应该一直停留在本地，因为登录态、MCP、共享 profile 和长期运行这些问题，本地阶段通常都只是被暂时绕过去了。

如果你坚持用自己的模型提供商，官方当前也支持 Google、OpenAI、Anthropic、Azure、Ollama、Qwen、DeepSeek 等路线（Browser Use Supported Models，2026-03-19）。但这时候你要分清一件事：你换的是“模型供应商”，不是“浏览器基础设施”。只换模型，不会自动帮你解决登录态、session、stealth 或 IDE MCP 集成。

本地阶段我建议你至少刻意验证三件事。第一，任务是否真的能在 8-15 步内收束，而不是刚开始看着能跑，后面一步步失控。第二，你依赖的网页是否经常出现登录弹窗、动态加载或人机验证，如果是，就不要过度乐观。第三，你的输出到底是“一次性拿结果”还是“后续要反复执行”，因为这会直接决定你还要不要往 MCP 或 Cloud 升级。

很多团队在这里会犯一个常见错误：看到本地 agent 能打开浏览器、点几下按钮，就以为路线已经定了。其实本地阶段更像技术可行性评估，而不是架构定案。你真正要观察的，不是第一遍能不能跑，而是第二遍、第三遍、换一个账号、换一个页面之后是否还稳定。这也是为什么我建议把本地路线理解成“第一站”，不要理解成“默认终点”。

Claude Code / Cursor 怎么接 Browser Use MCP

很多人真正想做的并不是写一段 Python 代码，而是在 Claude Code 或 Cursor 里直接说一句“帮我打开某个页面，读出表格，顺手把结果总结一下”。对这种场景，Hosted MCP 比本地 agent 更直接，因为它把“模型如何调用浏览器”变成了一个 MCP 配置问题。

官方当前把 Hosted MCP 明确写成 HTTP 型 MCP server，地址就是 https://api.browser-use.com/mcp，并且明确说适用于 Claude Code、Claude Desktop、Cursor、Windsurf 和 ChatGPT（Browser Use MCP Server，2026-03-19）。Claude Code 的最短配置命令就是：

bash复制
claude mcp add --transport http browser-use https://api.browser-use.com/mcp

如果你主要在 Cursor 里使用，官方文档给出的核心配置形态如下（Browser Use MCP Server，2026-03-19）：

json复制
{
  "mcpServers": {
    "browser-use": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://api.browser-use.com/mcp",
        "--header",
        "X-Browser-Use-API-Key: your-api-key"
      ]
    }
  }
}

Hosted MCP 的最大价值，是你几乎不用自己维护一层“编辑器到浏览器”的桥接逻辑。更重要的是，它不是只能做最简单的网页导航。官方 MCP 页面当前列出的工具包括 browser_task、list_browser_profiles 和 monitor_task，也就是你不只是能发任务，还能列出可用 profile，并追踪执行状态（Browser Use MCP Server，2026-03-19）。这正是它比“自己随手写个浏览器脚本再塞进 AI 工具调用”更适合长期使用的地方。

如果你想更快决定 Hosted MCP 是否值得配，可以直接用这个判断：

如果你不想依赖 Hosted MCP，官方也保留了本地 stdio 路线。MCP 文档当前在概览里把这条入口短写成 uvx browser-use --mcp，而手动启动、Claude Desktop 配置和故障排查示例仍普遍使用 uvx --from 'browser-use[cli]' browser-use --mcp；两者都指向免费自托管选项，但这条路线需要你自己提供 OPENAI_API_KEY 或 ANTHROPIC_API_KEY（Browser Use MCP Server，2026-03-19）。所以本地 MCP 和 Hosted MCP 的核心区别不是“谁更高级”，而是“你到底更想省掉云侧配置，还是更想省掉本地维护”。

如果你确定想先走本地 stdio MCP，最关键的不是配出一个 JSON，而是把它当成“自己维护一台浏览器工具服务器”。官方当前给出的最低命令是：

bash复制
uvx --from 'browser-use[cli]' browser-use --mcp

这条路线的优点，是浏览器工具留在你本机、可控性高；缺点也很明显，就是你要自己处理 uvx 路径、provider key、浏览器启动失败、CLI addon 等问题（Browser Use MCP Server，2026-03-19）。如果你的真正需求只是“在 Claude Code 里直接拥有浏览器能力”，通常不值得从第一天就接手这些维护工作。

还有一点经常被忽略：Hosted MCP 不只是“让 AI 能点网页”，而是把 profile 与任务监控也一起带进来了。文档当前列出的 list_browser_profiles 和 monitor_task，本质上就是告诉你这条路线已经开始靠近“可复用工作流”，而不是简单的单次命令执行（Browser Use MCP Server，2026-03-19）。这也是为什么它非常适合日常研究、运营协助和编辑器内自动化，而不只是玩具 demo。

如果你还想把 MCP 本身的工作流再看宽一点，可以顺手参考这篇 MCP 浏览器自动化指南。但针对 Browser Use 这一个产品，最关键的仍然是先判断你是要“在 IDE 里直接用”，还是要“自己写 agent 逻辑”。

什么时候必须上 Cloud：登录态、认证与长期任务

最常见的误判是：本地 demo 能跑，用户就以为自己已经“会用 Browser Use”了。其实只要你的任务开始碰到登录网站、多步流程、长期运行、并发、代理或 stealth，你讨论的就不再是“Browser Use 的 API 怎么写”，而是“浏览器基础设施怎么托管”。

GitHub README 现在对这件事讲得很直接。它在 production FAQ 里明确说，如果你要处理可扩展浏览器基础设施、内存管理、代理轮换、stealth browser fingerprinting 和高性能并行执行，应该使用 Browser Use Cloud API（GitHub README，2026-03-19）。这不是营销语气，而是产品边界说明。

Cloud 最重要的两个能力不是“快”而已，而是 sessions/profiles 和 authentication。Authentication 文档当前把 Cloud profile、cookie 同步、domain-scoped secrets、1Password 集成、TOTP / 2FA 都列成正式能力（Authentication & 2FA，2026-03-19）。如果你的任务需要登录后台、复用会话，或者不想把认证逻辑硬塞在本地脚本里，Cloud 是明显更合理的路径。

一个最小的 Cloud 心智模型可以理解成：本地 agent 适合“给我跑一下这个任务”，Cloud 适合“帮我托管一套能长期复用的浏览器执行环境”。这也是为什么 Cloud Quickstart 单独用 browser-use-sdk 起步，而不是继续沿用开源库的默认安装路线（Browser Use Cloud Quickstart，2026-03-19）。

如果你已经明确要试 Cloud，最小起步动作其实很简单：先装 SDK，再放入 BROWSER_USE_API_KEY，然后再决定是不是要引入 session 与 profile。官方 Cloud Quickstart 当前就是把 browser-use-sdk 作为单独入口，而不是让你继续在开源库上硬扩（Browser Use Cloud Quickstart，2026-03-19）：

bash复制
pip install browser-use-sdk
export BROWSER_USE_API_KEY=your_key_here

这一步的意义不在于多写两条命令，而在于它提醒你：从这里开始，你已经不再只是“让浏览器能被模型驱动”，而是在购买和配置一套托管执行环境。很多团队真正省下来的时间，不是来自 step 价格低了几美分，而是来自 profile、cookies、认证和长任务生命周期不再散落在本地脚本里。

成本也应该在这里一次讲清。Cloud 当前 pricing 写得很明确：

• 任务初始化费 $0.01/次
• 默认 browser-use-2.0 step 成本约 $0.006
• 一个 10 step 的任务示例总成本约 $0.07
• Browser Session 约 $0.06/小时，按分钟折算，提前停止会按比例退款（Browser Use Cloud Pricing，2026-03-19）

这意味着当你的任务足够短、本地环境也稳定时，继续留在开源库并不奇怪；但一旦你开始需要“持久登录态 + 可重入 session + 代理 / stealth + 更稳定的任务编排”，Cloud 往往不是“高级选项”，而是更便宜的总拥有成本。因为你节省的不是单次 step 费用，而是后面一整串排障、认证和稳定性工时。

判断是否该切 Cloud，我会看三个信号。第一，你开始频繁提到“账号”“登录”“验证码”“保持会话”。第二，你开始希望一个任务不是今天跑一次，而是明天、下周、换人接手后还能继续跑。第三，你发现自己花在环境排障上的时间，已经明显多于花在任务本身的时间。只要三条里命中两条，就别再把本地 demo 当长期方案。

再说得更具体一点，Cloud 特别适合三类任务。第一类是“登录后才有价值”的任务，比如后台巡检、CRM 更新、订单系统录入。第二类是“状态会积累”的任务，比如需要分多次执行、跨天继续、共享给同事复跑。第三类是“稳定性比一次跑通更重要”的任务，比如你已经准备把结果接到运营、销售或内部流程里。只要你的场景开始接近这三类，就没必要继续在本地脚本里硬塞越来越多的补丁。

国内团队怎么收束选择：官方、自备模型、聚合层分别适合谁

到了这一步，真正有用的问题就不再是“某家平台便不便宜”，而是“Browser Use 的浏览器层和模型层要不要一起买”。这是很多国内团队在落地时最容易混淆的地方。

如果你直接用 Browser Use 官方推荐路线，无论是本地开源库里的 ChatBrowserUse()，还是 Cloud 里的默认 browser-use-2.0，你买到的是一套更统一的“浏览器自动化 + 模型”组合。它的好处是路径最短，坏处是你需要接受官方当前的产品与计费方式。

如果你已经有自己的模型提供商，比如 OpenAI、Anthropic、Google 或其他 OpenAI-compatible 服务，那么 Browser Use 仍然可以只负责浏览器层，而把模型层交给你现有的 provider。Supported Models 页面说明了这一点：官方当前支持多家 provider 与多种部署形式，不强迫你只走一种模型入口（Browser Use Supported Models，2026-03-19）。

但如果你是中国团队，现实里经常还有第三种选择，也就是聚合层。这里必须讲清楚一条边界：聚合层通常只能解决“模型接入摩擦”，不能替代 Browser Use Cloud 的 profile、session、认证和 stealth 基础设施。也就是说，它能替你把模型 key 和 OpenAI-compatible 接口搞定，但不会自动把浏览器托管问题一起解决。

如果你需要一个更直接的收束表，可以看下面这一张：

拿 LaoZhang 这类聚合层举例，它当前文档写明支持 200+ 模型、OpenAI-compatible 接口，新账号提供 $0.05 测试额度，标准起充 35 元，并给出 base_url="https://api.laozhang.ai/v1" 的 OpenAI SDK 接法（老张 API 快速开始；老张 API 企业服务与定价，2026-03-19）。这对“先把模型接上、快速验证 Browser Use 能不能跑”的团队确实更省事，但它解决的是模型入口，不是浏览器基础设施本身。

所以国内团队真正稳的顺序通常是这样的：先决定浏览器层到底停在本地、MCP 还是 Cloud；再决定模型层是直接用 Browser Use 官方推荐路径，还是继续沿用你现有的 provider，或者临时用聚合层降低接入摩擦。只要这两个层次分清，很多原来看起来很乱的问题就会自动变简单。

如果你要把这句话说得更工程化一点，就是：先画清“浏览器控制面”和“模型调用面”的边界。前者决定你是否需要 Hosted MCP、Cloud profile、session、代理和认证；后者决定你是继续走官方推荐模型、自备 provider，还是临时用聚合层。很多“为什么 Browser Use 用着用着变复杂”的抱怨，本质上都是因为一开始就把这两层混成了一个问题。

反过来说，什么时候我不建议你先上聚合层？答案也很简单：当你真正卡住的是登录态、Cloud session、验证码、长期运行、代理或团队复用时。因为这时候你最缺的已经不是“另一个模型 base URL”，而是一套能把浏览器执行环境托起来的方案。继续在模型层反复切 provider，只会让问题看起来像是模型精度问题，实际上却是在回避浏览器基础设施问题。

常见问题

Browser Use 现在还适合直接照旧教程里的 pip install 开始吗？

如果你的目标只是“看看这个包能不能装上”，当然不是完全不行；但如果你想跟当前官方文档保持一致，不建议继续沿用旧教程。官方 Open Source Quickstart 当前明确给出的是 uv 环境工作流、uv pip install browser-use 和 uvx browser-use install，而 GitHub README 对空项目补充了 uv init && uv add browser-use && uv sync 这条更像项目初始化的写法，默认示例也已经切到 ChatBrowserUse()（Browser Use Open Source Quickstart；GitHub README，2026-03-19）。所以更准确的说法不是“旧命令一定错”，而是“旧命令不再是最值得推荐的起点”。

ChatBrowserUse() 和我自己接 OpenAI / Claude / Gemini，有什么本质区别？

本质区别不在“能不能跑”，而在“你是不是想把模型这层也一起收束掉”。官方当前把 ChatBrowserUse() 放在默认起步路线，并把它描述为更快、更省、专门为浏览器自动化优化的模型路径（Browser Use Open Source Quickstart；Browser Use Supported Models，2026-03-19）。如果你已经有现成的 provider 治理、预算或采购约束，继续用自备模型完全合理；但如果你只是想先减少变量，官方默认路线通常更省心。

Hosted MCP 和本地 stdio MCP，我该先配哪一个？

如果你主要场景是 Claude Code、Cursor、Claude Desktop 这类“AI 编辑器直接接浏览器”，先配 Hosted MCP。因为官方已经给了现成的 HTTP MCP 地址和配置块，维护成本最低（Browser Use MCP Server，2026-03-19）。只有当你非常明确地想把 MCP 完全留在本机、自己管理 provider key 和本地命令生命周期时，本地 stdio MCP 才更合适。

什么情况下我应该停止本地 demo，切到 Cloud？

最简单的判断标准是：一旦你开始认真讨论登录态、profile、2FA、session 复用、代理、stealth 或长期并发任务，就不要再把本地 demo 当作长期答案。Authentication 文档和 Cloud pricing 都说明，Cloud 解决的是“托管浏览器执行环境”这件事，而不是简单远程跑一下脚本（Authentication & 2FA；Browser Use Cloud Pricing，2026-03-19）。这类问题本来就不该由本地 demo 长期承担。

中国团队能不能只靠聚合层把 Browser Use 用起来？

能，但要知道自己到底省掉了什么、没省掉什么。像 LaoZhang 这类聚合层可以帮助你更快拿到 OpenAI-compatible 模型入口，并降低支付与测试摩擦（老张 API 快速开始；老张 API 企业服务与定价，2026-03-19）。但它不会自动替代 Browser Use Cloud 的 session、profile、cookies、2FA、代理或 stealth 能力。所以如果你最后还是要做登录网站、长任务和共享状态，聚合层最多只是模型层方案，不是整套 Browser Use 托管方案。

Browser Use Cloud 的成本大概怎么估才比较靠谱？

最稳的方式不是直接看月费，而是按“任务初始化费 + 平均 step 数 + session 时长”估。官方 pricing 当前给出的口径已经足够做第一轮预算：任务初始化 $0.01，默认 browser-use-2.0 约 $0.006/step，10 step 示例约 $0.07，Session 约 $0.06/小时（Browser Use Cloud Pricing，2026-03-19）。如果你的任务经常超过十几步、又需要登录态和长时间保持环境，Cloud 往往比你自己维护零散脚本更容易算清成本。

真正值得记住的结论其实很简单：先分清你在选“浏览器层”还是“模型层”，再决定 Browser Use 应该停在本地、Hosted MCP 还是 Cloud。路线一旦选对，Browser Use 会非常顺；路线一旦选错，后面每一个登录态、认证、成本和编辑器接入问题都会变得比它本身更麻烦。