LLM Agent vs 传统浏览器自动化：实测对比与选型指南

上个月我被一个大模型 Agent 项目整得想骂人。需求其实不复杂：让 AI 自己打开某个公开网站，定时抓取价格，再填一个查询表单，把结果整理成表格发到群里。我一开始理所当然选了 LLM Agent 路线，毕竟让大模型“看懂页面、自己操作”听起来才是未来。结果半个多月下来，速度慢、成本高、动不动就被一个弹窗卡死，最离谱的是页面改了一个 CSS 类名，Agent 直接原地崩溃，完全不知道该怎么办。

被逼到墙角之后，我回头老老实实测了一圈浏览器自动化工具：Playwright、Selenium、AutoFlow，甚至把安卓平板上的移动端自动化也翻出来试了一遍。测完最大的感触是：在 LLM Agent 被吹上天的这两年，传统浏览器自动化这条“笨路”不仅没死，反而在很多生产级场景里更可靠、更便宜、更可控。这期就聊聊我的实测过程和踩坑记录，给同样在 LLM Agent 和自动化脚本之间纠结的朋友一个参考。

1. 先聊聊我为什么从 LLM Agent “叛逃”回自动化脚本

1.1 我的原始需求：让 AI 自己去网站上填表单、查信息

我手上的任务其实相当典型：公司想监控一批竞品公开页面的价格变化，每天自动去这几个网站查询、截图、把关键数据抓回来。最开始我的设想特别“先进”——用大模型 Agent 直接操作浏览器，它能理解网页语义，遇到弹窗就自己关，遇到结构变化就自己调整策略，听起来几乎不需要维护。

于是我搭了一个最简单的 LLM Agent 流程：大模型作为“大脑”，浏览器作为一个工具，Agent 决定下一步点击哪个元素、输入什么内容。架构上很漂亮，大模型看页面截图或者 DOM 结构，输出动作序列，然后由浏览器工具执行。跑 Demo 的时候确实惊艳，GitHub 上那些演示视频不是假的，给大模型一个自然语言指令，它真的能自己去完成“搜索→筛选→抓取”这种多步任务。

但 Demo 和真实项目之间，隔着一条我低估了的鸿沟。

1.2 LLM Agent 踩到的三个真实痛点：速度、成本、幻觉

第一个痛点是速度。大模型每做一次决策，要先把页面信息传给它，它思考，再输出动作。看起来每次决策只需要几秒钟，但一个稍微复杂的流程有二十几步操作，累积起来常常要几分钟。我拿一个简单的“登录→进入商品列表页→选择价格区间→抓取前十个商品名”流程做了统计，纯 LLM Agent 平均耗时 3 分 25 秒，其中大部分时间消耗在“看页面”和“思考”上，真正执行动作反而是毫秒级的。

第二个痛点是成本。这里的成本不只是 API 费用，还有上下文窗口的消耗。大模型要理解一个现代网页，光 DOM 或截图就很占 token，如果页面里有大量图片、JS 动态插入的节点，一次请求轻松烧掉几千甚至上万 token。一次成功的任务可能 trial and error 好几次，一个月的成本足够买一台不错的云服务器。

第三个痛点是幻觉和“迷之自信”。最典型的表现是：大模型明明没有找到“登录按钮”，但它会认为自己找到了，然后输出一个不存在的坐标或选择器；又或者页面已经跳转到了“密码错误”提示页，它还坚持下一步是“点击查询”。当 Agent 陷入这种状态，你几乎无法通过参数调优解决，只能人工介入，这就完全失去了自动化的意义。

1.3 促发我写这篇测试的瞬间：一个 CSS 类名改版，让 Agent 原地崩溃

真正让我决定换赛道的是一次改版事故。那天早上接到测试反馈，说自动化任务全部失败。我打开日志一看，原来是网站前端把商品卡片的class="product-title"改成了class="product-name highlight"。放在传统自动化里，这就是改一行选择器的事；但放在 LLM Agent 里，我本以为它具备语义理解能力，应该能轻松跨过这种改动，结果它没有。

