browser-use 是这两年最出圈的浏览器智能体库之一：你用一句话交代任务，它自己打开浏览器、读页面、点按钮、填表单，直到把结果交回来。听起来像自动化的终点，真上手之后会发现，它更像一个聪明但按步收费的实习生——能干活，也能把坑一个个踩给你看。
官方仓库信息
项目托管在 GitHub，组织名 browser-use，仓库名同为 browser-use，MIT 许可证，Python 编写，星标数已超过十万。它底层用 Playwright 驱动真实浏览器，智能体循环负责理解页面和决定下一步动作；可接的大模型包括 OpenAI、Anthropic、Google 等多家的接口，也能用本地模型。项目方另提供收费的云端浏览器服务，和这个开源库不是一回事，自托管使用这个库本身不收费。
它干活的方式，决定了它的账单结构
每一“步”是这样跑的：把当前页面的结构整理成文本交给大模型，模型判断该点哪里、填什么，执行完再看新页面，如此循环。一个看似简单的任务，比如在几个网站比价再填一张表，轻松跑出二三十步，也就是二三十次大模型调用。用旗舰模型时，一次任务的接口费可能比你预想的高一个数量级；换便宜模型，判断失误又会增多，步数反而膨胀。省钱的正解是先拿真实任务测一遍单次成本，再决定要不要规模化。
部署成本：装上不难，养好不易
本地部署门槛不高，Python 环境加 Playwright 和浏览器内核就能跑，第一次安装主要是下载体积和依赖折腾。难的是长期运行：无头浏览器在服务器上要处理字体、弹窗、超时和内存回收，网站改版一次，之前调通的任务就可能失效，需要有人持续盯着修。把它当一次性脚本用，这些都不算事；当生产系统用，就得按养一个服务的标准配人。
四个真实坑点
第一，登录墙和验证码。需要登录、短信验证、人机验证的网站，智能体经常卡死；让它复用你真实浏览器的登录状态能绕开一部分，但等于把账号暴露给自动化程序，风险自担。第二，网页里的提示注入。页面上的文字会被模型当成上下文，恶意页面完全可能诱导它点错链接、泄露你交给它的信息，涉及支付和账号操作的任务尤其要隔离。第三，成功率不稳定。同一个任务今天跑通、明天失败并不稀奇，所以它不适合无人值守地跑下单、报名这类错了没法重来的事。第四，慢。每一步都要等模型返回，一个任务跑几分钟很常见，批量跑时时间成本和接口费一起涨。
适合它的场景是：流程会变、没法写死脚本的网页杂活，比如竞品信息巡检、表单搬运、把网页内容整理成结构化数据，而且旁边有人能复核结果。流程固定的任务，老老实实写 Playwright 脚本或用传统 RPA 更便宜也更稳。
