1. 多模态 Agent 做 UI 测试到底难在哪UI 测试这件事做过的人都懂——写起来不难维护起来要命。一个按钮挪了位置、一个弹窗改了文案、一个加载动画多转了半秒传统基于选择器的自动化脚本就可能集体飘红。而多模态 Agent 的出现让很多人看到了用自然语言描述意图让 Agent 自己看着屏幕去点的可能性。但真把它拉到项目里跑一圈就会发现能看懂界面和能规划出一条稳定的测试路径完全是两码事。我最近几个月一直在折腾多模态 Agent 在 UI 测试场景下的落地从最开始的截图丢给模型让它告诉我点哪到后来搭出一套还算能用的路径规划框架中间踩的坑足够写一本小册子。这篇就把我理解的多模态 Agent 规划 UI 测试路径这件事拆开讲清楚它是什么、为什么难、核心思路怎么设计、具体怎么落地、以及那些文档里不会写的坑。先说清楚适用人群。如果你是完全没接触过 UI 自动化的新手这篇能帮你建立整体认知知道这条路大概长什么样如果你已经在用 Selenium、Playwright、Appium 这类工具写脚本那这篇的价值在于告诉你怎么把多模态能力嵌进现有流程而不是推倒重来。核心关键词就三个多模态感知、路径规划、UI 测试稳定性。我先把结论摆前面多模态 Agent 规划 UI 测试路径本质上是把看屏幕—理解状态—决定下一步—执行动作—验证结果这个循环从硬编码的选择器逻辑换成基于视觉和语义的动态决策。难点不在于单步能不能点对而在于多步之间的状态衔接和异常兜底。下面逐层拆。2. 核心思路拆解为什么不能只靠看图点击2.1 传统 UI 测试的路径是写死的传统脚本的测试路径本质是一条预先编排好的状态机。你写click(#login-btn)是因为你知道登录按钮的 id 是login-btn。这条路径的每一步都依赖一个稳定的锚点——id、class、XPath、文本内容。问题在于现代前端框架React、Vue、Flutter、各种跨端方案生成的 DOM 结构经常变class 名可能是哈希值文本可能被国际化替换元素可能被虚拟列表懒加载。锚点一断路径就断。我见过最夸张的一个项目一个列表页的 class 名每次构建都会变导致基于 class 的脚本每周都要修。后来团队改成基于文本定位结果产品把提交改成确认提交脚本又挂了一片。这就是硬编码路径的宿命它假设界面是静止的但界面从来不是静止的。2.2 多模态 Agent 的路径是算出来的多模态 Agent 的思路完全不同。它不预先写死每一步点哪里而是每一步都重新看当前屏幕结合测试目标动态决定下一步动作。这里的看包括截图视觉、可访问性树结构、甚至 OCR 出来的文本语义。Agent 拿到这些信息后推理出当前处于登录页目标是进入订单列表那么下一步应该填写用户名。这个转变的意义在于路径从静态资产变成了动态决策。界面变了Agent 重新看一遍就能适应不需要人去改脚本。听起来很美但代价是——每一步决策都可能出错而且错误会累积。第一步点错了后面全错。所以多模态 Agent 规划路径的核心挑战不是能不能看懂而是怎么保证多步决策的鲁棒性。2.3 路径规划的三个层次我把多模态 Agent 的 UI 测试路径规划拆成三个层次理解这三层后面的实操就有章可循。第一层是单步动作决策当前屏幕状态下为了推进测试目标应该执行什么动作点击、输入、滑动、等待。这一层主要靠视觉 grounding 能力把登录按钮这个语义映射到屏幕上的具体坐标或元素。第二层是多步路径编排从当前状态到目标状态需要经过哪些中间状态每步之间的依赖关系是什么。这一层需要 Agent 有任务分解能力把完成下单拆成登录→搜索商品→加入购物车→结算→支付。第三层是异常恢复与重规划某一步失败或界面出现意外弹窗、广告、加载失败时Agent 能不能识别异常并重新规划路径。这一层是最难的也是决定 Agent 能不能上生产的关键。提示很多团队一上来就追求第一层的准确率忽略了第二、三层结果 demo 很惊艳一上真实环境就崩。我的建议是三层同步推进哪怕第二、三层先用简单规则兜底。3. 多模态感知层怎么搭截图、结构树、文本三路融合3.1 为什么单靠截图不够纯视觉方案听起来最通用——反正人怎么看屏幕Agent 就怎么看。但实测下来纯截图有几个硬伤。一是小元素识别不准比如一个 16x16 的关闭图标截图缩放到模型输入尺寸后可能就糊了。二是文本密集区域容易串行表格里一堆相似文字模型可能把 A 行的内容对应到 B 行的按钮。三是无法获取隐藏信息比如某个按钮当前是 disabled 状态截图上看只是颜色淡一点模型不一定能判断。所以我的做法是三路融合截图负责整体布局和视觉元素可访问性树负责精确的元素边界和属性OCR 负责兜底那些结构树里没有的文本比如 canvas 渲染的内容。3.2 可访问性树的取舍可访问性树Accessibility Tree是移动端和 Web 端都有的结构它比 DOM 更接近用户感知到的界面。但直接用完整树有个问题节点太多噪声太大。一个复杂页面可能有上千个节点全丢给模型既慢又容易干扰判断。我的处理方式是做剪枝只保留可见的、可交互的、有文本的节点并且把嵌套层级压平。具体规则是——过滤掉visiblefalse的节点过滤掉纯布局容器没有文本也没有交互事件的把每个可交互节点的关键属性类型、文本、边界框、是否可用提取成一个扁平列表。这样一棵上千节点的树通常能压到几十个有效节点模型处理起来轻松很多。3.3 三路信息的对齐三路信息拿到后需要对齐到同一个坐标系。截图有像素坐标结构树有边界框OCR 有文本框。我的做法是以结构树的边界框为主坐标系把 OCR 的文本框按重叠面积匹配到结构树节点上截图则作为整体背景提供给模型做视觉参考。对齐之后每个界面元素就有了一个统一的表示{类型, 文本, 边界框, 是否可用, 视觉截图片段}。这个表示既给了模型语义信息也给了它视觉信息还给了它精确的位置信息。实测下来这种融合表示比任何单路输入都稳。感知通道优势劣势适用场景截图布局直观、视觉元素全小元素糊、文本易串整体布局判断、图标识别可访问性树属性精确、边界准节点多、canvas 缺失元素定位、状态判断OCR文本兜底、canvas 友好无结构、易误识别文本密集区、自绘内容注意三路融合会增加预处理耗时。如果测试对速度敏感可以做成按需融合——先用结构树尝试定位定位不到再启用 OCR 和截图。4. 路径规划的核心从目标到动作序列的推理链4.1 任务分解把完成下单拆成可执行步骤多模态 Agent 拿到的是一个高层目标比如验证用户能成功下单。这个目标不能直接变成动作需要先分解。我的做法是维护一个领域知识库里面存着常见业务流程的步骤模板。比如电商下单模板是登录→搜索→选品→加购→结算→支付→确认。但模板不能写死因为不同产品的流程细节不一样。所以模板只提供步骤骨架具体每步怎么执行还是由 Agent 根据当前界面动态决定。这样既有结构约束又保留了灵活性。分解的粒度也很关键。太粗比如完成结算一步Agent 不知道具体点哪太细比如移动鼠标到坐标 (100,200)又失去了语义。我的经验是**分解到一个可交互元素上的一个动作**这个粒度最合适比如点击购物车图标、在搜索框输入关键词。4.2 状态表示Agent 怎么知道我现在在哪路径规划的前提是知道当前状态。多模态 Agent 的状态表示我通常用页面指纹 任务进度的组合。页面指纹是从当前感知信息里提取的特征比如页面标题、关键元素集合、URL如果有。任务进度是当前完成了流程模板里的哪几步。有了这两个Agent 就能判断我现在在登录页任务进度是 0/7下一步自然就是执行登录。如果页面指纹匹配不上任何已知状态说明出现了异常页面比如错误提示、验证码需要走异常处理分支。这里有个坑页面指纹不能太细。如果指纹包含每个元素的精确坐标那页面稍微动一下指纹就变了。我的做法是指纹只包含语义级特征——页面标题、主要区域的关键文本、核心交互元素的存在性。这样页面布局变了指纹依然稳定。4.3 动作空间设计Agent 能执行的动作需要预先定义好这就是动作空间。UI 测试里常用的动作有点击、输入、滑动、长按、返回、等待、截图断言。每个动作需要参数比如点击需要目标元素输入需要目标元素和文本。动作空间设计的关键是参数怎么给。如果让模型直接输出坐标精度不够如果让模型输出元素 id又依赖结构树稳定。我的折中方案是模型输出目标元素的语义描述比如登录按钮然后由一个定位器模块把语义描述映射到具体元素。定位器可以综合结构树、OCR、视觉匹配多种手段比模型直接输出坐标稳得多。4.4 推理链的组织把上面几块串起来一次完整的路径规划推理链是这样的感知当前界面生成元素列表和页面指纹根据页面指纹和任务进度确定当前状态从领域知识库取出当前状态对应的候选动作结合界面元素把候选动作实例化为具体动作含目标元素执行动作感知新界面验证是否推进了任务进度若否则触发重规划这个链条里第 3 步和第 6 步是保证鲁棒性的关键。第 3 步用知识库约束了动作空间避免模型乱点第 6 步用进度验证做了闭环避免错误累积。5. 实操落地一套可复现的 Agent 测试框架5.1 整体架构我搭的这套框架分四层感知层、规划层、执行层、验证层。感知层负责三路信息采集和融合规划层负责状态判断和路径生成执行层负责把动作落到具体设备或浏览器上验证层负责断言和异常检测。层与层之间通过一个共享状态对象通信这个对象里存着当前界面元素、页面指纹、任务进度、历史动作。这样任何一层都能拿到全局信息方便调试。5.2 感知层实现要点感知层的核心是采集频率和时机。不能每一步都全量采集太慢也不能采集太少信息不够。我的做法是动作后必采动作前按需采。每次执行完一个动作等界面稳定用等待策略判断然后全量采集一次。动作前如果距上次采集超过一定时间或者界面有变化迹象再补采一次。界面稳定的判断是个细节。简单做法是等固定时间但不可靠。我的做法是连续两次截图差异小于阈值就算稳定。阈值需要根据应用调动画多的应用阈值放宽静态页面收紧。5.3 规划层的提示词设计规划层用大模型做推理提示词设计直接决定效果。我的提示词结构是角色你是一个 UI 测试路径规划器。 当前任务{任务描述} 任务进度{已完成步骤}/{总步骤} 当前界面元素{元素列表} 历史动作{最近N步动作} 请输出下一步动作格式为 JSON{action: ..., target: ..., params: {...}}几个关键点一是元素列表要精简只给可交互元素二是历史动作要限制长度太长会干扰三是输出格式要严格方便程序解析。我试过让模型输出自然语言再解析错误率明显高于直接输出 JSON。5.4 执行层的容错执行层最容易出问题的是动作执行失败。比如点击了一个坐标但那个位置当时没有元素界面刚好在动画。我的做法是执行前二次确认目标元素存在且可用执行后验证界面有预期变化。如果没变化重试一次再失败标记该步失败触发重规划。重试策略也有讲究。不能无脑重试因为有些失败是界面真的变了重试也没用。我的策略是同一动作最多重试两次且两次之间要重新感知界面。如果重试后界面指纹变了说明是界面变化导致的失败直接走重规划。5.5 验证层的断言设计验证层不只是最后断言结果而是每一步都做轻量验证。比如点击登录后验证是否出现了登录后的特征元素用户头像、退出按钮。这种中间验证能及早发现问题避免错误累积到最后才暴露。断言的设计要宽松但有意义。太严界面小改就挂太松等于没验证。我的经验是断言语义级特征比如存在文本包含订单的元素而不是存在 id 为 order-list 的元素。6. 常见问题与排查技巧实录6.1 模型点错元素怎么办这是最高频的问题。排查思路分三步先看感知层给的元素列表里目标元素在不在、描述准不准再看规划层输出的目标描述和感知层的元素能不能对上最后看定位器把描述映射到元素时是不是映射错了。我遇到最多的情况是感知层元素描述不准。比如一个按钮的可访问性文本是空的OCR 又没识别出来那模型就不知道这个按钮是干嘛的。解决办法是给感知层加视觉描述兜底——对没有文本的元素用一个小视觉模型生成描述比如一个蓝色的圆形按钮中间有加号。6.2 路径走偏了怎么拉回来路径走偏通常表现为Agent 连续几步动作后页面指纹和任务进度对不上。这时候需要重规划。重规划不是从头再来而是从当前实际状态重新规划到目标。我的做法是维护一个已确认完成的步骤集合重规划时跳过这些步骤从当前状态继续。重规划的频率要控制。如果频繁重规划说明感知或规划有问题需要停下来排查而不是让 Agent 一直重试。6.3 界面加载慢导致的误判界面加载慢是 UI 测试的老大难。Agent 看到的是加载中的界面以为元素不存在就报错了。解决办法是等待策略要智能。我的做法是结合三种信号网络请求静默、界面截图稳定、关键元素出现。三者满足其二才认为加载完成。6.4 弹窗和广告的干扰真实环境里弹窗和广告防不胜防。Agent 需要能识别这不是我任务流程里的界面然后处理掉关闭弹窗再继续。我的做法是在规划层加一个异常界面识别分支如果当前页面指纹匹配不上任何已知状态且存在关闭类元素X 图标、跳过按钮就优先执行关闭动作。问题类型典型表现排查方向解决手段点错元素动作执行了但没效果感知描述、定位映射视觉描述兜底、定位器多路融合路径走偏连续动作后状态不符规划逻辑、状态判断重规划、进度校验加载误判元素找不到但实际存在等待策略多信号等待弹窗干扰出现未知界面异常识别关闭类动作优先6.5 几个我踩过的坑第一个坑是过度依赖模型输出坐标。早期我让模型直接输出点击坐标结果模型对坐标的估计误差经常在几十像素小按钮根本点不中。后来改成输出语义描述 定位器映射准确率大幅提升。第二个坑是忽略历史动作的上下文。有一次 Agent 在同一个按钮上连续点了三次因为每次点完界面变化很小它以为没点上。后来在提示词里加了历史动作并告诉模型如果最近三步有相同动作考虑换策略这个问题就解决了。第三个坑是验证太严导致误报。早期我用精确文本匹配做断言结果产品改了个标点符号测试就挂了。后来改成模糊匹配 语义判断误报率降了很多。提示多模态 Agent 的调试日志一定要详细。每一步的感知结果、规划输出、执行结果、验证结论都要记下来不然出了问题根本不知道是哪一层的事。7. 性能与成本让 Agent 跑得又快又省7.1 感知层的开销控制三路感知里截图和 OCR 是开销大头。我的优化是按需启用结构树能定位到的元素不跑 OCR结构树覆盖不到的区域才跑 OCR。截图也不是每步都全屏截可以只截变化区域。7.2 模型调用的优化大模型调用是另一个成本大头。优化手段有几个一是缓存相同页面指纹的规划结果可以缓存复用二是小模型分流简单的状态判断用小模型复杂的路径规划才用大模型三是批处理把多个待判断的元素打包一次调用。7.3 并行化UI 测试天然可以并行——不同用例跑在不同设备或浏览器实例上。但多模态 Agent 的并行要注意资源竞争尤其是模型调用的并发限制。我的做法是用一个任务队列统一调度控制并发数避免把模型服务打爆。8. 这套方案适合什么场景不适合什么场景多模态 Agent 规划 UI 测试路径最适合界面变化频繁、传统脚本维护成本高的场景。比如快速迭代的 C 端产品、多端适配的项目、有大量自绘 UI 的应用。这些场景下Agent 的适应性优势能明显体现。但它也不是万能的。对执行速度和确定性要求极高的场景比如高频交易系统的界面测试传统脚本反而更合适因为 Agent 的推理有延迟且存在不确定性。另外界面极其简单稳定的项目用 Agent 属于杀鸡用牛刀维护 Agent 框架的成本可能比维护脚本还高。我的建议是混合使用核心稳定流程用传统脚本易变流程和探索性测试用 Agent。两者共享同一套断言和报告体系这样既能保证稳定性又能覆盖变化。最后分享一个我在实际项目里总结的小技巧让 Agent 记录成功路径。每次成功完成一个测试用例把完整的动作序列和对应的界面指纹存下来。下次遇到相同页面指纹可以直接复用成功路径跳过规划推理。这样既省了模型调用又提高了稳定性。这个机制我称之为路径记忆实测能把重复用例的执行时间降一半以上。