大模型对着新的 DOM 结构看了半天，开始反复点击页面左上角的 logo，然后断言“商品标题的 CSS 选择器是.product-title a”——这个选择器在改版后的页面上根本匹配不到任何元素。它甚至没有尝试去推理“product-name”和“product-title”在语义上是一样的，也没有去检查页面实际渲染结果。那种感觉就像面试时遇到一个简历写得很漂亮的人，上手干活才发现他只会背题，不会解决新问题。

这次事故之后，我去翻了传统浏览器自动化工具的资料，发现我过去一年多被“LLM 万能论”带偏了。传统工具的定位不是“智能”，而是“确定性”：只要页面结构稳定，它就能精确执行，速度快、成本低、可测试、可审计。这恰恰是生产环境最需要的东西。

2. 浏览器自动化工具的底层逻辑：驱动、选择器和状态机

2.1 从驱动配置看“浏览器自动化”到底是什么

很多人一提浏览器自动化，第一反应是“就是用脚本控制浏览器”，但真正上手才发现，控制之前要先解决“驱动”问题。以 Selenium 为例，你要用 Chrome 浏览器自动化，就必须下载一个和浏览器版本完全匹配的chromedriver，这个可执行文件相当于一个桥接层：脚本发指令给 chromedriver，driver 再用 Chrome DevTools 协议去操作真实浏览器。

这个“版本必须匹配”的规则，是所有新手跨不过去的第一道坎。我见过太多人把 Chrome 升级到最新版，结果chromedriver还是旧的，启动脚本立刻报session not created或This version of ChromeDriver only supports Chrome version xx。解决办法不是粗暴地找个新版 driver 替换，而是搞清楚你的浏览器主版本号，去下载对应的大版本驱动。以 Chrome 为例，驱动版本的前三位要和浏览器版本完全一致，比如浏览器是 129.0.6668.89，驱动最好也是 129.0.xxxx.x。

Playwright 会选择性地绕开这个坑，它提供了npx playwright install命令自动下载匹配的浏览器和驱动，默认还会用补丁版本的 Chromium。这种“自带运行时”的设计，让我第一次体验到了“零配置”的快乐。但便宜不是白占的，如果你需要操作系统里已经安装的那个 Chrome（比如要保留用户的登录态），Playwright 也可以连接真实浏览器，这时候同样需要手动指定executablePath，版本匹配问题又回来了。

2.2 选择器不是玄学，是把页面结构翻译成可匹配的模式

驱动配置好之后，自动化脚本的核心工作就是“定位元素”。这段经历彻底改变了我对“智能”的理解。传统自动化工具的定位方式看起来很简单：通过 CSS 选择器、XPath、文本内容或者 ARIA 属性去匹配页面上的元素。但真正高效的做法，不是随便复制一个浏览器里生成的 XPath，而是要理解页面结构的语义层级。

我用一个具体例子说明。假设要抓取商品价格，最常见的 CSS 选择器是.product-card .price，XPath 可以是//*[contains(@class,'price')]。这两种写法在页面稳定时都有效。但问题是，现代前端项目经常带后缀哈希或者动态类名，比如price_12345，如果你写死了类名，任何一次前端构建都可能让脚本失效。

我的经验是“优先语义结构”而不是“优先视觉位置”。例如不要用#main > div:nth-child(3) > div > span这种绝对路径，因为只要上层加了一个 div，整个表达式就废了；而改用//span[contains(@class,'price')]或者[data-testid="product-price"]这种更接近业务含义的定位方式。Playwright 在这方面做得更现代，它推荐getByRole、getByText、getByTestId，这些 API 让我觉得像是给页面元素打了“语义标签”，本质上是把测试思维引入自动化。

2.3 为什么 AutoFlow 这类移动端自动化工具会让我意外？

