agent 浏览器自动化

做 Agent 的时候迟早会碰到一类任务：网页上点按钮、填表单、翻页抓数据、登录后看后台。这时候你是自己写 Playwright 脚本、让模型走无障碍树，还是干脆接一个现成的浏览器 Agent 服务？这篇不吹哪个最强，只给一套对照口径和排查顺序，帮你在动手前把路线定下来。

做 Agent 的时候迟早会碰到这类活：网页上点按钮、填表单、翻页抓数据、登录后看后台。这时候摆在面前的选择有三条路——自己写 Playwright 脚本、让模型读无障碍树做决策、或者直接接一个托管浏览器服务。三条路的维护成本差得挺远，选错一次后面全是补丁。

这篇不吹哪个方案最强，只给一套对照口径和排查顺序。核心思路是：先看清你的任务属于哪一类，再按站点数量、登录态、可复现性这几个硬约束去筛，最后才是跑起来之后的调优。动手前花十分钟把路线定下来，比写到一半推翻重来划算得多。

先分清你要的到底是哪一类浏览器自动化

很多人一上来就问「哪个浏览器 Agent 框架好」，但真正决定选型的不是框架，是你的任务形态。固定流程的批量操作、开放式探索点击、纯读取页面内容，这三类的结论完全不同，混在一起讨论只会越聊越乱。

• 判断标准一：页面结构是否稳定。改版频繁的站点，写死选择器的成本会一直往上走
• 判断标准二：是否必须带登录态。要登录且带验证码的，实现复杂度立刻上一个台阶
• 判断标准三：失败一次能不能简单重跑。不能重跑的流程，必须留人工接管入口
• 判断标准四：单次耗时能不能容忍。分钟级和秒级的要求，并发架构完全不一样

四条常见路线的能力边界对照

把路线拆开看，其实就四条：纯选择器脚本、脚本加模型兜底、模型直接看截图操作、接第三方托管浏览器服务。它们的差别集中在定位方式、抗改版能力、调试难度和资源占用这几项上，笼统说谁强没意义，得看你更怕哪一项。

费用口径这块要特别小心。自建方案的成本是机器资源和你的时间，托管服务的成本是调用量。两种不能直接比单价，得换算成同一件事的总成本。具体数字到 /price-watch 核对当时的口径，别拿记忆里的价格做决策。

选型时按顺序问自己这六个问题

1. 站点数量是个位数还是几十个。个位数可以每个站点单独写脚本，几十个就必须抽象出公共的导航和提取层，否则维护量压不住
2. 登录与验证码需要登录的先确认能不能用持久化会话，涉及验证码的要提前想好人工介入点，别等跑到一半才发现过不去
3. 可复现性要求需要回放和审计的，必须留一层确定性脚本，模型只做决策不做动作，否则出了问题没法复现
4. 失败容忍度能接受多少失败率、失败后是重试还是转人工，这个直接决定要不要做状态机和断点续跑
5. 运行位置跑本地还是服务端。本地调试方便但并发受机器限制，服务端要考虑网络出口和会话保持
6. 并发规模单机几路。这一项回头会决定内存预算和实例管理方式，提前估比事后救火便宜

顺序不要跳。站点数量决定架构分层，登录态决定实现方式，可复现性决定要不要保留脚本层。这三个定下来，后面的问题基本都有答案了。

跑起来之后容易被忽略的环境与成本项

路线定完、代码跑通，真正的坑才刚开始。最常见的是本地跑得好好的，一上服务端就各种超时；或者单机能开三路，开到第五路就集体卡死。这些多半不是逻辑问题，是环境和资源没算清楚。

无头与有头

无头模式下调试信息少、被拦截概率也不同，开发期建议先有头跑通再切无头

浏览器版本锁定

版本浮动会让行为和依赖体积一起变，锁版本能让排查范围小很多

单实例内存

每个浏览器实例的内存占用决定了单机能开几路，估并发前先量这个数

出口 IP 与代理

同一出口高频访问容易触发限制，代理策略要和并发数一起设计

截图与 trace 存储

为了排查保留的现场文件会持续增长，清理策略要一开始就定

跑不稳时的排查顺序

跑不稳的时候，第一反应往往是去翻日志，但日志里通常只有一句超时，看不出到底卡在哪。更快的办法是先看失败截图和 trace，一眼就能分清是页面没加载出来、元素没出现，还是动作点了没反应。

• 第一段：页面是否加载完。看截图是不是白屏或还在转圈，是的话问题在网络和等待策略
• 第二段：元素是否可交互。页面在了但点不到，多半是被遮挡、在 iframe 里、或者需要先滚动
• 第三段：动作是否生效。点了但结果不对，检查是不是触发了校验或跳到了意料之外的页面
• 通用动作：给每个关键步骤加断言和重试上限，别让 Agent 在一个点上无限重试

还有一个容易被忽略的分支：有些失败根本不是你的代码问题，而是站点识别出了自动化特征做了拦截。这种情况表现通常是偶发、无规律、换 IP 就好。想区分的话，可以拿同样的流程在本地有头模式手动跑一遍，对照结果。