【Browser Use】 源码剖析给 LLM 一双眼睛和一双手——DOM-First 【浏览器 Agent】 的设计哲学写在前面在拆完 LangGraph、Pocket Flow、Harness Agent 之后今天我们来看一个完全不同类型的 Agent 框架——Browser Use。它不做图计算不做 Coding Agent不做工作流编排——它只做一件事让 LLM 像人一样操作浏览器。GitHub 上超过85K StarWebVoyager 基准得分89.1%支持 Claude/GPT/Gemini/本地模型。它的核心论点极其简洁不要给 LLM 看截图给它看 DOM 树。这个看似简单的选择决定了整个框架的架构哲学。今天我们深入源码拆解 Browser Use 的每一个核心设计决策。 文章目录 一、Browser Use 是什么为什么它火了 二、Sense-Think-Act 循环四阶段感知-行动引擎 三、DOM 序列化管道为什么 DOM-First 击败了 Vision-First 四、动作系统20 内置动作 三种扩展方式️ 五、韧性机制循环检测 消息压缩 看门狗 评判系统⚖️ 六、Browser Use vs 传统 RPA vs Vision Agent 一、Browser Use 是什么为什么它火了1.1 一个简单到极致的想法Browser Use 的核心想法可以用一句话概括把网页的 DOM 树提取出来序列化为文本让 LLM 用文本推理来操作浏览器。不需要截图不需要视觉模型不需要坐标定位——LLM 读文本输出动作索引Playwright 执行动作。这个想法看似简单但它解决了一个根本问题如何让 LLM 精确地操作网页元素传统方案有两种——RPA 用选择器脆弱页面一改就挂Vision Agent 用坐标不精确动态页面经常点偏。Browser Use 用 DOM 索引稳定、精确、可解释找到了第三条路。1.2 为什么它火了Browser Use 在 GitHub 上获得了 85K Star这不是偶然。它解决了三个真实痛点痛点一RPA 太脆弱。传统 RPASelenium/Playwright 脚本用 CSS 选择器定位元素页面一改就挂。Browser Use 用 LLM 理解语义即使页面结构变化只要语义不变Agent 仍然能找到正确的元素。痛点二Vision Agent 太贵。截图送入 GPT-4V每一步消耗数千 Token一个 10 步任务可能花费 $1。Browser Use 的 DOM 文本通常只有几百 Token成本降低 10 倍以上。痛点三非视觉模型无法操作浏览器。GPT-4、Claude 等纯文本模型无法处理截图但它们可以完美处理 DOM 文本。Browser Use 让所有 LLM 都能操作浏览器不只是多模态模型。1.3 核心数据指标数值GitHub Star85KWebVoyager 基准89.1%支持模型Claude/GPT/Gemini/Ollama/任意 OpenAI 兼容内置动作20安装方式pip install browser-use 二、Sense-Think-Act 循环四阶段感知-行动引擎2.1 Agent Loop 的四阶段Browser Use 的 Agent Loop 是一个经典的Sense-Think-Act-Observe四阶段循环。每一步都是一次完整的 LLM 调用Agent 不断循环直到任务完成。Phase 1Sense感知。提取当前页面的 DOM 树过滤不可见/不可交互元素为可交互元素分配索引序列化为文本。这是 Browser Use 最核心的步骤——它决定了 LLM 看到什么。Phase 2Think思考。LLM 接收 DOM 文本 任务描述 历史动作推理下一步该做什么。输出格式是结构化的动作指令如click(index5)或input(index3, texthello)。Phase 3Act行动。Controller 解析 LLM 输出的动作指令通过 Playwright 执行对应的浏览器操作。点击、输入、导航、滚动——所有操作都通过 Playwright 的 API 完成。Phase 4Observe观察。等待页面稳定网络空闲、DOM 变化停止截图验证结果。如果任务完成返回结果否则回到 Phase 1 继续循环。2.2 为什么每一步都需要 LLM 调用这是 Browser Use 最大的成本来源——每一步都需要一次 LLM 调用。导航到页面LLM 调用。找到按钮LLM 调用。点击它LLM 调用。读取结果LLM 调用。对于复杂的多步任务API 账单会迅速累积。但这是不可避免的——因为每一步的决策都依赖于当前页面的状态而页面状态是动态变化的。LLM 必须在每一步重新看页面才能做出正确的决策。这是 Agent 范式的本质特征不是 Browser Use 的设计缺陷。2.3 源码入口# agent/agent.py — Agent Loop 的核心classAgent:asyncdefrun(self,task:str)-str:whilenotself.is_done:# Phase 1: Sense — 感知页面stateawaitself.browser.get_state()dom_textstate.element_tree# DOM 序列化文本# Phase 2: Think — LLM 推理actionawaitself.llm.decide(task,dom_text,self.history)# Phase 3: Act — 执行动作resultawaitself.controller.execute(action)# Phase 4: Observe — 观察结果awaitself.browser.wait_for_stable()self.history.append((action,result)) 三、DOM 序列化管道为什么 DOM-First 击败了 Vision-First3.1 五步 DOM 序列化管道Browser Use 的 DOM 处理是一个精心设计的五步管道每一步都在减少信息量、提高信噪比Step 1Raw DOM。从 Playwright 获取完整的 DOM 树。一个典型网页的 DOM 可能有数万个节点直接送给 LLM 会超出 Token 限制。Step 2Visibility Filter。过滤不可见元素——display:none、visibility:hidden、opacity:0、off-screen 元素。这一步通常能过滤掉 60-80% 的节点因为很多 DOM 节点是隐藏的如弹窗的背景、下拉菜单的选项等。Step 3Interactive Filter。只保留可交互元素——a、button、input、select、textarea、[contenteditable]等。不可交互的div、span、p被过滤掉除非它们包含重要的文本内容。Step 4Index Assignment。为每个保留的元素分配一个顺序索引0, 1, 2, …。LLM 通过索引引用元素如click(index5)或input(index3, texthello)。这个索引是 LLM 和 Playwright 之间的桥梁。Step 5Text Serialization。将过滤后的 DOM 树序列化为紧凑的文本格式。每个元素一行包含索引、标签名、关键属性href、placeholder、value 等和文本内容。3.2 DOM-First vs Vision-First维度DOM-FirstBrowser UseVision-First传统方案输入DOM 文本几百 Token截图数千 Token模型要求任意 LLM多模态模型GPT-4V 等定位精度索引引用100% 精确坐标定位容易偏移动态页面每步重新提取 DOM截图可能过时成本低~100 Token/步高~3000 Token/步速度快文本处理慢图像编码推理可解释性高文本可读低黑盒视觉推理3.3 索引引用的精妙设计索引引用是 Browser Use 最精巧的设计之一。它解决了LLM 如何精确指定页面元素这个核心问题[0] input typetext placeholderSearch [1] buttonSubmit/button [2] a href/aboutAbout Us/a LLM 输出 action: input(index0, textbrowser use) action: click(index1)LLM 不需要知道 CSS 选择器不需要计算坐标只需要输出索引号。Controller 根据索引找到对应的 Playwright ElementHandle执行操作。这个设计既简单又鲁棒——即使页面结构变化只要可交互元素的语义不变Agent 仍然能正确操作。 四、动作系统20 内置动作 三种扩展方式4.1 四类内置动作Browser Use 提供了 20 内置动作分为四类导航类go_to_url、go_back、refresh、wait。控制浏览器的导航行为。交互类click、input_text、select_option、scroll、send_keys。模拟用户的交互操作。这是最核心的动作类别——LLM 通过这些动作操作网页。数据类extract、save_to_file、read_file。从网页提取数据或读写本地文件。标签页类switch_tab、close_tab、open_tab。管理浏览器的多标签页。4.2 三种扩展方式Custom ToolsPython 函数即工具用 Pydantic 验证输入自动生成 JSON Schema。LLM 自动发现并调用。这是最简单的扩展方式——写一个 Python 函数加一个装饰器就能让 LLM 使用。MCP ServerModel Context Protocol 服务器动态发现工具运行时注入。支持第三方服务集成如文件系统、数据库、API 等。MCP 工具与内置工具合并到同一个工具集中LLM 无需区分。Skills 技能预定义的复杂行为模式如电商下单、“表单填写”。Skills 组合多个动作完成复杂任务减少 LLM 的决策负担。4.3 动作执行管道LLM 输出的动作指令经过三步处理解析从 LLM 输出中提取结构化动作如click(index5)验证检查索引是否有效、参数是否合法执行通过 Playwright 执行对应的浏览器操作# agent/controller.py — 动作执行管道classController:asyncdefexecute(self,action:Action)-ActionResult:# 1. 解析parsedself.parse_action(action)# 2. 验证self.validate(parsed)# 3. 执行ifparsed.nameclick:elementself.index_map[parsed.index]awaitelement.click()elifparsed.nameinput_text:elementself.index_map[parsed.index]awaitelement.fill(parsed.text)️ 五、韧性机制循环检测 消息压缩 看门狗 评判系统5.1 为什么需要韧性机制浏览器 Agent 面临的独特挑战是不确定性——页面加载可能失败元素可能不存在弹窗可能意外出现网络可能超时。LLM 也可能陷入循环反复点击同一个按钮或产生幻觉操作不存在的元素。Browser Use 用四重韧性机制应对这些挑战。5.2 Loop Detection——循环检测检测连续 N 步是否重复相同动作。如果 Agent 连续 3 步都在点击同一个按钮说明它陷入了循环。此时系统自动注入一个nudge消息提示 LLM 换一种策略。这个机制简单但有效——它防止了 Agent 在死循环中浪费 Token。5.3 Message Compaction——消息压缩长会话中历史消息会超出 Token 限制。Browser Use 的解法是渐进式压缩——保留最近 N 轮完整对话将更早的消息压缩为摘要。这与 Harness Agent 的 Compaction 机制类似但更简单——因为 Browser Use 的上下文主要是 DOM 文本和动作历史不需要复杂的压缩策略。5.4 Watchdog——看门狗Browser Use 的事件驱动架构基于 Watchdog 模式。每个 Watchdog 监听特定的浏览器事件如页面加载完成、网络空闲、DOM 变化停止在事件触发后执行回调。这确保了 Agent 在页面稳定后才继续操作避免了在页面加载过程中操作不存在的元素。5.5 Judge System——评判系统独立的 LLM 评估 Agent 的执行结果判断任务是否真正完成。这是最后一道防线——即使 Agent 认为任务完成了Judge 仍然可能判定失败触发重试。这个机制在 WebVoyager 基准测试中贡献了约 5% 的准确率提升。⚖️ 六、Browser Use vs 传统 RPA vs Vision Agent6.1 三种浏览器自动化范式维度传统 RPAVision AgentBrowser Use定位方式CSS 选择器坐标/边界框DOM 索引适应性页面一改就挂中等强语义理解模型要求无多模态任意 LLM成本低高中精度高但脆弱低坐标偏移高索引精确可解释性高低高动态页面差中强学习曲线高需编程中低自然语言6.2 Browser Use 的局限Browser Use 不是银弹。它有三个主要局限局限一每步都需要 LLM 调用。对于简单的重复任务如批量填表传统 RPA 脚本更高效、更便宜。Browser Use 的优势在于处理需要理解的复杂任务。局限二DOM 提取可能不完整。某些网站使用 Shadow DOM、iframe、动态渲染等技术DOM 提取可能遗漏关键元素。Browser Use 通过递归遍历 Shadow DOM 和 iframe 来缓解这个问题但并非 100% 可靠。局限三视觉信息丢失。DOM 文本无法传达布局、颜色、图片等视觉信息。对于需要视觉判断的任务如选择红色的按钮Browser Use 需要回退到截图模式。6.3 最佳实践根据任务特点选择合适的工具固定流程、页面不变→ 传统 RPAPlaywright 脚本需要视觉判断→ Vision AgentGPT-4V需要语义理解、页面多变→ Browser UseDOM-First混合场景→ Browser Use 截图回退 总结速查卡Browser Use 核心概念概念一句话解释DOM-First提取 DOM 树序列化为文本LLM 用文本推理操作浏览器Sense-Think-Act-Observe四阶段循环感知页面→LLM推理→执行动作→观察结果索引引用为可交互元素分配索引LLM 通过索引指定操作目标五步 DOM 管道Raw DOM → 可见性过滤 → 可交互过滤 → 索引分配 → 文本序列化Watchdog事件驱动架构监听页面变化确保页面稳定后才继续Loop Detection检测循环动作自动注入 nudge 提示换策略Judge System独立 LLM 评估执行结果判断任务是否真正完成一句话总结Browser Use 用 DOM-First 哲学重新定义了浏览器 Agent——不截图不坐标只给 LLM 看 DOM 文本。五步序列化管道过滤噪声、分配索引让 LLM 用文本推理精确操作网页元素。Sense-Think-Act-Observe 四阶段循环驱动 Agent 前进四重韧性机制循环检测消息压缩看门狗评判系统确保 Agent 不迷路。它不是最便宜的方案不是最通用的方案但它是让 LLM 像人一样操作浏览器最优雅的方案。参考链接Browser Use GitHub 仓库Browser Use DeepWiki 架构文档Browser Use: Give Your LLM a Browser and Watch It GoBuild an AI Browser Agent with LLMs, Playwright, Browser-Use