测试完桌面端，我又关注到移动端的浏览器自动化。手头刚好有一台安卓平板，就试了热搜里提到的 AutoFlow。这个工具最特别的一点是：没有独立的网页官网，官方/社区主要在网盘或直链分享里提供 APK 下载，所以很多新手第一反应是不敢装，怀疑是病毒。我实测下来的感受是——成也直链，败也直链。直链让工具避开了复杂的上架审核，也省了服务器费用，但“没有官网”这件事给用户带来了巨大的信任成本。

但在平板浏览器里用下来，AutoFlow 给了我一个很意外的启发：它把“选择器”这个概念简化成了“屏幕坐标 + 文字/图标匹配”。在安卓上做自动化，通常要借助无障碍服务权限，AutoFlow 就像一个轻量版 RPA，你可以录制一组操作，也可以写流程脚本，点击、长按、输入、滑动、全局断言都能做。对于平板浏览器里那些 H5 页面，我可以用它循环读取某个动态数据区域，这种能力在纯桌面自动化工具里反而不太好实现。

我当时的项目是需要在平板上自动打开某个网页版工具，每周点一遍所有菜单，收集各页面的加载时间。用 AutoFlow 配置了一个点击流程，跑了三天，成功率很高，只在平板休眠唤醒后因为权限弹窗卡住过一次。这让我意识到，浏览器自动化的“另一条路”，其实不只是在桌面 Web 里打转，移动端浏览器的自动化同样是拼图的重要一块。

3. 实操对比：我用自己的小任务跑了三种方案

3.1 任务设定：在某个公开商品页抓价格、自动登录并筛选

为了让测试有说服力，我设计了一个不涉及任何敏感数据的标准任务：打开一个公开的演示电商网站，登录测试账号，进入“数码产品”分类，按价格从低到高排序，抓取第一页全部商品名称和价格，输出 JSON。整个流程总共 8 步：打开首页 → 点击登录 → 输入账号密码 → 确认登录 → 点击分类入口 → 选择排序 → 等待列表加载 → 提取数据。

这个任务复杂度适中，既能体现 LLM Agent 的“语义理解”，也能体现传统脚本的“确定性执行”，对比起来比较公平。

3.2 方案 A：纯 LLM Agent（GPT-4o + 浏览器工具）的表现

方案 A 我用了 GPT-4o 配合一套开源的浏览器操作框架。大模型能看到页面的截图和可访问性树，每一步自主决策。前十次运行里，成功完成任务的次数是 7 次，看起来还行，但失败的 3 次问题都很典型：

• 一次是页面出现了“推荐弹窗”，Agent 点了关闭按钮，但弹窗动画还没结束，它马上又点了一次，结果第二次点击落在了背后的页面上，误触了一个广告位，跳到了无关页面；
• 一次是登录时输入框有前置校验，Agent 输入完账号密码立即点了登录，但页面还没完成 Ajax 验证，直接报“账号格式错误”；
• 一次是排序下拉框选项需要 hover 之后再点击，Agent 直接 click 了下拉框的收起区域，导致排序逻辑没生效。

这些失败让我很挫败。每一次失败，大模型都会“主动反思”，然后重新尝试，但新的尝试往往又引入新的误判。整个过程像在教一个聪明但手不稳的孩子做精细活，他理解你说的话，但手脚跟不上。

3.3 方案 B：纯 Playwright 脚本的表现

方案 B 就是我写一套 Playwright 脚本，用固定的选择器走完整个流程。写脚本花了我大概四十分钟，大部分时间用在等待条件判断上。我明确告诉脚本：点击登录后等待“账户信息”元素出现，再执行下一步；点击排序后等待列表第一个商品的文本发生变化，再开始抓取。全部用显式等待，不用time.sleep。

跑了一百次，成功率是 100%。耗时稳定在 9 秒左右，也就是 LLM Agent 的二十分之一。费用基本为零，因为脚本不调用任何大模型接口。唯一的维护成本就是如果页面结构发生变化，需要手动更新选择器。

