想象你坐在一辆自动驾驶出租车的后座，车里装着全城的高精地图和最聪明的人工智能大脑——它知道“去机场”需要走哪条路、在哪个路口转弯，但它没有方向盘、没有油门、也没有刹车。你告诉它“去机场”，它却只能干瞪着屏幕，无法亲手转动方向盘。现在的大语言模型就处于类似的窘境：它理解网页上的文字、能推理出“这里应该点击搜索按钮”，却无法真正把鼠标移动到按钮上按下去。Browser Use 就是为这辆“思考的汽车”装上的一套完整驾驶操控系统：它让大模型能够真正走进浏览器，点击、输入、翻页、切换标签，把“想得到”变成“做得到”。本文将用这趟“自动驾驶出租车”的旅程作比喻，带你认识 Browser Use 的架构、元素定位、交互自动化、多标签管理、与 Playwright 的集成方式，并最终动手构建一个能自主逛网页的 AI Agent。

岗位关联

掌握 Browser Use，等于拥有批量操作任意网页的“数字员工”，能让你的 AI Agent 从“只会聊天思考”升级为“能动手办公”，这是 AI 自动化开发者的核心技能之一。

目录
  1. 可视化演示
  2. 架构设计——自动驾驶系统的三位一体
  3. 元素定位——司机如何认出路标
  4. 交互自动化——方向盘与脚踏板
  5. 多标签管理——多车道的变道艺术
  6. Playwright集成——发动机与方向盘合体
  7. 构建实战——部署一台专属出租车
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

Agent层→Browser Use→Playwright三层架构，元素定位与交互自动化全流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

三层架构设计 Agent层接收LLM指令并规划任务 Browser Use层封装浏览器操作高级API LLM → Agent → Browser Use → Playwright → Browser 分层解耦使每层可独立测试和替换

架构设计——自动驾驶系统的三位一体

一辆能自己买咖啡的自动驾驶出租车，至少要配齐三样东西：能看路的传感器、会做判断的AI大脑、以及能执行转向和加减速的机械结构。Browser Use 的架构也长这样：大模型是“大脑”，Controller 是“传感器与控制臂的翻译官”，而 Playwright 驱动的浏览器则是它脚下的“车身与道路”。三者配合，Agent 才能在网页世界里自由穿行。

具体来说，当你把一个自然语言任务交给 Browser Use 时，Agent 会把它拆解成多步计划。每一步，LLM 基于当前页面状态输出一组候选动作，Controller 再将“点击这个按钮”“输入这段文字”这类高层指令翻译成浏览器能够执行的底层 API 调用。这种分层设计让“思考”与“执行”彻底解耦，也使同一个 Agent 可以平滑切换到 Chromium、Firefox 或 WebKit 等不同浏览器。

由于 LLM 往往会给多个候选动作打出不同分数，而不是直接给出唯一答案，Browser Use 会让 LLM 为一组候选动作分别打分，再通过 Softmax 函数把分数变成概率分布，最终按概率选择出要执行的动作：

这就像出租车司机在路口掏出手机导航：先看每条路的推荐指数，再平滑地转换为“我有七成把握走左转”，最后踩下油门。架构将这一套“评估—决策—执行”的流程固化成了可重复运行的框架，让大模型真正拥有了开车的手脚。

P(ai∣ht)=exp⁡(zi/τ)∑j=1nexp⁡(zj/τ)P(a_i \mid h_t) = \frac{\exp(z_i / \tau)}{\sum_{j=1}^{n} \exp(z_j / \tau)}
这个公式描述的是：Agent 在当前状态下有多大概率选择某个动作，就像出租车司机在路口评估“直行、左转、右转”三条路线时，给每条路线分配一个心理权重。
  1. $z_i$（原始得分）LLM 在时刻 $t$ 为第 $i$ 个候选动作打出的原始分值，分数越高代表模型越倾向选择它。
    zi∈Rz_i \in \mathbb{R}
  2. 温度系数 $\tau$（调节随机性）将 $z_i$ 除以 $\tau$ 再取指数；$\tau$ 越大，各候选概率越接近，动作越随机；$\tau$ 越小，则越偏向高分动作。
    zi/τz_i / \tau
  3. 指数函数 $\exp$（放大差异）对缩放后的分数取自然指数，将所有结果变为正数，并放大彼此之间的差距。
    exp⁡(zi/τ)\exp(z_i / \tau)
  4. 归一化分母（转成概率）用当前动作的指数值除以全部 $n$ 个候选动作的指数和，使所有概率之和为 1。
    ∑j=1nexp⁡(zj/τ)\sum_{j=1}^{n} \exp(z_j / \tau)

