AI Agent实战：从browser-use到video-use的自动化探索

网页自动化领域有一个长期存在的矛盾：脚本越写越多，维护成本却越来越高。传统自动化工具解决的是“操作稳定性”，但始终没有解决“理解能力”——页面结构一变，XPath 失效；元素加载方式调整，等待条件要重写。真正消耗开发者的时间，往往不在写脚本，而在改脚本。

browser-use 的出现，把一个很直接的想法带进了浏览器自动化：让大模型直接指挥真实浏览器。它不再要求开发者写死的选择器和等待逻辑，而是由多模态大模型理解页面截图和 DOM 信息，自行规划操作步骤。这个项目在 2024 年到 2025 年之间热度上升很快，已经成了 AI Agent 连接真实网络世界的一个重要工具层。

顺着同样的逻辑向下推，自然会出现一个延伸方向：video-use。网页有 DOM、有文本节点、有可访问性树，视频没有现成的“结构”可以直接读取。但视频同样可以被 AI 理解、被自动化处理——抽帧、识别镜头、解析语音、生成字幕、剪辑成片。browser-use 解决的是“AI 如何操作真实网页”，video-use 要解决的则是“AI 如何操作真实视频”。这篇文章会完整讲解 browser-use 的落地方法，包括安装、原理、代码示例、运行验证、常见问题和工程建议；同时，我会结合现有技术栈，给出一个 video-use 方向的探索性实现思路，帮助你把浏览器自动化的经验迁移到视频自动化的场景中。

1. 这篇文章真正要解决的问题

先聊一个更现实的问题：很多团队看到 browser-use 的第一反应是“又一个爬虫框架”。这其实低估了它。

browser-use 的核心价值不是爬取网页，而是给 Agent 提供一个浏览器执行环境。爬虫只是它能力范围内最简单的一种用途。在实际项目里，真正有代表性的场景是这些：

• 业务人员在后台系统里逐条填写表单，每天重复几百次。开发者可以用 browser-use 写一个 Agent，让大模型根据业务数据自动操作表单，省去人工录入。
• 网页自动化测试用例的维护成本过高。页面稍微改版，测试脚本就要跟着改。用 browser-use 后，测试目标变成自然语言描述，页面变化时大模型会重新推理操作路径。
• 跨网站的数据采集。多个网站结构互不相同，传统爬虫需要为每个网站单独写解析规则。browser-use 可以直接说“打开这些网站，把新闻标题和发布时间整理成表格”。
• 浏览器操作与视频操作开始产生联动。一个 Agent 可以在浏览器里寻找视频素材，下载后调用视频处理工具做裁剪、转码和字幕合成。

这篇文章适合三类读者：第一类是正在做网页自动化、RPA 替代和自动化测试的开发者，browser-use 可以显著降低脚本维护成本；第二类是关注 AI Agent 工程化的同学，需要理解 Agent 如何通过工具调用真实世界的能力边界；第三类是做视频工具、AIGC 产品的开发者，想了解 video-use 这样的方向为什么会成为浏览器自动化之后的下一站。

读完这篇文章，你能得到三个实际收益：掌握 browser-use 的最小可用环境搭建；理解 Agent 浏览器自动化的感知-推理-执行链路；基于现有视频处理工具，搭建一个 video-use 风格的视频自动化探索原型。

2. browser-use 核心概念：给 Agent 一把浏览器的钥匙

browser-use 本身并不是一个全新的浏览器，而是建立在已有浏览器自动化能力之上的智能层。从实现来看，它通常基于 Playwright 等浏览器自动化库，在控制真实浏览器执行点击、输入、滚动、跳转等操作的同时，把任务的决策权交给大语言模型。

2.1 感知-推理-执行-反思的循环

用 browser-use 写一个 Agent，它的运行过程可以拆成四个阶段：

