Browser Use大杀四方？传统与AI结合的曙光来临

Browser Use 是一个开源的浏览器自动化框架，它的核心是让 AI 智能体能够像人一样理解和操作浏览器。通过集成大语言模型（LLM）的智能决策能力，Browser Use 推动 UI 测试进入了“目标驱动”的新阶段，它不仅能理解开发者用自然语言描述的目标，还能自主规划并执行复杂的浏览器操作。

目前，该项目已在 GitHub 上获得了超过 18,000 个 Star：https://github.com/browser-use/browser-use。

先说实操验证结果：

1. 至少需要一个视觉模型（收费），个人试验用了qwen2.5-VL可行，为了减少视觉模型token的成本，又搭配一个免费的推理模型deepseek。双管齐下，分工干活。轻度使用，一天token大概花费为5毛钱不到（只试验了一个小模块，没有建立全系统的ui测试脚本）。

2. 运行速度上，一条基础页面结构检查用例执行约耗时40s，比agent-browser慢，比midscene快，属于中游阶段，可接受。无头模式下，速度可更快。

3. 可维护性上，test_agent中task传入自然语言步骤，哪怕前端页面频繁变动，也能执行下去。

💡 核心特点与优势

Browser Use 将复杂的 UI 自动化工作流，转变为智能体自主决策和行动的过程。其核心能力与优势主要体现在：

• 语言理解能力：用自然语言描述测试目标（如“登录系统，创建一个新项目”），Browser Use 能自动将其转换为可执行的操作序列。

• 核心架构：其技术底座强大，基于主流浏览器自动化工具 Playwright，并结合 LangChain 进行任务编排，这使得它天然具备跨浏览器（Chromium、Firefox、WebKit）的执行能力及强大的稳定性。

• 鲁棒性与可扩展性：

  • 智能定位：通过分析网页的视觉布局和HTML结构来理解页面，而非依赖固定的XPath。当页面元素变动时，AI自主适应并找到目标元素，大大降低了因前端频繁迭代而导致的脚本维护成本。

  • 自我纠错：当执行出错或遇到意外情况（如弹窗、加载缓慢）时，智能体具备尝试不同策略、绕过障碍或等待页面稳定的自我修正能力，显著提升了自动化流程的健壮性。

  • 并行执行：能够同时运行多个智能体实例共享一个浏览器，但保持各自的上下文环境，这对于大规模并发回归测试非常有价值。

  • 自定义操作：开发者可以轻松地为AI智能体注册自定义操作，例如“将数据保存到数据库”、“发送邮件通知”或“调用内部API”，极大地扩展了其应用边界。

🛠️ 在UI自动化测试中的应用

Browser Use为UI自动化测试带来了更多可能性，部分核心应用场景包括：

• 端到端（E2E）回归测试：用自然语言描述一个完整的业务流程（如“完成网站登录、商品搜索、加入购物车、提交订单的全流程”），让智能体自动执行。这种方式极大地降低了编写和维护庞大脚本的工作量。

• 探索式测试：可以命令智能体“浏览当前网站，点击所有可点击的元素并记录异常”，主动发现非预期的程序缺陷和潜在漏洞。

• 数据校验与监控：由智能体自动从指定页面提取数据（如产品价格、股票信息），与API返回值或数据库进行比对，实现持续的数据质量监控。

• 对抗性测试：模拟恶意用户输入，如在输入框注入XSS代码，验证网站的安全过滤机制是否生效；或用智能体进行高频操作，测试系统的极限负载能力。

🔄 与传统框架对比

下表清晰地展示了Browser Use与传统自动化框架（如Selenium、Puppeteer）的核心区别：

特性	传统框架 (Selenium/Puppeteer)	Browser Use (AI驱动框架)
核心范式	脚本驱动：编写精确的操作步骤	目标驱动：描述最终目标，AI自主规划
元素定位	依赖固定的XPath/CSS选择器，页面变动易失效	AI动态感知，通过分析网页视觉与HTML结构自主定位
对页面变化的适应性	脆弱，微小的UI调整即可能导致脚本失败	鲁棒，通过自我纠正机制适应页面变化，维护成本低
测试用例形式	指令集/代码	自然语言描述，易于编写和理解
核心价值	适合执行步骤固定、环境稳定的自动化任务	适合流程复杂、页面动态变化、探索式的测试场景，能极大提升测试效率和覆盖率

• 使用场景：它特别适用于流程复杂、变动频繁的E2E核心业务场景和难以用脚本完全覆盖的探索式测试。

• 灵活融合：Browser Use并非要完全取代现有工具。一个更务实的落地路径是，将其作为能力的补充，融入现有测试框架。例如，让Browser Use负责处理变数较多的自动化任务，而将稳定、可复用的原子操作留给传统脚本，形成一种“AI智体负责决策与路径规划，传统脚本负责稳定执行”的混合模式。

🔄 定位机制

机制	说明
截图视觉通道	take_screenshot() 获取截图
文本语义通道	使用 analyze_page() 解析
DOM 索引交互	指令用编号如 "click 5"
混合策略	优先 selector，失败回退视觉
自愈机制	已使用 AI 重试不同策略

💎 模型选择

Browser Use 对大语言模型的集成策略很灵活，核心是要求模型必须支持“函数调用”功能，以确保能生成结构化的操作指令。

框架本身不内置语言模型，而是允许你通过它提供的统一接口，接入多种主流模型。官方支持自研模型：bu-ultra (Browser Use Cloud)、ChatBrowserUse-2、bu-2-0。