元素定位——司机如何认出路标

开车去陌生的地方，依靠的是路牌、门牌号和路灯；AI 操作网页，首先也要知道“搜索框在哪里”“登录按钮长什么样”。如果 Agent 分不清屏幕上谁是谁，后面的一切点击和输入都无从谈起。

在 Browser Use 中，元素定位并不是把整张网页的 HTML 或截图直接扔给大模型——那既消耗大量 token，又容易让模型被无关信息干扰。它会先做一轮“预筛选”：用 CSS 选择器、XPath、可见文本、ARIA 角色等方式从 DOM 中提取候选元素，再把每个候选元素压缩成一段精简描述。最后，Agent 会结合当前任务目标，为每个候选元素计算一个综合匹配得分：

这就像出租车司机面对三个指着同一方向的路牌：他会先读文字，再瞄一眼哪个路牌更醒目，最后挑一个不用绕远路的。三者加权后总分最高的那个元素，就是本次交互的目标。

S(e)=w1×sim(texte,q)+w2×pos(e)−w3×dist(e,last)S(e) = w_1 \times \mathrm{sim}(\mathrm{text}_e, q) + w_2 \times \mathrm{pos}(e) - w_3 \times \mathrm{dist}(e, \mathrm{last})
元素定位借鉴了人类驾驶员的“视觉搜索”习惯：先看路牌文字是否与目的地匹配，再看它在视野中的位置是否醒目，最后还要考虑从当前位置转过去需要多大动作成本。
  1. $\mathrm{sim}(\mathrm{text}_e, q)$（文本相关性）计算候选元素 e 的可见文本与任务目标 q 的语义相似度，文字越接近，得分越高。
    sim(texte,q)\mathrm{sim}(\mathrm{text}_e, q)
  2. $\mathrm{pos}(e)$（位置优势）衡量元素是否位于页面视口的视觉焦点附近；越靠近页面中心或用户当前浏览区域，得分越高。
    pos(e)\mathrm{pos}(e)
  3. $\mathrm{dist}(e, \mathrm{last})$（动作代价）计算候选元素与上一次操作点之间的空间距离，距离越远，移动成本越高，会从总分中扣除。
    dist(e,last)\mathrm{dist}(e, \mathrm{last})
  4. 权重 $w_1, w_2, w_3$（调节偏重）三个权重决定文本、位置、距离各自的重要程度；在实战中可根据任务类型做敏感性调节。
    w1,w2,w3∈R+w_1, w_2, w_3 \in \mathbb{R}^+

交互自动化——方向盘与脚踏板

认准路牌之后，接下来要真正转动方向盘。网页上的“方向盘”就是一堆可交互元素：按钮需要点击，输入框需要键入，长页面需要滚动。Browser Use 把这些动作抽象成一组标准工具，Agent 每一步从中挑选一个并执行，就像司机根据路况在“加速、减速、打方向”之间做选择。

交互自动化的本质，是把 LLM 的自然语言决策翻译成对浏览器 DOM 的真实操作。例如“搜索一下天气”会被拆解成：点击搜索框 → 输入“天气” → 点击搜索按钮。每个动作都必须在正确的上下文下发生：上一步没点开搜索框，就不应该直接输入文字。因此，整条动作路径的概率可以用连续乘积来表示：

这就像一段连续驾驶：每一次转弯是否成功都建立在前面所有操作正确的基础上。只要某一步选错了动作，后续的路线就全乱了。交互自动化让 Browser Use 像一位谨慎的司机，每走一步都参考行车记录仪，确保动作链不会断。

