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_steps=40, # 防止Agent在复杂页面中死循环 verify_each_step=True, # 每个动作之后都要重新检查页面状态 stop_condition="csv文件已生成且大小大于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个"背后真正可靠的东西。技术带来的效率提升在明处，工程师对任务的判断、对边界的控制、对成本的敏感在暗处，两者缺一不可。
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_steps=40, # 防止Agent在复杂页面中死循环 verify_each_step=True, # 每个动作之后都要重新检查页面状态 stop_condition="csv文件已生成且大小大于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个"背后真正可靠的东西。技术带来的效率提升在明处，工程师对任务的判断、对边界的控制、对成本的敏感在暗处，两者缺一不可。