这个结果一点都不意外，但真实跑完我还是很受冲击。因为在 LLM Agent 的语境里浸得太久，我几乎快忘了“输入相同指令、每次结果都相同”是多么宝贵的特性。自动化测试领域这么多年沉淀下来的“等待策略”“重试机制”“快照断言”，放在 RPA 场景里完全适用，它们才是真正的工程资产。

3.4 方案 C：混合路线——LLM 负责写选择器，脚本负责执行

方案 C 是我自己尝试的新路线：让 LLM 只做“离线代码生成”，不参与运行时决策。具体操作是，把网站页面代码喂给 GPT-4o，让它生成一套 Playwright 脚本，要求所有元素定位都用>unknown error: net::ERR_CONNECTION_CLOSED

我一时间以为是网络问题，排查了半天防火墙、代理，甚至把代码里的超时时间都调整了一遍，问题依旧。最后实在没办法，进入交互模式手动启动 driver，才看到真正的报错：

SessionNotCreatedException: This version of ChromeDriver only supports Chrome version 126

那一刻真想抽自己。这也提醒我：所有浏览器自动化项目，都应该在启动时加一个版本检查。Playwright 有playwright install --dry-run可以检查浏览器版本，Selenium 则需要自己在代码里定期去检测driver.capabilities['browserVersion']和本地chromedriver版本是否一致。我后来干脆给服务器设了策略：禁止浏览器自动更新，统一用版本固定的容器镜像。这个教训对所有人应该都适用：自动化的前提是“环境可控”，连环境版本都不可控，后面所有稳定都是空谈。

4.2 CSS 选择器和 XPath 该怎么选？我的经验是“优先语义结构”

经常有人问：到底学 CSS 选择器还是 XPath 好。我的答案很直接：优先学 CSS 选择器，但 XPath 的“文本匹配”和“包含匹配”在某些场景下无可替代。

CSS 选择器的优势是简洁、可读性好，而且主流框架对 CSS 支持都很完善。比如.card .title、#username、input[name="email"]，一眼就能看出定位逻辑。XPath 的优势是功能更强大，可以按文本内容定位：//button[contains(text(),'立即登录')]，这在按钮没有稳定 class 时特别好用。

但我的真实建议是：能不用 XPath 就不用，因为 XPath 表达式一旦写长，可读性很差，而且很多 XPath 在页面结构微调时会静默失效，不像 CSS 选择器失配时就直接报NoSuchElementException，问题暴露得快。如果项目用的是 Playwright，最好优先使用它封装的定位 API：getByRole('button', { name: '立即登录' })，这种“按角色和可访问名称定位”的方式，比任何选择器都更贴近语义，也能兼顾可访问性。

真正要避开的坑是“绝对路径式”选择器。比如#root > div > div > ul > li:nth-child(3) > a，这种选择器现在能用，但任何一次前端结构调整都让你当场去世。反观相对路径ul.list > li a或者text=查看详情，就有韧性得多。写自动化脚本，要把页面当成一个“接口文档”，而不是“一串像素”。

4.3 页面异步加载导致的竞态条件：等元素，而不是等 sleep

异步加载是我踩过最深的坑，没有之一。现代网页几乎没有纯静态的，很多数据都是 Ajax 加载后 DOM 才出现。新手最容易犯的错误是“等待时间固定”，比如：

time.sleep(5)

这在网络快的时候没问题，一旦网络慢，5 秒不够用；网络快的时候又白白等很久。正确的思路是基于条件等待。Selenium 里是WebDriverWait配合expected_conditions，Playwright 里是locator.wait_for()或expect(locator).to_be_visible()。

我处理竞态条件的核心心法是：永远等“业务状态”而不是等“时间”。什么是业务状态？就是要抓数据的列表多出了一个特定元素，或者某个“加载完成”的暗号出现了。比如抓取价格列表前，我会等[data-testid="product-list"] .product-card元素数量大于 0，而不是等 10 秒。这种写法在 99% 的情况下都比固定 sleep 更快且更稳定。