P(a1,a2,…,aT)=∏t=1TP(at∣ht)P(a_1, a_2, \dots, a_T) = \prod_{t=1}^{T} P(a_t \mid h_t)
这个公式表达了一个朴素而重要的思想：每一次操作都依赖于之前全部操作留下的“车辙”，一条行动路径的总成功率，是每一步条件成功率的乘积。
  1. $h_t$（历史上下文）到第 $t$ 步为止的状态集合，包括页面 DOM 快照、已执行动作、以及 Agent 的中间推理，相当于司机的“行车记忆”。
    ht=(s0,a1,s1,…,at,st)h_t = (s_0, a_1, s_1, \dots, a_t, s_t)
  2. $P(a_t \mid h_t)$（条件动作概率）在已知历史上下文 $h_t$ 的情况下，选择当前动作 $a_t$ 的条件概率。
    P(at∣ht)P(a_t \mid h_t)
  3. $\prod$ 连乘（累计路径概率）将所有步骤的条件概率相乘，得到整条动作序列的联合概率。
    ∏t=1TP(at∣ht)\prod_{t=1}^{T} P(a_t \mid h_t)
  4. 对数化（防止下溢）实际实现中通常取对数将连乘转为连加，避免极小数相乘导致数值下溢。
    log⁡P(a1,…,aT)=∑t=1Tlog⁡P(at∣ht)\log P(a_1, \dots, a_T) = \sum_{t=1}^{T} \log P(a_t \mid h_t)

多标签管理——多车道的变道艺术

如果整个网页世界是一条高速公路，那么每个标签页就是一条车道。真实任务中，Agent 常常需要同时打开多个页面：从一个网站复制信息，再去另一个网站粘贴填写。这就像出租车司机要在几条车道之间灵活切换，既要看准目标车道，又不能撞上旁边的车。

多标签管理的难点在于，每个标签页都有自己独立的 DOM 状态、滚动位置和会话上下文。Browser Use 需要为 Agent 提供“新开标签”“切换标签”“关闭标签”三类工具。但在决定切向哪个标签时，不能随机选择，而要综合考量“这个页面跟任务有多大关系”和“这个页面是不是刚被访问过”。于是标签选择可以形式化为：

优秀的司机不会手忙脚乱地来回变道，而是快速扫一眼后视镜，选中最佳车道。多标签管理让 Agent 既能并行处理多条任务线索，又不会在混乱的上下文切换中迷失方向。

tab∗=arg⁡max⁡i[rel(tabi)+λ⋅rec(tabi)]\mathrm{tab}^* = \arg\max_{i} \left[ \mathrm{rel}(\mathrm{tab}_i) + \lambda \cdot \mathrm{rec}(\mathrm{tab}_i) \right]
它模拟的是司机变道时的决策：优先去与目的地最相关的车道，如果两车道相关度接近，就走最近看过的那个车道，因为那里路况更熟悉。
  1. $\mathrm{rel}(\mathrm{tab}_i)$（任务相关性）评估第 $i$ 个标签页中的页面内容与当前任务目标的语义相关性，内容越接近，得分越高。
    rel(tabi)∈[0,1]\mathrm{rel}(\mathrm{tab}_i) \in [0, 1]
  2. $\mathrm{rec}(\mathrm{tab}_i)$（近因性）记录该标签多久前被访问过，越新近访问的标签得分越高，用来防止频繁切换造成“驾驶疲劳”。
    rec(tabi)∈[0,1]\mathrm{rec}(\mathrm{tab}_i) \in [0, 1]
  3. $\lambda$（近因权重）控制近因性在决策中的影响力；任务需要频繁回看时，$\lambda$ 可以调大。
    λ≥0\lambda \geq 0
  4. $\arg\max$（最优选择）在所有候选中挑出综合得分最高的标签页，作为切换目标。
    tab∗=arg⁡max⁡i[⋅]\mathrm{tab}^* = \arg\max_{i} \left[ \cdot \right]

Playwright集成——发动机与方向盘合体

光有大脑、手臂和道路还不够，汽车还得有发动机与底盘。在 Browser Use 这套“自动驾驶系统”里，Playwright 就是那台发动机和底盘——它是一套功能强大的浏览器自动化库，能够统一驱动 Chromium、Firefox 和 WebKit 三种主流浏览器内核。

