上个月我把 BrowserUse 部署到本地用几个真实任务做了一轮对比测试结果有点出乎我意料在网页自动化这个细分场景里这个开源智能体的稳定性和可控性确实比 Anthropic 官方的 Computer Use 更适合日常使用。这篇文章不吹某个工具而是把我从部署、实测到踩坑的完整记录以及那个超越的说法到底成不成立一起摊开来讲清楚。给打算做智能体评测或者正在选型网页自动化方案的朋友一个参考。先说下背景。我做智能体相关开发有一段时间了之前重度依赖 Anthropic 的 Computer Use后来在 GitHub 上看到 browser-use 这个开源项目Star 涨得飞快。它本质上是一个把浏览器控制能力封装成 Agent 的框架底层用 Playwright 控制浏览器上层接入各种大模型让模型通过观察页面 → 决策 → 执行操作 → 再看结果的循环完成真实网页任务。由于它完全开源、支持自定义模型、每一步操作都透明可见不少社区评测认为它已经超越了 Anthropic 的 Computer Use。这引起了我的兴趣。1. 同一件事两条截然不同的技术路径1.1 Computer Use 的思路让模型看懂屏幕Anthropic Computer Use 的思路很直接把屏幕截图传给 Claude模型根据像素级画面输出下一步动作比如移动鼠标、点击、输入文字、滚动页面然后由 Anthropic API 端执行这个动作再截图再决策如此循环。这个设计在 demo 视频里看起来确实科幻一套操作如行云流水。但实际用起来你会发现它有几个比较头疼的问题。首先是 token 消耗极其夸张。截图本身就是高密度 token 消耗源一张 1080p 的截图传到模型里动辄一千到两千个 token。一个稍微复杂点的任务比如登录、填表、提交整个流程下来要传几十张截图输入 token 轻松十几万甚至更高。我跑过一个三步操作的小任务账单让我愣了一下第一次意识到大模型操作电脑这件事的成本有多高。然后是准确率问题。模型对像素坐标的判断偶尔会偏移尤其是页面布局稍微变化一下或者弹窗出现、悬浮层遮挡时模型经常表现得像隔着一层毛玻璃操作电脑明明东西就在眼前点了几次都点不中。最让人难受的是调试体验。整个运行过程是一个黑盒你只能看到输入和输出——给了模型什么截图模型返回什么坐标。中间哪一步判断错了、为什么错了基本靠猜。1.2 BrowserUse 的思路把网页变成模型能读的文本BrowserUse 走的是完全相反的路子。它不截图而是把网页的 DOM 树经过压缩处理后转换成一段带元素编号的文本描述传给大语言模型。模型看到的不是一张图而是类似这样的信息[1044] button idsubmit classprimary提交订单/button然后模型只需要回答点击元素 1044BrowserUse 底层通过 Playwright 精确定位并点击这个元素。整个过程没有像素坐标没有鼠标移动的模糊判断网页元素在模型眼里是精确、可定位的。这个差异用一句话类比Computer Use 是让实习生盯着电脑屏幕干活累了还得揉眼睛BrowserUse 是直接给实习生一份带操作说明的网页源码让他在命令行里精准执行每一条指令。还有一个很大的不同——模型无关性。BrowserUse 不在框架层绑定任何特定大模型你可以用 OpenAI 的 GPT-4o、Anthropic 的 Claude、Google 的 Gemini甚至本地部署的 Ollama 模型。想省钱就换便宜模型想提升效果就换旗舰模型自由度极高。1.3 超越这个说法成立吗我在测试过程中也一直在审视这个问题。先说结论在网页自动化这个垂直领域BrowserUse 确实在多个关键维度上优于 Computer Use但超越不是全场景的Computer Use 能做到系统级操作这一点 BrowserUse 暂时还替代不了。对比维度Anthropic Computer UseBrowserUse操作范围整个桌面系统不限浏览器仅在浏览器内页面理解方式屏幕截图视觉像素DOM 压缩文本可选加视觉开源程度闭源 API完全开源、MIT 协议模型接入仅 Claude 系列任意 LLM兼容 OpenAI 接口调试能力黑盒难以逐步干预开放可观察、可中断、可注入运行环境Anthropic 云端本机执行数据不出本地单任务成本高截图 token 多低文本 token 少单看这张表结论很清楚只要你的任务场景限定在搞定浏览器里的流程BrowserUse 是更合理的选择。它更大的想象空间在于开源社区的迭代速度——我自己逛它的 GitHub issues 时看到开发者几乎每周都在加新功能这种迭代节奏是闭源 API 给不了的。2. 部署实录从零到跑通第一个任务2.1 本地环境准备部署 BrowserUse 比我想象的简单它本质是一个 Python 包依赖核心是 Playwright。以下是适合大多数人的完整步骤。# 1. 建虚拟环境避免污染系统 Python python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate # 2. 安装核心依赖 pip install browser-use playwright python-dotenv # 3. 安装 Chromium 内核 playwright install chromium # 4. 如果服务器是 Linux还需要装系统依赖库 playwright install-deps chromium这里有个细节值得说一下为什么需要虚拟环境因为 Playwright 会下载特定版本的 Chromium如果你系统里已经装了其他浏览器容易出现 Chromium 内核和系统库冲突的问题。用虚拟环境隔离是省心又干净的方案我一开始图省事直接装到全局结果被依赖版本冲突折腾了半天。Linux 服务器部署时playwright install-deps那一步特别重要。缺了系统库Chromium 很可能启动即崩溃而且报错信息往往很隐晦——通常是一堆找不到 so 文件之类的提示。建议部署到服务器时务必执行这步。然后配置 API Keyexport OPENAI_API_KEYsk-你自己的key如果用 Claude 就配置ANTHROPIC_API_KEY用本地模型就配置OLLAMA_API_BASE。我测试时主要用 OpenAI 的模型跑主流程Claude 做交叉验证。2.2 一个最小可运行的 Agent 脚本通读文档之后我写了一个最简单但完整的脚本import asyncio from browser_use import Agent from langchain_openai import ChatOpenAI async def main(): agent Agent( task打开 GitHub 搜索页面搜索 browser-use 这个项目把第一页结果里的 star 数告诉我, llmChatOpenAI(modelgpt-4o-mini, max_tokens4096), max_steps15, use_visionTrue, # 是否把截图也传给模型 generate_gifFalse, # 是否生成操作过程 GIF ) history await agent.run() print(history) asyncio.run(main())第一次跑通的瞬间我还挺兴奋的——模型自己完成了打开浏览器、输入搜索词、点击结果、读取 star 数、总结回答的全过程。gpt-4o-mini这个模型比较便宜但在这个任务上表现不差。注意max_steps这个参数我建议一开始就设置。Agent 循环如果失控可能会在某个页面上无限重试没有上限的话费用会像漏水一样。15 步对于大部分简单任务足够复杂任务可以放宽到 40。2.3 自定义输出结构BrowserUse 的一个突出特性是可以让模型输出带结构化字段的结果而不只是自然语言。例如task 完成以下任务 1. 打开 Wikipedia 首页 2. 找到今天的特色条目 3. 返回一个 JSON 对象{article_title: ..., description: ...} 配合output_model参数你可以定义 Pydantic 模型来强制约束输出格式。这个能力在实际项目里相当好用——比如定时采集网页数据、做价格监控、生成结构化报告等场景输出的数据可以直接落库不用再写解析逻辑。我在测试数据聚合任务时就感受到了这个特性的便利。3. 四组实测任务表现到底怎么样跑通 Demo 只能算热身真正有价值的是拿真实任务压测。我选了四个典型场景覆盖日常使用的绝大多数情况。3.1 搜索类任务打开浏览器、搜索、提取信息第一个任务我直接让它去 GitHub 搜项目并返回 star 数量。整个流程模型走了大概 8 步打开浏览器、访问 GitHub、定位搜索框、输入关键词、点击搜索、等待结果加载、解析结果、输出 star 数。表现稳定没有多余操作。gpt-4o-mini在这个环节的优势是速度快、成本低全程 token 消耗还不到 1 万。我把同样的任务描述改用gpt-4o跑了一轮发现推理路径没有什么本质差别只是响应更快对页面元素的理解更聪明一些——遇到 cookie 弹窗时4o-mini 会犹豫4o 基本能直接判断出这是无需操作的弹层。3.2 登录与填表任务多步骤交互型场景第二个任务模拟了常见的表单填写场景。我用了 httpbin.org 提供的测试表单让它填写姓名、电话、邮箱三个字段并提交。这个任务的关键在于模型必须先识别出可交互的输入框然后逐个填充最后找到提交按钮。BrowserUse 的 DOM 文本模式在这里优势明显每个输入框都有精确的元素编号不会出现 Computer Use 那种点输入框结果点到输入框外面的情况。实测结果gpt-4o-mini 顺利完成了全程包括提交后的响应结果确认。整个流程让我有点意外地顺利因为表单填写类任务在传统 RPA 里算中高难度了。3.3 跨页面的数据聚合任务第三个任务稍微提高难度先访问一个词条页面提取基本介绍再打开另一个页面补充数据最后汇总返回一个 JSON。这是最能拉开差距的场景。因为每一步都需要模型记住前一个页面的信息再迁移到新页面对上下文管理能力要求较高。实测中 gpt-4o-mini 在这个任务上开始吃紧——偶尔会在第二个页面忘了任务目标或者提取的信息张冠李戴。换用 gpt-4o 后问题明显减少。这给我一个很重要的体感模型能力直接影响智能体表现上限框架本身能解决怎么做但做得对不对还是要靠模型自己。3.4 和 Computer Use 的同任务对比观测我无法在这里给出一个严格受控的自动化对比实验毕竟两端模型、成本、运行环境都不同。但我可以把之前用 Computer Use 跑类似任务的体验拿出来对照。在登录填表这个任务上Computer Use 出现过一次知道该输入内容但定位不准的问题。原因是页面上输入框旁边有浮动提示文字截图传递给模型后模型认为提示区域就是输入框多次点击未生效。BrowserUse 完全不存在这个问题因为它直接读 DOM 元素输入框的 ID、类型、位置在文本描述里写得明明白白。Cross-page 聚合任务方面Computer Use 在长任务里的 token 消耗增速惊人截图越来越多上下文越来越长到后面的步骤甚至可能出现忘记初始任务的情况。BrowserUse 每步只传递当前页面的 DOM 文本上下文更加精炼长任务表现更稳。4. 成本账两个方案放在一起算算4.1 为什么 token 消耗差距这么大这是所有对比里最直观的一项。Computer Use 每一步操作都要传截图一张截图相当于上千 tokenBrowserUse 传的是压缩后的 DOM 文本一个典型页面大概 2000-4000 token。同样一个搜索并返回结果的任务Computer Use 大约传 10-15 张截图输入 token 总量轻松达到 3-6 万BrowserUse 全程输入 token 通常在 1-2 万之间而且这些 token 是文本单价远低于图像 token打个比方一个是让员工每看一眼屏幕都付一次高清照片的钱一个是直接甩给他一份普通人就能看懂的文本说明书。4.2 用当前公开 API 价格做的费用估算以下是我测试时记录的近似成本具体的 API 价格会随时间和服务商调整但数量级可以作为参考方案配置单任务输入 token 估算单任务费用估算BrowserUse GPT-4o-mini1-2 万约 0.01-0.03 美元BrowserUse GPT-4o1-2 万约 0.05-0.10 美元BrowserUse Claude 3.5 Sonnet1-2 万约 0.05-0.15 美元Anthropic Computer Use5-10 万约 0.3-1.0 美元以上这只是单个任务的成本。如果做价格监控、批量数据采集或者每天跑几百上千次任务这个差距会直接决定方案可行性。成本敏感的场景BrowserUse 的优势是压倒性的。4.3 本地模型能不能用我在测试中也用 Ollama 加载了 Qwen 系列的本地模型试了试。对于简单的点击、读取操作本地模型跑得有模有样一旦任务复杂到需要多步推理本地模型的判断力明显弱于云端旗舰模型经常在某个页面环节卡住。我的建议是如果你只是拿它做自动化测试或者任务链路比较固定本地模型是个零成本的好选择如果任务需要复杂推理和临场应变宁可多花一点 API 费用用好一点的云端模型。把 BrowserUse 当作模型即插即用的框架不同任务搭配不同模型这才是它的核心优势所在。5. 踩过的坑和调优经验记录5.1 最大的坑视觉模型也会看不见弹窗我一度以为开启use_visionTrue后模型既能读 DOM 又能看截图双保险万无一失。结果在某个电商网站上页面突然弹出促销浮层模型虽然在视觉上看到了弹窗但因为 DOM 文本里没有这个浮层的明确按钮它在第一次尝试关闭时失败了。后来我发现这不是 BrowserUse 的缺陷而是模型决策机制的问题——当视觉信息和文本信息出现冲突时模型容易犹豫。解决办法是给 Agent 增加一个自定义动作函数检测到弹窗时优先尝试点击关闭按钮。这个经验也说明了为什么开源框架值得用遇到问题你可以直接改代码、注入自己的逻辑而不是等官方修复。5.2 DOM 过长被截断的问题有些页面 DOM 结构非常庞大比如后台管理系统、长列表页面。BrowserUse 默认会把 DOM 压缩后传给模型但遇到长页面还是可能超过模型上下文窗口导致模型看到的页面不全。解决方法有三个在任务描述里明确告诉模型只需要关注某个区域减少无关 DOM 的干扰关闭视觉模式纯文本模式下 DOM 压缩效率更高自研一个前置处理函数在传给模型前把不必要的 DOM 节点剪掉第三种方案其实非常有价值尤其适合固定结构的页面。比如你只需要提取价格和库存信息那就在任务开始时先把广告位、导航栏、推荐位全部剔除DOM 瘦身后模型准确率和执行速度都提升明显。5.3 动态加载页面前端渲染越来越普遍很多数据是页面加载完成后通过 JavaScript 异步请求才出现的。BrowserUse 内置了等待机制但有时响应慢的接口会让模型误判为页面已经加载完成进而执行下一步操作结果点击不存在的元素。我的解决办法是在任务描述中主动加上等待条件。比如等待价格标签出现后再点击购买按钮让模型在等待时主动调用观察动作而不是急着执行下一步。5.4 登录态的保持方式做需要登录的流程自动化时每次从零启动浏览器都会遇到登录壁垒。BrowserUse 支持传入浏览器 profile 路径相当于复用同一个浏览器用户数据目录。from browser_use import Agent, Browser, BrowserConfig browser Browser( configBrowserConfig( headlessFalse, user_data_dir./profile_chrome, ) )第一次运行时手动登录一次网站之后 Agent 启动时就会自动复用 Cookie 和登录状态。这个方法在实测中非常稳定避免了每次任务都要处理验证码的问题。需要说明的是user_data_dir 这种复用方式如果使用的是 Chrome 本身的用户目录可能存在版本不兼容或其他未知风险更推荐单独指定一个专用的 profile 目录保持隔离、方便排查。6. 选型结论每个方案都有自己的位置6.1 推荐 BrowserUse 优先的场景如果你主要处理的是网页内任务BrowserUse 几乎是无脑选择。典型的场景包括网页自动化测试特别是测试流程复杂、需要人工点击验证的页面数据采集和监控比如跟踪商品价格、抓取公开信息、生成日报RPA 替代方案尤其是不想被商业 RPA 软件的授权费套牢的团队智能体原型开发需要快速验证一个想法时BrowserUse 的 open-source 属性和 Python API 让二次开发变得非常容易BrowserUse 作为一个开源项目真正解决了商业工具在数据和流程上不透明的痛点。你可以看到每一步操作、每一次模型决策可以随时打断和修正完全掌控整个自动化流程。6.2 仍在 Computer Use 的场景Computer Use 有一块护城河是 BrowserUse 目前够不着的操作范围。它是系统级的智能体能操作任何桌面软件、跨应用协作、处理非网页任务。如果你的目标是让智能体操作微信、Excel、Photoshop 之类的原生应用Computer Use 才是对的方向。不过我也得补一句如果你仔细分析日常工作中哪些操作是真正高频的会发现超过七成的数字化操作其实都在浏览器里完成。这也是为什么 BrowserUse 这类垂直化智能体在真实工作流中性价比更高。6.3 我的最终选择一轮测试下来我个人的工作流已经切换到 BrowserUse。日常的网页自动化任务比如批量整理开源项目信息、定期监控数据变化、生成结构化报告都由它完成。而且整个流程透明可控出了问题我能立刻看到是哪一步决策错误。BrowserUse 这个开源项目让我确信智能体领域的竞争正在从模型能力向工程化能力扩散。模型是发动机但真正决定一辆车好不好开的还有底盘、转向、悬挂——BrowserUse 做的正是把发动机装到一辆结构扎实的车里。它的意义不只是一个工具而是一种可组合、可扩展、可掌控的自动化范式让普通开发者也能把大模型的能力落地到真实业务场景。如果你的需求刚好落在浏览器自动化和智能体这个交叉点上我强烈建议你花一个下午试试 BrowserUse。它能让你既保留开源的自由又享受智能体技术带来的效率提升——这种体验是闭源 API 很难给的。