传统爬虫的骄傲，是你比网站更懂它的DOM。
页面一改class，脚本就瞎。验证码一加，队列就停。内容全靠前端渲染，你还在等一个永远不出现的静态HTML。于是“能写正则”渐渐不够用，缺的是有人看着屏幕决定下一步点哪里。
browser-use把这件事交给模型。不是再发明一种解析器，是让Agent坐进真实浏览器里操作。原帖挖它时大约9.5万星，现在仓库已到11万星量级，数字还会涨。
仓库：https://github.com/browser-use/browser-use
官网：https://browser-use.com
协议MIT。作者Magnus Müller、Gregor Zunic有ETH Zurich背景，项目从苏黎世做到旧金山，后来也做了云服务和配套harness。开源库本身仍可自托管，模型Key自己备。
它狠在哪：路径是推理出来的
Selenium、Playwright写的是剧本：这个按钮、那个输入框、等三秒。页面改版，剧本作废。
browser-use写的是任务：“打开这个公开页面，找到星标数字，记下来。”中间的点击、滚动、换页由模型根据当前DOM和截图来选。布局变了，它有机会改道，而不是第一时间报错。
这就是原帖说的“开始会判断页面该怎么走”。对做Agent的人，这比“又能爬了”更重要——网页从接口变成了可行动的环境。
常见能力可以概括成：
- 控制真实浏览器（底层常见是Playwright一类）
- 用任意主流LLM，也可走他们自己的模型或本地方案
- 把目标拆成可执行的浏览器动作
- 带会话、下载、文件、自定义工具，以及和编程Agent（Claude Code、Cursor等）衔接的技能安装
安装形态很直接：pip install browser-use 或 uv add browser-use，再配模型Key。细节以仓库README为准。
对“普通爬虫”意味着什么
说翻天，说的不是正则过时，是一类场景的成本结构变了。
以前必须为人写选择器的页面：后台菜单、多步表单、纯前端渲染的列表。现在可以先让Agent试走。试得通，再决定要不要固化成更便宜的脚本。
它替代不了的部分也很清楚：
- 大规模、稳定、低成本的数据采集，专用爬虫加API仍然更便宜
- 模型每步都在看页、做判断，token和时间都不是免费
- 判断会错：点错菜单、理解错表格、在循环里转圈
- 网站会变，Agent会适应，也会在适应里做出你没允许的动作
所以更准确的定位是：会看页面的RPA / 浏览器Agent，不是新一代“无限制采集器”。
能做的，和不该做的
适合拿来试的，是你拥有权限的流程：
- 给自己的产品做端到端点击验收
- 把每天要在网页后台重复的操作收成任务
- 在公开信息页上做小范围核对（价格、文档、仓库元数据）
- 研究Agent如何把自然语言变成UI动作
不该默认去做的，是把别人的登录墙、反爬和隐私数据当成新矿区。能点登录框，不等于有权进别人的账号体系；能滚动动态列表，不等于平台允许整站搬运。条款、版权、个人数据，不会因为操作者变成模型就消失。
云端版本还要另看隐私政策：有的托管方案会声明用输入改进模型。敏感流程优先本地开源库，Key和浏览器会话留在自己机器上。
第一次跑，建议把任务写得很小
不要一上来就“把这个站点整站搬下来”。给一个可验收的句子：
“打开browser-use的GitHub页面，读取星标数，只把数字返回给我。”
看三件事：它是否真的打开了正确的页，中途点了什么，花了多少步。步数失控，先收紧任务，再谈接进业务。
和传统自动化的组合往往更健康：Agent负责探索和偶尔的改版适应，稳定路径再沉淀成Playwright脚本。全交给模型，账单和失误率会一起涨。
写在最后
爬虫界若被掀桌，掀开的不是“谁更会写解析”，是网页终于变成了Agent可以走动的地方。选择器是地图，browser-use更像请了一个会看路牌的司机。
司机可以送你去有权限的目的地，也可以把车开进不该进的院子。11万星证明这件事被需要，不证明每一种需要都合法或划算。
仓库在这里：
https://github.com/browser-use/browser-use
先让它完成一件你自己本来要点很多下的小事。真觉得传统爬虫被击中，击中的其实是那些必须靠人眼判断下一步的流程——以及你是否准备好为这种判断付token、付试错、付合规。
No comments yet