Browser Use 与 Playwright 的关系可以理解为“驾驶员”与“车辆”的关系：Playwright 负责底层的页面导航、DOM 操作、鼠标键盘事件模拟、网络请求拦截等机械能力；Browser Use 负责在它之上叠加 Agent 的规划与决策能力。两者通过一层轻量适配器对接，Browser Use 因此自动获得了 Playwright 的跨浏览器能力和无头模式等高级特性。当页面元素尚未渲染完成时，Agent 需要多次等待重试，元素的“就绪度”可以使用指数模型来描述：

在真正的驾驶中，你不能刚发动引擎就猛踩油门，得等发动机转速上来。Playwright 集成给 Browser Use 提供了“预热”机制——合理地等待元素就绪，才能避免因页面加载未完成而出现的定位失败。

r(t)=1−e−λtr(t) = 1 - e^{-\lambda t}
这个公式描述了一个常识：页面元素不会瞬间出现，而是像发动机预热一样，经过一段时间逐渐达到可操作状态；等待足够久，就绪度就趋近于 100%。
  1. $r(t)$（就绪度）表示等待 $t$ 秒后，目标元素已经出现在页面且可交互的概率。
    r(t)∈[0,1)r(t) \in [0, 1)
  2. $\lambda$（就绪速率）单位时间内元素完成渲染的概率，与网络速度、页面复杂度有关；网络越快，$\lambda$ 越大。
    λ>0\lambda > 0
  3. $e^{-\lambda t}$（未就绪衰减）指数衰减项表示“到时刻 $t$ 仍未就绪”的剩余概率，随时间增加逐渐逼近 0。
    e−λte^{-\lambda t}
  4. 极限行为（渐进收敛）当 $t \to \infty$ 时，$e^{-\lambda t} \to 0$，$r(t) \to 1$，意味着永不超时的情况下元素最终一定就绪。
    lim⁡t→∞r(t)=1\lim_{t \to \infty} r(t) = 1

构建实战——部署一台专属出租车

现在，把大脑、操控系统、路牌识别和发动机全部组装到一起，就得到了一辆可以接单的“自动驾驶出租车”。在代码世界里，这意味着我们只需要几个 Python API，就可以创建出一个能够自主浏览网页的 Agent。

构建实战的第一步是初始化一个 Agent 对象，并为其配置“大脑”——通常是一个 ChatOpenAI 之类的 LLM 实例。然后通过 task 参数用自然语言描述任务目标，调用 agent.run() 启动执行。Browser Use 会自动完成“任务拆解 → 观察页面 → 定位元素 → 执行交互 → 校验结果”的完整循环，并会把每一步决策记录在 history 对象中。任务执行得是否利落，可以用“正确动作步数占总步数比例”来衡量：

就像出租车公司通过评分来考核司机，开发者也可以用准确率来调优 Agent 的模型、温度参数和任务描述。搭建一个 Browser Use Agent 并不复杂：准备好 API Key，安装好库，几行代码就能让大模型真正“开上”浏览器这条高速公路。

acc=correct_stepstotal_steps×100%\mathrm{acc} = \frac{\text{correct\_steps}}{\text{total\_steps}} \times 100\%
这个指标类似出租车平台的“行程评分”：乘客看的是有没有安全到达、有没有绕路；开发者看的是 Agent 的每一步是否高效合理。
  1. correct\_steps（正确的步数）Agent 执行过程中，动作正确且对最终结果有正向贡献的步数。
    correct_steps\text{correct\_steps}
  2. total\_steps（总步数）Agent 从启动到返回结果的完整执行步数，包含探索、纠错等所有中间动作。
    total_steps\text{total\_steps}
  3. $\mathrm{acc}$（动作准确率）两者之比，反映 Agent 的决策质量；比值越高，说明每一步越“指哪打哪”。
    correct_stepstotal_steps\frac{\text{correct\_steps}}{\text{total\_steps}}
  4. 百分数换算（直观展示）乘以 100% 后便于直接对比不同任务、不同 LLM 配置下的表现。
    ×100%\times 100\%

AI 应用场景

自动填表与报销审批