还有个小技巧：对于无限滚动页面，可以用循环滚动到底部，每次滚动后判断页面高度是否变化，而不是随便滚几屏。我见过有人为了兼容无限滚动，直接向下滚 100 次，结果页面上所有数据全被滚“懒加载”出来，内存直接爆掉。正确的实现是：记录上一次滚动高度和当前滚动高度，相等时就说明到底了。

4.4 验证码、弹窗、懒加载：这些“反自动化”设计的破解思路

“破解”这个词不准确，我的意思是怎么合理应对。验证码存在的意义就是拦截自动化，如果你的自动化任务需要频繁登录，验证码是绕不过去的坎。我的经验是：能避免就避免，比如尽量用持久化登录态（保留 cookie / storage），而不是每次都走登录流程。Playwright 可以在登录一次之后，把 storage state 存成 JSON，下次启动直接加载——这在内部测试平台上非常实用，能规避掉 90% 的登录验证码问题。

弹窗是另一个高频干扰源。处理弹窗我不用复杂逻辑，而是准备一个“清除干扰”的函数：遇到模态框就点关闭，遇到隐私弹窗就点同意，然后重试主流程。关键在于给这个函数设置“失败即放弃”的熔断逻辑，防止脚本在弹窗上死循环。我见过最离谱的场景是：自动化脚本点击了一个不可见的遮罩层，然后触发了一连串的事件冒泡，把页面切到了另一个路由，最后卡在空白页。为了避免这种问题，所有点击动作都应该先行判断元素是否可见、是否可点击。

懒加载相对简单：需要哪个元素，就滚动到哪个元素附近，再等待它可见，而不是一上来就等待所有内容加载完成。

5. 移动端浏览器自动化的实测：AutoFlow 和那些“直接下载链接”

5.1 AutoFlow 是什么，为什么没有官网

AutoFlow 是一款安卓端的自动化工具，主打流程编排，支持点击、滑动、文本输入、条件判断、循环等操作。它最特殊的地方，不是功能，而是分发方式：没有独立的网页官网，官方和用户主要在分享链接里发布 APK。我第一次听说时，第一反应也是“这也太不正规了”，但研究了一下发现，不少这种工具选择不上架商店，主要是为了避开发布审核周期和抽成，尤其是自动化、无障碍相关工具，商店审核卡得很严。

所以当我在热搜词里看到“autoflow(安卓自动化) 没有独立的网页官网,直接用下载链接在平板浏览器”，我想说这是真实情况。我自己的做法是先用平板浏览器打开某一个网络收藏夹里的直链，下载 APK，安装后手动给无障碍权限。整个过程确实比从应用商店安装麻烦，但胜在直接，不用绕过什么限制。看到这种工具，我的态度是“谨慎但别一刀切”。先检查下载链接的域名是否正规，有没有可疑权限（比如请求短信、通讯录），再在闲置平板上试用一段时间，确认没问题再放到主力设备上。

5.2 在平板上装 AutoFlow 的真实体验：从 APK 下载到无障碍权限

我测试用的是一台普通的安卓平板，系统版本不高不低。下载 APK 后，系统可能会弹“未知来源”的警告，这里是需要主动确认的。安装完成后打开 AutoFlow，第一步就是引导开启“无障碍服务”，这个环节是在系统设置里操作，需要手动找到“已安装的服务”列表，把 AutoFlow 切换为开启状态。

开启无障碍服务后，AutoFlow 可以读取屏幕内容、模拟点击，这其实和桌面端浏览器的读 DOM 本质上是同一件事：都是把“可交互的信息”暴露给自动化引擎。但差别在于，移动端很多网页是用 WebView 渲染的，传统的无障碍树可能不完整，所以 AutoFlow 的定位逻辑里，“图像识别 + 文本匹配”会比纯节点定位更实用。

