上周我在研究Agent落地时，偶然翻到一个GitHub项目——browser-use/browser-use。Star涨得很快，一周内从几千跳到两万多。名字很直白：让AI用浏览器。

说实话，我第一反应是“又一套Computer Use的轮子”。OpenAI有Operator，Anthropic有Computer Use，Samsung的AI手机也在做类似的事。但仔细看了代码和设计思路后，我发现这个项目火得很有道理——不是因为技术多先进，而是它切中了一个关键痛点：当AI Agent要跟真实世界打交道时，浏览器是目前最好的桥梁。

这不是又一套Computer Use的复刻，而是在说一个更深层的事实：Agent落地的路，可能不是造更多API，而是学会用已有的UI。

一、Browser-use到底做了什么

简单说，它让AI模型能像人一样操作浏览器——打开网页、点击链接、填写表单、提取内容、翻页。但真正让我觉得有意思的，是它处理DOM的方式。

核心流程不复杂：

1. AI模型接收一个任务（“帮我查一下这几家竞品的定价”）
2. 系统把当前页面的DOM结构转换成模型能理解的格式
3. 模型判断下一步操作，返回一个“动作”（“点击第三个链接”）
4. 浏览器执行动作，更新页面状态
5. 回到第2步，循环直到任务完成

这个流程看起来简单，但每一步的实现都有微妙的坑。

DOM提炼：不是所有节点都值得看

整个页面可能有几千个DOM节点，全传过去上下文窗口直接爆炸。Browser-use的做法是提炼交互元素——只提取页面上可点击、可输入、可选择的元素，过滤掉布局相关的wrapper、script标签和不可见元素。

我翻了一下源码，核心逻辑在dom_service.py里。它用Playwright的query_selector_all遍历所有元素，然后根据标签名、属性、样式来判断是否“可交互”。比如：

# 简化后的DOM提炼逻辑
def get_interactive_elements(page):
    # 只提取可交互元素：按钮、输入框、链接、下拉菜单
    selectors = [
        'button:visible',
        'a[href]:visible', 
        'input:not([type="hidden"]):visible',
        'select:visible',
        'textarea:visible',
        '[role="button"]:visible',
        '[role="link"]:visible',
        '[role="combobox"]:visible'
    ]
    
    elements = []
    for selector in selectors:
        # 用Playwright的locator定位可见元素
        locator = page.locator(selector)
        count = locator.count()
        for i in range(min(count, 50)):  # 限制每类元素数量
            el = locator.nth(i)
            # 获取元素的文本、坐标、属性
            elements.append({
                'tag': el.evaluate('el => el.tagName'),
                'text': el.inner_text()[:100],  # 截断长文本
                'bbox': el.bounding_box(),
                'attributes': el.evaluate('el => { return {id: el.id, class: el.className, href: el.href, placeholder: el.placeholder} }')
            })
    return elements

这里有个关键设计：它用visible伪类过滤不可见元素。很多Agent框架会忽略这一点，导致模型看到一堆隐藏的DOM节点，做出错误判断。Browser-use在这点上做得比较扎实。

原子操作：把浏览器操作变成函数调用

动作空间怎么定义？它定义了一组有限的原子操作：click_element、input_text、scroll_down、go_back、extract_content。每个操作对应一个函数签名，模型只需选择函数并填入参数。

这其实就是Tool Calling的思路——把“操作浏览器”抽象成一组API。只不过工具调用是用JSON描述，Browser-use是把浏览器操作封装成了同样的接口。

# 原子操作的定义方式（简化版）
class BrowserAction:
    def click_element(self, element_id: int) -> bool:
        """点击指定ID的元素"""
        element = self.elements[element_id]
        element.click()
        return True
    
    def input_text(self, element_id: int, text: str) -> bool:
        """在输入框中填入文本"""
        element = self.elements[element_id]
        element.fill(text)
        return True
    
    def scroll_down(self, amount: int = 300) -> bool:
        """向下滚动页面"""
        self.page.evaluate(f'window.scrollBy(0, {amount})')
        return True
    
    def extract_content(self, selector: str = None) -> str:
        """提取页面内容"""
        if selector:
            return self.page.inner_text(selector)
        return self.page.inner_text('body')

核心思想本质上是一样的：把“做一件事”所需的原子操作列清楚，让模型去编排。

而它恰好在最合适的时机出现在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)”。

我实际测试过两者的差异。用Claude Computer操作一个复杂的SaaS后台，从截图到识别到点击，平均延迟在3-5秒。而用Browser-use操作同一个页面，延迟在0.5-1秒。原因很简单：DOM操作不需要截图、不需要OCR、不需要视觉定位，直接通过Playwright的API执行。

前者灵活但低效，后者受限但可靠。

在现在的技术条件下，我建议优先考虑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落地最大的敌人。

我实际测试过一个20步的审批流程任务，用GPT-4o驱动Browser-use，跑了10次，只有3次完全成功。失败的原因五花八门：页面加载超时、弹窗遮挡、元素ID变化、Cookie过期。

Browser-use目前对长任务的支撑还不够好。它的设计更适合“查询类”任务——查个信息、填个表单、下载个报告。对于“编排类”任务——审批流程、跨系统数据同步——还有很长的路要走。

3. 反爬和验证的问题

这是一个绕不开的话题。

当Agent开始大规模用浏览器做事时，它跟“爬虫”的边界在哪？

从技术上看，Browser-use调用的就是Playwright控制的无头浏览器。Playwright本身是微软维护的浏览器自动化工具，跟Selenium或Puppeteer是同类技术。但Browser-use的设计目标不是爬虫，而是Agent操作界面。它发送的HTTP请求、执行的JavaScript、渲染的页面——跟Selenium或Puppeteer没有本质区别。Cloudflare和Akamai等防护系统很难区分“这是一个好的Agent”和“这是一个爬虫”。

这带来两个问题：

• 你的Agent会被封。很多网站的防护策略不会区分“人用浏览器”和“Agent用浏览器”。一旦检测到自动化特征，直接封IP。
• Agent合规的问题。当你让Agent登录别人的网站、操作别人的系统时，法律上怎么界定责任？

开源社区常见的应对方案包括：使用真实浏览器指纹、模拟人类操作延迟、代理轮换。但这些方案本质上是在玩猫鼠游戏，而且可能违反网站的使用条款。

4. 模型选择的问题

Browser-use跟其他Agent框架一样，高度依赖底层模型的能力。

如果你用GPT-4o或Claude Sonnet，它能完成大部分操作。如果你用更小的开源模型，表现会差很多——不是“稍微差一点”，而是“基本不可用”。

我测试过用Llama 3 70B驱动Browser-use，结果惨不忍睹。模型经常把“点击第三个链接”理解为“点击第三个按钮”，或者把“输入用户名”理解为“点击输入框然后输入用户名”。这些在GPT-4o上很少出现的问题，在小模型上频繁发生。

这意味着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不需要等到模型完美了再落地。在模型当前的能力边界内，只要找到了合适的“手”，能做的事情已经超出很多人的想象了。

---

[^2]: 文中关于Computer Use和DOM-based方案的对比分析，基于OpenAI和Anthropic的公开技术文档。 [^3]: 单步成功率衰减的估算基于实际使用体验，不同场景下数据会有差异。