阶段：工具调用与业务自动化

解决的问题：行政、财务人员每天需要将大量发票信息手工录入 OA 系统，逐条填写“报销事由、金额、日期”既枯燥又容易出错。Browser Use 可以让 Agent 读取 PDF 发票内容，自动开标签页、定位表单字段、逐项填写并提交。

具体案例：某创业公司的财务部门将报销流程交给 Browser Use Agent：员工把电子发票放入指定文件夹，Agent 自动打开报销系统，识别金额与日期，填入表单，上传附件并提交审批，全程不需要人工打开浏览器。

竞品价格巡检

阶段：数据采集与信息整合

解决的问题：跨境电商运营需要每天巡查多个竞品店铺的价格和库存，以往打开十几个标签手动截图，耗时且容易漏看。Browser Use 的多标签管理能力让 Agent 可以按顺序打开每个竞品页面，读取关键价格信息，再汇总生成降价提醒。

具体案例：一位独立站运营者部署了一个 Browser Use 任务：每天上午 10 点自动打开 5 个竞品网站，分别记录 10 个核心 SKU 的价格，若发现某个商品降价超过 5%，就通过钉钉机器人推送提醒。

端到端 Web 自动化测试

阶段：测试执行与结果验证

解决的问题：传统 UI 自动化测试用 Playwright 硬编码选择器，页面结构一改脚本就崩。Browser Use 让测试用例用自然语言描述，Agent 每次运行时动态定位页面元素，即使类名或结构变化也能通过文本、角色等线索重新找到目标。

具体案例：某 SaaS 团队把核心用户路径——注册、登录、创建项目、邀请成员——写成四条自然语言测试用例，用 Browser Use Agent 配合 Playwright 无头模式跑回归测试，每次发布前自动验证主流程。

Python 演示

python24 行
import asynciofrom browser_use import Agentfrom langchain_openai import ChatOpenAI # 用自然语言描述任务，相当于给自动驾驶出租车下达目的地TASK = (    "打开 https://www.baidu.com，"    "在搜索框输入'AI Agent'，"    "点击搜索按钮，"    "返回第一条搜索结果的标题") async def main():    agent = Agent(        task=TASK,        llm=ChatOpenAI(model="gpt-4o", temperature=0.7),    )    history = await agent.run(max_steps=10)    final_result = history.final_result()    print("最终结果:", final_result)    print("执行步数:", len(history)) if __name__ == "__main__":    asyncio.run(main())
目的：演示用最少的 Python 代码创建一个能自主搜索网页的 Browser Use Agent，并查看它的执行历史与最终结果。
  1. from browser_use import Agent引入 Browser Use 封装好的 Agent 类，相当于坐进一辆已组装好的自动驾驶出租车。
  2. from langchain_openai import ChatOpenAI引入 LangChain 的 OpenAI 接口，用它来充当 Agent 的“大脑”。
  3. task=TASK用自然语言给 Agent 下达任务，它会自动拆解为多步浏览器操作。
  4. llm=ChatOpenAI(model="gpt-4o", temperature=0.7)指定大脑模型，temperature 控制回答的随机性。
  5. history = await agent.run(max_steps=10)启动执行，最多允许 10 步；await 表示等待整个任务完成。
  6. history.final_result()从执行历史中取出 Agent 的最终回答文本。
  7. len(history)查看 Agent 实际执行了多少步，用于评估任务复杂度。

常见误区

误区我一直以为 Browser Use 就是给 Playwright 套了一层更厚的壳，写起来更费劲，不如直接写 Playwright 脚本来得直接。

正解两者的定位完全不同。Playwright 是“手动挡的车”，它给你完整的浏览器控制能力，但每一步都要你自己踩离合换挡；Browser Use 是“自动驾驶模式”，它让 LLM 在每一步动态判断“看哪里、点什么、输入什么”。它不是简单封装，而是在 Playwright 之上加入了 Agent 的感知、规划与决策层。

为何常见：初学者先接触 Playwright 再看到 Browser Use，看到“它内部用了 Playwright”就很容易把它理解成一种高层封装，忽略了“由 LLM 驱动决策”这一核心差异。