• 感知：Agent 获取当前浏览器的状态，包括页面截图、DOM 结构、URL、可点击元素等。
• 推理：大模型结合用户的任务描述和当前状态，输出下一步要执行的动作，例如“点击某个按钮”“输入某段文字”。
• 执行：Agent 将模型输出的动作映射为浏览器操作，通过 Playwright 层真实执行。
• 反思：执行完成后，Agent 重新获取页面状态，判断任务是否完成。如果没有完成，继续进入下一步推理。

这个循环看起来简单，但意义在于它把“理解页面”这件事从开发者身上转移到了大模型身上。传统自动化脚本遇到页面改版时，开发者往往需要重新定位元素；browser-use 则通过大模型的语义理解能力，让 Agent 在结构变化时仍然完成目标。

2.2 与传统浏览器自动化的对比

需要注意，这并不意味着 browser-use 能完全替代传统自动化工具。在结构非常稳定、对执行速度要求极高的场景里，传统方式仍然更优。browser-use 的优势场景是页面变化频繁、任务目标相对高层、传统脚本维护成本过高的地方。

2.3 为什么模型选择是关键

browser-use 的智能程度高度依赖大模型。模型需要有三种能力：

• 视觉理解能力。Agent 拿到页面截图后，要识别按钮、输入框、弹窗和表格。
• 工具调用能力。模型需要输出结构化的动作指令，比如go_to_url、click_element、fill_input。
• 长上下文规划能力。一个任务可能包含几十个步骤，模型需要记住目标和已经执行过的操作。

所以在实际项目中，不建议在 browser-use 上使用过弱的模型。文本模型只能看到 DOM，多模态模型能看到截图，对页面布局的理解会更直接；工具调用能力弱的模型，动作序列经常出错，任务很难完成。模型选择直接决定了 Agent 的成功率和 token 消耗，这一点在后面的最佳实践部分还会展开。

3. video-use 是什么：从浏览器自动化到视频自动化

理解了 browser-use 的模式，再来看 video-use 就清晰了。browser-use 的核心，是把大模型的决策能力和浏览器的执行能力连接起来；video-use 则是把大模型的视频理解能力和视频处理工具连接起来。

3.1 视频自动化为什么比网页自动化难

视频文件的结构比网页复杂得多。一个网页有 DOM、有文本、有超链接，浏览器可以一键跳转；视频文件则是连续帧序列，还需要解码、抽帧、音频转录等一系列前置处理。要让 AI Agent 操作视频，相比网页需要额外解决几个问题：

• 内容不可直接读取：视频要先解码，提取关键帧和音频轨道。
• 语义理解复杂：一段视频里可能有多个镜头、多个场景、多句对白，Agent 需要确定“哪个片段才是用户感兴趣的内容”。
• 操作粒度差异大：网页操作是点击和输入，视频操作则是剪辑、转码、变速、加字幕、调整画面比例。
• 工具链分散：视频处理依赖 ffmpeg、OpenCV、剪辑 SDK、语音识别接口，Agent 需要一个统一的工具入口。

3.2 video-use 的三层架构

按照 browser-use 的逻辑，一个 video-use Agent 至少应该包含三层：

• 感知层：负责把视频转成 Agent 可理解的输入。典型做法是按固定间隔抽帧，配合音频转录文本，形成一个“视频内容清单”。
• 决策层：由大模型基于内容清单做规划。例如“找到第 2 分钟到第 5 分钟的高光片段”“给视频第一段加字幕”等。
• 执行层：调用 ffmpeg、OpenCV、字幕工具、语音识别服务等完成实际视频操作。

这里需要说明一点：目前并没有一个像 browser-use 那样一套代码通吃的“video-use”标准库，公开场景中更多是开发者自己组合视频处理工具。所以下面的实现部分，我会用 Python 构建一个最小可用原型，展示视频 Agent 的感知、决策、执行链路，然后你可以根据实际项目替换具体工具。

4. 环境准备与安装

无论跑 browser-use 还是做视频 Agent，都需要一套基础 Python 环境。以下环境均以 Python 3.10 以上版本为参考，工具版本建议以实际安装为准。

4.1 安装 browser-use

