AI智能体实战:browser-use浏览器自动化与video-use视频解析全攻略
2026/8/28 14:33:29 网站建设 项目流程

最近接手了一个内部提效项目,核心诉求是“让大模型自己把网页上的事办了”。看了不少自动化方案,最终还是落在了 browser-use 这类智能体框架上。顺手也把视频内容的自动化处理链路一并梳理了一遍,也就是标题里提到的 video-use 方向。这篇文章就把这套从浏览器自动化到视频内容解析的实战经验整理出来,包含完整代码、环境配置、常见坑点和工程建议,适合想用 AI 智能体替代重复人工操作的开发者参考。

1. 背景与核心概念

1.1 什么是 browser-use

browser-use 是一个基于 Python 的开源智能体框架,核心作用是让大语言模型(LLM)直接操作真实浏览器。传统爬虫用代码硬编码选择器去定位页面元素,页面一改结构就失效;而 browser-use 让模型“看”页面内容,像人一样理解页面、决定点击哪里、输入什么内容。

简单来说,它的工作流程可以拆成四步:

  1. 大模型接收任务描述。
  2. 框架将浏览器当前页面状态(DOM 结构、可见文本、可交互元素)转换为模型可理解的上下文。
  3. 模型基于页面内容自主决策下一步动作:点击、输入、滚动、跳转、等待。
  4. 框架执行模型给出的动作,更新页面状态,往复循环直到任务完成。

这种方式特别适合以下场景:

  • 需要在多个内部系统中反复录入、查询、核对数据的 RPA 类流程。
  • 需要理解页面语义而不是固定选择器的数据采集任务。
  • 需要模拟真实用户行为的端到端测试。
  • 将浏览器能力作为工具暴露给 AI Agent 使用的自动化编排场景。

1.2 什么是 video-use

video-use 不是 browser-use 的官方子项目,而是社区对“视频智能体工具链”的一种统称。它解决的是另一类问题:如何让 AI 自动化地处理视频内容,包括视频理解、内容摘要、关键帧提取、语音转写、标签生成以及视频生成等。

在实际业务中,video-use 通常会和 browser-use 联合使用。例如:

  • 用 browser-use 自动打开视频管理后台,批量上传视频素材。
  • 用 video-use 对视频进行结构化解析,生成标题、简介、标签后自动回填到内容管理系统中。
  • 用多模态大模型对视频逐帧分析,提取产品卖点、违禁词、竞品信息。

这篇文章里的实战示例会分别演示 browser-use 的浏览器自动化能力和 video-use 的视频解析链路,最后再把两者串成一个完整场景。

1.3 为什么需要掌握这类工具

现在的 AI 应用不再满足于“聊天问答”,而是进入“智能体执行任务”的阶段。大模型负责理解和规划,工具负责执行。browser-use 这类框架把互联网最大的交互入口——浏览器——变成了模型可调用的工具;video-use 则把视频这种非结构化数据变成模型可理解的信息。

对后端开发者来说,掌握这类工具意味着可以快速把重复的人工操作交付给 AI,减少低价值劳动。对测试和运维同学来说,掌握浏览器自动化意味着可以构建更智能的巡检、巡检报告和异常截图体系。

2. 环境准备与版本说明

2.1 基础运行环境

本文示例以 Python 3.10 以上版本为例。browser-use 依赖 Playwright 驱动浏览器内核,因此本机需要安装对应浏览器。下面是通用的环境清单:

依赖项说明
Python3.10 及以上版本,建议使用虚拟环境
browser-useAI 浏览器智能体框架,用于浏览器自动化
playwrightbrowser-use 底层浏览器控制库
langchain-openai大模型调用封装(如使用 OpenAI 兼容接口)
ffmpeg视频处理工具,video-use 示例中用于音视频分解
openai-whisper音频转写,提取视频中的语音内容

注意:browser-use 的 API 随着版本迭代变化较快。本文基于我当前使用的版本编写,如果你的版本较新,部分参数名可能需要调整。建议安装后先查看官方示例确认接口签名。

2.2 创建项目环境