我实测了在平板浏览器上跑一个 H5 页面自动化流程：打开一个数据报表页面 → 点击日期控件 → 选择最近七天 → 截图保存。AutoFlow 每一步都提示我录制一个操作，我也能手工设置“等待某段文字出现”作为同步点。整体体验很像轻量版的 UiPath，但跑在安卓端，对硬件要求也低。

5.3 用 AutoFlow 在平板浏览器里做自动化，和桌面端有哪些不同

最明显的不同是“执行上下文”。桌面端浏览器自动化，我可以假设窗口大小固定、网络环境稳定；但在平板上，我遇到的最大的坑是屏幕旋转。平板一旋转，屏幕坐标就变了，原本录制的点击位置全部偏移。我的解决办法是：在 AutoFlow 流程里强制固定屏幕方向，或者在每一步都用“元素文字”而不是“坐标”去定位，尽量减少对屏幕坐标的依赖。

第二个不同是“后台限制”。安卓系统为了省电，可能会在几分钟后杀掉后台进程，这就导致自动化只跑了一半就被系统中断。解决办法是在系统设置里关闭对 AutoFlow 的电池优化，个别系统还要在“最近任务”里给它加锁。这个细节我一开始没注意，前几次自动化任务总是神秘夭折，后来加了白名单才稳定下来。

第三个不同是“无障碍焦点的时效性”。有时屏幕内容已经变了，但无障碍服务返回的节点还是旧的，AutoFlow 如果立刻执行下一步，就会点错位置。我的经验是在关键步骤后增加 500~1000ms 的稳定等待，或者用“等待文本出现”来兜底。

5.4 自动化工具的合规使用边界：别拿来干坏事

聊到这里，必须补一句关于合规的话。浏览器自动化、移动端自动化都是强大的工具，但它们应该被用在合法、合规的范围内：比如测试自己的业务系统、抓取有授权或公开的数据、做无障碍辅助操作。不要拿这些工具去破解验证码、绕过付费墙、批量注册、抢占资源、恶意爬取个人信息。这既是法律底线，也是工程伦理。

我在团队内部使用自动化之前，都会和法务确认数据使用边界。不要觉得这是小题大做，现实中发生过很多因为自动化脚本“越界”而惹上麻烦的案例。工具越强，使用者越要自律——这也是“另一条路”能走长远的前提。

6. 我的结论：LLM Agent 和传统自动化的正确缝合姿势

6.1 把 LLM 用在最需要“理解”的地方，把执行交给确定性脚本

测完这么多工具，我对两者分工的理解清晰了很多。LLM Agent 的真正优势是“语义理解”和“开放世界建模”，它适合处理那些没有固定答案、需要动态推理的任务，比如“总结这封邮件的内容并写一封得体的回复”“帮我查一下几个平台上的同一款手机哪个更便宜”。

而浏览器自动化脚本的核心优势是“确定性和可测量”。它的执行结果可预期，成功失败一目了然，出现 bug 时可以快速定位。对于生产环境里的任务，确定性比智能更重要。为了一次价格抓取，我不需要它“聪明地猜出价格在哪”，我需要它“准确且迅速地把价格取回来”。

所以我现在的正确缝合姿势是：把大模型用在上游和下游的“认知”环节——比如从自然语言需求生成脚本骨架、从页面快照里识别业务字段，而在成百上千次的高频执行环节，全部交给 Playwright 或 AutoFlow 这种确定性工具去跑。这样既享受了大模型的理解能力，又避开了它的不确定性和成本。

6.2 我给团队的几条选型建议

如果你现在正面临选型，我这几条经验或许可以参考：

• 任务流程明确、页面结构相对稳定：直接上 Playwright 或 Selenium，不要迷信 LLM Agent。你缺的不是智能，而是执行框架。
• 需要识别复杂语义、分类提取非结构化信息：让 LLM 做“离线解析”，比如把 HTML 文本交给它提取结构化字段，再用脚本拿结果去操作页面。
• 页面改版频繁、没有稳定测试标识：优先推动前端团队加>