实战：浏览器/GUI 自动化 Agent
系列入口：如何使用 Agent。M9 第 7 篇。
一、GUI 自动化的价值与脆弱性
很多现实操作没有 API：内部老后台、第三方网站、桌面软件，只能靠人点鼠标。浏览器/GUI Agent（computer use 一类）能"看屏幕、读界面、执行点击输入"，把这类手工流程自动化，价值直接。
但 GUI 是出了名的脆弱环境：按钮位置和文案会变、弹窗随时出现、网络和渲染有延迟、动态页面元素异步加载。 一个依赖"坐标点 (x, y)"或固定截图匹配的脚本，界面稍改就崩，甚至点错按钮造成真实后果。因此用 GUI Agent，核心不是让它"会点"，而是让流程稳健、可校验、出错即停。
二、第一步：优先稳定的定位方式
让 Agent 操作界面前，先确定怎么定位元素最稳。优先级一般是：可访问性语义（角色 + 可访问名，如"名为『提交』的按钮"）> 稳定的测试专用标识（如 data-testid）> 结构选择器 > 文案 > 最不可靠的屏幕坐标。
语义定位之所以好，是因为它贴近"人如何理解界面"，对布局和样式变化不敏感。如果目标系统缺少稳定标识，可以让团队在开发时补 data-testid——这比让自动化去依赖像素位置可靠得多。一开始就把定位策略定稳，能减少日后大量"怎么又点不到了"的维护。
三、第二步：拆成可校验的小步，每步都确认
不要让它凭一张截图一路盲点到底。把流程拆成小步，每步动作后都等待并确认界面进入预期状态，再进行下一步。
确认的方式是针对可观察结果断言：某元素出现/消失、某文本或值正确、URL 或状态变化、列表多了一条。处理动态页面要用"等待条件满足"而非"死等固定秒数"——固定 sleep 要么太长拖慢、要么太短仍没加载好。每步保存关键状态（必要时截图），让流程具备自我核对能力，而不是假设每次点击都成功。
四、第三步：处理异常与误点后果
GUI 环境异常高发，要让 Agent 会识别和处理意外：加载失败、弹窗/遮罩、验证码、会话过期、元素找不到。原则是遇到无法处理的情况就暂停、截图、报错，而不是在状态不明时继续尝试"也许点这里"——后者极易误操作。
对可能造成真实后果的动作（提交订单、删除、支付、对外发送）尤其谨慎：先在测试/沙箱环境和脱敏账号上跑通，关键动作前做二次确认或只在低风险环境放开；绝不让一个看错屏幕的 Agent 直接在生产系统执行不可逆点击。能用 API/接口完成的，优先用接口，GUI 自动化留给真正没有接口的环节——接口比界面稳定得多。
五、第四步：端到端校验与防脆弱
流程跑通后，要验证它的稳定性而不只是"成功过一次"。连续多跑几轮、在不同数据和轻微界面差异下运行，观察是否偶发失败（flaky）。让 Agent 为整个流程生成可复用的脚本与清晰的失败信息：失败在哪一步、当时页面什么样（截图 + DOM/页面状态），便于快速定位是定位失效、时序问题还是真功能错误。
降低脆弱性的常用手段：最小化对样式和坐标的依赖、统一处理等待、隔离测试数据（每次可重置）、避免用例间相互依赖。把这类 GUI 自动化作为端到端回归的一部分，但因其较慢、易抖，宜数量精简、聚焦关键主路径，把大量细粒度校验交给更快的单元/接口测试。
六、判断一个任务适不适合 GUI 自动化
并非所有"现在靠手点"的操作都值得自动化，选错对象会陷入无尽的 flaky 维护。先用几个标准判断。
一看稳定性与频率：每天高频重复、且界面相对固定的流程（如批量审核、定时取数），自动化收益大；偶尔一次、界面又频繁改版的，手工更划算。二看有无更稳的通道：这是最关键的判断——若操作背后存在 API、可导入导出、或有命令行方式，应坚决走这些通道，它们不依赖渲染和时序、稳定且快；GUI 自动化只用于真正没有接口的"断头路"。
三看后果可不可控：纯读取、可撤销、在沙箱或测试账号内的操作适合先自动化；涉及支付、删除、对外发送且不可逆的，即使自动化也要多重确认和严格隔离，甚至保留人工。四看结果能否客观验证：每步是否有明确的界面信号可供断言，如果整个流程结果模棱两可、要靠人主观判断，自动化便失去了自检基础。用这四条筛过，你会把宝贵的自动化预算投在回报最高、维护最省的少数流程上，而不是被"什么都想让 Agent 点"的冲动拖入泥潭。
七、常见问题
Q：Agent 偶尔点错地方，怎么根治？ 多因定位不稳或时序问题。改用语义/testid 定位、显式等待元素就绪、每步断言结果；对危险动作加确认与沙箱隔离，让"看错"无法造成严重后果。
Q：界面经常改版，脚本维护成本高怎么办？ 尽量与开发协作内置稳定标识，减少对文案/坐标的耦合；流程聚焦少数关键路径，其余用更稳定的 API 层测试覆盖。
Q：一定要用截图识别吗？ 能直接访问 DOM/可访问性树时优先用结构化方式定位，比纯视觉识别更准更快；截图主要用于最终确认和失败取证。
Q：能用来做日常重复性业务操作（RPA）吗？ 可以，但应在受控账号、可撤销/可核对的前提下运行，并保留日志与人工抽查，防止无人值守的误操作累积。
七、让自动化流程长期稳定的维护习惯
GUI 自动化跑通只是开始，真正决定它生死的是后续维护——界面一两次改版后若无人修，流程就会被弃用。建立几个习惯能显著延长它的寿命。
失败信息要直指病灶：脚本失败时应说明在哪一步、什么元素没找到、当时页面什么样（截图 + 页面结构），让维护者一眼判断是选择器失效、时序问题还是真 bug，而不必从头复现。与开发协同内置稳定锚点：关键按钮和区域约定使用 data-testid 等不随样式变化的标识，从源头降低改版冲击。测试数据可重置：每次运行基于可恢复的干净数据，避免用例相互污染、越跑越不稳定。
定期健康检查：即使没有业务触发，也周期性跑一遍关键流程，及早发现静默失效。聚焦主路径、控制规模：GUI 流程慢且易抖，只保留覆盖核心业务的少数几条，细枝末节交给更稳的接口/单元测试。把这些习惯固化下来，自动化流程才能跨过"新鲜期"成为团队长期依赖的能力，而不是一批很快腐烂、被人遗忘的脚本。
八、处理登录、验证码与会话状态
GUI 流程中最常见的拦路虎是身份与会话：登录态过期、二次验证、弹窗遮罩，往往让自动化在第一步就失败。
稳定管理会话：优先使用长期有效的测试账号会话或注入凭证的方式，避免每次从头登录；凭证经安全存储而非硬编码。正视验证码/二次验证：这类为"区分人机"设计的环节不应试图绕过，可在测试环境申请关闭、使用测试专用通道，或在该步骤转人工，而不是让 Agent 去破解。检测会话失效：流程开始先确认登录状态，过期则按受控方式重新认证或立即报错。
隔离环境数据：自动化账号不应拥有危险权限，防止会话被滥用。把这些边界处理好，自动化才不会因为"不是技术问题、而是登录问题"频繁中断，也能守住安全与合规底线。
九、断言界面状态而非动作完成
GUI 自动化最常见的假成功，是"点了"就当"成了"，实际元素没响应、页面没跳转。
每步动作后都应针对可观察结果断言：某元素出现或消失、文本/数值正确、URL 或状态变化、列表条数改变。用"等待条件满足"替代固定 sleep，确保动态页面真正就绪再继续。只有每步都验证了结果，流程才不会一路盲点、到最后才发现早已偏离。
十、异常即停与安全兜底
界面异常（弹窗、遮罩、加载失败、元素缺失）高发，处理原则是保守而非侥幸。
状态不明就截图、暂停、报错，不要让 Agent 在不确定时继续尝试"也许点这里"，误点尤其危险。危险动作强约束：支付、删除、外发等不可逆操作只在沙箱与隔离账号执行、加二次确认；能走 API 的坚决不走界面。控制自动化账号权限作为最终兜底，让"看错屏幕"至多造成可挽回的后果，GUI Agent 才能被放心用于真实流程。
十一、用多轮运行消除 flaky
GUI 流程"偶尔失败"几乎是常态，若不主动验证稳定性，一次偶发就会动摇大家对自动化的信任。
连续多轮、不同数据下运行，统计成功率，定位偶发点——多数 flaky 来自时序（等待不足）或数据污染。用显式等待替代固定 sleep、让测试数据可重置、用例间不相互依赖。失败时带上截图与页面结构，便于判断是定位失效还是真错误。只在稳定性被验证后才纳入回归，并把 GUI 用例数量收敛到关键主路径，交给更快的测试层覆盖细节，自动化才不会因频繁误报而被弃用。
Q：第三方网站完全无法加 testid 怎么办？ 退而求其次，用可访问性语义和稳定结构定位、减少对文案坐标的依赖，并把这类流程视为高维护成本对象：聚焦少数关键路径、失败即截图，必要时保留人工兜底。
十二、检查清单
- 优先语义/稳定标识定位，避免屏幕坐标。
- 流程拆小步，每步等待条件并断言可观察结果。
- 已处理弹窗、超时、会话失效，异常即截图暂停。
- 危险动作在沙箱验证、有二次确认，优先用 API。
- 多轮运行验证稳定性，失败带截图与现场，用例聚焦关键路径。
总结
浏览器/GUI Agent 能自动化那些没有 API 的操作，但必须按"脆弱环境"来对待：优先用可访问性语义和稳定标识而不是屏幕坐标定位，把流程拆成小步、每步显式等待并断言界面真实变化，遇到弹窗、超时或找不到元素就截图暂停而非盲点，危险动作一律沙箱演练、二次确认，能走接口就不走界面；最后通过多轮运行、清晰的失败取证和测试数据隔离来消除 flaky，并把 GUI 自动化数量收敛到关键主路径，才能既拿到端到端自动化的便利、又不被多变的界面和误点风险拖垮。