做测试这么多年我发现自己最烦的不是用例设计而是写UI自动化脚本——尤其是那种要精确到按钮class、输入框id的脚本。直到我把Browser-use接进测试环境用它跑通第一个登录用例才意识到这个开源浏览器自动化框架跟Selenium、Playwright完全是两个物种。你不需要再写“点击id为login_btn的按钮”这种指令只需要说人话“打开登录页用test01/123456登录看能否进入首页并出现用户中心入口”它自己会定位、点击、输入、等待然后把结果汇报给你。这篇文章就是我过去两个月用Browser-use做测试的真实笔记包含能直接抄的配置、三个实战场景、四个关键踩坑以及我现在的应用边界判断。适合刚接触AI Agent、想把它落到测试工作里的同学。1. 测试工程师为什么需要Browser-useAI外挂到底解决什么问题1.1 传统UI自动化最大的痛定位器与维护成本我入行前几年一直在做服务端测试转UI自动化之后最不适应的不是写脚本本身而是维护。页面上一个按钮的名称变了、某个弹窗结构调整了脚本里几十处selector就要跟着改。稍微复杂一点的业务系统比如带权限管理的后台每个角色的菜单都不同写一套“登录→进入菜单→操作数据→验证结果”的脚本光等元素加载、处理弹窗和iframe就够喝一壶。更现实的问题是很多系统根本没有稳定可用的测试环境。前端频繁调版、后端mock数据不稳定脚本跑挂了第一反应是“环境又坏了”而不是“代码有bug”。这种情况下脚本越多维护负债越重。团队里一度出现“自动化用例数量不断上涨但有效执行率持续下降”的怪圈。1.2 Browser-use与传统自动化脚本的本质区别后来我开始接触AI Agent方向发现Browser-use做的事情和传统自动化完全是两个思路。传统脚本是精确指令每一步做什么、等什么元素、验证什么结果全部由人写死。Browser-use是目标驱动你只告诉AI“要做成什么事”它自己拆解步骤、识别页面元素、执行操作再根据页面反馈自我修正。打个比方传统脚本相当于你给一个新员工写了一份精确到“左脚迈进门槛、右手按下开关”的操作手册Browser-use则像你把任务丢给一个会使用浏览器的智能助手它自己知道要先输用户名、再输密码、然后找登录按钮。这种差异在页面结构不稳定的场景下尤其明显页面元素的class从btn-primary改成btn-success传统脚本立刻挂掉AI却不会——它看的是按钮的语义和位置不依赖某个写死的属性。Browser-use本质上是一个开源库底层通过Playwright控制浏览器上层把页面状态转成LLM能读懂的文本和截图由LLM输出结构化动作形成“观察→决策→执行→再观察”的循环。1.3 它适合谁来用我用了两个月之后的判断是Browser-use最适合三类人。第一类测试工程师做探索性测试辅助。它能在你手动点点点之前先按自然语言描述快速跑一遍主流程把明显异常暴露出来。第二类需要做大量重复性验收的人比如产品经理验证需求是否上线、项目经理验收第三方系统功能。很多第三方系统没有接口文档也没有测试环境人工走查一遍要半小时用AI Agent走一遍能省不少事。第三类想给现有自动化体系补盲区的团队比如用它做回归测试的“初筛雷达”先让AI扫一遍再人工聚焦可疑点。但它不是万能的。每分钟都在跑的精确回归、涉及大量数据比对、性能压测、复杂断言这些场景我还是会老实写Playwright或直接调接口。想用AI Agent完全替代确定性自动化目前还不太现实。2. 环境准备与第一个Agent跑通的完整过程2.1 环境依赖与安装时的版本坑先说安装browser-use目前的安装方式比较常规Python 3.10以上都行我用的是3.11。安装命令pip install browser-use这一步会连带安装Playwright和LangChain相关的依赖。装完后需要下载Chromium内核playwright install chromium如果你只是做普通Web测试chromium就够了不建议一上来把firefox、webkit全装上白白占几个G磁盘。我当时图省事全装了结果package版本冲突查了半天。这里必须提醒一个很关键的坑browser-use这个库版本迭代非常快不同版本的API差异很大甚至同一个类名在不同版本里的参数都不一样。网上教程五花八门有些代码直接复制根本跑不起来原因往往是版本对不上。我建议你在项目里固定版本比如pip install browser-use0.2.19我下面的所有示例都是基于0.2.x版本的写法。如果你用的是更新版本API可能有所变化但核心概念和排查思路是通用的。安装时还容易踩到LangChain的坑。browser-use依赖LangChain生态而LangChain的版本升级经常导致ChatOpenAI这类封装类报错。如果你项目里原本就有LangChain建议用虚拟环境隔离起来别跟其他项目混在一起装。2.2 模型接入API模式与本地Ollama模式browser-use本身不包含大模型它需要外部LLM来“看页面”和“下决策”。最省事的方式是接云端APIOpenAI、Anthropic、Google的模型都支持。官方的Demo里经常用ChatOpenAIfrom langchain_openai import ChatOpenAI llm ChatOpenAI( modelgpt-4o, temperature0, )注意我在测试场景里强制把temperature设为0。这个细节非常重要LLM天然有随机性同一个任务可能给出不同动作做测试如果不够确定性结果很难复现。温度设为0可以最大程度降低随机性但并不能完全消除。如果你不想依赖云端API或者对数据敏感可以用本地模型。browser-use支持通过Ollama接入本地模型比如from langchain_ollama import ChatOllama llm ChatOllama( modelqwen2.5vl:7b, temperature0, )本地跑需要一台有独立显卡的机器。小参数模型7B、8B级别跑起来速度还可以但“理解页面截图、准确找到按钮”的能力会比云端大模型弱不少。实测下来7B模型做简单登录流程勉强能跑做复杂多步操作时会频繁犯迷糊需要更大的模型如32B以上才有比较稳定的表现但显存要求又上去了。我的建议是先考虑用便宜的云端模型跑通再根据数据合规要求决定要不要上本地部署。2.3 第一个“用人话驱动浏览器”的Demo实测装好之后我做了第一个测试让AI打开一个本地测试系统的登录页手动输入账号密码并点击登录。完整代码如下import asyncio from browser_use import Agent, Browser, BrowserConfig from langchain_openai import ChatOpenAI async def main(): # headlessFalse 表示显示浏览器窗口方便观察AI的每一步操作 browser Browser(configBrowserConfig(headlessFalse)) agent Agent( task打开 http://localhost:8080/login 输入账号 test01密码 123456点击登录按钮 等待页面跳转确认首页右上角出现用户名 test01, llmChatOpenAI(modelgpt-4o, temperature0), browserbrowser, ) result await agent.run(max_steps15) print(状态:, result.status) for step in result.history: print(第, step.step_number, 步:, step.action_result) asyncio.run(main())跑的时候浏览器窗口会自动打开你就能看到AI像人一样操作先输入URL然后等待页面加载找到用户名输入框输入文本再找密码输入框……每一步都会在控制台打印出来。第一次看完这个完整过程我的感觉是这不是一个“测试脚本”更像一个远程实习生在我的屏幕上操作浏览器。我当时跑下来大概用了8个步骤完成登录耗时40秒左右。相比Playwright脚本的2秒完成这个速度慢得离谱但它的价值在于我根本没看任何前端代码不知道登录框的id、name甚至连登录页的HTML都没打开过。这就是最直接的“外挂”体验。3. 核心机制拆解浏览器状态如何变成AI能读懂的“眼睛”3.1 页面状态抽取原理很多人第一次用Browser-use会好奇AI到底是怎么“看”页面的它并不是直接看浏览器而是通过两套信息来理解当前页面。第一套是DOM序列化后的交互元素列表。Browser-use会把当前页面里所有可交互的元素输入框、按钮、链接、下拉框等抽取出来按顺序编号同时附带元素类型、文本内容、名称、位置等属性组装成结构化的文本描述。第二套是页面截图。当开启视觉模式时当前页面会截一张图一并交给模型。LLM收到的输入大致是“当前页面里有这些可交互元素1. 文本输入框[账号]2. 文本输入框[密码]3. 按钮[登录]4. 链接[忘记密码]……”再加上截图它就能判断下一步该点哪个、该往哪个框里填什么。理解这一点你就能明白为什么网页越复杂token消耗越大AI决策越慢。一个后台管理列表页可能有几百个按钮、筛选条件、分页控件全部序列化之后光页面状态就是一大段文本模型每次决策都要读一遍。这也是后面成本优化部分的底层原因。3.2 AI决策→执行→再观察的闭环Browser-use的每个循环是这样的模型接收任务描述、页面当前状态、历史操作记录。模型输出一个结构化的JSON动作例如点击某个编号的元素、向某个输入框填入文本、跳到某个URL、从页面提取文本等。Browser-use执行这个动作。等待页面加载完成后抽取新的页面状态。再次发给模型重复这个过程。这个循环会一直持续到模型判断任务已完成、或者达到max_steps上限、或者某个环节出错。max_steps这个参数值得单独拿出来说。它表示AI最多执行多少步操作。我见过有人不设置这个参数AI在页面上反复尝试、来回点击白白烧掉几百次API调用。设置合理的上限既控制成本也避免AI陷入死循环。另外每一轮循环的“历史操作记录”会不断累积。也就是说AI能记住它之前做过的所有操作不会“失忆”。但这同样意味着步骤越长上下文越长token消耗越大。3.3 关键配置项对测试效果的影响我在实际使用中重点观察了这几个配置项headless模式。无头模式下浏览器不显示窗口适合CI环境。但无头模式会带来“看不见”的问题后面会详细讲。开发调试阶段建议设置为headlessFalse肉眼盯着AI操作出问题能及时判断是模型决策错还是页面渲染问题。use_vision视觉开关。开启后模型能“看”截图对寻找按钮、判断布局非常有用但token消耗会显著增加。用本地小模型时视觉能力弱可能还不如纯文本模式靠谱。save_browser_state。这个功能允许你保存浏览器状态包括cookie、localStorage下次恢复上下文继续操作。对需要登录态的流程很好用——不用每次让AI重新登录一次。我通常把登录步骤单独跑一次保存状态后面的流程用例全部从已登录状态开始省时又省token。日志与可视化。开启debug日志后你能看到每一步的原始输入、输出的完整JSON排查问题时非常关键。我见过有人遇到AI定位错误不看日志直接换模型结果换了三轮没解决——其实就是页面元素描述里隐藏着同一个名字的两个按钮模型纠结选哪个。4. 测试实战用Browser-use跑三个真实测试场景4.1 场景一登录模块冒烟测试第一个场景是最简单的登录冒烟。这个用例的价值在于快速确认“登录主链路没有断”不用覆盖所有边界。我的任务描述是这样写的task ( 打开 http://localhost:8080/login 输入用户名 test01密码 123456 点击登录按钮。 如果页面跳转并且右上角出现 test01说明登录成功 如果出现错误提示记录提示内容并说明登录失败。 )这里有个很微妙的地方我明确告诉AI“什么叫成功”而不是只说“登录一下”。这能让模型在最后主动判断结果。因为Browser-use本身不是断言框架它更擅长“执行”判断结果需要靠人给的判断标准。跑完之后我通过result.status获取执行状态再打印最后一步的截图或页面文本作为辅助证据。如果需要纳入CI我会在代码里再对当前URL做一次常规断言assert result.status success这个用法适合做每日冒烟的第一道关卡不是替代精确断言而是把“页面是否还能正常登录”这个低级但高频率问题自动化掉。4.2 场景二多步骤跨页面流程验证下单流程第二个场景模拟电商里最常见的下单流程包含多个页面跳转和动态加载商品列表页→商品详情页→加入购物车→购物车页→结算页→提交订单。这类流程长交给AI执行最容易出问题的地方是中间某步操作后页面没有按预期加载模型就不知所措。我在任务描述里对每一步都给了兜底提示task ( 打开 http://localhost:8080/products 在商品列表中点击名为『测试笔记本』的商品 进入详情页点击『加入购物车』。 如果弹出加入成功提示点击『去结算』 如果页面卡住或者提示异常直接报告失败原因。 结算页确认收货地址后点击『提交订单』 最后确认是否出现订单号。 )跑这个场景时max_steps我设成了30。因为多步骤流程里AI打开商品详情页可能需要等待加载加入购物车后可能弹窗这些都会额外增加步数。步数太少容易失败太大会失控。我的经验是先跑一次看历史输出统计再根据情况调整。另外这类长流程建议和pytest-asyncio集成方便纳入回归体系。示例import pytest pytest.mark.asyncio async def test_purchase_flow(): agent Agent( task..., llmget_llm(), ) result await agent.run(max_steps30) assert result.status success4.3 场景三探索性测试与异常输入兜底验证第三个场景是我个人觉得最有意思的用AI做探索性测试。传统测试用例都是“输入A期望B”但在探索性测试里我们希望的是“输入任意诡异的东西看看系统会不会炸”。这种事让AI干再合适不过。比如测试一个搜索框我可以让AI尝试超长字符串、特殊字符、HTML标签、SQL注入片段在测试环境允许的范围内以及空字符串然后观察页面是正常提示还是出现500错误、弹窗异常、页面卡死。任务描述task ( 打开 http://localhost:8080/search 在搜索框中依次输入以下内容空字符串、 特殊字符 !#%……*、超长内容长度超过200字、HTML标签 scriptalert(1)/script。 每次输入后点击搜索观察页面是否出现服务端错误、页面崩溃或明显异常。 把每次的输入和页面表现记录下来最后汇总成一个列表。 )这里要注意涉及安全测试的内容必须在你自己公司授权的测试环境执行线上环境别乱来。AI只会按指令把字符输进去然后观察结果真正的“测试判断”其实还是人来看最后的结果列表。这个场景里我几乎不写断言而是让AI最后输出一份汇总报告我人工判读。因为探索性测试的价值在于发现未知问题而不是套固定断言。5. 我在实际项目中踩过的坑与排查链路5.1 坑一元素定位不稳定同样任务跑两次结果不同这个坑是我最早遇到的。同一个登录任务第一次跑能顺利通过第二次跑却在输入完用户名后直接去点了登录按钮然后因为密码为空而报错。我开始以为是模型随机性导致的把temperature调成了0结果问题依旧。排查链路是先打开debug日志把两次运行的每一步输出拉出来对比。我发现第二次运行时AI在我输入用户名后页面上的密码输入框已经存在但模型固执地认为“可以直接登录了”因为它从DOM快照里看到登录按钮的编号在变。根因是页面里可能有两个登录按钮一个在导航栏一个在表单里DOM序列化排序不稳定模型每次看到的元素编号不同。解决方式一是在任务描述里写得更具体比如“点击表单区域内的登录按钮不要点击顶部导航栏的登录入口”二是减少页面干扰元素通过配置过滤掉部分DOM节点比如只保留表单区域。这个思路同样适用于多标签页问题——如果浏览器打开了多个标签页页面状态会复杂很多任务描述里最好明确“只操作当前标签页”。5.2 坑二token消耗过快长页面一次决策烧掉几千token第二个坑是成本问题。公司后台管理系统页面密布表格一个列表页有几十列筛选条件、分页按钮、操作列按钮、导出按钮……DOM序列化之后页面状态文本非常长。一次简单操作可能消耗几千token一个长流程跑下来账单让人肉疼。我算了一笔账一个普通的后台列表页交互元素可能有三四百个每个元素按几十个token计算一次状态抽取可能产生一万多token。AI每执行一步操作就要重新读一遍这个状态加上历史记录不断增长十步之内token消耗就非常可观。解决思路有四个一是缩小页面可见范围。如果只需要验证表格里的数据可以先把页面上其他区域的可交互元素通过配置排除掉减少进入上下文的元素数量。二是换便宜模型做决策。决策过程不需要最强模型一些简单的定位和点击任务用小型快模型完全能胜任成本能降一个量级。三是任务拆分。一个大流程拆成多个小任务比如登录作为一个任务下单作为另一个任务中间用保存浏览器状态衔接。这样每个任务的上下文长度有限token不会无限膨胀。四是限制历史记录长度。Browser-use在较新版本里支持对历史记录的截断或总结如果你用的版本没有这个能力就靠前三条控制。5.3 坑三无头模式下“看不见”导致AI停顿这个坑是在接入CI时踩到的。本地跑没问题一放到服务器上用headlessTrue跑AI就频繁卡在“找不到按钮”这类操作上明明页面上有那个按钮。排查链路是先怀疑网络加载CI服务器访问被测环境慢后面排除。接着我看运行日志发现模型在无头模式下拿到的DOM序列化和截图跟有头模式不太一样。无头浏览器在某些CSS渲染、字体加载、弹窗动画上会有差异部分元素虽然存在但不可见模型根据“不可见”这个属性判断它不该被点击。另外无头模式的截图有时比有头模式“早”页面还没完全渲染完就截图了AI自然找不到按钮。解决方式在使用无头模式时我在任务描述里主动加了一句“如果目标元素没有立即出现请等待1-2秒后再尝试”。同时把页面加载超时时间调大。最关键的还是优先推荐有头模式尤其在开发阶段。CI里如果实在要用无头模式最好在固定浏览器窗口尺寸、关闭动画这些细节上做配置减少渲染差异。5.4 坑四与pytest集成后任务的超时与重试策略第四个坑是把Browser-use接入pytest之后发现的。早先我把max_steps当成唯一的超时控制忽略了LLM调用本身的耗时。一个复杂页面模型推理可能要等几十秒加上无数次状态抽取单个用例跑上三五分钟很正常。pytest默认没有全局超时测试套件跑挂了有时候是网络问题有时候是模型推理卡顿很难区分是测试失败还是环境问题。我的做法是双管齐下在外层用pytest-timeout给每个用例设一个合理的上限比如6分钟在内层给agent.run()设置不合理的max_steps上限防止死循环。同时对“AI操作失败”这类情况我设计了一套重试策略第一次失败后把失败信息拼进任务描述里让AI再试一次相当于给它一次“补救机会”。这个重试策略对偶发的页面加载慢很有效但注意别无限重试会浪费token。6. 成本优化与测试落地建议给团队的接入方案6.1 任务拆分轻量模型验证者模式的组合如果要在团队里真正落地Browser-use我的建议是“拆”字诀。拆任务、拆模型、拆职责。拆任务很好理解一个大而全的任务描述会让AI频道走偏干脆拆成几个独立的小Agent每个只专注一段流程登录Agent、查询Agent、下单Agent。两个Agent之间用保存的浏览器状态衔接。拆模型是说决策模型和质量验证模型分开。执行过程中用便宜的轻量模型成本低、速度快最后验证阶段用更强的模型或普通代码断言来把关。我在一个数据核对场景里只让轻量模型负责“走到导出页面、点导出”真正的数据校验还是用pandas读文件对比这样既省钱又可靠。6.2 用data-testid约束前端降低AI决策成本这是我从实际项目里总结出来的一个重要经验给前端页面加稳定的自动化测试标识对AI Agent同样友好。传统自动化里我们经常用> Browser-use实战指南：用AI Agent自然语言驱动UI自动化测试
做测试这么多年我发现自己最烦的不是用例设计而是写UI自动化脚本——尤其是那种要精确到按钮class、输入框id的脚本。直到我把Browser-use接进测试环境用它跑通第一个登录用例才意识到这个开源浏览器自动化框架跟Selenium、Playwright完全是两个物种。你不需要再写“点击id为login_btn的按钮”这种指令只需要说人话“打开登录页用test01/123456登录看能否进入首页并出现用户中心入口”它自己会定位、点击、输入、等待然后把结果汇报给你。这篇文章就是我过去两个月用Browser-use做测试的真实笔记包含能直接抄的配置、三个实战场景、四个关键踩坑以及我现在的应用边界判断。适合刚接触AI Agent、想把它落到测试工作里的同学。1. 测试工程师为什么需要Browser-useAI外挂到底解决什么问题1.1 传统UI自动化最大的痛定位器与维护成本我入行前几年一直在做服务端测试转UI自动化之后最不适应的不是写脚本本身而是维护。页面上一个按钮的名称变了、某个弹窗结构调整了脚本里几十处selector就要跟着改。稍微复杂一点的业务系统比如带权限管理的后台每个角色的菜单都不同写一套“登录→进入菜单→操作数据→验证结果”的脚本光等元素加载、处理弹窗和iframe就够喝一壶。更现实的问题是很多系统根本没有稳定可用的测试环境。前端频繁调版、后端mock数据不稳定脚本跑挂了第一反应是“环境又坏了”而不是“代码有bug”。这种情况下脚本越多维护负债越重。团队里一度出现“自动化用例数量不断上涨但有效执行率持续下降”的怪圈。1.2 Browser-use与传统自动化脚本的本质区别后来我开始接触AI Agent方向发现Browser-use做的事情和传统自动化完全是两个思路。传统脚本是精确指令每一步做什么、等什么元素、验证什么结果全部由人写死。Browser-use是目标驱动你只告诉AI“要做成什么事”它自己拆解步骤、识别页面元素、执行操作再根据页面反馈自我修正。打个比方传统脚本相当于你给一个新员工写了一份精确到“左脚迈进门槛、右手按下开关”的操作手册Browser-use则像你把任务丢给一个会使用浏览器的智能助手它自己知道要先输用户名、再输密码、然后找登录按钮。这种差异在页面结构不稳定的场景下尤其明显页面元素的class从btn-primary改成btn-success传统脚本立刻挂掉AI却不会——它看的是按钮的语义和位置不依赖某个写死的属性。Browser-use本质上是一个开源库底层通过Playwright控制浏览器上层把页面状态转成LLM能读懂的文本和截图由LLM输出结构化动作形成“观察→决策→执行→再观察”的循环。1.3 它适合谁来用我用了两个月之后的判断是Browser-use最适合三类人。第一类测试工程师做探索性测试辅助。它能在你手动点点点之前先按自然语言描述快速跑一遍主流程把明显异常暴露出来。第二类需要做大量重复性验收的人比如产品经理验证需求是否上线、项目经理验收第三方系统功能。很多第三方系统没有接口文档也没有测试环境人工走查一遍要半小时用AI Agent走一遍能省不少事。第三类想给现有自动化体系补盲区的团队比如用它做回归测试的“初筛雷达”先让AI扫一遍再人工聚焦可疑点。但它不是万能的。每分钟都在跑的精确回归、涉及大量数据比对、性能压测、复杂断言这些场景我还是会老实写Playwright或直接调接口。想用AI Agent完全替代确定性自动化目前还不太现实。2. 环境准备与第一个Agent跑通的完整过程2.1 环境依赖与安装时的版本坑先说安装browser-use目前的安装方式比较常规Python 3.10以上都行我用的是3.11。安装命令pip install browser-use这一步会连带安装Playwright和LangChain相关的依赖。装完后需要下载Chromium内核playwright install chromium如果你只是做普通Web测试chromium就够了不建议一上来把firefox、webkit全装上白白占几个G磁盘。我当时图省事全装了结果package版本冲突查了半天。这里必须提醒一个很关键的坑browser-use这个库版本迭代非常快不同版本的API差异很大甚至同一个类名在不同版本里的参数都不一样。网上教程五花八门有些代码直接复制根本跑不起来原因往往是版本对不上。我建议你在项目里固定版本比如pip install browser-use0.2.19我下面的所有示例都是基于0.2.x版本的写法。如果你用的是更新版本API可能有所变化但核心概念和排查思路是通用的。安装时还容易踩到LangChain的坑。browser-use依赖LangChain生态而LangChain的版本升级经常导致ChatOpenAI这类封装类报错。如果你项目里原本就有LangChain建议用虚拟环境隔离起来别跟其他项目混在一起装。2.2 模型接入API模式与本地Ollama模式browser-use本身不包含大模型它需要外部LLM来“看页面”和“下决策”。最省事的方式是接云端APIOpenAI、Anthropic、Google的模型都支持。官方的Demo里经常用ChatOpenAIfrom langchain_openai import ChatOpenAI llm ChatOpenAI( modelgpt-4o, temperature0, )注意我在测试场景里强制把temperature设为0。这个细节非常重要LLM天然有随机性同一个任务可能给出不同动作做测试如果不够确定性结果很难复现。温度设为0可以最大程度降低随机性但并不能完全消除。如果你不想依赖云端API或者对数据敏感可以用本地模型。browser-use支持通过Ollama接入本地模型比如from langchain_ollama import ChatOllama llm ChatOllama( modelqwen2.5vl:7b, temperature0, )本地跑需要一台有独立显卡的机器。小参数模型7B、8B级别跑起来速度还可以但“理解页面截图、准确找到按钮”的能力会比云端大模型弱不少。实测下来7B模型做简单登录流程勉强能跑做复杂多步操作时会频繁犯迷糊需要更大的模型如32B以上才有比较稳定的表现但显存要求又上去了。我的建议是先考虑用便宜的云端模型跑通再根据数据合规要求决定要不要上本地部署。2.3 第一个“用人话驱动浏览器”的Demo实测装好之后我做了第一个测试让AI打开一个本地测试系统的登录页手动输入账号密码并点击登录。完整代码如下import asyncio from browser_use import Agent, Browser, BrowserConfig from langchain_openai import ChatOpenAI async def main(): # headlessFalse 表示显示浏览器窗口方便观察AI的每一步操作 browser Browser(configBrowserConfig(headlessFalse)) agent Agent( task打开 http://localhost:8080/login 输入账号 test01密码 123456点击登录按钮 等待页面跳转确认首页右上角出现用户名 test01, llmChatOpenAI(modelgpt-4o, temperature0), browserbrowser, ) result await agent.run(max_steps15) print(状态:, result.status) for step in result.history: print(第, step.step_number, 步:, step.action_result) asyncio.run(main())跑的时候浏览器窗口会自动打开你就能看到AI像人一样操作先输入URL然后等待页面加载找到用户名输入框输入文本再找密码输入框……每一步都会在控制台打印出来。第一次看完这个完整过程我的感觉是这不是一个“测试脚本”更像一个远程实习生在我的屏幕上操作浏览器。我当时跑下来大概用了8个步骤完成登录耗时40秒左右。相比Playwright脚本的2秒完成这个速度慢得离谱但它的价值在于我根本没看任何前端代码不知道登录框的id、name甚至连登录页的HTML都没打开过。这就是最直接的“外挂”体验。3. 核心机制拆解浏览器状态如何变成AI能读懂的“眼睛”3.1 页面状态抽取原理很多人第一次用Browser-use会好奇AI到底是怎么“看”页面的它并不是直接看浏览器而是通过两套信息来理解当前页面。第一套是DOM序列化后的交互元素列表。Browser-use会把当前页面里所有可交互的元素输入框、按钮、链接、下拉框等抽取出来按顺序编号同时附带元素类型、文本内容、名称、位置等属性组装成结构化的文本描述。第二套是页面截图。当开启视觉模式时当前页面会截一张图一并交给模型。LLM收到的输入大致是“当前页面里有这些可交互元素1. 文本输入框[账号]2. 文本输入框[密码]3. 按钮[登录]4. 链接[忘记密码]……”再加上截图它就能判断下一步该点哪个、该往哪个框里填什么。理解这一点你就能明白为什么网页越复杂token消耗越大AI决策越慢。一个后台管理列表页可能有几百个按钮、筛选条件、分页控件全部序列化之后光页面状态就是一大段文本模型每次决策都要读一遍。这也是后面成本优化部分的底层原因。3.2 AI决策→执行→再观察的闭环Browser-use的每个循环是这样的模型接收任务描述、页面当前状态、历史操作记录。模型输出一个结构化的JSON动作例如点击某个编号的元素、向某个输入框填入文本、跳到某个URL、从页面提取文本等。Browser-use执行这个动作。等待页面加载完成后抽取新的页面状态。再次发给模型重复这个过程。这个循环会一直持续到模型判断任务已完成、或者达到max_steps上限、或者某个环节出错。max_steps这个参数值得单独拿出来说。它表示AI最多执行多少步操作。我见过有人不设置这个参数AI在页面上反复尝试、来回点击白白烧掉几百次API调用。设置合理的上限既控制成本也避免AI陷入死循环。另外每一轮循环的“历史操作记录”会不断累积。也就是说AI能记住它之前做过的所有操作不会“失忆”。但这同样意味着步骤越长上下文越长token消耗越大。3.3 关键配置项对测试效果的影响我在实际使用中重点观察了这几个配置项headless模式。无头模式下浏览器不显示窗口适合CI环境。但无头模式会带来“看不见”的问题后面会详细讲。开发调试阶段建议设置为headlessFalse肉眼盯着AI操作出问题能及时判断是模型决策错还是页面渲染问题。use_vision视觉开关。开启后模型能“看”截图对寻找按钮、判断布局非常有用但token消耗会显著增加。用本地小模型时视觉能力弱可能还不如纯文本模式靠谱。save_browser_state。这个功能允许你保存浏览器状态包括cookie、localStorage下次恢复上下文继续操作。对需要登录态的流程很好用——不用每次让AI重新登录一次。我通常把登录步骤单独跑一次保存状态后面的流程用例全部从已登录状态开始省时又省token。日志与可视化。开启debug日志后你能看到每一步的原始输入、输出的完整JSON排查问题时非常关键。我见过有人遇到AI定位错误不看日志直接换模型结果换了三轮没解决——其实就是页面元素描述里隐藏着同一个名字的两个按钮模型纠结选哪个。4. 测试实战用Browser-use跑三个真实测试场景4.1 场景一登录模块冒烟测试第一个场景是最简单的登录冒烟。这个用例的价值在于快速确认“登录主链路没有断”不用覆盖所有边界。我的任务描述是这样写的task ( 打开 http://localhost:8080/login 输入用户名 test01密码 123456 点击登录按钮。 如果页面跳转并且右上角出现 test01说明登录成功 如果出现错误提示记录提示内容并说明登录失败。 )这里有个很微妙的地方我明确告诉AI“什么叫成功”而不是只说“登录一下”。这能让模型在最后主动判断结果。因为Browser-use本身不是断言框架它更擅长“执行”判断结果需要靠人给的判断标准。跑完之后我通过result.status获取执行状态再打印最后一步的截图或页面文本作为辅助证据。如果需要纳入CI我会在代码里再对当前URL做一次常规断言assert result.status success这个用法适合做每日冒烟的第一道关卡不是替代精确断言而是把“页面是否还能正常登录”这个低级但高频率问题自动化掉。4.2 场景二多步骤跨页面流程验证下单流程第二个场景模拟电商里最常见的下单流程包含多个页面跳转和动态加载商品列表页→商品详情页→加入购物车→购物车页→结算页→提交订单。这类流程长交给AI执行最容易出问题的地方是中间某步操作后页面没有按预期加载模型就不知所措。我在任务描述里对每一步都给了兜底提示task ( 打开 http://localhost:8080/products 在商品列表中点击名为『测试笔记本』的商品 进入详情页点击『加入购物车』。 如果弹出加入成功提示点击『去结算』 如果页面卡住或者提示异常直接报告失败原因。 结算页确认收货地址后点击『提交订单』 最后确认是否出现订单号。 )跑这个场景时max_steps我设成了30。因为多步骤流程里AI打开商品详情页可能需要等待加载加入购物车后可能弹窗这些都会额外增加步数。步数太少容易失败太大会失控。我的经验是先跑一次看历史输出统计再根据情况调整。另外这类长流程建议和pytest-asyncio集成方便纳入回归体系。示例import pytest pytest.mark.asyncio async def test_purchase_flow(): agent Agent( task..., llmget_llm(), ) result await agent.run(max_steps30) assert result.status success4.3 场景三探索性测试与异常输入兜底验证第三个场景是我个人觉得最有意思的用AI做探索性测试。传统测试用例都是“输入A期望B”但在探索性测试里我们希望的是“输入任意诡异的东西看看系统会不会炸”。这种事让AI干再合适不过。比如测试一个搜索框我可以让AI尝试超长字符串、特殊字符、HTML标签、SQL注入片段在测试环境允许的范围内以及空字符串然后观察页面是正常提示还是出现500错误、弹窗异常、页面卡死。任务描述task ( 打开 http://localhost:8080/search 在搜索框中依次输入以下内容空字符串、 特殊字符 !#%……*、超长内容长度超过200字、HTML标签 scriptalert(1)/script。 每次输入后点击搜索观察页面是否出现服务端错误、页面崩溃或明显异常。 把每次的输入和页面表现记录下来最后汇总成一个列表。 )这里要注意涉及安全测试的内容必须在你自己公司授权的测试环境执行线上环境别乱来。AI只会按指令把字符输进去然后观察结果真正的“测试判断”其实还是人来看最后的结果列表。这个场景里我几乎不写断言而是让AI最后输出一份汇总报告我人工判读。因为探索性测试的价值在于发现未知问题而不是套固定断言。5. 我在实际项目中踩过的坑与排查链路5.1 坑一元素定位不稳定同样任务跑两次结果不同这个坑是我最早遇到的。同一个登录任务第一次跑能顺利通过第二次跑却在输入完用户名后直接去点了登录按钮然后因为密码为空而报错。我开始以为是模型随机性导致的把temperature调成了0结果问题依旧。排查链路是先打开debug日志把两次运行的每一步输出拉出来对比。我发现第二次运行时AI在我输入用户名后页面上的密码输入框已经存在但模型固执地认为“可以直接登录了”因为它从DOM快照里看到登录按钮的编号在变。根因是页面里可能有两个登录按钮一个在导航栏一个在表单里DOM序列化排序不稳定模型每次看到的元素编号不同。解决方式一是在任务描述里写得更具体比如“点击表单区域内的登录按钮不要点击顶部导航栏的登录入口”二是减少页面干扰元素通过配置过滤掉部分DOM节点比如只保留表单区域。这个思路同样适用于多标签页问题——如果浏览器打开了多个标签页页面状态会复杂很多任务描述里最好明确“只操作当前标签页”。5.2 坑二token消耗过快长页面一次决策烧掉几千token第二个坑是成本问题。公司后台管理系统页面密布表格一个列表页有几十列筛选条件、分页按钮、操作列按钮、导出按钮……DOM序列化之后页面状态文本非常长。一次简单操作可能消耗几千token一个长流程跑下来账单让人肉疼。我算了一笔账一个普通的后台列表页交互元素可能有三四百个每个元素按几十个token计算一次状态抽取可能产生一万多token。AI每执行一步操作就要重新读一遍这个状态加上历史记录不断增长十步之内token消耗就非常可观。解决思路有四个一是缩小页面可见范围。如果只需要验证表格里的数据可以先把页面上其他区域的可交互元素通过配置排除掉减少进入上下文的元素数量。二是换便宜模型做决策。决策过程不需要最强模型一些简单的定位和点击任务用小型快模型完全能胜任成本能降一个量级。三是任务拆分。一个大流程拆成多个小任务比如登录作为一个任务下单作为另一个任务中间用保存浏览器状态衔接。这样每个任务的上下文长度有限token不会无限膨胀。四是限制历史记录长度。Browser-use在较新版本里支持对历史记录的截断或总结如果你用的版本没有这个能力就靠前三条控制。5.3 坑三无头模式下“看不见”导致AI停顿这个坑是在接入CI时踩到的。本地跑没问题一放到服务器上用headlessTrue跑AI就频繁卡在“找不到按钮”这类操作上明明页面上有那个按钮。排查链路是先怀疑网络加载CI服务器访问被测环境慢后面排除。接着我看运行日志发现模型在无头模式下拿到的DOM序列化和截图跟有头模式不太一样。无头浏览器在某些CSS渲染、字体加载、弹窗动画上会有差异部分元素虽然存在但不可见模型根据“不可见”这个属性判断它不该被点击。另外无头模式的截图有时比有头模式“早”页面还没完全渲染完就截图了AI自然找不到按钮。解决方式在使用无头模式时我在任务描述里主动加了一句“如果目标元素没有立即出现请等待1-2秒后再尝试”。同时把页面加载超时时间调大。最关键的还是优先推荐有头模式尤其在开发阶段。CI里如果实在要用无头模式最好在固定浏览器窗口尺寸、关闭动画这些细节上做配置减少渲染差异。5.4 坑四与pytest集成后任务的超时与重试策略第四个坑是把Browser-use接入pytest之后发现的。早先我把max_steps当成唯一的超时控制忽略了LLM调用本身的耗时。一个复杂页面模型推理可能要等几十秒加上无数次状态抽取单个用例跑上三五分钟很正常。pytest默认没有全局超时测试套件跑挂了有时候是网络问题有时候是模型推理卡顿很难区分是测试失败还是环境问题。我的做法是双管齐下在外层用pytest-timeout给每个用例设一个合理的上限比如6分钟在内层给agent.run()设置不合理的max_steps上限防止死循环。同时对“AI操作失败”这类情况我设计了一套重试策略第一次失败后把失败信息拼进任务描述里让AI再试一次相当于给它一次“补救机会”。这个重试策略对偶发的页面加载慢很有效但注意别无限重试会浪费token。6. 成本优化与测试落地建议给团队的接入方案6.1 任务拆分轻量模型验证者模式的组合如果要在团队里真正落地Browser-use我的建议是“拆”字诀。拆任务、拆模型、拆职责。拆任务很好理解一个大而全的任务描述会让AI频道走偏干脆拆成几个独立的小Agent每个只专注一段流程登录Agent、查询Agent、下单Agent。两个Agent之间用保存的浏览器状态衔接。拆模型是说决策模型和质量验证模型分开。执行过程中用便宜的轻量模型成本低、速度快最后验证阶段用更强的模型或普通代码断言来把关。我在一个数据核对场景里只让轻量模型负责“走到导出页面、点导出”真正的数据校验还是用pandas读文件对比这样既省钱又可靠。6.2 用data-testid约束前端降低AI决策成本这是我从实际项目里总结出来的一个重要经验给前端页面加稳定的自动化测试标识对AI Agent同样友好。传统自动化里我们经常用>