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 就该被淘汰。它的稳定性和可预测性依然不可替代，尤其是核心业务回归测试、金融类项目这种“一次都不许错”的场景，我反而会坚持用 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[name='account']" }, { "action": "fill", "selector": "input[name='account']", "value": "__USER_ACCOUNT__" }, { "action": "click", "selector": "button[type='submit']", "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, headless=True, **kwargs): self._playwright = sync_playwright().start() self.browser = self._playwright.chromium.launch( headless=headless, args=["--disable-blink-features=AutomationControlled"], ) self.context = self.browser.new_context( viewport={"width": 1280, "height": 720}, locale="zh-CN", ) self.page = self.context.new_page() def act(self, step: dict): action = step["action"] if action == "goto": self.page.goto(step["url"], wait_until="networkidle") 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_key=api_key, base_url=base_url, model=model_name, temperature=0.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( task=task_description, snapshot=page_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(headless=True) planner = AgentPlanner(...) task = ( "进入订单管理页面，筛选最近24小时订单，" "提取订单号、商品名称、实付金额、订单状态，" "翻页直到没有更多数据" ) steps = planner.plan(task, page_snapshot=op.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(f"outputs/{platform_config['name']}_orders.csv", index=False) 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: true

pytest 那边的 conftest.py 定义一个全局 fixture，让每条用例都能用到同一个浏览器操作器：

# tests/conftest.py import pytest from browser.operator import BrowserOperator from config.config_loader import load_settings @pytest.fixture(scope="session") def operator(): settings = load_settings() op = BrowserOperator( headless=settings["browser"]["headless"], timeout_ms=settings["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", action="store", default="test", help="运行环境: dev/test/staging/prod") @pytest.fixture(scope="session") def env(request): return request.config.getoption("--env") @pytest.fixture(scope="session") def base_url(env): return get_env_config(env)["base_url"] @pytest.fixture(scope="session") def api_headers(env, operator): token = operator.extract_token_from_cookie(env_config[env]["login_url"]) return {"Authorization": f"Bearer {token}"}

调用时：

pytest --env=staging tests/test_order_api.py pytest --env=dev 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 --env=staging --alluredir=reports' } } 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 作为目录名的一部分。

附一张快速排查表，方便直接对照：

最后分享一点个人体会

我自己跑下来的体会是：AI 浏览器代理工具最擅长的，是那些“流程清晰、目标明确、但页面细节反复变化”的重复劳动。它把原先需要懂前端、懂测试框架、懂脚本维护的人才能干的活，压缩成了“用自然语言描述任务 + 定时审阅执行结果”，门槛低了一大截。但这并不意味着它不需要工程能力——恰恰相反，真正让工具稳定跑起来的核心，还是分层架构、中间 JSON、失败回读和上下文隔离这些实打实的工程细节。自动化能力的本质从来都不是“让机器替代人”，而是“让人把有限的精力放在最关键的选择和判断上”。这套工具就是朝这个方向走得很远的一个底座。