mkdir ai-browser-agent cd ai-browser-agent python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install --upgrade pip pip install browser-use playwright langchain-openai playwright install chromium

playwright install chromium这一步很关键,它会下载 Chromium 内核。如果不执行,后续运行时会报浏览器启动失败的错误。视频处理场景还需要额外安装 ffmpeg:

# macOS brew install ffmpeg # Ubuntu/Debian sudo apt update && sudo apt install ffmpeg

2.3 自定义工具扩展

最新版本的 browser-use 允许用户通过@tool装饰器注册自定义 Python 函数,将普通函数封装为模型可调用的工具。当内置的按钮点击、输入、滚动等原子操作无法满足需求时,自定义工具能显著扩展智能体能力。

例如,你可以把“获取当前时间”“调用内部接口查询订单状态”“执行一段 SQL”封装成工具,让模型在任务中直接调用。这种模式和函数调用机制一致,是 browser-use 从简单演示走向真实业务的关键能力。

3. 核心原理拆解

3.1 LLM 如何控制浏览器

browser-use 底层基于 Playwright 与真实浏览器建立连接。每次模型需要决策时,框架会从浏览器中提取一份结构化的“可访问性快照”,这份快照包含:

  • 当前页面可见的文本内容。
  • 页面中的按钮、输入框、链接等可交互元素。
  • 元素的编号索引和基础属性。

然后将快照传给大模型。模型根据任务目标和当前页面状态,输出类似这样的决策:

  • 点击编号为 12 的元素。
  • 在编号为 8 的输入框中输入内容。
  • 滚动页面到某个位置。
  • 等待固定时间。

框架解析模型输出并调用 Playwright 执行对应动作,执行完成后再次生成新的页面快照,继续让模型决策。整个过程形成一个“感知-决策-执行”的闭环。

3.2 核心 API 拆解

以目前常见的写法为例,一个最小任务是这样组织的:

from langchain_openai import ChatOpenAI from browser_use import Agent import asyncio async def run_search_task(): agent = Agent( task="打开百度,搜索浏览器自动化框架 browser-use,并把搜索结果标题列出来", llm=ChatOpenAI(model="gpt-4o", temperature=0), ) result = await agent.run(max_steps=20) print(result) if __name__ == "__main__": asyncio.run(run_search_task())

各参数的作用:

参数作用
task给智能体的任务描述,描述越具体执行越准确
llm驱动智能体决策的大模型实例
max_steps最大执行步数,防止模型无限循环
controller自定义工具控制器,注册额外能力

3.3 自定义 Controller 注册工具

当内置能力不够时,可以通过Controller注册自定义工具。这里的核心思路是:写一个普通 Python 函数,加上@controller.action装饰器,函数就变成了模型可以调用的工具。

from browser_use import Controller from pydantic import BaseModel controller = Controller() class DateParams(BaseModel): format: str = "%Y-%m-%d" @controller.action("获取当前日期", param_model=DateParams) async def get_current_date(format: str) -> str: from datetime import datetime return datetime.now().strftime(format)

注册后,将controller传入Agent

agent = Agent( task="告诉我今天的日期", llm=llm, controller=controller, )

这样模型在回答任务时如果发现需要当前日期,就会调用这个自定义工具来获取。对于复杂业务,可以把内部系统查询、数据库读取、文件操作全部封装成这类工具。

3.4 容易混淆的概念

新手容易把 browser-use 和 Selenium、Playwright 原生自动化混为一谈。两者区别如下:

方向传统自动化(Selenium/Playwright)browser-use
定位元素依赖选择器、XPath、CSS依赖模型理解语义
页面改版影响改版后脚本需要重写改版后模型通常能自适应
适用复杂度适合稳定页面适合页面结构经常变化的场景
成本开发成本高依赖模型调用费用
稳定性更高,确定性执行受模型能力影响

这个区别很关键。browser-use 不能替代传统自动化,它更适合把“需要人来判断”的流程交给模型,而不是把“已经确定、高频、需要毫秒级响应”的流程交给模型。

4. 完整实战案例

4.1 场景设计