误区我以为 AI 必须看到整个网页的 HTML 或截图才能做判断，所以每次都把完整 DOM 传给模型，觉得这样信息最全。

正解完整 DOM 往往包含大量脚本标签、隐藏元素和无关文本，既消耗 token，又会让模型“看花眼”。Browser Use 会先做候选元素抽取与压缩，把少量高价值候选元素和当前视口信息交给 LLM，这与人类“先扫一眼、再聚焦目标”的视觉注意力机制更接近。

为何常见：我们对“看网页”的直观理解就是“把整个屏看到”，没有意识到大模型的信息处理窗口跟人类一样有注意力瓶颈。

误区我想让 Agent 同时开 50 个标签页并行处理任务，以为标签开得越多跑得越快。

正解每个标签页都会占用浏览器内存和 Agent 的上下文记录，标签过多时 LLM 的决策历史变得臃肿，定位和切换都会变慢，甚至触发浏览器崩溃。好的多标签管理应该是“按需打开、用完即关”，就像司机不会同时开进五条车道。

为何常见：人类浏览网页时习惯随手开一堆标签，这种直觉被错误地迁移到了 AI Agent 上，忽略了上下文窗口与内存成本。

误区我以为网页的 CSS 类名一变，Browser Use 的选择器就会失效，Agent 整个任务就废了。

正解Browser Use 的定位策略是“组合评分”：它同时使用文本、角色、位置和结构特征，并不依赖单一选择器。即使样式类名变了，只要按钮的可见文字仍然是“提交”，Agent 就能重新定位。这种动态适应能力是硬编码脚本做不到的。

为何常见：长期写固定选择器脚本的人，会把“选择器失效”等同于“自动化失败”，低估了 LLM 通过语义信息进行柔性地定位的能力。

误区我以为 `pip install browser-use` 之后一切都装好了，结果一运行就报错说找不到浏览器。

正解Browser Use 只是 Python 库，它需要 Playwright 去下载并启动真正的浏览器内核（Chromium 等），因此还需要执行 playwright install。就像买了汽车钥匙不等于买了发动机，你还得把发动机安装好。

为何常见：很多 Python 库装完就是完整工具，但浏览器自动化比较特殊——它的运行环境在库之外，需要额外的浏览器驱动，初学者很容易忽略这一步。

面试题

Q1. Browser Use 在 AI Agent 生态中的主要角色是什么？

单选题 · easy

  • A.让 LLM 能操作浏览器的桥梁← 正确答案
  • B.专门负责大模型的训练
  • C.负责业务数据的持久化
  • D.封装前端组件开发工具

答案：A。Browser Use 的核心价值是让大语言模型从“只能生成文本”升级为“能实际操作网页”，它像一座桥连接了 LLM 和浏览器。B 是训练任务，C 是存储任务，D 是前端开发任务，都与 Browser Use 的定位不符。

Q2. 在 Browser Use 架构中，Controller 的主要职责是什么？

单选题 · easy

  • A.生成用户的prompt提示词
  • B.完成语言模型的参数微调
  • C.把 LLM 决策翻译成浏览器动作← 正确答案
  • D.建立与用户的语音对话通道

答案：C。Controller 是“翻译官”，负责把 LLM 输出的高层动作指令转化为 Playwright 可执行的浏览器 API 调用，比如把“点击搜索按钮”变成实际的鼠标事件。A、B、D 分别属于交互、训练、语音识别范畴，与 Controller 的执行翻译职责无关。

Q3. 网页元素定位中常用的策略包括哪些？

多选题 · mid

  • A.根据 CSS 选择器路径定位← 正确答案
  • B.根据 XPath 路径结构定位← 正确答案
  • C.根据可见文本与角色属性定位← 正确答案
  • D.根据浏览器插件的主题色定位

答案：ABC。CSS 选择器、XPath、可见文本和 ARIA 角色都是主流定位方式，Browser Use 会组合使用它们做评分。主题色属于视觉样式，与元素的结构定位无关，不能作为稳定定位依据。

Q4. 交互自动化中，type 动作通常用于做什么？

