最近 GitHub 上有个项目突然窜红，star 涨得很快——browser-use/browser-use。
名字很直白：让 AI 用浏览器。
说实话，第一眼看到的时候我没什么感觉。让 AI 控制浏览器？这不是 Computer Use 已经做过的事吗？OpenAI 有 Operator，Anthropic 有 Computer Use，Samsung 的 AI 手机也在做类似的事。
但仔细看了之后，发现这个项目火得很有道理。不是因为它的技术多先进，而是因为它切中了一个关键的痛点——当 AI Agent 要跟真实世界打交道时，浏览器是目前最好的桥梁。
这不是又一套 Computer Use 的轮子，而是在说一个更深层的事实：Agent 落地的路，可能不是造更多 API，而是学会用已有的 UI。
一、Browser-use 做了什么
简单说，它让 AI 模型能像人一样操作浏览器——打开网页、点击链接、填写表单、提取内容、翻页。
核心流程不复杂：
- AI 模型接收一个任务（"帮我查一下这几家竞品的定价"）
- 系统把当前页面的 DOM 结构转换成模型能理解的格式
- 模型判断下一步操作，返回一个"动作"（"点击第三个链接"）
- 浏览器执行动作，更新页面状态
- 回到第 2 步，循环直到任务完成
这个流程看起来简单，但每一步的实现都有微妙的坑。
DOM 结构怎么传给模型？整个页面可能有几千个 DOM 节点，全传过去上下文窗口直接爆炸。Browser-use 的做法是提炼交互元素——只提取页面上可点击、可输入、可选择的元素，过滤掉布局相关的 wrapper、script 标签和不可见元素。
动作空间怎么定义？它定义了一组有限的原子操作：click_element、input_text、scroll_down、go_back、extract_content。每个操作对应一个函数签名，模型只需选择函数并填入参数。
这其实就是 Tool Calling 的思路——把"操作浏览器"抽象成一组 API。只不过工具调用是用 JSON 描述，Browser-use 是把浏览器操作封装成了同样的接口。
核心思想本质上是一样的：把"做一件事"所需的原子操作列清楚，让模型去编排。
而它恰好在最合适的时机出现在 GitHub 上——当所有人都意识到"Agent 需要跟物理世界交互"的时候。
二、为什么是"浏览器"成了焦点
这里有一个更深层的问题值得想：为什么 AI Agent 落地的第一个关键抓手是浏览器，而不是别的？
回答这个问题之前，先说一个观察。
现在市面上的 AI Agent 产品，工作方式基本分两类：
- 通过 API 操作。Agent 调某个 SaaS 的开放接口，发指令、拿数据、做变更。优点是稳定、可控；缺点是接口不统一、很多系统没有 API。
- 直接操作界面。Agent 像人一样点鼠标、敲键盘，在你电脑上干活。优点是"万用"；缺点是慢、容易错、容易被反爬。
2025 年大家主要做第一种，发现落地很难——因为企业内部几十套系统，每套都接 API 是不现实的。
2026 年的风向开始转向第二种。Browser-use 的火爆就是在这个转折点上发生的。
浏览器是"操作界面"这个思路最自然的载体。 原因有三。
第一，浏览器有统一的技术栈。 不管后台是什么语言写的系统，最终呈现到用户面前的都是 HTML + JavaScript。这意味着 Agent 只需要"理解"这一套标准，就能操作几乎所有 Web 应用。
第二，浏览器的交互模型是有限的。 点、写、滚、选、翻——人用浏览器做的事情，基本可以归纳到几十种原子操作里。这对 Agent 来说非常友好——动作空间小意味着模型更容易学习和泛化。
第三，浏览器本身就是信息入口。 企业里的大部分信息——邮件、文档、看板、报表——最终都是通过浏览器呈现的。Agent 只要"能操作浏览器"，就等于能访问企业里的几乎所有信息。
Browser-use 的火爆，不是因为它的技术有多强，而是因为它代表了 Agent 落地思路的一次转向——从"请给我 API"到"我自己看网页"。
三、和 Computer Use 的本质差异
很多人把 Browser-use 跟 OpenAI 的 Computer Use、Anthropic 的 Claude Computer 相提并论。这种比较不能说错，但忽略了本质区别。
Computer Use 的愿景是：Agent 能操作你的整个电脑。桌面、文件系统、各种桌面应用、甚至命令行。
Browser-use 的愿景是：Agent 能用好浏览器。
这是两种完全不同的边界假设。
Computer Use 的边界更宽，但代价是抽象层更厚。Agent 要理解的是像素级别的屏幕截图，从中识别出按钮、文本输入框、下拉菜单。这个过程计算量大、延迟高、容易出错。
Browser-use 的边界更窄，但优势是信息密度更高。它操作的不是像素图，而是 DOM 树——结构化的、带语义的、精确到每个元素的文档对象模型。Agent 不需要"猜"哪个像素是按钮，DOM 树直接告诉它"这是一个 button，text='提交'，坐标=(x,y)"。
这就像让一个厨师做饭：Computer Use 是"看着成品图自己猜配方"。Browser-use 是"给你一本菜谱照着做"。
前者灵活但低效，后者受限但可靠。
在现在的技术条件下，我建议优先考虑 Browser-use 这种"利用已有结构信息"的方案。Computer Use 还需要一段时间的迭代才能变得真正实用。
从我的角度来看，这两种方案不是竞争关系，而是分层关系：
- 对于有良好结构的 Web 页面（大部分 SaaS 产品、后台管理系统），DOM-based 方案更高效
- 对于没有结构的桌面应用、老旧的 C/S 系统，Computer Use 是唯一的方案
- 未来更可能是两者的融合——先尝试 DOM 方案，失败了再降级到屏幕方案
四、真正有趣的事情：Agent 开始有了"手"
Browser-use 这类项目之所以值得关注，不是因为它本身是"下一代颠覆性技术"，而是它代表了一个更重要的趋势：AI Agent 正在长出"手"。
过去两年，AI 的发展集中在"大脑"能力——更强的推理、更长的上下文、更准的回答。但"大脑"再聪明，如果它不能操作这个世界，能做的事情就非常有限。
Agent 需要的是：
- 强脑——LLM 提供推理和规划能力
- 一双眼睛——读取和理解界面信息
- 一双手——操作界面，完成实际动作
- 一个身体——运行环境确保它能存活和迭代
Browser-use 提供的就是"手"。它让 Agent 有了操作 Web 界面的能力。手是大脑跟世界交互的桥梁。
没有手的大脑，只是一个百科全书。有手的大脑，才是一个行动者。
这个趋势的下一阶段也很好预测：Agent 会逐渐长出更多的"肢体"——操作文件系统、调用命令行、在代码编辑器里实时修改代码、在 Figma 里操作设计稿。每一种"肢体"的加入，都意味着 Agent 的能力边界往外扩了一圈。
五、Browser-use 落地过程中的实际挑战
说了这么多定性的东西，聊几个实际的问题。
1. 稳定性的问题
Browser-use 的原理决定了它的执行是"脆弱"的。
一个页面改了个 CSS class 名称，解析逻辑可能就变了。弹了一个非预期的弹窗，后续的动作序列就可能全部错位。网络慢了一秒，Agent 以为页面加载完了，但实际上关键元素还没渲染出来。
这种"非确定性的执行环境"对 Agent 来说是一个持续的挑战。API 调用是确定性的——调了就是调了，结果要么成功要么失败，逻辑是清晰的。但浏览器操作不是——一次点击可能因为各种原因没有生效。
目前业界的做法是加各种"兜底逻辑"：重试机制、超时检测、状态验证。但这增加了系统的复杂度，也让延迟变得不可控。
2. 多步骤任务的问题
一个复杂的任务可能涉及几十步操作。每一步都有失败的可能。当步骤数增多时，整体成功率会快速下降。
假设单步成功率是 95%，10 步的成功率是 0.95^10 ≈ 60%，20 步是 0.95^20 ≈ 36%。这种累积效应，是 Agent 落地最大的敌人。
Browser-use 目前对长任务的支撑还不够好。它的设计更适合"查询类"任务——查个信息、填个表单、下载个报告。对于"编排类"任务——审批流程、跨系统数据同步——还有很长的路要走。
3. 反爬和验证的问题
这是一个绕不开的话题。
当 Agent 开始大规模用浏览器做事时，它跟"爬虫"的边界在哪？
从技术上看，Browser-use 调用的就是无头浏览器，跟市面上几乎所有爬虫工具用的是同一套底层技术。它发送的 HTTP 请求、执行的 JavaScript、渲染的页面——跟 Selenium 或 Puppeteer 没有本质区别。Cloudflare 和 Akamai 等防护系统很难区分"这是一个好的 Agent"和"这是一个爬虫"。
这带来两个问题：
- 你的 Agent 会被封。很多网站的防护策略不会区分"人用浏览器"和"Agent 用浏览器"。一旦检测到自动化特征，直接封 IP。
- Agent 合规的问题。当你让 Agent 登录别人的网站、操作别人的系统时，法律上怎么界定责任？
Browser-use 的商业化版本通过"云浏览器 + 代理轮换"来绕过反爬检测，但这本质上是在玩猫鼠游戏。
4. 模型选择的问题
Browser-use 跟其他 Agent 框架一样，高度依赖底层模型的能力。
如果你用 GPT-4o 或 Claude Sonnet，它能完成大部分操作。如果你用更小的开源模型，表现会差很多——不是"稍微差一点"，而是"基本不可用"。
这意味着 Browser-use 的 Agent 能力上限，就是它所依赖的模型的能力上限。如果模型本身不擅长"将自然语言指令映射到原子操作"这件事，Browser-use 做再多的封装也没用。
他们自己训练了一个专用的 ChatBrowserUse 模型，就是为了解决这个问题。但这也意味着对大多数开发者来说，使用开源模型的自由度会受到限制。
六、更大的图景
把视线拉远一点来看。
Browser-use 的火爆，本质上反映的是 AI 行业的一个集体直觉：通往通用 AI 助手的路，大概率不是造一个"更聪明的模型"，而是让现有模型能做更多的事情。
这个方向上的技术栈正在逐渐成型：
应用层：Agent 框架 (Browser-use, LangChain, CrewAI)
能力层：模型推理 + 工具调用 + 浏览器操作
连接层：MCP 协议 (Anthropic), Function Calling (OpenAI)
基础层：多模态大模型 (GPT-4o, Claude-4, Gemini)
每一层都在快速演进。Browser-use 站在"能力层"和"应用层"的交界处，它吃的是上层模型的能力红利，解决的是下层 Agent 框架的工程问题。
这个位置选得很好。它不会成为基础技术（那是模型供应商的事），但它会成为 Agent 生态里不可或缺的一层。
如果把 Agent 比作一个机器人，Browser-use 就是机器人的"手"。手本身不聪明，但没有手，大脑再强也搬不动东西。
Browser-use 证明了：Agent 不需要等到模型完美了再落地。在模型当前的能力边界内，只要找到了合适的"手"，能做的事情已经超出很多人的想象了。