为了演示 browser-use 和 video-use 的配合,我们设计一个内容审核场景:

  1. 用 browser-use 自动登录内部内容管理后台。
  2. 在后台打开待审核视频列表。
  3. 下载视频文件到本地。
  4. 用 video-use 链路对视频做解析:提取音频、转写字幕、抽取关键帧。
  5. 将视频摘要、语音转写文本、关键帧信息汇总成审核辅助报告。

演示环境是内部测试系统,生产环境使用前必须确保有合法授权,并遵守平台的 robots 协议和用户协议。

4.2 项目结构

为了让代码清晰,我按下面的结构组织项目:

ai-browser-agent/ ├── .env # 环境变量 ├── config.py # 配置项 ├── main.py # 主流程 ├── browser_tools.py # browser-use 自定义工具 ├── video_tools.py # 视频解析工具模块 └── requirements.txt # 依赖清单

4.3 编写配置文件

.env文件保存敏感信息:

OPENAI_API_KEY=sk-xxxx OPENAI_BASE_URL=https://api.openai.com/v1 BROWSER_HEADLESS=false VIDEO_DIR=./downloads ALLOWED_DOMAIN=admin.internal.example.com

config.py 读取配置:

import os from dotenv import load_dotenv load_dotenv() class Config: OPENAI_API_KEY = os.getenv("OPENAI_API_KEY") OPENAI_BASE_URL = os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1") HEADLESS = os.getenv("BROWSER_HEADLESS", "false").lower() == "true" VIDEO_DIR = os.getenv("VIDEO_DIR", "./downloads") ALLOWED_DOMAIN = os.getenv("ALLOWED_DOMAIN", "")

4.4 browser-use 自动化登录与列表提取

在 browser_tools.py 中,我注册了一个自定义动作,用于检查当前页面 URL 是否在允许的域名范围内,防止模型误操作跳转到外部站点:

from browser_use import Controller from pydantic import BaseModel controller = Controller() class CheckUrlParams(BaseModel): expected_domain: str = "" @controller.action("检查当前页面域名是否允许", param_model=CheckUrlParams) async def check_url_domain(expected_domain: str) -> str: # 需要通过框架上下文获取当前页面地址 # 示例中简化为返回检查结果 if expected_domain and expected_domain not in current_url: return "当前页面不在允许域名内,请回到后台系统" return "当前页面允许访问"

登录和列表提取的主逻辑放在 main.py 中。由于不同内部系统的登录方式差异很大,这里用伪代码演示流程,你需要根据自己系统的实际选择器或操作流程来替换对应步骤:

import asyncio import config from browser_use import Agent from browser_tools import controller async def process_video_review(): prompt = f""" 请完成以下任务: 1. 打开内部内容后台地址 {config.LOGIN_URL}。 2. 使用账号密码登录,账号信息已保存在环境变量中。 3. 登录成功后,进入“视频审核”菜单。 4. 找到最新的待审核视频,点击进入详情页。 5. 将详情页中的视频标题、上传时间、视频下载地址、当前状态记录到结果文件中。 """ agent = Agent( task=prompt, llm=llm, controller=controller, ) result = await agent.run(max_steps=40) return result

需要强调一点:把账号密码直接写进任务描述是一个高风险行为,生产环境应改用自定义工具注入凭据,不要让模型在上下文中保存明文密码。

4.5 video-use 视频解析链路

video_tools.py 实现视频解析核心逻辑。先抽取视频音频和关键帧:

import subprocess import os def extract_audio(video_path: str, audio_path: str): """使用 ffmpeg 提取视频中的音频轨道""" cmd = [ "ffmpeg", "-y", "-i", video_path, "-vn", "-acodec", "pcm_s16le", "-ar", "16000", "-ac", "1", audio_path, ] subprocess.run(cmd, check=True, capture_output=True) def extract_keyframes(video_path: str, output_dir: str, interval: int = 10): """每隔指定秒数抽取一帧关键帧""" os.makedirs(output_dir, exist_ok=True) cmd = [ "ffmpeg", "-y", "-i", video_path, "-vf", f"fps=1/{interval}", os.path.join(output_dir, "frame_%04d.jpg"), ] subprocess.run(cmd, check=True, capture_output=True)

