接手UI自动化项目的人应该都有同感真正难的根本不是写断言、搭框架而是怎么让测试稳定地跑到那些埋在层层交互后面的页面。传统做法是靠人手动点一遍把路径录下来写成脚本。可只要UI改一个入口文案、挪一个按钮位置脚本就废掉更不用说那些藏在二级菜单、弹窗逻辑里的分支路径测试覆盖率全靠人工记忆硬撑。我最近在一套跨平台系统的UI测试里引入了多模态Agent来规划测试路径。简单说让Agent像人一样看屏幕截图、理解界面结构再自主决定下一步点哪里、输什么内容、什么时候回退最后把探索到的路径自动沉淀成可回归的测试用例。实测下来对于那种菜单层级深、状态切换多、组合条件复杂的界面路径发现效率比人工录制高出不少而且UI小改动后Agent能自适应调整不用每改一次界面就重录一遍脚本。这篇文章就把这套思路从头到尾拆一遍。适合正在被UI自动化维护成本折磨的同学也适合想了解多模态模型怎么落地到测试场景的读者。我会把感知层的设计、路径规划的决策逻辑、主控循环怎么搭、常见坑怎么避开一次性写清楚。1. 先聊明白UI测试路径规划到底难在哪1.1 传统UI自动化的痛点脚本固化、选择器脆弱、只能验证预设路径传统UI自动化的核心思路是录制回放 固定断言。测试人员手动走一遍业务流工具把每一步操作记录成脚本之后每次回归都重复执行。问题就出在固定这两个字上一旦界面元素发生变化脚本里的选择器就会失效。举个例子某个配置中心的入口从左侧导航栏挪到了首页工具栏测试人员需要手动修改若干条用例里的元素定位路径。改动小还好要是涉及几十个页面、上百条用例这一个改动就能耗掉大半天。更隐蔽的问题是业务状态导致的路径漂移。比如某个流程依赖前置状态测试路径必须先进入特定条件分支再操作人工漏掉一个前置步骤脚本跑起来就会莫名其妙地失败而且很难排查。还有一层更容易被忽略传统脚本验证的都是预设路径你录过什么它就跑什么。那些在真实的用户操作习惯里有可能出现的路径——比如先切到某个Tab再返回、快速双击、在加载动画期间点击——几乎不会被覆盖到。这些恰恰又是最容易出线上事故的交互。1.2 为什么是多模态Agent核心在于感知能力对齐人眼多模态Agent解决的核心问题不是自动执行而是自主探索。它的感知层直接吃截图和布局文本相当于拿人眼的输入方式去理解界面。人的点击依据是视觉可见的比如右上角有个蓝色按钮这个弹窗里第一个选项是黑色粗体字而多模态模型恰好擅长这种视觉加语义的综合判断。这跟传统基于源码级DOM解析的自动化有本质区别。传统自动化拿到的元素树虽然结构化但很多视觉上明确、DOM里没有语义信息的区域比如Canvas绘制的图表、视频播放器的控制条、地图组件传统方式根本定位不到。而多模态Agent把这些统统视为我看到的像素不需要额外接入定制化的组件SDK就能操作。我在实践中最大的感受是多模态Agent生成的路径是意图级的而不是坐标级的。它理解当前页面的业务含义再决定下一步操作。这种能力让它面对UI改动时具备一定的自适应性——按钮位置改了但文案还在模型依然能通过语义定位找到可点击目标路径规划就不会全盘崩溃。1.3 核心需求拆解感知、意图与决策三条线把规划UI测试路径这件事拆开看底层有三条能力线要打通。第一是感知。Agent需要回答当前屏幕上有什么包括哪些区域可交互、元素之间的层级关系、弹窗是否遮挡了主界面。这一层的难点在于用视觉方式还原出结构化的UI状态而不是简单返回一张图。第二是意图理解。Agent要回答当前任务需要做什么。同样是配置一个告警规则落到UI上的操作可能是先填表单、再点确认、然后验证列表里出现新条目。意图理解如果不到位后续所有决策都是空转。第三是决策规划。Agent要回答下一步点哪里、什么时候需要回退、路径搜索遇到死路怎么处理。这一层直接决定了路径的质量和覆盖率也是整个方案里最考验设计的地方。这三条线缺一不可。感知弱Agent会对着错误的界面瞎规划意图弱Agent做的事跟任务目标南辕北辙决策弱Agent会在一个状态里原地打转路径永远探索不出去。2. 让Agent看见界面多模态感知层的设计与选型2.1 先解决三个基本问题看见、认到、定位到感知层看起来只是给模型传一张截图实际要过三个关卡。看见指的是图像输入通道要通。正常情况下直接截取当前窗口需要做的预处理很少。但截图分辨率如果超过视觉模型支持的输入上限就必须考虑缩放或切片否则模型对远距离小元素的感知会失真。认到指的是模型能从截图中区分出这是一个输入框这是一组Tab这是一个不可点击的普通标签。这一步依赖视觉语言模型本身的UI理解能力。市面上的通用模型对常见组件的识别都还可以但如果界面里大量使用自定义控件、不规则图标就需要针对性补充示例提示或者在测试样本上做小规模微调。定位到指的是把语义描述映射到屏幕上的具体坐标或区域。比如模型说点击登录按钮坐标落在哪里。这个环节属于UI grounding能力也是我选型时最关注的维度。一个简单验证方法把一张截图发给模型要求它输出确认按钮的中心坐标看它与标注框交并比是否稳定。2.2 截图预处理分辨率、缩放与分区域喂图截图不是随便扔给模型就行。我踩过最明显的坑是高分屏下整张截图直接上传模型要么忽略角落区域要么把坐标换算搞得一塌糊涂。我在实践中采用的方案是三步走。第一步截取全屏视图统一等比缩放到视觉模型推荐的最长边尺寸比如1280或者1024保持宽高比。第二步做分区域增强如果界面信息密度高把截图按网格切分成若干块配合这是页面的左上区域的补充说明分别让模型分析最后汇总。第三步是关键——坐标换算。模型感知到的是缩放后的坐标系执行点击时必须按缩放比例映射回真实屏幕坐标否则误差会直接转化成点击失败。很多人会忽略的一个小细节截图里鼠标光标也会被拍进去模型有时会把光标当成一个UI元素来理解。我在执行截图前会先把光标移走或者统一隐藏系统指针有效避免了这类幽灵元素导致的路径规划偏差。2.3 双通道输入截图加布局文本优势互补只用截图有一个明显短板视觉模型对密集列表、长文本内容的精确识别能力不够稳定。比如一堆商品名称旁边对应的具体价格数字看是看得见但OCR级别的精确输出可能出错。我的方案是截图 布局文本双通道。截图为模型提供空间布局和视觉层次同时在请求里附上一份精简的布局树文本包含关键元素的文本内容、大致位置和类型标注。这听起来有点像DOM树但注意区别布局文本是我从系统辅助功能接口或者渲染管线里抽取出来的简化表示内容只包含模型决策需要的关键字段。双通道的好处是在空间感知和语义精度之间取平衡。模型先通过布局文本建立准确的元素清单再通过截图验证每个元素的视觉状态。比如某个按钮上虽有文案确认但截图显示它处于置灰状态模型应当判定它不可点击而不是仅仅依据文本就规划点击动作。2.4 视觉模型的选型思路先看UI grounding再比上下文与延迟我只讲选型经验不指定具体厂商。模型选型有几个硬性评估点。第一是UI grounding准确率。准备一组带有标注框的UI截图样本让模型输出自然语言指令对应的元素坐标统计定位准确率。这个指标决定了路径规划的上限。第二是上下文长度和图像编码能力。UI路径规划是一个多轮决策过程Agent需要记忆已经访问过哪些页面轮次一多上下文窗口不够就会遗忘。图像编码质量也很关键目前主流方案普遍采用高分辨率视觉编码器对密集UI细节识别更好。第三是推理延迟和成本。路径探索阶段需要大量看-想-动循环单步延迟超过5秒的话一条路径跑下来体验会很差。我通常会准备两套模型快速模型负责常规状态识别精度更高的模型负责关键节点决策或者信息汇总在成本和效率之间做切分。如果你是第一次接手这类项目我的建议是先用容易获取的通用视觉语言模型把整条链路跑通不要一开始就追求最高的grounding精度链路通了之后再逐步替换或优化模型组件。3. 从看见到规划路径意图解析与状态决策3.1 任务意图解析把用户级需求翻译成UI原子操作路径规划的起点是任务意图解析。用户给Agent的需求往往是检查一下发布流程是否正常新增一条策略然后验证它在列表页展示。这种高层描述不能直接执行需要拆解成UI原子操作序列。直观理解就是人怎么完成这个任务。人在新增一条策略时脑子里会自然浮现出几个子任务进入新增页面、填写对应字段、保存、回到列表页确认数据。Agent要做同样的事但它是通过模型推理产生这个子任务序列的。我建议在主控循环里单独加一个任务解析阶段。第一次拿到任务描述时先让模型输出它在当前界面上的执行计划用文字描述预期步骤然后再进入具体执行循环。这样做有两个好处一是后续如果执行偏离计划可以判断是计划理解有问题还是执行环境变化了二是这段计划文本本身可以沉淀成未来人工审计路径的文档。3.2 状态表示与记忆三个关键状态必须分开记路径规划里最容易乱套的是状态。我自己的经验是把状态分成三层当前真实状态——模型从最新截图和布局文本中感知到的界面。这是决策的直接依据。目标状态——完成任务的判定条件。比如表单成功提交后出现的成功提示页列表中新增了一条记录且状态为运行中。目标状态要尽可能定义成可验证的断言而不是模糊的任务完成。已探索状态集合——记录Agent访问过的页面状态和操作序列。这层记忆用于避免循环探索和规划回退路径是路径规划能否收敛的核心。已探索状态的记录方式我是用状态签名来做的。把当前界面的关键特征页面标题、几个主按钮文案、核心Tab选中态拼成一个哈希字符串。每次动作执行后重新计算签名如果发现签名与历史某个状态完全一致且最近动作没有实质改变界面就判定进入了死循环触发回退分支。3.3 路径搜索策略深度优先为主条件分支做广度补充探索路径本质上是一个在界面状态空间里搜索最优轨迹的过程。我在实践中的策略组合是深度优先为主、条件分支广度补充。深度优先意味着沿着一条业务流一直往下走走到终点或死胡同再回溯。这条策略的优点是很符合人的操作直觉能快速打通主线路径适合大多数表单流程、引导流程。遇到分支页面——比如一个弹窗同时提供确定和取消两个功能——我倾向于把分支动作记录下来在主线跑完之后主动回到该分支状态探索备选路径这就相当于做了广度优先展开。还有一个重要的搜索维度是基于可疑元素的优先探索。模型识别到一个罕见的按钮或者一个从未见过的组件时优先点击它往往能发现意想不到的状态分支。我把这作为一种启发式规则注入到路径规划提示词里显著提高了对异常分支的覆盖能力。3.4 动作空间定义交互粒度决定了路径质量路径规划里的动作不能抽象成做某件事要细化为可执行、可验证的原子操作。我维护的动作空间包括点击附带坐标和语义描述、输入附带文本内容和目标字段描述、滑动附带方向和距离、长按、等待、回退、刷新。每个动作执行之后都跟着一次观察点更新状态和结果评估。这里有一个初学者容易犯的错误把输入动作直接绑定到具体的框而没有记录这个框的语义特征。一旦界面布局变化输入的定位就失效。我的做法是每个动作同时保存语义描述和位置坐标。执行时优先按语义描述让模型重新定位找不到再退而使用坐标这种双保险机制让动作的鲁棒性提升非常明显。不要小看等待这个动作。界面加载动画、网络请求返回、数据渲染都是非瞬时状态变化。规划路径时Agent要学会根据界面变化动态决定等待长短而不是固定睡几秒。当截图显示加载指示器消失且目标元素出现时才算状态稳定再执行下一步。4. 实操搭一个能跑通的多模态UI路径规划Agent4.1 整体架构主控循环加三个独立组件整条链路我建议拆成四个模块主控循环Orchestrator、感知引擎Perception、决策引擎Planner、执行器Executor。它们各司其职之间通过标准接口传递数据。主控循环是大脑负责调用感知引擎拉取当前状态把状态交给决策引擎生成下一步动作再把动作交给执行器去做最后接收回报判断是否完成或者需要回溯。就是这样一个看-想-动-验的循环。感知引擎屏蔽了不同平台截图接口和布局提取的差异。无论是桌面端、移动端还是Web端它输出的数据结构统一为截图路径 布局文本 可交互元素列表。决策引擎是纯模型推理模块负责把统一状态输入转化为动作。执行器会把模型给的语义动作转换成真正操作系统的鼠标键盘事件并返回执行结果。这样一个完整链路大约千行代码量核心实现思路见下面的伪代码class Orchestrator: def __init__(self, perception, planner, executor): self.perception perception self.planner planner self.executor executor self.visited set() def run(self, task): state self.perception.observe() task_plan self.planner.plan(task, state) for step in task_plan: result self.execute_step(step, task) if result.reached_goal: return self.export_path() return None def execute_step(self, step, task): state self.perception.observe() if self.detect_loop(state): self.executor.back() return action self.planner.decide(step, state) self.executor.perform(action) new_state self.perception.observe() self.remember(state, new_state, action) return Evaluation(state, new_state, task)实际项目中模块化很重要。路径探索过程中感知引擎可能被调用成百上千次如果感知和决策耦合在一起排查问题时完全无从下手。4.2 提示词模板双阶段设计让Agent不乱来我试过单条提示词一把梭给模型一个完整任务然后让它直接开玩效果并不理想——模型往往会一通乱点或者过度自信地跳到不存在的操作上。后来我改成系统提示词 用户提示词双阶段结构。系统提示词里放的是规则层包括你是UI测试路径探索Agent。你只能基于感知引擎提供的截图和布局文本做决策。 每次你只能输出一个动作格式必须是JSON。 坐标必须基于截图上的坐标空间并在动作字段里说明该元素的语义依据。 如果当前状态与任务无关优先点击取消/关闭回到上一个有意义的页面。 每5次动作后回顾一次已探索的状态清单如果连续多步没有状态变化主动回退。用户提示词放的是当前这一轮的决策输入包括任务描述、当前截图、布局文本以及历史动作摘要。这里有一个我反复调整出来的经验不要在提示词里塞太多的历史对话只需让模型看到最近三次动作和对应的状态摘要信息更多反而会干扰决策。4.3 动作执行与校验每一个动作都要闭环执行器不是简单把动作发出去就完事。每个动作在执行前后都要做快照校验。执行前感知引擎记录当前界面摘要确认这个元素确实存在且可交互执行后再次观察界面状态对比前后状态变化是否与预期一致。举个例子模型规划点击确定按钮后应该弹出二次确认弹窗。执行器点击后立刻重新取图如果发现弹窗没有出现就要把这次执行标记为动作无效果并反馈给决策引擎调整策略。这条反馈回路非常重要否则Agent会在错误的路径上越走越远而不自知。我在实现里还为每个动作加了一个效果分界面发生了预期变化记正分没有变化或出现意外页面记负分。当连续出现负分动作时主控循环会自动触发回退而不是让Agent继续在当前分支上消耗轮次。4.4 路径生成与输出探索结果沉淀成可回归的用例路径探索完成后Agent产出的是一个带语义标注的动作序列。这段序列不能直接当脚本用要再经过一轮路径固化处理。路径固化要做三件事。第一是去冗余把探索过程中产生的试错步骤删掉比如点错后的回退操作、多余的等待节奏只保留直接完成任务的最小动作序列。第二是加校验断言在每个关键状态节点补充界面上应当出现什么元素的描述让回归测试具备自我验证能力。第三是参数化把输入的测试数据抽成占位符这样同一路径可以配不同的输入数据跑多轮。我最终的导出格式倾向于结构化的数据文件而不是传统测试框架的函数代码。好处是路径数据与执行引擎解耦UI变化导致路径失效时可以直接用Agent重新探索生成新路径而不需要手写大量代码。5. 常见问题与排查技巧实录5.1 元素识别不准先看截图质量再谈模型能力我遇到过大量元素识别错乱的情况排查下来很多都不是模型的问题而是截图质量不过关。界面存在模糊效果、毛玻璃元素时静态截图会让模型产生理解偏差深色模式下部分控件对比度太低也会导致识别遗漏。排查建议先把截图用图像处理库做一次简单的清晰度统计如果区域模糊严重考虑调整系统显示缩放级别或者切换成更标准的渲染模式执行测试。除此之外界面文字偏小时要注意检查缩放后的截图是否仍能保持文字可读必要时为模型提供局部放大图。5.2 坐标偏移模型给的点击位置总是点歪这是路径规划里最让人抓狂的坑。我总结下来主要有三个原因截图缩放后坐标换算没做对模型对截图坐标系的理解偏差热区坐标与视觉中心坐标不一致。前两个好解决在坐标换算工具里统一处理就行。第三个比较隐蔽有些按钮的可点击区域并不是它的可见范围视觉模型按照可见文字中心输出坐标实际点击区却在别处。我的对策是在执行点击动作前额外调用一次元素命中检测判断目标坐标是否真的落在可交互区域如果不是则修正到有效热区。5.3 路径规划走进死循环怎么办死循环的根源在于Agent在一个界面状态里反复尝试相似操作而主控循环没有识别出来。我有两套应对机制。第一套是状态签名去重。前面提过把页面关键特征哈希化动作执行后重新计算签名一旦重复就回退。第二套是最大轮次限制。无论探索多么顺利都要为单个任务设置动作上限超限强制进入回退或终止流程避免测试挂起。实际项目中死循环往往还跟弹窗、遮罩有关。Agent以为自己在操作主界面实际上被某个透明遮罩拦住了每次点击都落在遮罩上界面状态不变。建议在状态签名里显式包含当前是否存在遮罩或弹窗的特征字段。5.4 Agent幻觉点了不该点的地方多模态模型偶尔会推断出界面上并不存在的元素比如提示词过度引导时模型脑补了一个确定按钮的位置。这类幻觉动作比定位不准更危险因为它会带着路径探索往错误的方向走。我的经验是给每个动作加元素依据字段模型必须输出它判定这个按钮存在的依据文本。执行前我对依据文本做一致性校验如果模型中提到的元素特征与布局文本明显不一致这条动作就会被拦截不让执行器执行。这个防线挽救了很多次测试运行。5.5 探索效率低单轮决策太慢跑一条路径要半小时效率问题是这类方案规模化应用最大的阻力。每步都要经过截图、上传、模型推理、动作执行、状态校验五个环节单轮耗时主要卡在模型推理上。优化手段可以优先考虑四个方向缩小截图分辨率到刚好能决策的程度用轻量模型做常规状态识别重模型只处理决策分支点把感知引擎抽出的布局文本精简到只保留可交互元素和关键文本同时在本地缓存重复出现的状态签名如果签名完全相同可以直接复用历史动作。我实测下来这四个方向叠加使用单轮决策时间最多可以压缩到原来的三分之一。对于日均回归上百条路径的团队来说这个优化幅度有实际意义。5.6 常见问题速查表现象直接原因排查/修复思路元素识别频繁出错截图质量低、界面模糊检查渲染清晰度、提高对比度、局部放大模型点击坐标偏右上坐标换算未考虑缩放比例统一缩放前后的坐标系使用中心点换算永远点不到确认框弹窗遮罩未识别状态签名中加入遮挡层特征识别后先关闭路径探索原地打转状态签名去重失效检查签名字段是否包含弹窗与加载状态动作依据与界面不符模型幻觉生成了不存在的元素强制输出依据文本执行前一致性校验单轮耗时过长模型推理大图传输降低分辨率、轻/重模型分层、本地缓存状态写在最后的一个经验这套多模态路径规划方案我做了快一年中间踩过无数坑最大的收获是意识到了一个问题多模态Agent不是传统自动化脚本的替代品它是一种路径产生器。它的价值是快速、大规模地探索UI空间把人类容易遗漏的路径找出来但真正进入稳定回归阶段还是需要把Agent产出的路径经过人工确认和固化再纳入常规测试体系。我现在的习惯是每周让Agent对核心业务模块做一次无约束自由探索把新发现的路径与既有用例对比有差异就人工判断是否需要补充进自动化回归集。这样既保留了Agent探索的广度又守住了回归测试的确定性。对这种方案感兴趣的读者我建议先从单个核心流程入手别急着全量铺开跑通之后再逐步扩大探索范围。