AI浏览器代理实战：基于Playwright与大模型驱动的网页自动化

这两年做自动化最大的感受不是脚本越写越复杂而是“怎么让自动化理解页面”这件事被彻底换了个玩法。我日常主力里有一套AI浏览器代理工具说白了就是让AI替我把浏览器里的活儿干了它自己看页面、自己决定点哪里、自动填表单、自动抓表格数据最后把这一套动作串成完整自动化流程。先澄清一个容易误会的地方标题里的“代理”是Agent的意思也就是AI智能体它代理的是“你在浏览器里的操作”不涉及任何网络通信链路的改造。它能解决的核心问题是那些写脚本成本高、维护更烦人的重复网页操作现在可以用自然语言描述出来让AI直接执行。本文基于我这套工具的实践聊聊它能做什么、我是怎么组装的、落地了哪些场景以及过程中踩过的坑。适合自动化测试工程师、跨境电商运营、还有被重复网页操作折磨的办公人群看。1. AI浏览器代理工具到底是什么从“录脚本”到“看屏幕”1.1 录屏回放、元素定位、AI决策三代自动化有什么本质差别先说清楚我为什么需要这么一套东西。浏览器自动化其实不是新概念最早一批工具是“录屏回放”你在浏览器里手动操作一遍工具把鼠标键盘动作录下来下次重放。这玩意儿最痛的地方是页面稍微改个布局、多插一个弹窗回放就全崩。原因很简单它记录的是“坐标和事件”根本不理解自己在干什么。就像照着菜谱做菜菜谱一丢就当场傻眼。第二代是元素定位加脚本逻辑也就是大家熟悉的Selenium、Playwright这套思路。你通过CSS选择器、XPath把页面上的按钮、输入框定位出来再写断言和逻辑。这套方案到今天依然是主流但维护成本非常真实。前端一个class改个名或者按钮文案从“登录”改成“立即登录”你的脚本就得跟着改。更别提动态表格、多iframe、懒加载这些场景定位元素的时间往往比写业务逻辑还长。第三代就是我现在说的AI浏览器代理。它不要求你在代码里写死每个元素而是让大模型理解页面上下文再用自然语言描述目标AI自己决定下一步动作。这个改变本质上是把自动化从“坐标驱动”升级成“意图驱动”。以前脚本是人翻译给机器听现在是机器自己听指令干活。就像一个新手厨师永远不敢离开菜谱而AI代理更像一个有经验的帮厨看到土豆就知道要削皮切块看到锅热了就问你要不要下菜。1.2 它能做什么、不能做什么以及我对能力边界的理解从我现在的使用范围看它主要覆盖四类事情。第一重复性网页操作每天登录后台、导出报表、填一堆重复表单。第二跨平台数据同步和抓取比如跨境电商多平台订单抓取、把A系统的数据搬到B系统。第三UI自动化测试给定一条业务路径描述AI去自动点击、填表、验证结果。第四把多个步骤编排成完整工作流AI负责看页面执行外层脚本负责调度、报告、通知。它不能做什么先说能力边界。它所有的操作都建立在浏览器环境之内无法替代后端接口压测也无法处理那些不依赖浏览器界面的服务端逻辑。对反爬做得比较严的站点它同样会受限因为本质上还是一个自动化浏览器。你能做的只是控制访问频率、只获取授权范围内的数据没有任何一种浏览器自动化能绕过服务端的风控策略遇到这种情况正确做法是放弃硬抓申请官方API通道。另外要注意的是这套工具的目标是“提高重复操作的效率”不是“无脑替你决策”。AI在单步操作上确实聪明但在涉及多个系统、多步判断的复杂任务里如果没有外层脚本的约束和目标拆分它会跑偏。所以我的定位一直是AI负责执行和感知人负责定义目标和校验结果。2. 架构拆解我的AI浏览器代理自动化能力是这样组装的2.1 五个核心组件浏览器、感知层、决策层、执行层、编排层整套系统看起来是个工具实际上我把它拆成了五个层次每层只干一件事出了问题也好排查。第一层是浏览器运行时我用的是Playwright驱动Chromium。这层负责打开页面、执行点击输入、读取页面状态。第二层是感知层这一层最关键它负责把页面“翻译”给AI看。不能直接拿整页HTML扔给大模型信息太杂、Token太贵而且大模型看不懂底层字节码。我的做法是提取页面上的可交互元素清单把按钮、输入框、链接、下拉框的文案和标识符整理成结构化文本让AI拿到的是“这个页面有哪些能点的东西”而不是一堆标签符号。第三层是决策层也就是大模型接口。它根据感知层提供的页面上下文和目标指令输出下一步要做的动作统一格式是JSON。第四层是执行层负责把AI返回的动作指令翻译成Playwright调用完成点击、输入、跳转这些真实操作。第五层是编排层用pytest、定时任务、工作流脚本来管理整个任务的开始、结束、断言、重试和报告。这五层里最容易被忽略的是编排层。很多人做完第一版AI浏览器代理发现单个操作很聪明但整套流程跑起来却乱糟糟问题就出在没有编排。AI在单步决策上很强但缺乏对全局任务的记忆和校验能力所以必须由外层脚本告诉它现在执行到第几步、上一步是否成功、下一步该往哪个方向走。2.2 为什么底座选Playwright而不是Selenium底座选型这件事我纠结过挺久。我之前用Selenium做了两年自动化测试不是它不好只是当我需要把浏览器的控制权交给AI时有几个点是硬需求对比下来Playwright更合适。第一是自动等待机制。Selenium需要手动写显式等待WebDriverWait用起来又长又啰嗦页面加载快了慢了都容易出问题。Playwright内置了自动等待点击元素前会自动判断可见、可点、稳定这在AI循环里太重要了因为AI无法像人一样实时判断“页面到底加载完没有”。第二是网络请求拦截能力。AI代理经常要等一个接口返回之后再操作Playwright可以直接等特定响应完成这在订单数据抓取场景里特别实用。第三是上下文隔离。Playwright的BrowserContext可以低成本实现多用户登录态隔离我可以同时开几个店铺后台互不干扰。第四是有codegen录制能力虽然AI代理不依赖录制但调试的时候用它快速定位某个元素还是很顺手。我把自己的体验整理成一张选型对照表便于你按需选择能力项PlaywrightSelenium自动等待内置点击前自动校验需要WebDriverWait手动管理动态定位支持get_by_role、get_by_label等语义API主要依赖XPath和CSS网络控制能拦截和等待响应接口较弱多上下文原生支持隔离干净配置麻烦AI生态数据快照、截图、注入方便相对传统这个表不是要否定Selenium如果团队已经有一套成熟的Selenium框架没必要推翻重来。但如果你是搭一套新的AI浏览器代理我建议直接上Playwright省掉一半等待和兼容性的烦心事。2.3 Python pytest 大模型接口的搭配方式技术栈我选了Python主要原因倒不是Python本身多厉害而是自动化测试领域的生态都堆在Python这边pytest的fixture管理、pytest-html的报表、各种大模型API的SDK用起来都顺手。整个项目结构也不复杂核心就三层Agent层负责AI决策和执行循环Page层负责封装浏览器操作Test层负责业务编排和断言。大模型接口我建议用OpenAI兼容协议来做好处是以后想换任意一家支持该协议的模型只需要改BaseURL和模型名。我用环境变量把API Key放在外部代码里不写死任何密钥。有人可能会问为什么不用LangChain其实LangChain在我这套架构里只占很小一部分我更多是直接调用Chat Completions接口自己控制提示词和动作协议。如果只是做一个浏览器代理没必要把LangChain的工具调用链路全部引进来简单的东西反而容易排查。3. 三个直接落地的场景订单抓取、UI自动化测试、办公工作流3.1 跨境电商多平台订单抓取是怎么跑通的这个场景是我最早跑通的业务案例。做跨境电商的运营经常会面临一个困境同时开着Amazon、eBay、速卖通好几个后台每天要把订单数据导出成Excel再汇总到一张总表里。手工操作的话一个店铺按5分钟算三个平台下来就是十几分钟打底而且天天重复特别容易出错。用AI浏览器代理的思路就很直接。第一步先保存每个平台的登录状态Playwright可以登录一次后把StorageState存成JSON文件后续每次启动直接加载省掉扫码和验证的环节。第二步让AI在订单页面定位表格区域提取订单号、商品名称、数量、金额、收货国家这些字段。这里要重点说下提取方式我并没有让AI自己去猜整个表格结构而是在Prompt里给出明确的页面上文和需要的字段清单AI只负责从可见表格里找到对应列。第三步把数据统一格式输出成CSV或写入数据库再触发报表脚本生成汇总。实操中比较坑的地方在于这类后台系统很多是懒加载表格滚动到底才加载下一页数据。解决方案是给动作协议加一个scroll动作AI判断当前表格数据不足时就先滚动再提取。另外提醒一句做数据抓取一定要守住合规边界只抓自己有权限的店铺数据控制抓取频率别对别人的店铺或公开数据做批量采集这不仅涉及平台风控也可能踩到数据合规的红线。3.2 用AI生成UI自动化测试脚本不再一个class一个class找选择器我以前写UI自动化测试用例至少有三分之一时间花在定位元素上。打开开发者工具复制XPath然后发现这个XPath是绝对的上一层加个div就全废。后来做了这套AI浏览器代理后我换了一种方式由AI根据业务路径去生成测试动作再由测试框架做断言。具体流程是这样的。测试人员只需要写一句自然语言描述比如“打开商城首页搜索‘手机’进入第一个商品详情页加入购物车去结算”。AI代理会自己打开页面找到搜索框输入关键词点击搜索结果完成加购操作。这个过程里不需要我预先把选择器写进代码AI通过感知层给到的可交互元素清单实时决定哪个元素是搜索框、哪个是商品卡片。这种做法对前端改动的容忍度明显更高因为AI依赖的是“用户看得到的文案和结构”而不是底层的class名。当然断言还是要人写的AI不会替你判断业务是否正确。我的做法是在AI完成步骤后用Playwright的断言去检查关键状态的可见性或者文本内容。比如结算页有没有出现“订单确认”标题购物车角标数量是不是1。这其实是一种混合模式AI负责高频变化的操作步骤确定性代码负责核心业务校验两边各管自己擅长的部分。3.3 繁琐的网页操作和跨机器文件流转除了电商和测试日常办公里AI浏览器代理的价值更大。比如每天上班要打开内部系统填一堆重复表单点掉各种弹窗再下载几十个报表。这种活儿用脚本写吧因为系统是老旧的表格布局选择器又长又脆弱写完的维护成本远高于收益。但换成AI代理之后反而简单了直接把“用户看得见的步骤”描述给AI它就能照着操作。还有一个我经常用的组合是浏览器操作加上跨机器文件流转。有时我需要在一台Linux服务器上跑分析脚本再把生成的文件传到本地Windows机器上。这里我用的是最常见的SSH/SCP命令脚本属于非常常规的运维手段。整个流程可以串起来AI代理在网页上触发服务器任务外层脚本通过SSH连接服务器执行脚本和文件传输把文件拉到本地再由AI代理把文件内容填进网页表单或者上传到系统后台。这样组合的好处是AI不用硬扛“跨机器”这种它不理解的操作SSH负责它该负责的传输AI只负责它在行的浏览器操作各司其职整体稳定性反而更高。4. 从0到1搭建一个AI浏览器代理自动化项目4.1 环境准备与最小工程结构我直接还原搭建流程你跟着做就能跑通最小版本。环境要求是Python 3.10以上先装依赖pip install playwright pytest pytest-html playwright install chromium这里说明下pytest-html是用来生成HTML测试报告的如果暂时不需要报告可以先不装。工程目录我喜欢这样组织ai_browser_agent/ ├── agent.py # AI决策与执行循环 ├── page_utils.py # 可交互元素提取、滚动、截图 ├── conftest.py # pytest的浏览器fixture ├── test_workflow.py # 业务用例 └── .env # 存放API密钥先写最简单的浏览器fixture给pytest用# conftest.py import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopesession) def browser(): with sync_playwright() as p: b p.chromium.launch(headlessFalse) yield b b.close()headlessFalse的好处是调试时你能亲眼看到AI操作到哪一步等跑稳定了再改成无头模式在服务器上跑任务时建议用无头模式。4.2 核心循环让大模型看懂页面并下发动作指令核心代码是agent.py里的主循环。我先定义一个动作协议目前包含六个动作goto跳转指定URLclick点击指定名称的元素fill向输入框填入内容extract提取页面数据wait等待一段时间done任务完成要让AI看到页面可交互元素先写一个提取函数# page_utils.py def get_interactive_elements(page): items [] selectors button, input, a, select, textarea, [rolebutton] for el in page.locator(selectors).all(): tag el.evaluate(e e.tagName) if tag INPUT: name ( el.get_attribute(placeholder) or el.get_attribute(aria-label) or el.get_attribute(name) or ) else: name el.inner_text(timeout2000).strip()[:50] if name: items.append(f{tag} {name}) return | .join(items[:60])这一步为什么重要直接拿body文本给大模型AI很难分清哪些是可点的、哪些只是描述文字。给一份可交互元素清单就像给司机一张标了路况的地图决策准确率会高很多。然后主循环长这样# agent.py import json import os import re from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) PROMPT 你是一个浏览器自动化代理。你只能输出JSON动作。 可用动作goto, click, fill, extract, wait, done。 当前页面可交互元素 {elements} 用户任务{task} 请基于当前页面状态输出下一步动作一次只输出一个动作。 def run_browser_task(page, task: str, max_steps15): step 0 while step max_steps: elements get_interactive_elements(page) prompt PROMPT.format(elementselements, tasktask) resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0 ) content resp.choices[0].message.content.strip() content re.sub(rjson|, , content) action json.loads(content) action_type action.get(action) target action.get(target, ) value action.get(value, ) if action_type goto: page.goto(value, timeout30000) elif action_type click: page.get_by_role(button, nametarget, exactFalse).first.click() elif action_type fill: page.get_by_placeholder(target).first.fill(value) elif action_type extract: result page.locator(target).all_inner_texts() print(提取内容, result[:5]) elif action_type wait: page.wait_for_timeout(int(value or 1500)) elif action_type done: break step 1这里有一个关键选择把temperature设为0让模型尽量稳定输出不至于同一页面两次决策差异很大。动作执行时用Playwright自身的自动等待尽量避免元素还没加载完就点击的尴尬。4.3 和pytest结合把AI动作变成可断言的测试用例有了上面的核心循环接入pytest就很简单了。我在test_workflow.py里写用例用自然语言描述业务流程AI代理执行最后用普通断言做业务校验# test_workflow.py def test_search_and_add_to_cart(browser): page browser.new_page() page.goto(https://your-shop.example.com) run_browser_task(page, 搜索手机进入第一个商品详情页加入购物车) cart_count page.locator(.cart-badge).inner_text() assert int(cart_count) 1跑测试直接用pytest命令pytest test_workflow.py -v --htmlreport.html这套组合的收益是业务需求变化时只改自然语言描述而不需要去改背后的定位代码。但也送给新接触的人一句忠告AI生成的自动化测试更适合流程冒烟不太适合对性能和边界值这类精确断言要求极高的场景。AI帮你把流程跑通最终校验还是落到普通代码上别把AI当成不用写断言的免死金牌。4.4 稳定性和成本控制AI定位不是万能的这部分是我最想讲的。很多项目挂就挂在稳定性和成本失控上。先说稳定性。生产环境里不要让AI每一步都自由决策正确的策略是“确定性优先AI兜底”。能写死选择器的关键节点就直接写死比如登录按钮、提交按钮这些核心操作只有在元素频繁变化、选择器脆弱的地方才交给AI语义定位。另外动作循环要设置最大步数上限避免异常页面让AI无限循环。我还会在每个关键动作后面加一个状态检查如果上一步失败直接跳出重试而不是硬着头皮往下执行。再说成本。AI浏览器代理最烧钱的是Token而Token消耗大户是感知层传给大模型的页面上下文。优化方法有三个一是只传可交互元素不传整页HTML二是对元素数量做截断先取前60个三是把一次性的大任务拆成多个小步骤每步决策上下文更小更准。我实测下来一次10步左右的流程Token费用可以控制在几毛钱以内完全在可接受范围。5. 常见问题与排查技巧实录5.1 高频故障与解决方案速查表AI浏览器代理的故障模式和传统自动化脚本不太一样我把实际遇到的高频问题整理成一张速查表先收藏出了状况照着查现象可能原因排查与解决AI反复点同一个错误元素可交互元素清单太长相似按钮太多缩小上下文只取当前可见区域元素或给按钮加更具体的文案点击后无反应元素被弹窗遮挡或还在懒加载先执行一次wait或scroll再点击必要时设置click的timeout提示找不到元素页面是iframe内部元素用frame_locator定位iframe内部或让AI在动作里带上frame信息登录态每次都要重新验证没有保存StorageState登录成功后调用context.storage_state()保存后续启动直接加载Token消耗异常高每次决策都传整页HTML换成可交互元素清单并对长度做截断任务跑到一半卡住页面出现未知弹窗或验证码异常分支检测逻辑遇到弹窗先关闭遇到验证码就停止并通知人工用例偶发失败网络慢导致响应未完成关键接口用expect_response等待返回不要只靠固定sleep5.2 我在实践中踩过的三个坑第一个坑是过度相信AI的每一步决策。最早做的版本是让大模型从页面跳转、点击、校验全程自由发挥结果在一次任务里它连续点击同一个不相关链接三次整个流程跑偏。后来我强行规定每个节点的目标必须来自外层任务拆分AI只能决定“怎么执行”不能决定“执行什么目标”。这个改动直接把成功率拉高一大截。第二个坑是感知层给的信息太“脏”。有一段我图省事直接截取body的innerText给大模型结果AI经常分不清页面底部版权信息和顶部导航哪个是按钮。后来改成只提取可交互元素并给每个元素标注标签类型决策准确率才真正稳定下来。这里面的经验是不要让AI在噪音里自己找信号你要先帮它把页面结构提纯。第三个坑是忘了给“完成条件”下定义。很多任务不是天然有终点的比如“抓取所有订单”AI可能会一直抓下去。后来我把任务目标细化成“抓到当前第1页的20条订单并停止”在动作协议里加done动作并在外层脚本设置最大步数问题才算解决。用这类工具之前先想好终止条件是自动化项目最容易被忽略的一环。最后再说一个我个人的体会。AI浏览器代理工具不是把老的自动化脚本技巧扔进垃圾桶它更像是在你原来的自动化能力旁边装了一个能听懂人话的驾驶辅助。我到现在依然会手写核心脚本、手写断言、手工控制频率和合规边界AI只负责接管那些选择器维护成本高的重复动作。如果你准备尝试我建议先别急着做全链路全自动挑一个每天重复且页面变化频繁的单一动作入手比如每天导出报表或者填一张表单把最小闭环跑稳再慢慢扩展。这套工具的收益曲线是加速的前期搭建辛苦一点后期每次业务系统改版你都会庆幸当初留了这层容错。