提取音频后,用语音转写模型把音频变成文字,再交给大模型做摘要和标签提取:

def transcribe_audio(audio_path: str) -> str: """使用 openai-whisper 将音频转写为文本""" import whisper model = whisper.load_model("base") result = model.transcribe(audio_path) return result["text"]

获得文本后,使用大模型生成结构化审核信息:

def generate_video_summary(transcript: str, llm) -> dict: """将视频转写文本交给大模型,生成摘要与标签""" messages = [ { "role": "system", "content": "你是一名视频内容审核助手。请根据用户提供的视频语音转写文本,输出:1. 一句话内容摘要;2. 五个内容标签;3. 是否存在违禁风险。", }, {"role": "user", "content": transcript}, ] response = llm.invoke(messages) return {"summary": response.content}

4.6 串联 browser-use 与 video-use

main.py 中的完整主流程如下:

import asyncio import os import config import video_tools from pathlib import Path async def main(): # 1. 浏览器自动化获取待审核视频信息 video_meta = await fetch_video_meta() # 2. 下载视频文件到本地(演示用,下载前必须确认授权) video_path = download_video(video_meta["url"]) # 3. 提取音频 audio_path = video_path.replace(".mp4", ".wav") video_tools.extract_audio(video_path, audio_path) # 4. 转写语音 transcript = video_tools.transcribe_audio(audio_path) # 5. 生成审核摘要 summary = video_tools.generate_video_summary(transcript, llm) # 6. 输出审核报告 print("审核报告:") print(summary) if __name__ == "__main__": asyncio.run(main())

4.7 运行与预期输出

在项目根目录执行:

python main.py

如果一切正常,会看到浏览器窗口弹出并自动完成登录、列表访问、详情页信息提取等操作;视频解析链路则会在本地生成音频文件和关键帧图片,控制台输出最终的审核摘要内容。

由于内部系统和模型版本不同,预期输出无法给出绝对固定的文本。但整体流程应该串得通:浏览器智能体获取了视频元信息,本地视频解析链路生成了结构化结果,两个模块通过文件或函数调用完成数据交换。

5. 常见问题与排查思路

5.1 高频问题清单

问题现象常见原因解决思路
浏览器启动失败未安装 chromium 内核执行playwright install chromium
模型调用超时网络不稳定或 API Key 无效检查网络和 Key,设置超时重试
元素点击无效页面使用了 iframe 或 Shadow DOM使用 browser-use 的 iframe 支持能力,或在任务描述中注明
智能体任务未完成就结束达到max_steps上限增大步数上限,拆分子任务
登录凭据被识别没有合理模拟用户行为增加等待、随机延时,避免高频操作
视频转写结果为空白音频提取失败或采样率不匹配检查 ffmpeg 命令输出,确认音频轨存在
输出 report 文件丢失文件路径权限问题确认目录可写,使用绝对路径
模型决策不准确任务描述太模糊将任务拆成更细颗粒度的子任务

5.2 典型报错场景分析

场景一:安装后运行报 ModuleNotFoundError。

这种通常是包没装全或 Python 环境没激活。执行pip list | grep browser-use确认包是否已安装,并确保在虚拟环境中运行脚本。

场景二:浏览器能打开但页面一直停留不动。

可能原因有两个:一是模型 API 调用失败但没有明显报错,建议打印llm调用日志;二是浏览器页面存在弹窗或验证码,模型不知道如何处理。此时可以在任务描述里补充“如果出现弹窗,先点击关闭按钮”。

场景三:视频解析时 ffmpeg 报错。

检查 ffmpeg 是否安装,并查看具体错误码。常见的是文件路径包含空格或特殊字符,建议统一使用Path对象处理路径,避免手写字符串拼接。

5.3 排查建议

遇到问题不要盯着智能体的报错信息看,先分清楚是哪个环节出了问题:

  1. 是浏览器操作环节还是模型决策环节?
  2. 是视频解析环节还是最终汇总环节?
  3. 打印关键中间结果,例如把模型决策输出、视频转写文本都输出到日志文件。