创建一个新的 Python 虚拟环境，然后安装 browser-use 和 Playwright 浏览器。

python -m venv .venv source .venv/bin/activate pip install browser-use playwright playwright install chromium

说明：

• browser-use是核心 Agent 库，负责把大模型指令转换为浏览器操作。
• playwright是浏览器自动化底层依赖，browser-use需要它来驱动真实浏览器。
• playwright install chromium用于安装 Chromium 浏览器内核。如果你本机已经有 Chrome，也可以配置 browser-use 使用现有浏览器，但初次体验用内置 Chromium 最省事。

4.2 配置大模型 API

browser-use 需要通过 LangChain 的大模型接口来对接各家模型。以 OpenAI 模型为例，需要先设置环境变量：

export OPENAI_API_KEY="sk-你的API密钥"

如果使用其他模型，可以安装对应 LangChain 包，比如langchain-anthropic、langchain-google-genai，在代码中创建对应的 LLM 实例即可。

4.3 验证安装是否成功

在命令行中执行：

python -c "from browser_use import Agent; print('browser-use ok')"

如果这条命令没有报错，说明核心依赖已经装好。接下来进入代码示例。

5. 最小可运行示例：让 Agent 自己打开网页搜索

先用一个最小示例跑通全流程。这个示例会让 Agent 打开搜索引擎，输入关键词，返回首个结果标题。

5.1 完整代码

# 文件路径：minimal_browser_use.py from browser_use import Agent from langchain_openai import ChatOpenAI import asyncio async def main(): agent = Agent( task="打开百度，搜索“Python 3.13 新特性”，把搜索结果的第一条标题返回给我", llm=ChatOpenAI(model="gpt-4o"), ) await agent.run() if __name__ == "__main__": asyncio.run(main())

5.2 代码逻辑解释

这段代码只有三个关键对象：

• Agent：browser-use 的核心类，接收任务描述和大模型实例。
• task：开发者用自然语言描述的目标。这里把目标拆成“打开百度”“搜索关键词”“返回第一条标题”三个子步骤。
• ChatOpenAI：通过 LangChain 包装的 OpenAI 模型。它负责在每个决策节点上根据当前页面状态输出动作。

整个执行过程是自动的。你不需要指定 URL，也不需要写搜索框的选择器，Agent 会在浏览器里自行找到搜索框、输入关键词、点击搜索按钮。

5.3 运行方式

python minimal_browser_use.py

运行时，桌面上会弹出一个 Chromium 窗口。你可以看到 Agent 的操作过程：页面依次跳转、输入框被自动填写、搜索结果页被打开。终端同时会输出 Agent 的每一步动作日志。

5.4 单步执行和调试模式

如果任务较复杂，建议开启调试模式，方便观察 Agent 每一步的动作：

# 文件路径：debug_browser_use.py from browser_use import Agent from langchain_openai import ChatOpenAI import asyncio async def main(): agent = Agent( task="打开百度，搜索“browser-use 教程”，把搜索结果的前三条标题整理成列表", llm=ChatOpenAI(model="gpt-4o"), max_steps=30, ) await agent.run(max_steps=30) if __name__ == "__main__": asyncio.run(main())

这里的max_steps用于限制 Agent 的最大动作步数。在早期调试阶段建议设置一个合理的上限，防止任务偏离预期后一直循环执行，消耗过多 token。

6. 进阶示例：让 Agent 打开真实网页提取结构化数据

验证完最小流程后，重点看一个更接近生产需求的场景：打开一个新闻聚合页面，提取标题列表，并以 JSON 格式返回。

6.1 使用无头浏览器提升效率

默认情况下 browser-use 会弹出浏览器窗口。在服务器或 CI 环境里，我们需要使用无头模式。

# 文件路径：headless_table_agent.py from browser_use import Agent, Browser, BrowserConfig from langchain_openai import ChatOpenAI import asyncio async def main(): browser = Browser( config=BrowserConfig( headless=True, ) ) agent = Agent( task="打开 Hacker News 首页，提取前 5 条新闻标题和对应链接，以 JSON 格式输出", llm=ChatOpenAI(model="gpt-4o"), browser=browser, ) result = await agent.run() print(result) await browser.close() if __name__ == "__main__": asyncio.run(main())