选择主要是对成本、复杂度和隐私三方需求的权衡：

• 追求高性能与可靠性: OpenAI GPT-4o 或 Anthropic Claude 系列是首选。如果预算允许，官方托管的 bu-ultra 能提供一站式的最佳性能和稳定性。

• 兼顾预算与效果: DeepSeek-V3 和 Google Gemini 系列是高性价比之选，能在保证不错效果的同时，大幅降低调用成本。

• 注重数据隐私或特殊场景: Ollama 本地部署是理想方案。如果任务需要强大的推理能力，可以考虑支持推理模式的 DeepSeek Reasoner

🗂️ 实战项目结构

browser-use-test-demo/
├── config/ # 配置层
│ ├── __init__.py
│ └── settings.py # 项目配置 (API密钥， 超时， 链接)
├── services/ # 基础服务层
│ ├── __init__.py
│ ├── browser_service.py # 浏览器管理 (启动， 关闭， 上下文)
│ └── llm_factory.py # 大模型工厂 (管理模型实例)
├── pages/ # 页面对象层
│ ├── __init__.py
│ ├── base_page.py # 页面基类 (通用操作)
│ ├── login_page.py # 登录页面
│ ├── product_list.py # 商品列表页
│ ├── cart_page.py # 购物车页
│ └── checkout_page.py # 结算页
├── custom_actions/ # 自定义操作层 (业务扩展)
│ ├── __init__.py
│ └── business_actions.py # 业务相关自定义动作
├── tests/ # 测试用例层
│ ├── __init__.py
│ ├── test_agent.py # Agent测试用例
│ └── conftest.py # pytest夹具
├── run_tests.py # 执行脚本
├── requirements.txt # 项目依赖
└── .env # 环境变量 (API Keys)

⚙️第一步：配置层 (Configuration)

配置层集中管理所有环境变量和通用设置，确保环境一致性，便于维护。

🧰 第二步：基础服务层 (Services)

服务层负责提供 Browser Use 的核心能力，如管理浏览器和提供大模型接口。

services/llm_factory.py - 大模型工厂:

services/browser_service.py - 浏览器服务:

📄 第三步：页面对象层 (Page Objects)

页面对象层通过将页面交互逻辑封装成类，并与 Controller 和自定义 Action 结合，构建出稳定、可复用的操作模块，有效降低核心测试逻辑对页面细节的依赖。

具体实现包括 BasePage 基类提供通用方法，以及 LoginPage、ProductListPage、CartPage、CheckoutPage 等页面类，分别封装了各自的业务逻辑（如等待方法、控制器注册等）。

pages/login_page.py - 登录页面:
封装在登录页面上的各种业务操作，并为每个操作提供清晰的自然语言描述，方便 Agent 在决策时调用。

📐 核心设计思路

在 Page 层封装时，遵循 "场景驱动" 的选型原则：

• 核心业务步骤 → 常规 Playwright 写法
  如登录、搜索、加入购物车、下单等。这些步骤执行频率高、稳定变化可控，直接用 page.get_by_role()、page.locator() 等确定性写法，执行快、成本低。

• 变化频繁或脆弱环节 → 自然语言描述
  如广告弹窗、动态推荐位、复杂页面的元素识别。这类场景下传统定位器极易失效，借助 AI 的适应性可大幅降低维护量，对稳定性和容错性更有价值。

from .base_page import BasePageclass LoginPage(BasePage):async def login_with_credentials(self, email: str, password: str):"""使用提供的邮箱和密码登录"""page = await self._get_page()await self.wait_for_load_state()# 使用常规Playwright写法，更加稳定await page.fill('input[type="email"]', email)await page.fill('input[type="password"]', password)await page.click('button[type="submit"]')# 等待登录成功跳转await page.wait_for_url(lambda url: url != page.url)print("Login action executed.")return True# 如果需要让Agent自动分析页面，也可以通过自然语言描述@propertyasync def login_action_for_agent(self):"""适用于Agent的自然语言登录描述"""return """1. 找到邮箱输入框并输入: testuser@example.com2. 找到密码输入框并输入: testpass1233. 找到并点击"登录"按钮"""

🔧 第四步：自定义操作层 (Custom Actions)

自定义操作层基于 controller.action 装饰器实现，为 Agent 的“工具箱”增加业务相关的专用工具，如验证订单等，使自动化流程更贴近真实业务需要。

🧪 第五步：测试用例层 (Tests)

测试用例层利用 pytest 框架编排测试流程，组装并运行 Agent，验证业务场景。

• tests/conftest.py:
  使用 pytest 的 fixture 功能，为测试用例提供预先初始化好的 BrowserService、LLM 实例和 Agent 等组件。

• tests/test_agent.py - Agent测试用例:

import pytest
import asyncio
from config.settings import settingsclass TestE2EShoppingFlow:"""端到端购物流程测试套件"""@pytest.mark.asyncioasync def test_login_failure_scenario(self, agent):"""测试登录失败的场景"""task = f"""在网站 {settings.BASE_URL} 上，使用错误的密码尝试登录。账号: {settings.TEST_USER}错误密码: "wrong_password_123"验证：系统是否显示“用户名或密码错误”的提示信息。"""my_agent = agent(task)history = await my_agent.run()# 可在此处添加更具体的断言assert my_agent.is_successful(), "Agent 未正确检测到登录失败或失败提示信息"

🚀 第六步：执行脚本

通过 run_tests.py 脚本，可以方便地运行测试。