本文深入探讨了Browser-Use项目，该项目通过自然语言与大模型交互，实现浏览器自动化操作。文章介绍了Browser-Use如何结合Playwright和视觉大模型，并以实际案例展示了其在网页搜索、内容总结及论坛签到等场景下的应用。同时，文章提供了使用国内开源大模型（如Qwen2.5-VL-72b）进行配置的详细指导，并讨论了使用本地浏览器以保留登录状态的优势。尽管Browser-Use在token消耗和执行效率方面存在挑战，但它为未来人机交互提供了新的视角，预示着更自然的浏览器操作方式。

✨ **Browser-Use项目核心功能**：该项目允许用户通过自然语言指令与大模型互动，进而操控浏览器完成各种任务，如搜索信息、提交表单等。它整合了Playwright的浏览器自动化能力与视觉大模型的理解能力，使得机器能够“看懂”网页并作出响应。

🎯 **实际应用案例展示**：文章通过两个具体案例展示了Browser-Use的实际效果。第一个案例演示了如何让大模型搜索天气信息并进行总结，过程中展示了视觉模型对页面元素的识别框选以及分步思考的日志输出。第二个案例则实现了本地浏览器登录技术论坛并成功签到，强调了使用本地浏览器保存登录状态的便捷性。

🔧 **技术实现与模型适配**：文章详细介绍了Browser-Use的基础代码实现，包括如何初始化Agent、执行任务，以及如何通过`browser_session`参数指定使用本地浏览器（如Chrome）并指定调试端口。特别地，针对国内用户倾向于使用开源大模型的需求，文章提供了将Qwen2.5-VL-72b等模型通过OpenAI兼容API进行适配的配置方法。

🚀 **性能考量与未来展望**：文章客观分析了Browser-Use在实际使用中可能遇到的问题，如token消耗较大、执行效率有待提升。作者也提及了其他可能的解决方案，如使用Tavily工具进行数据搜索，并预告了未来将介绍不依赖视觉模型的MCP+Playwright技术方案，以期实现更高效、低成本的浏览器自动化操作。它描绘了未来人机交互的愿景，即用户可能不再需要键盘鼠标，而是直接通过对话来驱动浏览器工作。

一、引言

最近一段时间笔者作为研发人员参与了公司不少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 asynciofrom browser_use import Agentasync 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浏览器的进程PIDbrowser_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 ChatOpenAIfrom typing import Optional, Literalfrom browser_use.llm import ChatOpenAIdef 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，受制于文章篇幅将在下一篇文章中进行详细阐述。