6.2 关键点说明

关于浏览器实例，需要特别注意。Browser和BrowserConfig用于创建浏览器实例，headless=True表示不显示窗口。在无头模式运行完成后，一定要调用browser.close()释放资源，否则进程可能残留。

关于任务描述，提取结构化数据时，任务描述里要写明输出格式，例如“以 JSON 格式输出”。大模型会尽力按格式返回，但最终结果仍然需要你的代码做二次校验。更稳妥的做法是，在 task 最后加上“不要输出多余解释，只输出 JSON”。

运行该脚本后，终端会输出 Agent 的执行日志，最终打印结果对象。你可以通过result.final_result()获取最终的文本结果：

# 在 main 函数中修改 result = await agent.run() final_text = result.final_result() print(final_text)

6.3 将结果写入文件

把 Agent 输出保存到文件，是生产环境中的常见做法：

import aiofiles import json async def save_result(result_text: str): async with aiofiles.open("result.json", "w", encoding="utf-8") as f: await f.write(result_text)

实际项目中，建议对 Agent 返回的结果做结构校验，确保它包含你需要的字段，而不是直接把字符串写入文件。因为大模型的输出存在格式不确定性，在数据入库前必须校验。

7. 从 browser-use 到 video-use：一个可运行的探索框架

现在回到 video-use。前面说过，目前还没有一套统一的标准库，但我们可以按照 browser-use 的“感知-推理-执行”思路搭建一个最小原型。这里的重点不是交付一个完整工具，而是帮助你理解视频自动化的核心架构。

7.1 video-use 感知层的具体做法

视频感知是整个流程里最关键的一步。我们要把视频变成 Agent 能理解的内容。最常用的思路是抽帧 + 音频转录。

# 文件路径：video_perception.py import cv2 def extract_frames(video_path: str, interval_seconds: float = 1.0): """按固定时间间隔抽取视频帧，返回帧的时间点列表。""" cap = cv2.VideoCapture(video_path) fps = cap.get(cv2.CAP_PROP_FPS) frame_interval = int(fps * interval_seconds) frame_info = [] count = 0 while cap.isOpened(): ret, frame = cap.read() if not ret: break if count % frame_interval == 0: timestamp = count / fps output_path = f"frame_{int(timestamp)}.jpg" cv2.imwrite(output_path, frame) frame_info.append({"timestamp": timestamp, "frame": output_path}) count += 1 cap.release() return frame_info if __name__ == "__main__": frames = extract_frames("input.mp4", interval_seconds=2.0) print(f"抽取了 {len(frames)} 帧")

这段代码的核心逻辑是：用 OpenCV 打开视频，按固定的时间间隔抽取帧保存为图片，同时记录每张图片对应的时间点。这样，后续大模型就能结合图片和时间戳去理解视频内容。

7.2 将视频信息交给大模型规划

抽取关键帧之后，Agent 需要理解画面内容。一种方式是把多张截图交给多模态大模型；另一种是把画面描述成文本，供文本模型决策。以下是一个伪代码示例，展示决策层如何基于感知结果规划操作。

# 文件路径：video_agent_framework.py import asyncio from language_model_client import VideoLLMClient async def plan_video_operations(video_metadata: list): """ 输入：video_metadata 是感知阶段生成的关键帧描述、时间点、音频转录。 输出：一个视频操作计划，比如剪切某个片段、给某个片段加字幕。 """ llm = VideoLLMClient(model="your-video-model") prompt = f""" 你是一个视频处理 Agent。 这是视频的关键帧描述：{video_metadata} 用户希望通过视频号运营素材来完成一条 30 秒的竖屏短视频。 请规划出 3 步以内的视频操作，并输出 JSON 格式。 """ plan = await llm.predict(prompt) return plan

