Browser Agent 数据提取与表单填写实战：从 LLM 视觉到 DOM 选择器

Browser Agent 是 2025 年企业落地最密集的 Agent 类型之一。两个高频场景——从网页批量抽取结构化数据和自动填写表单提交——占了 80% 的实际需求。本文系统讲解这两类任务的工程实践。

一、两类任务的本质差异

维度	数据提取	表单填写
操作方向	读（read-only）	写（write）
错误代价	低（错了不提交）	高（填错就提交）
速度要求	批量化（每秒多页）	串行（必须等前一步完成）
容错需求	中（可重试）	高（必须验证）
成功率	95%+ 可接受	必须 99%+
反爬对抗	中	高

关键区别：数据提取是只读的、可批量的；表单填写是写的、有副作用的。表单填错的代价包括重复扣款、错误下单、垃圾数据、合规风险。所以表单 Agent 必须有"撤回"和"人工确认"机制，而数据提取可以无人值守。

二、三种动作定位策略

策略 1：纯视觉 LLM

最早的范式，把整张页面截图发给 GPT-4o / Claude / Gemini，让模型直接输出坐标。优点是无需解析 DOM，对前端技术栈无要求；缺点是坐标精度差（±10-20 像素）、延迟高（1-3 秒）、成本高（每张截图 1000+ tokens）。

策略 2：DOM 选择器

把页面的 accessibility tree / DOM tree 提取出来，序列化为文本，让 LLM 输出 CSS/XPath 选择器。优点是精度高、速度快（< 500ms）、成本低（500-2000 tokens）、可解释；缺点是 DOM 噪音大、Shadow DOM 难处理、iframe 嵌套、动态 class。

关键优化：用 accessibility tree 代替 raw DOM——浏览器原生提取的 ARIA 树只包含语义元素，节点数通常只有 raw DOM 的 5%-10%。这是 Browser-Use、Stagehand、MCP Playwright 的核心做法。

策略 3：混合坐标

先用 DOM 提取候选元素列表，再用视觉 LLM 在缩小后的截图上做最后确认。优点是精度高、速度快、抗遮挡；缺点是实现复杂。

三种策略对比

维度	视觉 LLM	DOM 选择器	混合坐标
精度	中	高	高
速度	中	高	中
成本	中	高	中
实现难度	简单	中等	复杂
抗样式变化	高	中	中
反爬对抗	中	高	中
适用页面	极简/老旧	现代 SPA	复杂混合

经验法则：90% 的现代 Web 应用 → DOM 选择器；反爬严格的页面 → 视觉 LLM；精度要求极高的任务 → 混合坐标。

三、数据提取实战

案例 1：批量抓取电商商品列表

假设需要从某电商平台抓取 1000 个商品的标题、价格、月销量。关键优化点：滚动加载触发（电商用 IntersectionObserver，Agent 必须模拟滚动到底才能加载完所有 DOM）、分页 vs 无限滚动（淘宝/京东/小红书都是无限滚动）、数据校验（"￥99.00 起"必须解析成数字）、去重。

案例 2：抽取新闻文章

使用 Stagehand + DOM 提取：访问文章页，调用 page.extract 接口，传入 instruction 和 schema，提取标题、作者、发布时间、正文。

四、表单填写实战

案例 3：自动注册账号

Agent 任务描述包括：在邮箱输入框输入 email，在用户名输入框输入 username，在密码输入框输入密码，点击"我同意条款"复选框，点击"注册"按钮，等待页面跳转，截图确认注册成功。关键：表单操作前必须有二次确认，等待服务器返回再进入下一步。

案例 4：自动化办公填报

假设企业要给员工批量提交一份月报表（Excel + 浏览器表单混合）。直接用 Playwright 操作，跳过 LLM——LLM 表单填写失败率高（5-15%），纯 Playwright 是 0%。每个 submit 后必须 wait_for_selector——表单提交涉及异步网络，必须等服务器返回再提交下一个。

关键经验：能用纯 Playwright 就不要用 LLM；每个 submit 后必须 wait_for_selector；失败重试 + 跳过策略；敏感操作必须人工审批。

五、四大框架横评

Browser-Use

Browser-Use 是 2024 年最受欢迎的 Python 框架（30k+ stars）。优势：纯 DOM 路线、最快、最便宜。劣势：对 iframe 嵌套支持较弱；不支持视觉回退；复杂页面需要精细 prompt。

Stagehand（by Browserbase）

Stagehand 是 Browserbase 推出的 TypeScript 框架，强调代码 + AI 混合。优势：代码/AI 混合切换、TypeScript 类型友好、有云端 Browserbase 浏览器托管。劣势：云端版本收费。

Playwright MCP（by Microsoft）

Playwright MCP 是微软官方推出的 MCP Server，把 Playwright 暴露为 MCP 工具。优势：与 Claude/Cursor 深度集成、原生支持多 Tab、微软官方维护。劣势：受限于 LLM 客户端（Claude Desktop / Cursor），不能直接用于生产后端。

Skyvern

Skyvern 用视觉 LLM + 计算机视觉做浏览器自动化，目标是"无 API 也能自动化"。优势：纯视觉路线，对老旧/无法访问 DOM 的系统有效。劣势：成本高、速度慢。

框架对比

维度	Browser-Use	Stagehand	Playwright MCP	Skyvern
路线	DOM	DOM + Code	DOM	Vision
语言	Python	TypeScript	MCP（任意）	Python/Cloud
速度	高	高	中	低
成本	高	中	中	低
易用性	高	高	高	中
生产级	中	高	中	高
反爬对抗	中	中	中	高

六、反爬与生产部署

反爬对抗

企业级 Browser Agent 必须处理反爬：headless=False 通过率更高；user_agent、locale、timezone、proxy 配置；disable-blink-features=AutomationControlled 去掉 webdriver 标识。

生产部署架构

API 层接收任务分配 Browser 实例；调度层用 Redis 队列 + 优先级 + 失败重试；执行层是 Browser-Use worker pool + 浏览器隔离；浏览器池是本地 Playwright 或 Browserbase 云端。

关键架构原则：浏览器隔离（每个任务独立 BrowserContext）、资源回收（任务结束必须 close page）、限流（同一域名 QPS ≤ 2）、失败重试（指数退避，最多 3 次）、日志全链路（每次 action 截图 + DOM snapshot）。

七、常见陷阱

1. 所有按钮都用 LLM 找：登录、提交、确定——这些按钮的 selector 是固定的，永远用 CSS 选择器。
2. 不验证就提交：表单填写后必须等待服务器返回，截图确认。
3. headless = 默认：反爬严格的站点必须 headless=False + 反检测参数。
4. iframe 是黑盒：跨 iframe 操作前必须先 switch_to_frame。
5. 验证码识别绕过：验证码本质是反自动化，绕过涉及法律风险。

八、选型建议

• 企业内部工具 / 研发自用：Browser-Use
• SaaS 产品集成：Stagehand
• AI 客户端（Claude/Cursor）：Playwright MCP
• 政府/金融老系统：Skyvern
• 数据批量采集：自研 Browser-Use + 代理池 + 限流

最后一句话：Browser Agent 的成功率 70% 来自 prompt 工程，30% 来自框架选择。