Browser-Use Agent使用初体验

一、引言

最近一段时间笔者作为研发人员参与了公司不少Agent的功能实现，在开发的过程中了解到了一个名叫 Browser-Use的项目（Browser Use），这个项目提供了一种方案可以通过自然语言与大模型进行交互然后由大模型来操作浏览器。

其实浏览器自动化并不稀奇，只要是做过自动化测试的朋友都知道playwright和Selenium 两个鼎鼎大名的浏览器自动化测试工具，其实Browser-Use项目也是基于playwright技术加上视觉大模型来实现的。也就是因为基于视觉模型，所以使用下来感觉整体速度不是很快，但是基本的功能是可以实现的。

由于官方网站的模型是基于OpenAI的，在国内大多数公司可能还是倾向使用国内的开源大模型，所以本文介绍的方案是基于qwen2.5-vl-72b 模型为主体来实现大模型操作浏览器的功能。

二、案例效果演示

下面我以两个案例来介绍下这个组件的使用：

任务1： 打开百度搜索合肥未来一周天气情况，并做总结

任务分析：这个案例首先大模型首先需要驱动浏览器打开百度，并进行合肥的天气搜索，然后还需要在页面上获取一周的天气数据，最后还需要去做内容总结，总体上这是一个有点复杂的任务

任务执行效果： 程序运行之后，自动唤起一个浏览器，并自动在搜索栏输出了关键字，如下图所示

可以看出基于视觉模型，在图片中出现了大量的框选的部分，这是大模型在基于当前页面找出关键可访问元素。此外从程序运行过程中可以看出打开的浏览器并非本地自带的浏览器而是使用了PlayWright自带的浏览器驱动。

从代码的控制台的日志输出可以看出，整体运行步骤中大模型是存在思考的，整体过程是分步骤进行的，并在最终给出的Result （PS：可以留意下这里的截图中的Token消耗，143K的token花费 整体的开销还是比较大的）

但是事实上Browser-Use内部在执行任务的时候会有效的利用缓存来降低消耗和无关元素干扰，例如在这个案例中，程序会将天气的JSON数据先写到一个临时文件里，然后后面进行内容总结时无需基于整体页面进行总结，而是基于临时文件中的内容做总结，从而降低了token消耗。此外按照官网说明如果使用 Gemini-2.0-flash-exp 模型将有更好的效果，token花费也更低。

任务2: 让agent为我们打开浏览器，并为我当前账号在技术论坛执行一次签到

任务分析：这个任务我需要程序使用我本地的浏览器，而不是使用playwright驱动的方式，此外还需要精准识别页面哪个才是签到按钮并进行点击。

任务执行效果：首先页面唤起一个浏览器，这里我代码里面做了调整直接唤起的是我本地电脑安装的的chrome浏览器（本地浏览器因为存在过登录的缓存，所以无需考虑登录问题），随后正确点击了签到按钮进行了签到。

三、代码实现

3.1 browser_use Agent 基础使用

如何去使用Browser-use组件呢？其实非常简单，我们首先需要一个视觉大模型，比如本文使用的 qwen2.5-vl-72b-instruct 模型，然后我们需要一个明确的任务说明，然后就可以借助Browser-Use为我们提供的内置Agent智能体进行任务执行了,代码如下：