这里的VideoLLMClient只是占位符，实际项目中接入 OpenAI、Claude 或其他多模态模型即可。

7.3 执行层：用 ffmpeg 完成真实剪辑

规划完成后，Agent 需要执行具体的视频操作。以 ffmpeg 为例，可以用 subprocess 调用命令行工具完成剪切。

# 文件路径：video_execution.py import subprocess def cut_video(input_path: str, start_time: float, duration: float, output_path: str): """调用 ffmpeg 剪切视频片段。""" command = [ "ffmpeg", "-ss", str(start_time), "-t", str(duration), "-i", input_path, "-c", "copy", output_path, "-y", ] result = subprocess.run(command, capture_output=True, text=True) if result.returncode != 0: raise RuntimeError(f"ffmpeg 执行失败: {result.stderr}") return output_path if __name__ == "__main__": cut_video("input.mp4", start_time=10.0, duration=5.0, "clip_10s.mp4")

这里的意义在于，视频操作已经和 Agent 的决策分离。大模型不需要知道 ffmpeg 的复杂参数，它只需要输出“从第 10 秒开始剪 5 秒”，执行层负责把这一指令翻译成 ffmpeg 命令。这个模式与 browser-use 让大模型调用浏览器动作的逻辑完全一致。

7.4 完整视频 Agent 的工作流

你可以把前面三段代码串起来，形成一个完整的 video-use 链路：

1. 感知：抽帧并转录音频，生成视频内容索引。
2. 规划：Agent 分析内容索引，输出操作步骤。
3. 执行：调用 ffmpeg、字幕工具或剪辑 SDK，按步骤执行。
4. 验证：再次抽帧检查输出视频是否符合预期。

这套链路是 browser-use 思想在视频方向的自然延伸。它与成熟的 browser-use 相比还比较原生化，但这恰恰是开发者可以发力的地方：如果你能在一套框架里把感知、规划、执行三个层统一起来，它就是一个非常有价值的 video-use 雏形。

8. 运行效果与验证

无论是运行 browser-use 还是视频 Agent，都需要明确“怎样算成功”。

8.1 browser-use 的预期输出

以第 5 节的搜索示例为例，运行python minimal_browser_use.py后，你会看到：

• Chromium 浏览器窗口自动打开。
• 地址栏自动输入百度地址并跳转。
• 搜索框被自动填入关键词。
• 搜索结果页显示，Agent 自动提取第一条标题。

终端日志中会出现类似“Step 1: navigate”“Step 2: input_text”“Step 3: extract_content”这样的信息。不同版本的日志格式可能有差异，但基本结构相似。

如果最终终端打印出正确标题，说明任务成功。如果运行中途停滞，第一步应该查看日志中最后一步动作，看是页面没有加载完成，还是模型输出动作无法映射到浏览器元素。

8.2 视频 Agent 的预期输出

跑通视频感知框架后，你会得到一个关键帧文件列表。例如输入一段 10 秒视频，每隔 2 秒抽一帧，最终会得到 5 张图片。运行ffmpeg剪切后，你会得到一个新的视频文件。验证方法是：

ffprobe clip_10s.mp4

ffprobe是 ffmpeg 工具集里的视频信息查看器。如果输出视频时长与预期一致，说明剪切成功。

8.3 如何判断任务是否真正完成

Agent 任务的结果不能只看“最后一句话”。建议在工程上增加三个验证点：

• 动作验证：每个动作在执行后，检查浏览器或视频工具是否发生预期变化。
• 结果验证：对 Agent 的最终输出做结构化校验。
• 人工抽查：在初期阶段，对 Agent 的处理结果进行抽样检查，确认没有出现语义偏差。

一个常见误区是 Agent 提示词里写了“以 JSON 输出”，开发者就直接对输出做json.loads。但模型偶尔会输出 Markdown 代码块或额外文本。更可靠的做法是先清洗再解析，或者要求模型输出纯 JSON 并关闭多余解释。

9. 常见问题与排查思路

下面整理几种在 browser-use 使用过程中的高频问题，以及对应的排查建议。

