UI 自动化做了不少年头从录制回放到页面对象模型技术栈换了一波又一波可有一件事始终让人头疼测试路径怎么规划。页面一改脚本就崩元素一变定位就失效更别提那些只有视觉上才能发现的问题传统脚本根本感知不到。这几年开始深度接触多模态 Agent 之后我发现“规划 UI 测试路径”这件事被重新定义了——Agent 能看图、能读文本、能理解意图还能在页面上自己迈步子。它不再需要把每一步的坐标或控件 ID 写死而是像人一样看着屏幕判断“下一步该点什么”。如果你也在做 UI 自动化、测试策略设计或者想看看多模态模型怎么真正落地到工程里这篇文章值得认真读完。我会从思路拆解、关键环节、轻量 Demo 到避坑经验把多模态 Agent 规划 UI 测试路径这件事讲透不绕弯子。1. 先想清楚为什么 UI 测试路径规划要交给多模态 Agent1.1 传统 UI 测试路径规划的痛点过去几年做 UI 自动化最常见的路径规划方式是“人肉走一遍脚本录一遍”。录制回放工具确实上手快但维护成本高得吓人。页面布局稍微调整坐标就偏了按钮文案从“登录”改成“登 录”OCR 识别和文本匹配立刻出问题更麻烦的是很多元素没有稳定 ID只能用 XPath 层级去定位前端重构一次XPath 断一片。就算你用的是页面对象模型测试路径本质上还是静态的。所有分支提前写死在用例里每一层页面需要走哪些操作、先点哪里后点哪里全部靠测试工程师手工设计。遇到权限弹窗、动态加载、A/B 实验这些运行期才知道的变化传统脚本基本没有应变能力。换句话说传统路径规划解决的是“已知的、确定的、流程固定的”场景但真实业务里大量测试路径是“未知的、动态的、视觉相关的”这就留下了巨大空白。还有一个常被忽略的点传统自动化对“视觉问题”几乎是盲的。按钮重叠、样式错乱、图片遮挡、弹窗盖住关键内容这类问题用 DOM 结构和坐标断言很难发现必须靠人去盯截图。可一旦测试路径覆盖到几十个页面、上千个节点人力盯图就完全不现实了。1.2 多模态 Agent 的切入点和不可替代性多模态 Agent 之所以能切入这个场景核心原因是它同时具备三种传统工具很难叠加的能力视觉理解、语言推理和行动决策。它看一张截图能知道页面大概长什么样、主要按钮在哪个位置给它一句“完成注册流程”这样的自然语言指令它能拆出“先找到注册入口”“再填写信息”“最后提交”这样的子目标每走一步它还能结合当前屏幕状态和历史轨迹决定下一步动作。这不是简单的 OCR 加坐标映射。OCR 只告诉你文字在哪多模态模型还知道上下文——比如它看到“手机号”旁边有个输入框就知道这里应该填手机号而不是点了旁边那个“验证码”按钮。这种对界面语义的理解是以前所有基于选择器的方案都不具备的。适用场景也很明确跨端页面冒烟遍历、新功能回归路径生成、视觉异常巡检、混合应用Web 嵌套原生测试。在这些场景里测试路径本身是开放性的允许 Agent 自由探索容错空间也比核心链路大得多。当然它不适合追求绝对确定性的支付链路和低频核心流程在这些地方我通常还是建议用规则和人工设计的路径兜底多模态 Agent 负责补盲和扩覆盖。2. 整体设计思路把“测试路径规划”重新建模2.1 把路径规划拆成“感知-决策-执行”三步模型我在模拟项目 X 里落地多模态 Agent 规划 UI 测试路径时没有一上来就堆模型而是先把问题拆成了三层感知层、决策层、执行层。感知层负责把“当前屏幕长什么样”变成结构化信息包括截图、OCR 文本、控件的可操作位置决策层负责回答“现在应该做什么动作”这一步是 Agent 的核心执行层负责把决策变成真实操作并观察操作后的反馈。这个拆分最大的好处是每一层都能单独替换和优化。比如感知层今天用 OCR 加无障碍树明天换成更强的版面分析模型决策层代码不用动执行层从浏览器驱动换成移动端驱动感知层和决策层的接口也可以保持不变。路径规划本身被建模成一次带视觉反馈的状态搜索节点是页面状态边是 Agent 做出的动作目标是在有限的步数内从起点状态走到满足任务条件的终点状态。很多人容易忽略的一点是状态搜索里的“状态”必须足够稳定。页面如果有动画、轮播、时间戳这类频繁变化的内容直接用截图做状态判断会误判成“新页面”导致路径发散。所以我在状态表示里混合了视觉特征、关键文本和路由信息只有三者同时变化才算真正进入新状态。这一点后面会详细讲。2.2 关键技术选型视觉定位、状态表示和探索策略选型上我踩过不少坑这里直接说结论。视觉定位优先采用“语义描述加相对坐标”的方式Agent 输出“点击右上角那个头像入口”或“定位到页面中部的提交按钮”再由执行层换算成实际坐标。绝对坐标几乎不可用因为不同分辨率、不同窗口大小下数值全部漂移你不可能为每个尺寸都重新调参。状态表示则采用“三通道”策略。第一通道是截图经过轻量视觉模型提取的嵌入向量第二通道是 OCR 抽出的关键文本集合按区域排序第三通道是当前页面的 URL 或路由标识。用一个加权相似度公式判断两个状态是否相同经验阈值一般是 0.9 到 0.95。太高会把同一个页面的微小变化当成新状态太低又会把真正的新页面误判成旧页面这块需要拿历史数据多调几次。探索策略方面我测试过纯随机、深度优先和多模态 Agent 决策三种方式。纯随机覆盖率尚可但效率极低经常重复点击深度优先容易卡在某个深层流程里出不来多模态 Agent 决策是效果最好的它会根据当前任务意图和屏幕内容做局部最优判断偶尔插入一次随机探索来跳出死胡同。最终我采用了“目标驱动为主、随机探索为辅”的混合策略比例大概在 9:1 到 8:2 之间具体取决于被测页面是偏表单型还是偏浏览型。2.3 为什么这样的架构能规避传统方案的主要坑传统方案最大的坑是“结构脆、路径死、视觉盲”。这个三步模型恰好一一对应解决。结构脆的问题由视觉理解兜底页面不管怎么改版只要视觉上还能认出这是个“登录按钮”Agent 就能继续工作路径死的问题由动态决策解决每一步动作都是根据当前屏幕重新生成的而不是回放预先录制的坐标视觉盲的问题则被多模态输入天然抹平因为决策过程本身就依赖“看图”。还有一个容易被低估的好处是可追溯性。传统脚本失败之后你看到的是“第 3 步超时element not found”这样的日志根本不清楚 Agent 脑海里当时在想什么。但是我在设计输出格式时强制要求 Agent 给每个动作附上“判断理由”比如“检测到页面出现验证码弹窗先点击关闭按钮”出问题时顺着理由回看截图定位效率高了好几倍。这部分在后面的常见问题里我会展开讲。3. 手把手实现多模态 Agent 规划测试路径的关键环节拆解3.1 感知截图、OCR 与无障碍树的多模态融合感知层是整个路径规划的地基地基不稳后面全是空中楼阁。我一般在每次动作前先做三步等页面稳定、截取全屏、提取结构化信息。页面稳定不能简单用“sleep 3 秒”正确做法是等待网络请求空闲、关键元素出现、动画结束三者满足其一才算稳定。有一个很实际的技巧先把页面滚动到顶部截一张全屏长图再对长图做 OCR这样不会漏掉屏幕外的内容但要注意长图会引入滚动条和底部导航的干扰需要做区域裁剪。OCR 是感知重头戏尤其中文场景直接决定了 Agent 能不能看懂按钮文案。我跑下来的经验是把 OCR 按区域切块每个文本块附带 bbox 坐标和置信度比把所有文本丢给模型要可靠得多。因为多模态模型虽然能看图但对密集小字的识别能力有限你把 OCR 结果作为辅助文本输入进去等于给了它一个“放大镜”。再加上从页面结构里解析出的候选可操作控件列表Agent 就能清楚地知道哪些区域是可以点的、哪些只是展示文案。这里有一个很多人会忽略的细节无障碍树和截图信息有时候是冲突的。比如截图里明明有个按钮但无障碍树里没有或者树里有几个隐藏节点截图里看不到。我的处理原则是“以视觉为主树为辅”。视觉能确认的元素优先用树里的信息用来补候选位置但如果 Agent 选择点击树中存在但截图中不可见的元素就要拦截并给警告。3.2 决策意图理解与步骤拆分决策层是 Agent 真正动脑子的地方。我给它定义了一个标准的观察空间屏幕摘要、候选动作列表、历史轨迹、任务目标。每次循环里系统先把感知层的数据整理成一段结构化描述连同最近几步的操作记录一起发给多模态模型让它输出下一步动作。动作输出格式必须严格约束我的做法是强制输出 JSON字段包括 action 类型click/input/swipe/back/assert/wait、目标元素语义描述、执行参数和判断理由。不约束格式就会出现灾难模型自由发挥写一段话解析器要么崩溃要么误判。还必须在提示词里加入“存在性校验”要求让 Agent 先根据 OCR 文本或候选列表确认目标元素真实存在再输出动作。我见过太多次它一本正经地点击一个页面上根本不存在的按钮原因就是没做校验。步骤拆分方面长任务一定要拆成子目标。比如“走一遍下单流程”这个任务直接让 Agent 一口气规划完整个路径到后半程基本会迷失。正确做法是先定义几个 milestone首页搜索商品、查看详情、加入购物车、结算支付。Agent 每完成一个 milestone就把任务重新聚焦到下一个。这个过程不需要人工干预提示词里加一段“milestone 拆分指引”就能实现实测效果比让模型自由规划稳定得多。3.3 执行动作落地、状态追踪与循环检测执行层的关键词是“安全”和“可恢复”。Agent 说“点击登录”执行层不能直接盲目点击需要先把语义描述映射到具体控件再确认控件可见、可点击最后才真正触发动作。这一步我通常会做一个白名单校验防止 Agent 误点到“退出登录”“删除账号”这类危险操作。对于输入操作还要限制输入内容类型不能用测试数据去填真实手机号或支付密码。状态追踪方面每执行完一个动作系统会再次感知页面状态然后和动作前的状态做对比。如果页面没有明显变化说明这个动作或者没有生效或者点到了一个无效区域这时要触发重试或者换一条路径不能让 Agent 一直重复同一个无效动作。循环检测更要前置。我维护了一个状态哈希表每次进入新状态就计算一个指纹如果发现当前状态在历史记录中出现过并且接下来的动作序列和上次一模一样就判定为陷入循环。处理方式是强行插入一个随机探索动作或者把当前状态标记为“已遍历”要求 Agent 换一个入口继续走。没有这套机制Agent 可能会在一个弹窗和页面首页之间来回点几十次看起来好像很忙实际一步都没前进。3.4 路径规划评测指标怎么设很多团队做完了路径规划功能却不知道怎么评价效果全靠人看点记录。我自己常用的指标有四个缺一不可。第一个是任务完成率指 Agent 在最大步数限制内成功到达目标状态的比例这个指标直接反映规划能力第二个是平均路径长度即完成任务消耗的步数越短说明规划效率越高第三个是状态覆盖率指探索过程中访问过的唯一页面状态占整个应用可访问状态的比例这个指标衡量探索广度第四个是稳定性同一任务跑 10 次至少 8 次结果一致才算合格否则测试路径本身就不靠谱。这四个指标一定要组合着看。只看完成率可能漏掉规划效率低下只看状态覆盖率Agent 可能到处乱逛但完不成具体任务。我建议每次改动提示词或模型之后把四个指标一起拉出来对比宁可单点指标略降也不能让整体失衡。路径规划不是越激进越好稳和准永远排在快前面。4. 一个可复现的轻量级 Demo核心逻辑与参数说明4.1 环境准备和基础流程为了验证这套方法我搭了一个模拟项目 X取名叫“某跨平台商城 Demo”。它包含首页、搜索结果页、商品详情页、购物车、结算页和登录页页面之间有一定动态内容比如轮播图和推荐位适合拿来当测试标的。整个 Demo 的技术栈不复杂就是普通前后端项目但页面布局基本还原了真实商城的复杂度。环境方面我准备了四样东西Python 运行环境、一个多模态模型接口、一个浏览器自动化库、以及一个轻量 OCR 工具。多模态模型接口负责截图理解和决策OCR 负责抽文字自动化库负责真实点击和输入。浏览器选择上一定要用支持无头模式或者可后台运行的版本否则弹窗会打断 Agent 的操作节奏实测中这个细节非常影响稳定性。基础流程是这样先启动被测页面然后用多模态模型对首页截图做一次预扫描生成初始状态描述接着进入主循环每一轮里依次执行感知、决策、执行、状态更新四步最后当任务目标达成或者步数耗尽时结束输出路径记录和统计指标。整个流程不依赖任何手工标注的控件坐标所有定位信息和动作选择都由 Agent 动态生成这是这套 Demo 和传统自动化脚本最本质的区别。4.2 核心实现代码与参数说明核心循环我写了一个精简版本方便你理解整体逻辑而不是纠结在框架细节里。伪代码结构可以让不同技术背景的读者都能看懂大意真正实现时替换成具体的库和模型即可。# 模拟项目X多模态 Agent UI 测试路径规划 Demo 核心循环 max_steps 30 # 最大步数限制 similarity_threshold 0.92 # 状态相似度阈值 exploration_rate 0.15 # 随机探索率 timeout_seconds 5 # 页面稳定等待超时 state_history [] # 历史状态列表 action_history [] # 历史动作列表 current_state None task_finished False for step in range(max_steps): # 1. 感知当前页面状态 page perceive_screen(timeout_seconds) current_state compute_state_signature( image_embedding(page.screenshot), ocr_texts(page.ocr_result), page.route ) # 2. 循环检测当前状态是否和某个历史状态重复 if is_similar(current_state, state_history[-1], similarity_threshold): force_explore True else: force_explore False # 3. 决策目标驱动为主随机探索兜底 if random.random() exploration_rate or force_explore: action generate_random_action(page.candidate_actions) else: action multimodal_agent_decide( task_descriptiontask, current_screenpage, candidate_actionspage.candidate_actions, historyaction_history[-5:] # 给最近5步动作保留时序上下文 ) # 4. 危险操作白名单校验 if action.action_type in {dangerous}: action generate_safe_action(page.candidate_actions) # 5. 执行动作并记录轨迹 result execute_action(action) action_history.append({ step: step, action: action.to_dict(), result: result.status, reason: action.reason }) state_history.append(current_state) # 6. 判断任务是否完成 if verify_task_complete(current_state, task_goal): task_finished True break # 输出路径记录和统计指标 generate_path_report(action_history, state_history)几个参数我给一下依据。max_steps 设 30 是因为模拟项目 X 的完整下单流程手工走大概需要 8 到 12 步给两倍余量足够应对探索开销再大就开始原地兜圈子了。similarity_threshold 设成 0.92 是经过 20 轮实验的比较值0.9 时会频繁把轮播图变化误判成新状态0.95 时又会漏掉真正的新页面0.92 在模拟项目 X 上平衡得最好。exploration_rate 设 0.15既能让 Agent 在个别页面尝试更多入口又不至于让路径太发散纯表单流程我会降到 0.05浏览型页面则调到 0.2。4.3 路径规划效果与评估我在模拟项目 X 上分别跑了纯随机操作、无历史记录的 Agent、带历史记录和循环检测的完整 Agent 三种方案每种跑 20 轮统计结果如下。方案任务完成率平均路径长度状态覆盖率稳定性10轮通过率纯随机操作45%24.6步38%20%Agent 无历史记录80%15.2步52%60%Agent 完整版历史循环检测白名单95%9.8步61%90%完整版 Agent 在任务完成率上明显领先平均路径长度比纯随机缩短了一半以上稳定性也达到了可接受的标准。最让我意外的是状态覆盖率的提升——因为循环检测避免了反复点击同一批元素Agent 反而有更多机会走到之前没探索过的页面探索效率比纯随机高很多。这组数据证明了一个结论多模态决策的真正价值不只是“能读懂界面”而是“能用读懂的界面信息做出全局更优的路径选择”。没有决策能力的随机点击就算跑再久也摸不清业务边界。5. 实测中出现的高频问题与排查技巧5.1 高频问题速查表以下是模拟项目 X 迭代过程中我记录次数最多的问题每条都附上了排查思路和解决方案可以直接当参考表用。问题现象可能原因排查方法解决方式Agent 反复点击同一个位置页面无变化状态相似度阈值过低或页面反馈效果不明显回看步记录里状态指纹是否变化调高阈值到 0.93 以上增加状态签名里的 OCR 文本权重Agent 点击页面上不存在的元素感知层候选控件列表不完整提示词缺少存在性校验检查 OCR 文本和控件树是否覆盖查看 Agent 输出理由在提示词中强制要求“仅从候选列表中选择目标”多步骤长任务后半程开始乱点历史记录给得太少上下文丢失查看最近 5 步动作是否与任务目标脱节把历史记录从 5 步增加到 8 步或增加 milestone 状态页面加载慢导致截图拍到半成品等待条件不足只用了固定 sleep观察日志里截图时间点和网络请求时间是否匹配改成网络空闲加关键元素出现双重等待Agent 在弹窗和首页之间来回切换循环检测没有命中或检测到了但没有强制改道检查状态哈希表确认弹窗状态指纹是否独立循环时强制随机探索一次并标记该状态已遍历输入框测试数据被页面自行清空输入太快触发校验或输入前焦点未对准慢放动作录像观察输入前后屏幕差异每个输入动作前先点击一次目标框再输入5.2 规避路径规划跑偏的三个独家技巧第一个技巧是强制 Agent 输出“动作理由”。这个字段看似和测试结果无关却是排查效率的最大杠杆。有一次路径规划到第 12 步突然回首页我打开步记录看到理由写着“检测到购物车图标上有角标认为需要先回首页检查消息中心”立刻意识到问题出在模型对图标的语义理解偏差上。没有理由字段这段误判可能还要花半天去推测。第二个技巧是给 Agent 装一个“轨迹回放器”。每执行一步就把当轮截图、OCR 文本、候选动作、模型输出和最终动作结果打包存成一份 JSON 文件。路径规划失败时用这个文件逐帧回放能精确看到是哪一步决策出错、当时屏幕上有什么、模型为什么做出这个选择。我在实际调试中对这个工具的依赖程度远超日志打印它基本就是测试路径规划的飞行记录仪。第三个技巧是对模型本身的置信度设一个兜底规则。当多模态模型的输出置信度低于某个阈值时不直接把控制权交给它而是退回结构化控件树做一次决策仲裁。比如模型说“点击右上角按钮”但置信度只有 0.6同时控件树显示右上角有一个“菜单”按钮那就优先点击菜单按钮。这套混合决策机制极大地降低了模型幻觉带来的风险代价只是每轮多付出几十毫秒的仲裁时间完全可接受。还有一点很实际的建议先不要追求让多模态 Agent 全自动跑完整条业务链路。我在初期让 Agent 自由规划完整流程时成功率一直上不去后来改成双人模式——Agent 负责生成路径规划和探索建议测试工程师审核跑过一轮之后再放开自动执行——这个过渡帮我把整体稳定性从 60% 拉到了 90% 以上。多模态 Agent 不是一上来就能当主力用的把它当好用的规划器、探路器、视觉巡检器再逐步扩大自动执行范围才是更稳妥的落地路径。我在模拟项目 X 上反复跑了几轮之后最直观的感受是多模态 Agent 让路径规划从“写脚本”变成了“描述意图”。以前测试工程师是在跟代码搏斗现在是在跟屏幕对话这中间省掉的维护成本是数量级的。但也不要神话它Agent 仍然需要清晰的边界、严格的输出约束和精细的参数调校。后续如果想继续扩展可以把 Agent 规划出的路径自动转成传统自动化脚本实现“探索和回归”的闭环也可以加入更多样的视觉断言让路径规划在探索过程中顺便完成一轮基础视觉巡检。这条路线的上限很高但每一步都要踩实了再走。