浏览器自动化工具的复兴：从 Selenium 到 AI Agent

浏览器自动化是个老生常谈的话题，但 2025 年它正在经历一次有趣的复兴。

传统工具的困境

Selenium、Puppeteer、Playwright——这些工具我们已经用了十几年。它们的核心能力始终如一：程序化地控制浏览器。

这套模式在测试场景下工作良好：你写下明确的步骤，“点击这个按钮”、“填写那个表单”、“验证页面出现某段文字”。但面对真实世界的复杂网页时，传统工具开始显得笨拙。

问题在于：网页是不稳定的。DOM 结构会变，CSS 选择器会失效，广告和弹窗会随机出现。维护一套健壮的自动化脚本往往比写它本身更耗时。

大语言模型的出现改变了这个领域的玩法。新一代工具不再只依赖 DOM 操作，而是让 AI 直接”看懂”网页。

Playwright + LLM 的组合正在成为主流范式。你可以给 AI 一个高阶指令——“在 GitHub 上搜索我的名字，找到我 star 最多的项目”——AI 会自己理解页面结构、定位搜索框、解析结果，而不是执行硬编码的点击序列。

这种范式的优势在于容错性。即使 GitHub 改版了，只要页面上还有搜索功能，AI 大概率能找到它。它不再依赖具体的 DOM 路径，而是依赖对页面语义的理解。

这类工具专注于让 AI 能方便地操作浏览器。Playwright 和 Puppeteer 依然是底层基础设施，但上层封装变得更智能化。

典型特征：

一些工具开始直接提供”测试 Agent”——你描述想测试什么，AI 自己生成测试步骤、执行验证、报告结果。

这比传统测试框架更灵活，但也带来了不确定性：同样的描述，两次运行可能走不同的路径。这对追求可重复性的测试场景既是机遇也是挑战。

浏览器自动化最常见的用途之一是数据采集。AI Agent 让这个场景更强大：它可以处理复杂的分页、登录态保持、反爬策略识别。

不再是”抓取第3个 div 里的文本”，而是”找到页面上所有价格信息”——AI 会自己判断什么元素包含价格。

对于想在自己项目中引入 AI 浏览器自动化的开发者，关键决策点包括：

页面表示方式：给 LLM 看原始 HTML？清理后的文本？截图？不同方式各有利弊。文本方式 token 开销小但丢失视觉信息，截图方式保留完整视觉但成本高。

操作粒度：是让 AI 输出具体的点击坐标，还是输出高阶意图（“点击登录按钮”）由框架解析？后者更鲁棒，但需要框架维护元素识别逻辑。

人机协作边界：完全自动还是保留人工确认点？涉及敏感操作（如支付、删除数据）时，人工介入仍然是必要的。

AI 浏览器自动化并非万能药。

成本问题：每次操作都需要调用 LLM，成本远高于传统脚本。高频自动化场景（如每分钟检查一次页面状态）可能不划算。

延迟问题：LLM 推理需要时间，交互响应比原生脚本慢一个数量级。

可靠性问题：AI 的”创造性”在某些场景是优势，在另一些场景是隐患。关键业务流程可能仍需要确定性的传统脚本。

浏览器自动化正在从脚本驱动向意图驱动演进。

短期内，两者会并存：AI Agent 负责探索性、复杂、变化频繁的流程；传统脚本负责高频、确定、性能敏感的操作。

长期看，随着模型成本下降和响应速度提升，AI 驱动的方案会占据更大份额。但在那之前，混合架构可能是最务实的选择。

对于开发者来说，值得花点时间了解这个领域的新进展——它可能在不久的将来改变你写测试、采集数据、甚至构建产品的方式。

文章发表于 gumi.ink