单选题 · mid

  • A.在当前聚焦元素中输入文本← 正确答案
  • B.移动鼠标到页面的指定坐标
  • C.关闭当前正在浏览的标签页
  • D.强制等待页面加载完成

答案：A。type 是键盘输入类动作，作用是在聚焦的输入框中写入文本，比如把搜索关键词填入搜索框。B 是鼠标移动，C 是关闭标签，D 是等待类动作，它们分别属于不同的交互工具。

Q5. 在多个标签页之间切换时，需要注意哪些问题？

多选题 · mid

  • A.判断目标标签是否已经打开← 正确答案
  • B.找到对应的 page 对象实例← 正确答案
  • C.同步 Agent 的上下文状态与记忆← 正确答案
  • D.重新下载浏览器内核组件

答案：ABC。切换标签前要先确认目标是否已存在，再拿到正确的 page 对象，同时更新 Agent 对“当前页面”的认知，否则 Agent 会以为还在旧页面上下达指令。浏览器内核是全局组装的，标签切换不需要重新下载。

Q6. 相比纯 Playwright 脚本，Browser Use 更适合 LLM 驱动的根本原因是？

单选题 · hard

  • A.它完全不依赖任何浏览器内核
  • B.它要求开发者硬编码每一条步骤
  • C.它让 LLM 动态生成定位和动作计划← 正确答案
  • D.它无法处理动态变化的网页内容

答案：C。Browser Use 把“决定下一步做什么”交给了 LLM，让 Agent 根据页面状态实时生成下一步计划和元素定位策略，而不是执行固定步骤。A 错误，它依赖浏览器内核；B 恰恰相反；D 错误，动态网页正是它的强项。

Q7. 以下关于 Browser Use 和 Playwright 关系的描述，哪些是正确的？

多选题 · easy

  • A.Browser Use 依赖 Playwright 来驱动浏览器← 正确答案
  • B.Playwright 提供底层页面控制和事件模拟← 正确答案
  • C.Browser Use 在 Playwright 之上提供 Agent 级抽象← 正确答案
  • D.Browser Use 可以完全替代 Playwright

答案：ABC。Browser Use 是基于 Playwright 构建的高层 Agent 库，Playwright 负责底层浏览器控制，Browser Use 负责任务规划与决策，二者是协同关系。D 错误，因为少了 Playwright，Browser Use 就没有可用的浏览器底座。

Q8. 无头模式（headless）运行浏览器最大的优势是什么？

单选题 · mid

  • A.页面渲染速度会变得比有头模式更慢
  • B.所有页面都无法执行任何 JavaScript 脚本
  • C.不显示浏览器窗口，节省资源便于服务端部署← 正确答案
  • D.只能访问纯静态的文本网页

答案：C。无头模式的核心价值是“看不见的浏览器”：没有窗口渲染，节省了图形资源，适合部署在 Linux 服务器上。无头浏览器仍然能正常执行 JavaScript，也不是只能访问静态页面，因此 A、B、D 都不正确。

Q9. 元素评分公式中，$w_1 \times \mathrm{sim}(\mathrm{text}_e, q)$ 这一项主要度量的是什么？

单选题 · hard

  • A.元素文本与任务目标的语义相关性← 正确答案
  • B.浏览器引擎的网页打开速度
  • C.网络请求的响应延迟时长
  • D.页面中图片文件的体积大小

答案：A。公式中的 $\mathrm{sim}(\mathrm{text}_e, q)$ 表示候选元素的文本与任务目标 $q$ 的语义相似度，权重 $w_1$ 控制它在总评分中的分量。B、C、D 都是网络或性能指标，与元素本身的内容匹配度无关。

Q10. Agent 运行结束后，开发者可以从 history 对象中获取哪些信息？

多选题 · hard

  • A.每一步执行的浏览器动作← 正确答案
  • B.最终的文本结果输出← 正确答案
  • C.中间过程的推理与状态变化← 正确答案
  • D.用户的浏览器登录密码原文

答案：ABC。history 记录了 Agent 的完整执行轨迹，包括每一步做了什么动作、看到什么页面状态、最终输出了什么结果，相当于出租车的行车记录仪。D 错误，Browser Use 遵循安全原则，不会也不应该暴露用户的敏感凭证。