浏览器驱动Agent实战：从感知到执行，效率重构的完整打法

2026年9月15日下午两点多运营同事拿着一张截图找到我说竞品官网改版了他们手工维护了半年的价格表全部要重来。我一边听一边打开终端把浏览器驱动Agent的任务描述从按SKU抓取描述和价格改成了打开页面找出产品表格翻完所有分页把结果存成结构化文件。第二天早上核查抽样结果跟运营人工复核的完全一致全程没写一条XPath。后来我把这套东西用到了商品巡检、报表下载、表单填报和跨站点比对上才真正理解1个工程师能顶4个这句话不是噱头而是人力结构被重构之后的结果。这篇文章不是ChatGPT式的概念科普是我从需求到落地、从踩坑到收敛的一套真实打法。适合正被重复性浏览器操作缠住的工程师也适合想让团队少招人的管理者看完你能直接判断自己手上哪些活适合交给Agent。1. 从按脚本办事到按目标办事浏览器自动化的范式变化1.1 传统自动化工具最让人头疼的五个瞬间在Agent出现之前大家日常用的浏览器自动化基本是两条路一条是录制回放工具鼠标点几下生成操作流程另一条是写代码用选择器定位按钮和输入框。两条路都有效但都让我头疼过。第一条路的问题是录制时流畅重播时翻车。录好的流程只要页面布局微调哪怕只是按钮往下移了10个像素点击就落空。第二条路的问题是把大量时间花在维护选择器上。页面上一个class名从price-list改成plist__item整套脚本就得人工排查一遍改错一个定位符后面全乱。更麻烦的是登录态很多系统有单点登录、双因子校验、滑条验证脚本一跑就卡在登录页纯粹是浪费人的生命。还有一类问题是动态内容。现代前端大量使用异步渲染和懒加载脚本等元素出现要写轮询等图片加载要写重试稍不留神就把还没渲染完当成页面异常。到了后期反自动化机制也越来越常见请求频率一高正常浏览器也会被识别成爬虫然后整个IP被临时封禁。你会发现维护一套传统自动化脚本的隐性成本远远超过当初写脚本的时间。1.2 Agent带来的三个关键变量视觉、语义、规划浏览器驱动Agent把上面这些问题换了个解法。它不再要求你精确告诉每一步点哪里而是你告诉它要达成什么目标它自己观察页面、决定动作、执行并验证。这个转变靠的是三个关键变量。第一个是视觉感知。Agent能看到页面截图理解按钮、表格、弹窗在什么位置也能从界面布局上判断这页有没有数据。页面样式变了只要用户还能看懂Agent基本也能看懂这直接化解了选择器失效的困境。第二个是语义理解。它读取的不只是截图还有浏览器的DOM快照和可访问性树。视觉负责看语义负责读两者结合表格里的价格、状态标签、链接地址都能被精确提取不会被排版干扰。截图丢了字的细节DOM补上DOM里冗余噪声太多截图帮它聚焦。第三个是规划能力。Agent可以把把今年所有采购订单导出并去重这么一句口语拆解成登录、进入列表页、设置筛选条件、循环翻页、点击导出、核对文件大小等一串动作。传统脚本是我给你一条完整路线所有路口都标好Agent是我给你目的地它自己看着路牌走。1.3 为什么要用浏览器而不是直接调接口很多人会问能调接口为什么要操作浏览器答案是大部分真实业务根本不给开放接口。第三方平台的数据只展示在页面上内部老系统的按钮逻辑谁也说不清跨系统之间又没有API网关。能用接口的地方当然用接口快、稳、省成本但现实中存在大量页面即接口的场景这时候浏览器驱动Agent就成了最通用的适配层。而且它的价值不只是能操作而是让操作方式从预先写死变成现场理解。你不需要等网站在HTML里预留什么数据接口也不需要对方配合你改任何代码。页面能看Agent就能操作这对长期需要和外部系统打交道的团队来说是本质区别。2. 那4个人到底在被什么消耗我把时间账摊开给你看2.1 一个典型数据采集团队的人员构成在没有Agent之前一个稳定的页面数据生产线通常需要四个人。第一个是采集开发工程师负责写爬取脚本主要工作是定位元素、处理分页、解决反爬。第二个是数据清洗工程师负责把抓回来的脏数据做格式转换去重、补字段、映射枚举值。第三个是测试回归工程师每次页面改版都要把历史任务全部跑一遍确认没有地方坏掉。第四个是巡检响应人员盯着定时任务和告警群一旦任务失败就要手动补跑、排查原因。这是很多公司和部门里真实存在的人力结构只是未必有四个人这么完整。更常见的是一个人同时身兼两三个角色然后优先保证最要紧的任务先跑其余的一拖再拖。团队表面上忙得不可开交实际效率天花板很低。2.2 时间都花在哪了我用一张表给老板讲清楚我把一个典型任务每三天抓取一次竞品价格表的耗时摊开算过一笔账做成表格之后老板立刻理解了为什么需要换个思路。工作环节传统人工耗时Agent参与后的耗时写采集脚本与定位4小时开发联调15分钟写任务描述页面改版后修复脚本2到8小时逐个排查30分钟内重新看页面即可数据清洗与格式统一2到3小时写规则30分钟让Agent按模板输出回归测试全部历史任务半天到一天1小时内批量巡检日常失败响应与重跑每天1到2小时大多数失败由重试策略自动消化这里面最夸张的不是单次抓取而是页面改版后的修复。传统模式下前端工程师改一个class名后面可能拖累几十个脚本Agent模式下改版只是截图里的像素结构变化重新识别一下就能继续跑。一次改版省下的维修时间就够覆盖Agent运行好几天的token成本。2.3 顶4个的真正含义是产能杠杆不是裁员先说清楚我说1个工程师顶4个不是鼓励谁去裁员。而是同一个工程师过去只能维护两三条采集流水线现在可以同时维护几十条还能腾出手来处理真正需要人来判断的业务问题。人员结构从脚本维护者变成了任务编排者和结果审核者。这背后的逻辑是产能的边际成本变了。传统脚本每新增一个页面就要重新开发、调试边际成本很高。Agent每新增一个页面大多数情况下只是再写一段任务描述甚至描述可以复用边际成本接近零。单位人效自然被放大。当然前提是Agent具备足够的稳定性和可控性否则省下的时间都会加倍还给运维。3. 让Agent睁开眼、伸出手、长出大脑感知-决策-执行闭环的搭建3.1 感知层截图和DOM快照要一起用很多第一次上手的人会问Agent到底靠什么理解页面是像人一样看图还是像程序一样读代码答案是两者都需要而且不是二选一是互补关系。截图的价值在于理解布局和状态。弹窗有没有出现、加载转圈是否结束、表格有没有跑到下一页这些视觉状态通过图像识别最直观。DOM快照的价值在于拿到精确的文本和结构。页面上的价格到底是多少、按钮对应的真实URL是什么、某个字段的原始属性值是什么这些靠像素识别容易出错从结构数据里直接读取最准确。我常用的做法是截图定位、DOM取值。让Agent先生成截图观察整体状况决定下一步操作等到需要精确字段时再回到DOM和可访问性树里提取。两者频率大约是6比4视觉负责决策语义负责执行。这样既能避开纯视觉方案认字不准的问题也能避开纯DOM方案看不懂页面状态的天真。页面上那些动态渲染的内容也都只需要等条件成立不需要靠猜。3.2 决策层把任务拆成可验证的动作序列Agent的决策核心是一个观察-思考-行动-验证的循环。它在每次循环里做四件事观察当前页面状态形成一个文本或结构化的摘要判断当前目标是否完成如果没有完成决定下一个动作是什么执行动作然后回到观察步骤。写成伪代码大概是这个样子agents_run AgentLoop( task从订单页面导出最近30天的已完成订单存为CSV, max_steps40, # 防止Agent在复杂页面中死循环 verify_each_stepTrue, # 每个动作之后都要重新检查页面状态 stop_conditioncsv文件已生成且大小大于0, on_failure记录当时的完整页面快照触发人工告警 )关键不是动作多精确而是每一步都可验证。点击按钮之后不是直接进入下一步而是先问一句页面变化符合预期吗新内容出现了吗如果20秒内没变化就尝试第二种方案。把任务拆成这个粒度Agent跑起来才有确定性。3.3 执行层点击之后的等待绝不能靠sleep这是我在实际使用中最频繁提醒组员的一点等待页面不要硬性sleep。很多脚本喜欢点击之后固定睡两秒结果网速一波动不是点太快漏了元素就是等太久浪费一大截时间。Agent的执行层应该用条件等待等到目标元素的特定状态出现或者等到网络请求完成再继续下一步。具体落地时可以用短轮询超时兜底每0.5秒检查一次页面连续检查10次仍然没有出现目标状态就触发备用逻辑。备用逻辑可以是刷新重试、换另一种操作路径、或者停下来截图并通知人工。这样一来正常时速度拉满异常时也不会带病运行。3.4 端到端示例把整页表格翻完并导出结构化数据拿我做过的一个实际案例说任务是打开某企业内部报表系统翻完最近30天的日更数据表把每个日期对应的数值导入Excel。Agent的执行序列大致是这样第一步打开固定URL检查是否出现登录框。第二步如果出现登录框插入已保存的账号密码处理登录后的二次确认弹窗。第三步进入报表页后先截一张全页图确认表格渲染完成。第四步读取第一页表格内容存入内存。第五步点击下一页等待表格内容刷新。第六步重复直到下一页按钮不可用。第七步把所有页数据合并生成Excel并校验行数。整个过程没有写任何一个表格行的选择器全靠对下一页按钮的文字识别和表格结构的语义读取。第一次跑的时候大概用了4分钟后续每次大约2分钟。这个任务如果交给人工每天雷打不动要花半小时而且非常容易因为忘了翻页而漏数据。4. 真正拖垮效率的细节往往不在Demo里登录态、页面漂移与成本控制4.1 登录态与身份环境让Agent有长期记忆Demo里最容易被忽略的就是登录态。演示的时候是开着开发者模式、带着已登录会话跑的看着很顺畅一上线Agent从全新环境启动第一关就是登录页。如果碰到双因子验证或短信码整个任务就卡在第一步。我的建议是给Agent配一个可持续复用的用户数据目录把登录之后的Cookie、LocalStorage会话信息持久化保存下来。同一个任务域复用同一个身份环境可以大幅减少重复登录频率。需要说明的是这只适用于你自己有权限访问的系统或者合规授权的数据源别拿去做不该做的事。遇到强登录体系更稳妥的做法是把登录也定义为任务的一部分让Agent识别登录页元素、调用密码管理器、识别验证码类型。如果验证码实在无法自动通过就引入人工兜底队列卡住时自动通知值班人员输入一次之后继续跑。千万别让Agent在登录页无限重试那只会快速耗尽配额。4.2 页面漂移的自我修复选择器失效了怎么办页面不是一成不变的。运营改一个样式、开发加一个埋点都可能导致原有的稳定操作路径失效。传统脚本的做法是等告警、查日志、改定位符。Agent虽然不容易因为class名变化就挂但当页面改动幅度太大时同样会迷路。我做了个分层修复策略。第一层目标元素没变只是位置偏移靠视觉识别重新定位这是最常见的情况。第二层目标元素的文字变化了比如按钮从确定改成确认利用同义词和页面上下文重试。第三层页面整体重构原有操作路径完全不成立此时Agent应当停下生成一份页面结构前后对比报告给工程师而不是继续瞎猜。有了这三层绝大多数页面漂移不需要人介入真正需要人出面的场景会被收敛到很少。4.3 token成本与并发节奏省出几十万的真金白银享受效率红利的同时也要算成本账。浏览器驱动Agent的每一个动作都涉及模型调用截图要花钱DOM快照要花钱思考过程要花钱一天跑几十条流水线费用就是真金白银。不看成本地冲并发月底账单会让你怀疑人生。我控制成本的办法有三条。一是尽量做页面状态摘要每次都把完整的DOM塞给模型那是成本爆炸的根源只提取当前页与目标相关的字段和状态关键词可以省下大量token。二是批次内复用页面快照。同一个页面里要提取多张表格只截一次屏让模型基于同一份快照完成多个提取任务。三是区分任务优先级高价值的核心任务用最强模型维护性巡检任务用轻量模型反正看的是最终结果不是全程表演。优化手段效果只传必要DOM摘要不传整页源码token消耗降低约60%同页多个字段提取复用一次截图调用次数大幅减少低优先巡检任务换轻量模型单次任务成本下降约70%设置错误重试上限避免失败任务无限烧钱4.4 结果置信度与抽样复核Agent说完成不等于做对Agent的自我评估并不总是可信。它说任务完成可能有三种情况真的完成了中途漏了几行没处理但它以为做完了页面加载失败它把空结果当成了没有数据。想让运行结果稳定必须建立独立的复核机制。我给每条关键流水线都加了出口校验。任务结束之后单独用一个小模型或规则引擎检查输出文件的行数、必填字段完整性、数值范围是否合理。如果导出的是Excel还校验表头是否和模板匹配。这个校验环节只花很少token却能把误报率压下去一到两个数量级。实践下来最好是每十条任务至少人工抽一条抽检率可以向百分百推进看你对这块业务的容忍度。别等业务方投诉再回头查Agent那时候信任已经流失了。5. 哪些项目不该用Agent硬扛我踩过的边界和避开的坑5.1 强合规与高安全场景该锁死权限的时候必须锁死浏览器驱动Agent不是银弹第一个不能碰的就是支付、合同、医疗、实名认证等高敏感动作。技术在进步但让一个自主决策的Agent去点支付按钮风险完全不可控。哪怕它每一步都符合逻辑只要一步判断偏差很可能造成不可逆的结果。我自己的原则是Agent只做读取、填报草稿、整理导出这类低风险动作涉及确认交易、审批流转、规则裁决必须把动作停在草稿状态由人来执行最后一步。这不是技术限制而是责任边界。Agent可以作为人的助手但在高影响动作上把决策权留给人类团队才不会在深夜被电话吵醒。5.2 动态图表与弱结构页面视觉再强也有天花板Agent真正头疼的是没有稳定结构的页面。比如用Canvas完全绘制的动态图表鼠标悬停才显示数值这种页面在视觉上能看到内容但DOM里什么都没有。Agent想取数的路径很窄只能靠像素识别数字一旦遇到抗锯齿字体识别率就会下降。这类场景我的建议是宁可绕路优先看能不能从页面发出的接口请求里拿数据拿不到再看有没有导出按钮都没有才考虑用OCR兜底。把操作浏览器当成最后手段而不是第一手段。页面结构越弱Agent的稳定性就越差选型时心里要有一杆秤。5.3 反自动化环境识别如何提前预判是否适合Agent有些网站会在页面里埋很多检测逻辑。短时间高频点击、鼠标轨迹异常、截图行为、固定窗口尺寸都可能触发挑战机制。遇到这种情况硬跑Agent完全是浪费时间和配额。判断一个页面适不适合Agent我一般看三个信号第一登录是否频繁触发器二次验证第二正常用户访问时是否经常弹活动异常第三同一操作重复5次以上是否出现页面变形或接口拦截。只要中了两条就果断放弃转人工或者寻找替代数据源。这个判断做在写任务描述之前比什么都重要。5.4 一个选型判断清单最后给一份我自己反复用的选型判断清单都是一些低成本的快速体检问题不用写代码就能判断一个活儿适不适合交给浏览器驱动Agent这个任务的目标是否可以用一句话说清楚操作路径是否在10个步骤以内或者可以分成几个10步以内的子阶段页面结构是否相对稳定或者即使变化靠视觉也能理解任务失败时最坏影响是什么是否能控制在可接受范围内运行频率是每天几次而不是每分钟几百次数据出口是否可以用文件或表格承接如果以上问题全部通过这个任务大概率非常适合Agent化。如果其中有两三个亮红灯那就要重新设计路径或者考虑其他方案。我没有见过哪个任务难点在Agent不够聪明更多是在需求描述不清晰和边界意识不够强。从2026年9月15日那次演示开始我养成了一些不太起眼的习惯新建每条Agent流水线之前先小批量试跑三遍再全量放量每项任务都设置明确的超时上限超过就停下来认输不硬编每周挑两个历史任务重放一遍确认现在还能跑通。这些习惯不酷但它们是1个工程师顶4个背后真正可靠的东西。技术带来的效率提升在明处工程师对任务的判断、对边界的控制、对成本的敏感在暗处两者缺一不可。