这里需要特别强调：排查 Agent 类工具的问题，思路和排查传统程序不太一样。传统程序报错有明确堆栈，Agent 工具的错误往往出现在“模型理解”和“页面状态”的偏差上。所以，最有效的排查手段其实是日志：确保你的 Agent 运行日志里包含每个步骤的动作、模型输入、模型输出和页面状态摘要。

10. 最佳实践与工程建议

10.1 任务描述要具体，但不必过于细节

browser-use 的任务描述是自然语言，但也不是越简短越好。把目标拆解成可见的中间结果，比如“打开页面后先等待登录完成，再进入个人中心”，Agent 的成功率会明显提高。反过来，如果任务目标太模糊，Agent 可能耗费大量步数在无关操作上。

10.2 模型选择要分层

在实际项目中，不建议所有任务都用同一个最强模型。可以按任务复杂度分层：

• 简单导航、表单填写：使用性价比更高的模型。
• 需要复杂页面理解、多步骤推理：使用多模态强模型。
• 定时批量任务：可以先用小模型跑，失败后升级到大模型重试。

这种“模型路由 + 失败重试”的思路，能把成本控制在合理范围，同时保证成功率。

10.3 给 Agent 设置边界

Agent 操作的是真实浏览器，生产环境里需要严格限制权限。建议做好以下几点：

• 只允许 Agent 访问任务需要的域名，使用代理白名单或网络策略限制。
• 不超过max_steps上限，避免失控循环消耗资源。
• 涉及提交数据时，先跑测试环境，确认无误后再切生产。
• 日志中包含敏感信息时脱敏。

10.4 引入自定义工具

browser-use 的魅力在于它可以被扩展。不要把它当成一个只能浏览网页的黑盒，而是把它当作一个 Agent 框架。在浏览器操作之外，你可以把内部 API、数据库查询、文件处理、ffmpeg 调用等能力注册为自定义工具，让 Agent 在一个任务里既浏览网页，又调用后端服务。

video-use 方向的探索同样遵循这个原则。感知层替换成视频解析模块，执行层替换成视频剪辑模块，决策层不需要变，Agent 就能从“网页操作员”变成“视频处理员”。

10.5 做好成本控制

Agent 类任务消耗的是 token，成本会比传统脚本高。建议：

• 对任务步骤做预算，超过预算自动终止。
• 缓存页面截图和 DOM 摘要，避免同一页面重复推理。
• 优先使用无头模式跑批量任务，只在调试时打开可视化窗口。
• 对模型返回结果做结构校验，避免因格式错误重新执行整个任务。

11. 总结与下一步

回到最初的问题：browser-use 到底解决的是什么？它解决的不是“如何更稳地操作浏览器”，而是“如何让 AI 理解并操作浏览器”。它把网页自动化从“选择器编码”推进到了“意图驱动”，这也是 AI Agent 时代工具层的一个典型样本。

video-use 站在同样的逻辑起点上。视频没有 DOM，但视频有画面、有时间线、有语音轨道，这些都可以被解析成 Agent 能理解的输入。只要感知层做得足够好，决策层和执行层的模式与 browser-use 几乎一致。这也是我判断 video-use 会成为浏览器自动化之后重要方向的原因。

接下来你可以从三个方向继续深入：第一，把 browser-use 接入自己的业务流程，从一个最小任务开始积累 Agent 日志和调优经验；第二，研究自定义工具的注册方式，让 Agent 不仅操作浏览器，还能操作你内部的 API 和工具链；第三，把文中的视频感知框架跑通，用一段真实视频测试帧抽取、语音转录和 ffmpeg 剪辑的组合效果。

需要提醒的是，Agent 自动化和传统脚本有一个根本区别：它的判断不是 100% 确定的。生产环境落地时，一定要给 Agent 设置验证点和回退机制，让它在任务异常时能停下来交给人处理，而不是无限重试。这套“让机器执行，让人监督”的思路，才是 browser-use 和 video-use 真正落地时最核心的工程经验。