这样能快速定位问题,而不是盲目调参。

6. 最佳实践与工程建议

6.1 任务设计建议

智能体的任务描述质量直接决定执行效果。好的任务描述应该包含:目标、路径、兜底策略。

反面示例:“打开后台,找到那个视频,看看有没有问题。”

正面示例:“打开后台视频审核页面,登录后找到第一个状态为‘待审核’的视频,进入详情页,将标题和播放地址填入本地 JSON 文件。如果找不到待审核视频,直接输出‘无待审核任务’。”

此外,尽量把长任务拆成多个短任务。一个 Agent 跑 40 步容易出现步骤偏差,两个 Agent 各跑 15 步,配合检查点,稳定性会好很多。

6.2 配置与敏感信息管理

  • API Key、账号密码一律放到环境变量或密钥管理服务中,不要硬编码在代码里。
  • 自定义工具负责获取敏感信息,避免把明文凭据拼到任务描述里。
  • 生产环境使用独立的低权限账号,并配置严格的 IP 白名单。
  • 项目中的.env文件加入.gitignore,防止误提交。

6.3 安全边界

  • 智能体只能访问业务需要的域名,如果框架支持 URL 过滤,一定要配置。
  • 视频下载前确认有合法授权,遵守平台服务条款。
  • 审核类任务不要把原始视频的敏感画面直接发送给云端大模型,应先本地脱敏。
  • 所有自动化操作建议在测试环境充分验证后再用于生产。

6.4 日志与可观测性

智能体任务不记录日志相当于黑盒运行。建议至少记录以下几类内容:

  1. 任务开始时间、结束时间、执行状态。
  2. 模型每次决策的动作和页面 URL。
  3. 每个阶段的耗时。
  4. 视频解析的中间产物路径。
  5. 最终输出文件内容摘要。

结构化 JSON 日志是最方便的,后续可以直接接入日志平台做分析和告警。

6.5 成本控制

browser-use 每执行一次任务都会消耗多次模型调用,长任务调用量不容小觑。控制成本的方式有:

  • 任务描述精简,减少无效步骤。
  • 优先使用性价比高的模型处理简单步骤。
  • 对高频重复任务先做结果缓存。
  • 合理设置max_steps,避免模型在页面中反复试探。

6.6 失败重试与人工兜底

任何智能体方案都可能失败,尤其是登录流程和验证码环节。建议在工程上做好重试:

  • 失败后自动重试 2 到 3 次。
  • 达到重试上限后自动发消息通知人工处理。
  • 保留页面截图和当时的状态快照,方便人工快速定位问题。

7. 总结与学习路线

这篇文章围绕 browser-use 和 video-use 两个方向展开了完整的实战链。核心要点可以总结为:

  • browser-use 解决了“让大模型操作真实浏览器”的问题,适合任务描述清晰、需要语义理解的自动化场景。
  • video-use 也不是单一框架,而是视频解析、语音转写、关键帧提取、内容摘要等一系列工具的集合。
  • 两者结合可以把“浏览器获取视频信息 → 本地下载解析 → AI 生成结构化审核结果”的完整流程自动化。

如果你想继续深入,下一步可以从这几个方向入手:

  • 研究 Playwright 的底层 API,理解浏览器自动化的事件模型和等待机制。
  • 学习提示词工程,掌握如何为智能体编写更稳定的任务描述。
  • 了解多模态大模型的视频理解能力,目前不少模型可以直接输入视频帧序列,省去本地抽取关键帧的步骤。
  • 关注 browser-use 社区的新版本特性,这类项目迭代很快,及时更新认知很重要。

实际落地时优先关注安全和合规:授权要清晰、凭据要加密、数据要脱敏、操作要留痕。自动化不是越猛越好,稳定可控才是生产环境的底线。

如果你正在规划类似的智能体自动化项目,建议先拿一个低频、低风险的流程做试点,跑顺之后再逐步扩大范围。这样既能验证效果,也能积累团队对这套技术栈的运维经验。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询