import asyncio
from browser_use import Agent
async def main():
    agent =Agent(
        task="打开浏览器搜索今天的杭州的天气情况，并做总结",
        llm=llm
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

但是很多情况下我们可能需要一些定制例如,我想给这个Agent制定专属提示词，并且使用我自己本地安装的浏览器来执行任务，代码就可以做下述改动。

browser_session = BrowserSession(
    executable_path='C:\Program Files\Google\Chrome\Application\chrome.exe',
    user_data_dir='~/.config/browseruse/profiles/default',
)

# 填写本地Chrome浏览器的进程PID
browser_session = BrowserSession(browser_pid=60256)
# 重写默认提示词
override_system_message = "任务执行完成后请回复：任务完成啦"

async def main():
    agent = Agent(
        task="去某某技术论坛签到",
        llm=llm,
        browser_session=browser_session,
        override_system_message=override_system_message,
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

在上面的这段代码中我们为Agent额外添加了 browser_session 和 override_system_message 两个新的参数

• override_system_message

修改Agent的提示词其实官方更为推荐使用"extend_system_message" 参数，他会继承Agent之前的默认提示词，并将你设定的提示词放在系统默认提示词的后面，这里使用的override_system_message 则是完全的复写了系统提示词。

• browser_session

这个参数让我们能够实现使用本地浏览器的功能，注意如果使用本地的浏览器，需要本地的浏览器开启debug端口，这个可以自行百度，这里我直接写了一个windows的powerShell脚本来方便测试，通过这个脚本可以开启本地9222浏览器调试端口

# 关闭所有 Chrome 进程
taskkill /f /im chrome.exe

# 启动带调试端口的 Chrome
$chromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"
$debugPort = 9222
$userDataDir = "C:\ChromeDebugProfile"
Start-Process -FilePath $chromePath -ArgumentList "--remote-debugging-port=$debugPort", "--user-data-dir=$userDataDir"

使用本地浏览器的好处在于我们本地的浏览器有很多cookie和登录记录，免去了需要输入密码的麻烦，尤其现在许多网站还开启了MFA 验证，每次都要登录就变得非常麻烦。

3.2 browser_use 模型切换为国内开源模型

从Browser-Use官网介绍中我们可以看出，对于模型的支持中最为推荐的还是Google的Gemini 模型

但是我们在国内大多数公司还是倾向使用DeepSeek或者Qwen这样的开源模型。这里官网也说了使用Qwen模型需要使用OpenAI的compatibale API 进行包装，其实就是类似适配器模式的思想，用不支持的模型去适配OpenAI的接口规范，模型适配代码如下：

# from langchain_openai import ChatOpenAI
from typing import Optional, Literal
from browser_use.llm import ChatOpenAI
def create_openai_llm(
    model: str,
    base_url: Optional[str] = None,
    api_key: Optional[str] = None,
    temperature: float = 0.0,
    **kwargs,
) -> ChatOpenAI:
    """
    Create a ChatOpenAI instance with the specified configuration
    """

    llm_kwargs = {"model": model, "temperature": temperature, **kwargs}

    if base_url: 
        llm_kwargs["base_url"] = base_url

    if api_key: 
        llm_kwargs["api_key"] = api_key

    return ChatOpenAI(**llm_kwargs)

这里一定要注意，ChatOpenAI 不要导错包了，这里需要导入成browser_use.llm 包中的 ChatOpenAI， 不要导入 langchain_openai 的ChatOpenAI 依赖，通过这个适配方法，我们只需要在.env 文件写入下述信息，并传到这个create_openai_llm 函数中作为入参，即可达到使用Qwen-VL的模型效果：

VL_API_KEY=sk-你自己的sk信息 
VL_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 
VL_MODEL=qwen2.5-vl-72b-instruct

四、总结

通过初步体验browser_use项目，相信读者们对这门技术也有了一定了解，官方网站中还有更多的相关用法，读者可以自行探索。

总体来看，虽然browser_use项目表现出来的效果挺惊艳，并在GitHub上有67Kstar， 但是总体体验下来，token消耗大、执行效率低的问题还是比较明显的，大部分情况下如果大模型需要支持进行数据搜索能力，使用tavily工具也许更为适合。

但是这个项目为我们提供了一种愿景，在未来也许我们不需要键盘鼠标来和浏览器进行交互了，借助大模型的自然语言理解能力，也许未来我们可以直接和浏览器进行对话沟通，让浏览器按照我们的需求进行工作。

事实上目前Agent操作APP界面或者端侧浏览器，往往需要端侧配合做功能定制，使用的长连接+AIDL的技术方案，以达到节省Token和提升响应速度的效果，而不是单纯的依赖视觉模型。在后续的文章中笔者还会介绍使用MCP+Playwright技术来实现大模型操作浏览器的方式，并且这种方式并不依赖视觉模型，所以更为节省token，受制于文章篇幅将在下一篇文章中进行详细阐述。