朋友公司每天要处理几百条来自不同电商平台的订单人工在各个卖家后台来回切换、复制、粘贴再汇总成表格。他问我能不能写个脚本自动搞定换作以前我大概率会给他一套 Selenium Python然后说“先学会 CSS 选择器再说”。但现在我的答案变了我会直接给他一个 AI 浏览器代理工具。所谓 AI 浏览器代理工具简单讲就是把大模型的理解能力、浏览器的操作能力、自动化测试的工程化能力拼在一起让机器替人“看页面、想步骤、动手点”。这篇文章就当作我的自动化能力清单加实战复盘讲讲这东西到底怎么搭、怎么用、踩了哪些坑希望对正在做自动化测试、爬虫聚合和运维巡检的朋友有帮助。1. 这个东西到底是什么AI 浏览器代理工具与传统自动化的分水岭1.1 从“写脚本”到“下指令”的本质变化传统浏览器自动化核心动作是“定位元素、操作元素、断言结果”。人负责把页面每一个细节都告诉程序第几行的按钮叫什么 id下拉框选项的值是哪个翻页按钮的链接长什么样。这套模式的痛点是显而易见的——页面结构只要改一个小类名脚本就崩了维护成本全堆在“选择器”上。AI 浏览器代理工具换了一种思路我不再逐条告诉机器“你要点哪里、输入什么”而是直接告诉它“你今天要完成什么”。比如“打开订单管理后台筛选昨天到今天的订单把订单号、金额、状态抓下来存成 CSV”。工具内部的大模型会自己规划步骤调用底层浏览器能力去执行执行完再回读页面结果验证。这个过程中“自动化能力”从“人肉翻译页面结构”变成了“让模型理解目标并自行拆解动作”。这是一个本质变化命令式自动化关心的是 HOW怎么点、怎么输入声明式自动化关心的是 WHAT要什么结果。实际体验下来后者在面对页面频繁迭代的场景时能省掉至少一半的维护精力。1.2 这套工具能覆盖的自动化能力矩阵我日常把它当成一套完整的自动化底座来用大概覆盖五个方向浏览器 UI 自动化登录、点击、表单填写、翻页、文件下载底层走 Playwright。接口与数据自动化登录态的 Cookie/Token 直接从浏览器会话拿配合 Python 的 requests 做接口校验和数据拉取。跨平台数据抓取与汇总比如电商订单聚合、竞品价格监控、行业信息采集这类“多平台、多页面、多格式”的活AI 代理非常擅长。自动化测试体系建设把 AI 生成的步骤转化为 pytest 用例接入 Allure 报告跑完自动分析失败原因。自动化运维联动配合 Ansible 做环境部署配合 Jenkins 做定时巡检让浏览器巡检和系统健康检查无人值守。这五个方向不是各自独立的。实际链条通常是运维工具把环境准备好 - AI 浏览器代理做端到端验证 - 接口层做数据校验 - 结果汇总成报告推送出来。我后文会按这个链条依次展开。1.3 和 Selenium、RPA、传统测试框架的区别很多朋友会问这不就是 Selenium 套了个大模型壳吗我的回答是壳只是表象真正的差异在“决策逻辑”和“等待机制”。这里我列个表方便直观对比对比维度传统 Selenium 脚本传统 RPA 工具AI 浏览器代理工具指令方式逐条写死动作录制回放为主自然语言目标 自动拆解步骤页面变化适应性差选择器一变就挂一般重录一遍即可较强模型会重新理解页面元素定位策略依赖 id/xpath/CSS依赖图像识别 坐标语义定位 DOM 结构双通道调试手段打印日志、断点录屏回放trace 回放 AI 失败归因学习成本高要会框架和选择器低但脚本难维护中先学会描述任务和审阅结果需要注意的是我并不是说 Selenium 就该被淘汰。它的稳定性和可预测性依然不可替代尤其是核心业务回归测试、金融类项目这种“一次都不许错”的场景我反而会坚持用 Selenium 写死每一步。AI 浏览器代理工具适合的是“流程稳定但页面细节变化频繁、目标明确但执行路径多样”的场景两者是互补关系不是替代关系。2. 技术底座为什么是 Playwright pytest AI 语义层2.1 Playwright 的操作控制力是最适合被 AI 调度的AI 模型擅长做“下一步动作”的决策但它需要一套高质量、高可控性的执行器。我选 Playwright 作为底层原因有三个。第一Playwright 有自动等待机制。它不像旧框架那样依赖 sleep 去等元素加载而是自动轮询查找元素直到可操作。这个特性对 AI 调度尤其重要因为模型写出来的步骤里不可能精确预估网络延迟自动等待能让“我的操作已经完成”这件事变得可靠。第二Playwright 提供 trace 回放能力。每次执行自动录制页面截图、网络请求、控制台报错和 DOM 快照AI 在排错时可以直接把这些数据喂给模型做归因分析。我实际用下来这套“执行 回放 归因”的闭环是传统 Selenium 完全比不了的。第三Playwright 的 context 隔离模型非常干净。每次任务可以新建一个独立的浏览器上下文Cookie、缓存、存储状态全隔离跑完直接销毁。做多任务并行时这是刚需。2.2 pytest 作为工程化骨架补齐了测试能力AI 浏览器代理能“跑通”但自动化测试要的是“反复跑、跑完能报告、失败能定位”。这块靠 pytest 补上。我采用的组合是 pytest pytest-playwright Allure。好处在哪呢fixture 机制可以把浏览器实例、页面对象、登录状态都做成可复用的夹具。比如全局定义一个 session 级别的浏览器上下文所有用例共用登录态再定义一个 function 级别的 page fixture每条用例拿到一个干净的标签页。这正好与 Playwright 的上下文模型完美契合。还有参数化。同一个订单抓取任务我可以用参数化去跑不同店铺维度同一个表单流程可以用参数化覆盖不同用户角色。AI 生成的任务描述是模板pytest 参数化负责把模板展开成矩阵这是纯脚本做不到的工程化能力。2.3 AI 语义指令怎么变成浏览器操作中间 JSON 是关键很多人在做“自然语言转浏览器操作”时第一步就掉坑里了直接让大模型输出 Python 代码然后 exec 执行。这种方式偶尔能跑通但一旦模型出错你只能在乱成一团的执行日志里慢慢捞而且代码注入风险也很高。我的做法是加一层“中间指令”。大模型不直接生成代码而是生成一个结构化的 JSON 动作序列再由一个本地执行器把 JSON 翻译成 Playwright 调用。这样做有三个好处可控、可审计、可重试。模型输出 JSON 之后执行器会做 schema 校验字段类型不对直接让模型重新生成而不是盲目执行。一个典型的中间指令长这样{ task_id: order_export_001, steps: [ { action: goto, url: https://seller.example.com/login, wait_for: input[nameaccount] }, { action: fill, selector: input[nameaccount], value: __USER_ACCOUNT__ }, { action: click, selector: button[typesubmit], wait_for: url:contains(dashboard) }, { action: extract_table, selector: table.order-list, columns: [order_id, amount, status], to_csv: orders_20250120.csv } ] }执行器拿到这个 JSON 后会逐步执行并验证每一步的前提条件。如果某一步失败比如定位器找不到元素执行器会把当前页面的 DOM 快照和报错信息返回给大模型让它修正后续步骤。这个“执行 - 回读 - 修正”的循环就是 AI 浏览器代理工具和被动的录制回放工具之间最大的分水岭。2.4 大模型选型方面的实践经验模型层我建议用两种方案对外服务型任务用 API 方式的高上下文模型胜在稳定、函数调用能力强内部数据敏感的任务用本地部署的开源模型配合 Ollama 或者 vLLM 跑保证数据不出内网。实际体验下来小模型的“指令遵循”能力是瓶颈。让它生成一个 JSON 动作序列它经常会把字段名编错、把 CSS 选择器格式写错。我的经验是不要直接上大模型先给一个 few-shot 示例库内置十几条常见动作的 JSON 模板模型照着填参。这样哪怕模型水平一般输出格式也不会跑偏。还有一招更实用把页面的可访问性树Accessibility Tree抓下来作为上下文输入给模型中文网页里很多按钮文本、输入框标签都能从可访问性树拿到这比让模型猜选择器靠谱得多。3. 从零搭建一套能跑的 AI 浏览器代理工具3.1 环境准备清单先说明这套工具跑在 Linux 或 Windows 都行推荐用 Python 3.10 以上版本Node.js 作为辅助。基础依赖如下# 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装核心依赖 pip install playwright pytest pytest-playwright langchain openai pip install pandas allure-pytest requests pyyaml # 安装浏览器内核 playwright install chromium这里有个容易忽略的细节playwright install chromium只是装了 Chromium如果需要模拟更多浏览器环境可以用playwright install msedge装 Edge 内核。在 Linux 服务器上跑还需要安装系统级依赖执行playwright install-deps可以一口气装好。3.2 推荐的项目目录结构我用得比较顺手的结构是这样agent-browser/ ├── agent/ │ ├── planner.py # 大模型规划任务描述 - JSON 步骤序列 │ ├── executor.py # 执行器JSON - Playwright 调用 │ └── fixer.py # 失败回读与自动修正 ├── browser/ │ ├── operator.py # Playwright 封装goto/fill/click/extract │ └── context.py # 浏览器上下文管理登录态复用 ├── tasks/ │ ├── order_fetch.py # 电商订单抓取任务 │ ├── health_check.py # 系统健康巡检任务 │ └── ui_test_cases.py # 对应 pytest 用例 ├── config/ │ ├── settings.yaml # 全局配置超时、重试次数、模型参数 │ └── selectors.yaml # 兜底选择器AI 定位失败时备用 ├── reports/ # Allure 结果与截图输出目录 └── tests/ └── conftest.py # pytest fixture 定义这个结构把“Agent”“浏览器操作”“任务定义”“配置”四层拆开。好处是AI 规划层只管生成动作序列浏览器操作层只管执行动作任务定义层负责聚合业务逻辑配置层统一管环境差异。任何人接手时不用看一遍 AI 的 prompt 就能快速定位问题。3.3 核心代码骨架调度器和操作器先写一个最基础的浏览器操作器。它封装 Playwright 的常见操作并支持把页面关键信息回传给 Agent# browser/operator.py from playwright.sync_api import sync_playwright class BrowserOperator: def __init__(self, headlessTrue, **kwargs): self._playwright sync_playwright().start() self.browser self._playwright.chromium.launch( headlessheadless, args[--disable-blink-featuresAutomationControlled], ) self.context self.browser.new_context( viewport{width: 1280, height: 720}, localezh-CN, ) self.page self.context.new_page() def act(self, step: dict): action step[action] if action goto: self.page.goto(step[url], wait_untilnetworkidle) elif action fill: self.page.fill(step[selector], step[value]) elif action click: self.page.click(step[selector]) elif action extract_table: rows self.page.locator(step[selector]).all_inner_texts() return {rows: rows} return {ok: True} def snapshot(self): # 返回可访问性树快照供大模型理解当前页面 return self.page.accessibility.snapshot() def close(self): self.browser.close() self._playwright.stop()注意我用的是 sync API适合大多数内部自动化脚本。如果要做高并发建议换成 async API事件驱动模型效率更高。然后是 Agent 的规划器。这个模块负责把自然语言任务交给大模型拿到结构化的动作序列# agent/planner.py from langchain.prompts import FewShotPromptTemplate, PromptTemplate from langchain.chat_models import ChatOpenAI class AgentPlanner: def __init__(self, api_key, base_url, model_name): self.llm ChatOpenAI( api_keyapi_key, base_urlbase_url, modelmodel_name, temperature0.1, ) # few-shot 示例从 config 里加载保证输出格式稳定 self.examples load_few_shot_examples() self.prompt FewShotPromptTemplate(...) def plan(self, task_description: str, page_snapshot: dict None) - list[dict]: prompt_text self.prompt.format( tasktask_description, snapshotpage_snapshot if page_snapshot else 无, ) response self.llm.invoke(prompt_text) return json.loads(response.content)[steps]第一次跑通这个循环你会明显感觉到自然语言任务的容错性强了很多。“把页面上所有订单金额加总”这种模糊描述模型会自己去表格里找金额列并求和而不是傻等某个固定选择器。3.4 完整案例跨境电商多平台订单抓取这是我朋友的真实场景。他每天要在三个电商平台后台导出当天订单再合并成一个表发到运营群。过去靠人肉复制偶尔漏单。用 AI 浏览器代理后整个流程大概是这样的任务描述只需一句话“登录三个卖家后台分别抓取今天之前的 24 小时订单输出到一个合并 Excel发到指定目录。”执行过程分几步第一步登录。三个平台的登录方式不同一个扫码、一个短信验证码、一个账密登录。我把三个登录流程都封装成独立的“登录算子”放入任务模板。AI 在规划时识别到“登录”这个意图会直接挂载对应的登录算子而不需要每次都在 prompt 里描述登录细节。第二步抓取。进入订单列表页后AI 会读取表格的可访问性树自动识别表头字段。如果页面表格没有标准表头比如某些平台是卡片式布局执行器会自动切到文本提取和正则匹配兜底。第三步汇总。三个平台抓下来的原始数据都落成 DataFrame统一字段名然后按订单号去重、合并金额输出到一个 Excel 工作簿。关键代码如下# tasks/order_fetch.py import pandas as pd from agent.planner import AgentPlanner from browser.operator import BrowserOperator def fetch_orders(platform_config, cookie_dir): op BrowserOperator(headlessTrue) planner AgentPlanner(...) task ( 进入订单管理页面筛选最近24小时订单 提取订单号、商品名称、实付金额、订单状态 翻页直到没有更多数据 ) steps planner.plan(task, page_snapshotop.snapshot()) records [] for step in steps: result op.act(step) if step[action] extract_table: records.extend(parse_table(result[rows])) df pd.DataFrame(records) df.to_csv(foutputs/{platform_config[name]}_orders.csv, indexFalse) op.close() return df这里最核心的经验是固定的页面跳转规则比如筛选条件的选择器不要完全交给 AI 去猜这些适合写死在模板里。AI 负责的是“动态部分”识别当前页面有没有弹窗、要不要翻页、表格列顺序变了怎么自适应。把静态与动态分层执行成功率会大幅提升。我踩过太多“全交给 AI”导致定位器乱写的坑经验就是AI 做决策规则做底座两者结合才稳定。3.5 Agent-Browser 接入自动化测试组件的配置细节很多人拿到这类工具后最关心的是“怎么把 Agent-Browser 接到现有测试体系里”。我的建议是不要让 Agent 直接驱动 pytest 的 use case而是让 Agent 生成步骤结果再由 pytest 调用执行器来完成断言。在 config/settings.yaml 里我这样配browser: headless: true viewport_width: 1280 viewport_height: 720 timeout_ms: 30000 agent: model_name: qwen2.5:14b temperature: 0.2 max_retry: 3 test: base_env: staging parallel_workers: 4 screenshot_on_failure: true trace_on_failure: truepytest 那边的 conftest.py 定义一个全局 fixture让每条用例都能用到同一个浏览器操作器# tests/conftest.py import pytest from browser.operator import BrowserOperator from config.config_loader import load_settings pytest.fixture(scopesession) def operator(): settings load_settings() op BrowserOperator( headlesssettings[browser][headless], timeout_mssettings[browser][timeout_ms], ) yield op op.close() pytest.fixture() def page(operator): context operator.browser.new_context() yield context.new_page() context.close()这样跑 pytest 时UI 自动化、接口自动化、数据抓取三种用例可以共用一个底层浏览器操作器而断言逻辑则由 pytest 的 assert 来承接。整体框架的可维护性立刻上了一个台阶。4. 自动化能力的三个落地场景UI 测试、接口测试、运维联动4.1 UI 自动化测试从手工选择器到语义生成用例UI 自动化里最烦的就是选择器维护。我的做法是让 AI 生成语义化定位策略同时在关键路径上保留手动校验过的备用选择器。打个比方以前写用例是“请点一下 id 为 submit-btn 的按钮”现在写用例是“请完成表单提交”。模型会根据当前页面的可访问性树找到“提交”按钮哪怕它的 id 从 submit-btn 改成了 submit_button模型依然能认出来。具体到一个用例def test_login_and_create_order(operator, page): # 用自然语言定义步骤由 Agent 生成具体操作 steps planner.plan( 登录测试账号创建一个金额为 99 元的测试订单提交后确认成功提示出现 ) for step in steps: operator.act(step) # 断言交给 pytest 管 success_text page.locator(text订单提交成功) assert success_text.is_visible(), 预期成功提示未出现这套用法的好处是业务人员也能看懂用例在干嘛测试同学则可以把精力放到断言和边界条件设计上。4.2 接口自动化自动切换环境的关键细节接口自动化和浏览器自动化经常要混跑。很多团队都有多套环境dev、test、staging、prod测试代码最怕的是把请求打到错误环境。结合 AI 浏览器代理工具我的方案是浏览器会话自动携带当前环境的基础 URL执行器在建构中间指令时会自动把__BASE_URL__替换成当前环境地址。环境切换用 pytest 的--env参数动态注入而不是写死在代码里。登录态从浏览器上下文自动导出作为 requests 的 Cookie 和 Authorization 头接口测试和 UI 测试天然共用一套身份。核心代码如下# tests/conftest.py 增加环境切换逻辑 def pytest_addoption(parser): parser.addoption(--env, actionstore, defaulttest, help运行环境: dev/test/staging/prod) pytest.fixture(scopesession) def env(request): return request.config.getoption(--env) pytest.fixture(scopesession) def base_url(env): return get_env_config(env)[base_url] pytest.fixture(scopesession) def api_headers(env, operator): token operator.extract_token_from_cookie(env_config[env][login_url]) return {Authorization: fBearer {token}}调用时pytest --envstaging tests/test_order_api.py pytest --envdev tests/test_order_api.py这个方案彻底解决了“环境配置分散、切换时容易忘改地址”的痛点。我实际用下来团队里测试人员跑错环境的概率降到了零因为环境信息只由命令行参数维护而不是散布在用例里。4.3 自动化运维无人值守的浏览器巡检与系统健康检查自动化运维场景里AI 浏览器代理工具最亮眼的用途是浏览器巡检。传统运维只能监控服务器指标CPU、内存、端口但业务系统的“真实可用性”必须通过浏览器端到端操作才能验证。我的做法是用 Ansible 批量执行环境部署和启动任务确保被测系统已经更新到最新版本然后 Jenkins 定时触发 AI 浏览器代理巡检脚本模拟关键用户路径登录、查询、提交、登出最后把检查结果和失败截图推送到内部 IM。这个链路完全无人值守比单纯 ping 一个端口要可靠得多。Jenkins Pipeline 的一个简化示例pipeline { agent any stages { stage(Deploy) { steps { sh ansible-playbook deploy_playbook.yml -i inventories/test } } stage(UI Health Check) { steps { sh source .venv/bin/activate pytest tests/test_health_check.py --envstaging --alluredirreports } } stage(Archive Reports) { steps { allure generate reports -o allure-report --clean } } } }有人会担心这类“AI 自动操作浏览器”会不会被安全机制拦截。我的经验是对内部系统做巡检没有这个问题因为本来就有业务账号和操作权限工具只是替代键盘鼠标。如果是对外部公开页面做数据巡检一定要控制频次、控制抓取范围并且只拿公开可见的数据。自动化能力本身是中性工具使用边界由场景定义这句话值得写进每一个自动化项目的 README。5. 常见问题与排查技巧实录5.1 AI 生成的脚本为什么跑一次就挂这是初用者遇到最多的一个问题。AI 第一次规划出的动作序列跑通了第二次页面只要有一点变化比如多了一个广告弹窗、按钮文案改了后续步骤全崩。我的排查思路分三步。首先看 trace 记录确认崩在哪一步。绝大多数是元素定位失败。其次把失败那一步的页面可访问性树重新喂给大模型让它重新生成后续步骤而不是从头跑。最后在任务模板里为关键动作增加“兜底分支”比如检测到弹窗就关闭再继续原计划。这个“失败归因 局部重规划”的机制现在基本能把脚本的一次通过率从 50% 提到 85% 以上。5.2 元素定位不稳定与“锁住/未锁住”问题的排查在浏览器自动化项目里我经常听到“页面锁住了”“元素未锁住”这种描述其实对应的是两类实际问题。一类是浏览器上下文锁Playwright 同一个 page 对象同时被多个协程操作时会报错表现为操作互相打断。排查时看日志里有没有“Target closed”或“Execution context was destroyed”如果有基本就是并发访问同一个页面导致的。另一类是登录态锁电商后台通常会把登录状态绑定到当前浏览器指纹和 IP换一个上下文重新执行时Cookie 带过去了但指纹变了被判定为登录失效。这类问题在“多平台订单抓取”这种需要切换多个账号的场景特别常见。我的处理方式是给每个平台、每个账号单独建一个持久化上下文目录存独立的 Cookie 和本地存储运行时用browser.new_context(storage_state...)加载。这样“锁住”和“未锁住”的会话边界就非常清晰了。5.3 无头模式下的风控与验证码AI 浏览器代理工具默认跑无头浏览器这很容易触发网站的风控策略常见表现是出现滑块验证、短信验证拦截提示。我的建议是分场景处理如果是内部业务系统巡检尽量用有头模式跑在测试机上配合固定的测试账号。如果是抓取外部公开数据不要绕验证码更不要搞破解直接优化抓取策略降低频率、增加随机延迟、只取必要字段。如果必须用无头模式可以给 Chromium 加禁用自动化特征参数再配合真实用户代理实测能减少一部分风控误判但这不是永久的解法。遇到滑块验证我的原则是该人工处理就人工处理不要在这种地方消耗工程资源。自动化工具最大的价值是替代重复劳动而不是与安全机制做猫鼠游戏。5.4 并行执行与会话隔离最后说并行。AI 浏览器代理工具可以同时开多个浏览器上下文跑不同任务但有两个坑第一资源消耗。每个 Chromium 实例内存占用至少 300MB我建议用进程池限制并发数。在我的配置里默认 4 个 worker 算比较稳的。第二任务隔离。不同任务的 Cookie、Download 文件目录、截图目录必须分开否则会出现“A 任务截图被 B 任务覆盖”这种诡异问题。解决办法很简单每个任务初始化时都建一个独立输出目录并把任务 id 作为目录名的一部分。附一张快速排查表方便直接对照现象可能原因解决方案元素点击无响应页面弹窗遮挡 or 元素未加载完全检查 trace换语义定位增加弹窗关闭兜底登录状态频繁失效浏览器上下文未持久化使用 storage_state 持久化登录态多任务并发互相干扰输出目录或上下文共用每个任务独立目录、独立 context执行速度越来越慢上下文未关闭内存堆积任务结束后强制 close并做资源监控模型生成 JSON 格式错误缺少 few-shot 示例在 prompt 中加入模板示范和 schema 校验最后分享一点个人体会我自己跑下来的体会是AI 浏览器代理工具最擅长的是那些“流程清晰、目标明确、但页面细节反复变化”的重复劳动。它把原先需要懂前端、懂测试框架、懂脚本维护的人才能干的活压缩成了“用自然语言描述任务 定时审阅执行结果”门槛低了一大截。但这并不意味着它不需要工程能力——恰恰相反真正让工具稳定跑起来的核心还是分层架构、中间 JSON、失败回读和上下文隔离这些实打实的工程细节。自动化能力的本质从来都不是“让机器替代人”而是“让人把有限的精力放在最关键的选择和判断上”。这套工具就是朝这个方向走得很远的一个底座。 AI浏览器代理工具实战：从自然语言指令到自动化操作
朋友公司每天要处理几百条来自不同电商平台的订单人工在各个卖家后台来回切换、复制、粘贴再汇总成表格。他问我能不能写个脚本自动搞定换作以前我大概率会给他一套 Selenium Python然后说“先学会 CSS 选择器再说”。但现在我的答案变了我会直接给他一个 AI 浏览器代理工具。所谓 AI 浏览器代理工具简单讲就是把大模型的理解能力、浏览器的操作能力、自动化测试的工程化能力拼在一起让机器替人“看页面、想步骤、动手点”。这篇文章就当作我的自动化能力清单加实战复盘讲讲这东西到底怎么搭、怎么用、踩了哪些坑希望对正在做自动化测试、爬虫聚合和运维巡检的朋友有帮助。1. 这个东西到底是什么AI 浏览器代理工具与传统自动化的分水岭1.1 从“写脚本”到“下指令”的本质变化传统浏览器自动化核心动作是“定位元素、操作元素、断言结果”。人负责把页面每一个细节都告诉程序第几行的按钮叫什么 id下拉框选项的值是哪个翻页按钮的链接长什么样。这套模式的痛点是显而易见的——页面结构只要改一个小类名脚本就崩了维护成本全堆在“选择器”上。AI 浏览器代理工具换了一种思路我不再逐条告诉机器“你要点哪里、输入什么”而是直接告诉它“你今天要完成什么”。比如“打开订单管理后台筛选昨天到今天的订单把订单号、金额、状态抓下来存成 CSV”。工具内部的大模型会自己规划步骤调用底层浏览器能力去执行执行完再回读页面结果验证。这个过程中“自动化能力”从“人肉翻译页面结构”变成了“让模型理解目标并自行拆解动作”。这是一个本质变化命令式自动化关心的是 HOW怎么点、怎么输入声明式自动化关心的是 WHAT要什么结果。实际体验下来后者在面对页面频繁迭代的场景时能省掉至少一半的维护精力。1.2 这套工具能覆盖的自动化能力矩阵我日常把它当成一套完整的自动化底座来用大概覆盖五个方向浏览器 UI 自动化登录、点击、表单填写、翻页、文件下载底层走 Playwright。接口与数据自动化登录态的 Cookie/Token 直接从浏览器会话拿配合 Python 的 requests 做接口校验和数据拉取。跨平台数据抓取与汇总比如电商订单聚合、竞品价格监控、行业信息采集这类“多平台、多页面、多格式”的活AI 代理非常擅长。自动化测试体系建设把 AI 生成的步骤转化为 pytest 用例接入 Allure 报告跑完自动分析失败原因。自动化运维联动配合 Ansible 做环境部署配合 Jenkins 做定时巡检让浏览器巡检和系统健康检查无人值守。这五个方向不是各自独立的。实际链条通常是运维工具把环境准备好 - AI 浏览器代理做端到端验证 - 接口层做数据校验 - 结果汇总成报告推送出来。我后文会按这个链条依次展开。1.3 和 Selenium、RPA、传统测试框架的区别很多朋友会问这不就是 Selenium 套了个大模型壳吗我的回答是壳只是表象真正的差异在“决策逻辑”和“等待机制”。这里我列个表方便直观对比对比维度传统 Selenium 脚本传统 RPA 工具AI 浏览器代理工具指令方式逐条写死动作录制回放为主自然语言目标 自动拆解步骤页面变化适应性差选择器一变就挂一般重录一遍即可较强模型会重新理解页面元素定位策略依赖 id/xpath/CSS依赖图像识别 坐标语义定位 DOM 结构双通道调试手段打印日志、断点录屏回放trace 回放 AI 失败归因学习成本高要会框架和选择器低但脚本难维护中先学会描述任务和审阅结果需要注意的是我并不是说 Selenium 就该被淘汰。它的稳定性和可预测性依然不可替代尤其是核心业务回归测试、金融类项目这种“一次都不许错”的场景我反而会坚持用 Selenium 写死每一步。AI 浏览器代理工具适合的是“流程稳定但页面细节变化频繁、目标明确但执行路径多样”的场景两者是互补关系不是替代关系。2. 技术底座为什么是 Playwright pytest AI 语义层2.1 Playwright 的操作控制力是最适合被 AI 调度的AI 模型擅长做“下一步动作”的决策但它需要一套高质量、高可控性的执行器。我选 Playwright 作为底层原因有三个。第一Playwright 有自动等待机制。它不像旧框架那样依赖 sleep 去等元素加载而是自动轮询查找元素直到可操作。这个特性对 AI 调度尤其重要因为模型写出来的步骤里不可能精确预估网络延迟自动等待能让“我的操作已经完成”这件事变得可靠。第二Playwright 提供 trace 回放能力。每次执行自动录制页面截图、网络请求、控制台报错和 DOM 快照AI 在排错时可以直接把这些数据喂给模型做归因分析。我实际用下来这套“执行 回放 归因”的闭环是传统 Selenium 完全比不了的。第三Playwright 的 context 隔离模型非常干净。每次任务可以新建一个独立的浏览器上下文Cookie、缓存、存储状态全隔离跑完直接销毁。做多任务并行时这是刚需。2.2 pytest 作为工程化骨架补齐了测试能力AI 浏览器代理能“跑通”但自动化测试要的是“反复跑、跑完能报告、失败能定位”。这块靠 pytest 补上。我采用的组合是 pytest pytest-playwright Allure。好处在哪呢fixture 机制可以把浏览器实例、页面对象、登录状态都做成可复用的夹具。比如全局定义一个 session 级别的浏览器上下文所有用例共用登录态再定义一个 function 级别的 page fixture每条用例拿到一个干净的标签页。这正好与 Playwright 的上下文模型完美契合。还有参数化。同一个订单抓取任务我可以用参数化去跑不同店铺维度同一个表单流程可以用参数化覆盖不同用户角色。AI 生成的任务描述是模板pytest 参数化负责把模板展开成矩阵这是纯脚本做不到的工程化能力。2.3 AI 语义指令怎么变成浏览器操作中间 JSON 是关键很多人在做“自然语言转浏览器操作”时第一步就掉坑里了直接让大模型输出 Python 代码然后 exec 执行。这种方式偶尔能跑通但一旦模型出错你只能在乱成一团的执行日志里慢慢捞而且代码注入风险也很高。我的做法是加一层“中间指令”。大模型不直接生成代码而是生成一个结构化的 JSON 动作序列再由一个本地执行器把 JSON 翻译成 Playwright 调用。这样做有三个好处可控、可审计、可重试。模型输出 JSON 之后执行器会做 schema 校验字段类型不对直接让模型重新生成而不是盲目执行。一个典型的中间指令长这样{ task_id: order_export_001, steps: [ { action: goto, url: https://seller.example.com/login, wait_for: input[nameaccount] }, { action: fill, selector: input[nameaccount], value: __USER_ACCOUNT__ }, { action: click, selector: button[typesubmit], wait_for: url:contains(dashboard) }, { action: extract_table, selector: table.order-list, columns: [order_id, amount, status], to_csv: orders_20250120.csv } ] }执行器拿到这个 JSON 后会逐步执行并验证每一步的前提条件。如果某一步失败比如定位器找不到元素执行器会把当前页面的 DOM 快照和报错信息返回给大模型让它修正后续步骤。这个“执行 - 回读 - 修正”的循环就是 AI 浏览器代理工具和被动的录制回放工具之间最大的分水岭。2.4 大模型选型方面的实践经验模型层我建议用两种方案对外服务型任务用 API 方式的高上下文模型胜在稳定、函数调用能力强内部数据敏感的任务用本地部署的开源模型配合 Ollama 或者 vLLM 跑保证数据不出内网。实际体验下来小模型的“指令遵循”能力是瓶颈。让它生成一个 JSON 动作序列它经常会把字段名编错、把 CSS 选择器格式写错。我的经验是不要直接上大模型先给一个 few-shot 示例库内置十几条常见动作的 JSON 模板模型照着填参。这样哪怕模型水平一般输出格式也不会跑偏。还有一招更实用把页面的可访问性树Accessibility Tree抓下来作为上下文输入给模型中文网页里很多按钮文本、输入框标签都能从可访问性树拿到这比让模型猜选择器靠谱得多。3. 从零搭建一套能跑的 AI 浏览器代理工具3.1 环境准备清单先说明这套工具跑在 Linux 或 Windows 都行推荐用 Python 3.10 以上版本Node.js 作为辅助。基础依赖如下# 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装核心依赖 pip install playwright pytest pytest-playwright langchain openai pip install pandas allure-pytest requests pyyaml # 安装浏览器内核 playwright install chromium这里有个容易忽略的细节playwright install chromium只是装了 Chromium如果需要模拟更多浏览器环境可以用playwright install msedge装 Edge 内核。在 Linux 服务器上跑还需要安装系统级依赖执行playwright install-deps可以一口气装好。3.2 推荐的项目目录结构我用得比较顺手的结构是这样agent-browser/ ├── agent/ │ ├── planner.py # 大模型规划任务描述 - JSON 步骤序列 │ ├── executor.py # 执行器JSON - Playwright 调用 │ └── fixer.py # 失败回读与自动修正 ├── browser/ │ ├── operator.py # Playwright 封装goto/fill/click/extract │ └── context.py # 浏览器上下文管理登录态复用 ├── tasks/ │ ├── order_fetch.py # 电商订单抓取任务 │ ├── health_check.py # 系统健康巡检任务 │ └── ui_test_cases.py # 对应 pytest 用例 ├── config/ │ ├── settings.yaml # 全局配置超时、重试次数、模型参数 │ └── selectors.yaml # 兜底选择器AI 定位失败时备用 ├── reports/ # Allure 结果与截图输出目录 └── tests/ └── conftest.py # pytest fixture 定义这个结构把“Agent”“浏览器操作”“任务定义”“配置”四层拆开。好处是AI 规划层只管生成动作序列浏览器操作层只管执行动作任务定义层负责聚合业务逻辑配置层统一管环境差异。任何人接手时不用看一遍 AI 的 prompt 就能快速定位问题。3.3 核心代码骨架调度器和操作器先写一个最基础的浏览器操作器。它封装 Playwright 的常见操作并支持把页面关键信息回传给 Agent# browser/operator.py from playwright.sync_api import sync_playwright class BrowserOperator: def __init__(self, headlessTrue, **kwargs): self._playwright sync_playwright().start() self.browser self._playwright.chromium.launch( headlessheadless, args[--disable-blink-featuresAutomationControlled], ) self.context self.browser.new_context( viewport{width: 1280, height: 720}, localezh-CN, ) self.page self.context.new_page() def act(self, step: dict): action step[action] if action goto: self.page.goto(step[url], wait_untilnetworkidle) elif action fill: self.page.fill(step[selector], step[value]) elif action click: self.page.click(step[selector]) elif action extract_table: rows self.page.locator(step[selector]).all_inner_texts() return {rows: rows} return {ok: True} def snapshot(self): # 返回可访问性树快照供大模型理解当前页面 return self.page.accessibility.snapshot() def close(self): self.browser.close() self._playwright.stop()注意我用的是 sync API适合大多数内部自动化脚本。如果要做高并发建议换成 async API事件驱动模型效率更高。然后是 Agent 的规划器。这个模块负责把自然语言任务交给大模型拿到结构化的动作序列# agent/planner.py from langchain.prompts import FewShotPromptTemplate, PromptTemplate from langchain.chat_models import ChatOpenAI class AgentPlanner: def __init__(self, api_key, base_url, model_name): self.llm ChatOpenAI( api_keyapi_key, base_urlbase_url, modelmodel_name, temperature0.1, ) # few-shot 示例从 config 里加载保证输出格式稳定 self.examples load_few_shot_examples() self.prompt FewShotPromptTemplate(...) def plan(self, task_description: str, page_snapshot: dict None) - list[dict]: prompt_text self.prompt.format( tasktask_description, snapshotpage_snapshot if page_snapshot else 无, ) response self.llm.invoke(prompt_text) return json.loads(response.content)[steps]第一次跑通这个循环你会明显感觉到自然语言任务的容错性强了很多。“把页面上所有订单金额加总”这种模糊描述模型会自己去表格里找金额列并求和而不是傻等某个固定选择器。3.4 完整案例跨境电商多平台订单抓取这是我朋友的真实场景。他每天要在三个电商平台后台导出当天订单再合并成一个表发到运营群。过去靠人肉复制偶尔漏单。用 AI 浏览器代理后整个流程大概是这样的任务描述只需一句话“登录三个卖家后台分别抓取今天之前的 24 小时订单输出到一个合并 Excel发到指定目录。”执行过程分几步第一步登录。三个平台的登录方式不同一个扫码、一个短信验证码、一个账密登录。我把三个登录流程都封装成独立的“登录算子”放入任务模板。AI 在规划时识别到“登录”这个意图会直接挂载对应的登录算子而不需要每次都在 prompt 里描述登录细节。第二步抓取。进入订单列表页后AI 会读取表格的可访问性树自动识别表头字段。如果页面表格没有标准表头比如某些平台是卡片式布局执行器会自动切到文本提取和正则匹配兜底。第三步汇总。三个平台抓下来的原始数据都落成 DataFrame统一字段名然后按订单号去重、合并金额输出到一个 Excel 工作簿。关键代码如下# tasks/order_fetch.py import pandas as pd from agent.planner import AgentPlanner from browser.operator import BrowserOperator def fetch_orders(platform_config, cookie_dir): op BrowserOperator(headlessTrue) planner AgentPlanner(...) task ( 进入订单管理页面筛选最近24小时订单 提取订单号、商品名称、实付金额、订单状态 翻页直到没有更多数据 ) steps planner.plan(task, page_snapshotop.snapshot()) records [] for step in steps: result op.act(step) if step[action] extract_table: records.extend(parse_table(result[rows])) df pd.DataFrame(records) df.to_csv(foutputs/{platform_config[name]}_orders.csv, indexFalse) op.close() return df这里最核心的经验是固定的页面跳转规则比如筛选条件的选择器不要完全交给 AI 去猜这些适合写死在模板里。AI 负责的是“动态部分”识别当前页面有没有弹窗、要不要翻页、表格列顺序变了怎么自适应。把静态与动态分层执行成功率会大幅提升。我踩过太多“全交给 AI”导致定位器乱写的坑经验就是AI 做决策规则做底座两者结合才稳定。3.5 Agent-Browser 接入自动化测试组件的配置细节很多人拿到这类工具后最关心的是“怎么把 Agent-Browser 接到现有测试体系里”。我的建议是不要让 Agent 直接驱动 pytest 的 use case而是让 Agent 生成步骤结果再由 pytest 调用执行器来完成断言。在 config/settings.yaml 里我这样配browser: headless: true viewport_width: 1280 viewport_height: 720 timeout_ms: 30000 agent: model_name: qwen2.5:14b temperature: 0.2 max_retry: 3 test: base_env: staging parallel_workers: 4 screenshot_on_failure: true trace_on_failure: truepytest 那边的 conftest.py 定义一个全局 fixture让每条用例都能用到同一个浏览器操作器# tests/conftest.py import pytest from browser.operator import BrowserOperator from config.config_loader import load_settings pytest.fixture(scopesession) def operator(): settings load_settings() op BrowserOperator( headlesssettings[browser][headless], timeout_mssettings[browser][timeout_ms], ) yield op op.close() pytest.fixture() def page(operator): context operator.browser.new_context() yield context.new_page() context.close()这样跑 pytest 时UI 自动化、接口自动化、数据抓取三种用例可以共用一个底层浏览器操作器而断言逻辑则由 pytest 的 assert 来承接。整体框架的可维护性立刻上了一个台阶。4. 自动化能力的三个落地场景UI 测试、接口测试、运维联动4.1 UI 自动化测试从手工选择器到语义生成用例UI 自动化里最烦的就是选择器维护。我的做法是让 AI 生成语义化定位策略同时在关键路径上保留手动校验过的备用选择器。打个比方以前写用例是“请点一下 id 为 submit-btn 的按钮”现在写用例是“请完成表单提交”。模型会根据当前页面的可访问性树找到“提交”按钮哪怕它的 id 从 submit-btn 改成了 submit_button模型依然能认出来。具体到一个用例def test_login_and_create_order(operator, page): # 用自然语言定义步骤由 Agent 生成具体操作 steps planner.plan( 登录测试账号创建一个金额为 99 元的测试订单提交后确认成功提示出现 ) for step in steps: operator.act(step) # 断言交给 pytest 管 success_text page.locator(text订单提交成功) assert success_text.is_visible(), 预期成功提示未出现这套用法的好处是业务人员也能看懂用例在干嘛测试同学则可以把精力放到断言和边界条件设计上。4.2 接口自动化自动切换环境的关键细节接口自动化和浏览器自动化经常要混跑。很多团队都有多套环境dev、test、staging、prod测试代码最怕的是把请求打到错误环境。结合 AI 浏览器代理工具我的方案是浏览器会话自动携带当前环境的基础 URL执行器在建构中间指令时会自动把__BASE_URL__替换成当前环境地址。环境切换用 pytest 的--env参数动态注入而不是写死在代码里。登录态从浏览器上下文自动导出作为 requests 的 Cookie 和 Authorization 头接口测试和 UI 测试天然共用一套身份。核心代码如下# tests/conftest.py 增加环境切换逻辑 def pytest_addoption(parser): parser.addoption(--env, actionstore, defaulttest, help运行环境: dev/test/staging/prod) pytest.fixture(scopesession) def env(request): return request.config.getoption(--env) pytest.fixture(scopesession) def base_url(env): return get_env_config(env)[base_url] pytest.fixture(scopesession) def api_headers(env, operator): token operator.extract_token_from_cookie(env_config[env][login_url]) return {Authorization: fBearer {token}}调用时pytest --envstaging tests/test_order_api.py pytest --envdev tests/test_order_api.py这个方案彻底解决了“环境配置分散、切换时容易忘改地址”的痛点。我实际用下来团队里测试人员跑错环境的概率降到了零因为环境信息只由命令行参数维护而不是散布在用例里。4.3 自动化运维无人值守的浏览器巡检与系统健康检查自动化运维场景里AI 浏览器代理工具最亮眼的用途是浏览器巡检。传统运维只能监控服务器指标CPU、内存、端口但业务系统的“真实可用性”必须通过浏览器端到端操作才能验证。我的做法是用 Ansible 批量执行环境部署和启动任务确保被测系统已经更新到最新版本然后 Jenkins 定时触发 AI 浏览器代理巡检脚本模拟关键用户路径登录、查询、提交、登出最后把检查结果和失败截图推送到内部 IM。这个链路完全无人值守比单纯 ping 一个端口要可靠得多。Jenkins Pipeline 的一个简化示例pipeline { agent any stages { stage(Deploy) { steps { sh ansible-playbook deploy_playbook.yml -i inventories/test } } stage(UI Health Check) { steps { sh source .venv/bin/activate pytest tests/test_health_check.py --envstaging --alluredirreports } } stage(Archive Reports) { steps { allure generate reports -o allure-report --clean } } } }有人会担心这类“AI 自动操作浏览器”会不会被安全机制拦截。我的经验是对内部系统做巡检没有这个问题因为本来就有业务账号和操作权限工具只是替代键盘鼠标。如果是对外部公开页面做数据巡检一定要控制频次、控制抓取范围并且只拿公开可见的数据。自动化能力本身是中性工具使用边界由场景定义这句话值得写进每一个自动化项目的 README。5. 常见问题与排查技巧实录5.1 AI 生成的脚本为什么跑一次就挂这是初用者遇到最多的一个问题。AI 第一次规划出的动作序列跑通了第二次页面只要有一点变化比如多了一个广告弹窗、按钮文案改了后续步骤全崩。我的排查思路分三步。首先看 trace 记录确认崩在哪一步。绝大多数是元素定位失败。其次把失败那一步的页面可访问性树重新喂给大模型让它重新生成后续步骤而不是从头跑。最后在任务模板里为关键动作增加“兜底分支”比如检测到弹窗就关闭再继续原计划。这个“失败归因 局部重规划”的机制现在基本能把脚本的一次通过率从 50% 提到 85% 以上。5.2 元素定位不稳定与“锁住/未锁住”问题的排查在浏览器自动化项目里我经常听到“页面锁住了”“元素未锁住”这种描述其实对应的是两类实际问题。一类是浏览器上下文锁Playwright 同一个 page 对象同时被多个协程操作时会报错表现为操作互相打断。排查时看日志里有没有“Target closed”或“Execution context was destroyed”如果有基本就是并发访问同一个页面导致的。另一类是登录态锁电商后台通常会把登录状态绑定到当前浏览器指纹和 IP换一个上下文重新执行时Cookie 带过去了但指纹变了被判定为登录失效。这类问题在“多平台订单抓取”这种需要切换多个账号的场景特别常见。我的处理方式是给每个平台、每个账号单独建一个持久化上下文目录存独立的 Cookie 和本地存储运行时用browser.new_context(storage_state...)加载。这样“锁住”和“未锁住”的会话边界就非常清晰了。5.3 无头模式下的风控与验证码AI 浏览器代理工具默认跑无头浏览器这很容易触发网站的风控策略常见表现是出现滑块验证、短信验证拦截提示。我的建议是分场景处理如果是内部业务系统巡检尽量用有头模式跑在测试机上配合固定的测试账号。如果是抓取外部公开数据不要绕验证码更不要搞破解直接优化抓取策略降低频率、增加随机延迟、只取必要字段。如果必须用无头模式可以给 Chromium 加禁用自动化特征参数再配合真实用户代理实测能减少一部分风控误判但这不是永久的解法。遇到滑块验证我的原则是该人工处理就人工处理不要在这种地方消耗工程资源。自动化工具最大的价值是替代重复劳动而不是与安全机制做猫鼠游戏。5.4 并行执行与会话隔离最后说并行。AI 浏览器代理工具可以同时开多个浏览器上下文跑不同任务但有两个坑第一资源消耗。每个 Chromium 实例内存占用至少 300MB我建议用进程池限制并发数。在我的配置里默认 4 个 worker 算比较稳的。第二任务隔离。不同任务的 Cookie、Download 文件目录、截图目录必须分开否则会出现“A 任务截图被 B 任务覆盖”这种诡异问题。解决办法很简单每个任务初始化时都建一个独立输出目录并把任务 id 作为目录名的一部分。附一张快速排查表方便直接对照现象可能原因解决方案元素点击无响应页面弹窗遮挡 or 元素未加载完全检查 trace换语义定位增加弹窗关闭兜底登录状态频繁失效浏览器上下文未持久化使用 storage_state 持久化登录态多任务并发互相干扰输出目录或上下文共用每个任务独立目录、独立 context执行速度越来越慢上下文未关闭内存堆积任务结束后强制 close并做资源监控模型生成 JSON 格式错误缺少 few-shot 示例在 prompt 中加入模板示范和 schema 校验最后分享一点个人体会我自己跑下来的体会是AI 浏览器代理工具最擅长的是那些“流程清晰、目标明确、但页面细节反复变化”的重复劳动。它把原先需要懂前端、懂测试框架、懂脚本维护的人才能干的活压缩成了“用自然语言描述任务 定时审阅执行结果”门槛低了一大截。但这并不意味着它不需要工程能力——恰恰相反真正让工具稳定跑起来的核心还是分层架构、中间 JSON、失败回读和上下文隔离这些实打实的工程细节。自动化能力的本质从来都不是“让机器替代人”而是“让人把有限的精力放在最关键的选择和判断上”。这套工具就是朝这个方向走得很远的一个底座。