1. 从点按钮到看懂界面多模态 Agent 做 UI 测试的底层逻辑变了UI 自动化测试这件事做了几年的人都有一个共同感受脚本写得再漂亮界面一改就全废。传统方案靠的是选择器——XPath、CSS Selector、元素 ID本质上是在背坐标。页面结构一动坐标就失效维护成本高得离谱。而多模态 Agent 的出现把这件事的底层逻辑换掉了它不再依赖固定选择器而是像人一样看界面——截图、理解布局、识别控件语义再决定下一步点哪里。这就是多模态三个字的分量。所谓多模态指的是 Agent 能同时处理多种输入形态视觉截图、渲染画面、文本DOM 文本、可访问性树、页面文案、有时还包括结构化数据接口返回、日志。它把这些信息融合起来形成一个对当前界面的理解然后基于这个理解去规划测试路径。为什么这件事值得单独拿出来讲因为规划路径才是 UI 测试真正的难点。点击一个按钮不难难的是知道该点哪个按钮、按什么顺序点、点完之后界面应该变成什么样、如果没变成那样又该怎么回退或重试。传统脚本把这些决策全部硬编码在代码里而多模态 Agent 把决策交给了模型推理。这就带来一个全新的问题模型怎么规划出一条可靠的测试路径我先把结论摆出来多模态 Agent 规划 UI 测试路径核心是三步——感知界面状态、推理可达路径、验证执行结果。这三步循环往复构成一个闭环。听起来简单但每一步都有大量工程细节踩过的坑也不少。下面我按实际落地时会遇到的顺序把这件事拆开讲透。这篇文章适合三类人看正在做 UI 自动化、被选择器维护折磨的测试工程师想引入 Agent 能力但不知道从哪下手的开发以及对多模态模型落地感兴趣、想找一个具体场景练手的技术人。不管你是哪一类读完应该都能拿到一套可参考的思路和可复现的步骤。2. 感知层Agent 到底看到了什么决定了它能规划出什么2.1 三种界面表征方式各有各的坑多模态 Agent 感知界面主流有三种输入来源我逐个说清楚它们的优劣因为这直接决定了后续路径规划的质量。第一种是纯截图像素级视觉输入。这是最接近人类的方式Agent 拿到的就是一张渲染后的图片。优点是所见即所得不管前端用什么框架、DOM 多复杂截图里长什么样就是什么样。缺点是模型要自己从像素里识别出这是一个按钮那是一个输入框对视觉理解能力要求高而且坐标定位容易有偏差——模型说点这里换算成实际像素坐标时可能差几个像素点偏了就失败。第二种是可访问性树Accessibility Tree。这是操作系统或浏览器为辅助功能暴露的一套结构化描述每个节点带有角色button、textbox、link、名称、状态。优点是语义清晰Agent 不用猜这是不是按钮树里直接写着 rolebutton。缺点是很多前端组件根本没做好可访问性自定义组件在树里可能就是一个没有语义的 divAgent 照样抓瞎。第三种是DOM 结构 文本内容。这是最传统的优点是信息全缺点是噪声大——一个页面几千个节点模型塞进去容易迷失重点。实际落地时我的经验是三者融合效果最好截图给模型提供整体布局和视觉线索可访问性树提供语义标签DOM 文本补充细节文案。但融合不是简单拼接而是要做一个对齐——把可访问性树里的节点和截图里的区域对应起来这样模型说点击登录按钮时系统能同时知道它的语义节点和像素位置。2.2 界面表征的预处理别把原始数据直接喂给模型很多人第一次做的时候直接把整页截图和完整 DOM 丢给模型结果模型要么超长上下文爆掉要么抓不住重点。这里必须做预处理我总结了几个关键动作。截图要分块和标注。整页截图如果分辨率很高模型对小控件的识别会下降。常见做法是把页面按区域切分或者对疑似交互区域做高亮标注。我试过给截图叠加一层半透明的网格和坐标刻度模型在输出坐标时准确率明显提升——因为它有了参照系。可访问性树要剪枝。树里大量节点是不可交互的容器、装饰性元素这些对路径规划没用。剪枝策略是保留有交互角色button、link、textbox、checkbox 等的节点保留有文本内容的节点其余折叠。剪枝后节点数往往能从几千降到几十模型处理起来轻松很多。建立统一的元素索引。这是最关键的一步。不管输入来自截图还是树最终都要映射到一套统一的元素 ID 上。Agent 规划路径时说的是点击元素 E17而不是点击坐标 (320, 480)。这样即使页面滚动、布局微调只要元素还在ID 就还有效。这套索引机制是路径规划能稳定执行的基础。2.3 一个容易忽略的点状态快照要带时间戳和上下文UI 测试不是静态的页面会变。Agent 每次感知到的界面都是某一时刻的快照。如果不记录时间戳和操作上下文Agent 很容易刻舟求剑——它以为界面还是三步之前的样子结果点了个已经消失的按钮。我的做法是给每个快照打上标记当前 URL、上一步操作、操作后等待了多久、页面是否有加载动画。这些元信息一起喂给模型它才能判断现在这个界面是不是稳定了、能不能操作。实测下来加上这层上下文后Agent 误操作率能降一大截。3. 规划层路径不是搜出来的是推理 约束出来的3.1 为什么不能直接让模型自由发挥有人会想既然模型能看懂界面那直接告诉它帮我测登录流程让它自己一步步点不就行了理论上可以实际上一塌糊涂。原因有三模型可能走偏点进无关页面、可能循环在两个页面间反复横跳、可能漏测跳过了关键校验点。所以路径规划必须加约束。约束来自哪里来自测试意图的结构化表达。你不能只说测登录而要拆成输入合法账号密码 → 点击登录 → 校验跳转到首页 → 校验用户名显示正确。这些是测试用例的原子步骤Agent 的任务是在界面上找到实现每个步骤的路径而不是自由探索。3.2 把测试意图翻译成 Agent 能懂的目标序列这一步是规划层的核心。我通常把测试用例拆成一个目标序列每个目标包含三要素动作意图、目标元素描述、预期结果。举个例子登录流程拆完是这样步骤动作意图目标元素描述预期结果1输入用户名输入框框内出现输入文本2输入密码输入框框内出现掩码字符3点击登录按钮页面跳转或出现加载态4校验首页用户信息区显示当前用户名注意目标元素描述用的是自然语言不是选择器。这正是多模态 Agent 的价值——它根据描述去界面上找匹配的元素。描述写得越准匹配越稳。我踩过的坑是描述太模糊比如只写输入框页面上有三个输入框Agent 就懵了。后来改成位于表单第一行、标签为用户名的输入框命中率立刻上来了。3.3 路径推理从当前状态到目标状态怎么走有了目标序列Agent 要解决的是当前界面状态下怎么到达下一个目标。这是一个典型的规划问题但和传统规划不同这里的状态空间是界面动作是点击、输入、滚动、等待。我的实现思路是分层规划先做粗粒度规划确定大方向比如需要先打开登录弹窗再做细粒度规划确定具体点哪个元素。粗粒度规划靠模型对页面整体结构的理解细粒度规划靠元素匹配。这里有个实用技巧让模型输出候选路径而不是唯一路径。因为界面可能有多种到达方式比如登录入口可能在顶部导航也可能在侧边栏让模型列出 2-3 条候选系统按置信度排序优先尝试高置信度的失败了再试下一条。这比让模型赌一条路要稳得多。3.4 约束条件哪些路不能走规划必须带约束否则 Agent 会做出危险操作。常见约束包括禁止操作白名单外的元素比如删除按钮、支付按钮测试环境里要显式禁止或需要二次确认。步数上限防止 Agent 陷入循环一般单个目标超过 5 步还没达成就判定失败并回退。状态回退点每完成一个目标记录一个可回退的快照失败时能回到上一个稳定状态重试。超时控制每个动作后等待界面稳定的时间上限超时视为失败。这些约束不是限制 Agent 的能力而是保证它在可控范围内工作。我见过不加约束的 Agent在测试环境里把测试数据删了个精光教训很深刻。4. 执行与验证点完之后怎么知道点对了4.1 动作执行坐标点击 vs 语义点击Agent 决定点某个元素后执行层要把它落地。两种方式坐标点击和语义点击。坐标点击就是算出元素中心点的像素坐标模拟鼠标点过去。优点是通用什么界面都能点。缺点是脆弱页面稍微滚动或缩放就偏了。语义点击是通过可访问性接口或 DOM 事件直接触发元素优点是精准缺点是有些自定义组件不响应。我的做法是优先语义点击失败回退坐标点击。语义点击成功率高且稳定实在不行再用坐标兜底。实测这个组合能覆盖绝大多数场景。4.2 结果验证三种校验手段配合使用点完之后必须验证否则 Agent 不知道自己做对没有。验证手段有三种视觉校验对比操作前后的截图看预期区域是否发生变化。比如点击登录后页面应该从登录页变成首页截图差异会很明显。这种校验适合大范围的状态变化。语义校验检查可访问性树或 DOM 里是否出现了预期元素。比如登录成功后树里应该出现用户名相关的文本节点。这种校验精准适合细粒度判断。断言校验针对具体数据做判断比如输入的用户名是否真的显示在了页面上。这种校验最严格但需要预先知道预期值。实际用的时候三者是配合的视觉校验做快速判断语义校验做精确定位断言校验做最终确认。任何一层失败都触发重试或回退。4.3 失败处理重试、回退、还是放弃Agent 执行失败是常态关键是怎么处理。我的策略分三级瞬时失败比如元素还没加载出来等待后重试最多 3 次。路径失败比如这条路径走不通回退到上一个稳定状态尝试候选路径。目标失败所有路径都走不通标记该步骤失败记录现场截图 树 日志继续下一个目标或终止。这里有个经验失败现场一定要存全。截图、可访问性树、DOM、操作日志、时间戳一个都不能少。因为 Agent 失败的原因往往很隐蔽事后复盘时如果现场不全根本查不出来。我吃过这个亏后来强制要求每次失败都打包一份完整现场。5. 实战拆解一个登录流程的完整路径规划过程5.1 场景设定与初始状态假设我们要测一个 Web 应用的登录流程。初始状态是打开首页未登录页面右上角有登录入口。测试目标是完成登录并校验跳转。Agent 第一步感知界面截图显示页面顶部有导航栏右侧有登录文字可访问性树里对应节点 rolelinkname登录。Agent 判断当前状态是未登录首页下一个目标是打开登录界面。5.2 从首页到登录表单的路径推理Agent 分析要打开登录界面需要点击登录入口。候选路径有两条——点击顶部导航的登录链接或者滚动到底部找登录入口。模型根据布局判断顶部入口更直接置信度高选择第一条。执行语义点击登录链接。验证截图显示弹出了登录表单可访问性树里出现了用户名输入框、密码输入框、登录按钮。目标达成记录快照。5.3 表单填写与提交的路径规划下一个目标是填写表单并提交。Agent 拆解为输入用户名 → 输入密码 → 点击登录按钮。输入用户名Agent 在树里找到标签为用户名的输入框语义聚焦后输入测试账号。验证输入框 value 变化截图显示框内有文本。输入密码同理找到密码输入框输入密码。验证框内显示掩码。点击登录找到登录按钮语义点击。验证页面出现加载态随后跳转。5.4 跳转后的校验与异常分支跳转后Agent 感知新界面URL 变了页面出现用户信息区。校验树里出现当前用户名文本与输入一致。目标达成流程结束。但如果跳转失败呢比如密码错误页面停留在登录页并提示错误。Agent 的验证会发现URL 没变且出现了错误提示文本。这时它应该判定登录失败并根据测试用例的预期决定这是不是符合预期如果测的就是错误密码场景那反而是通过。这个异常分支的处理正是多模态 Agent 比传统脚本强的地方——它能看懂错误提示而不是死板地等某个元素出现。6. 踩坑实录那些让 Agent 规划失败的隐蔽原因6.1 动态加载与动画Agent 的时间感问题最常见的坑是页面还在加载Agent 就急着操作。比如点击登录后按钮有个 300ms 的禁用动画Agent 立刻去点下一个元素结果点了个寂寞。解决办法是给 Agent 加稳定等待逻辑每次操作后持续感知界面直到连续两次快照差异小于阈值才认为界面稳定。这个阈值要调太松会误判太紧会等太久。我的经验是截图差异率低于 2% 且持续 500ms基本可靠。6.2 元素描述歧义模型找错了目标前面提过描述太模糊会导致匹配错误。还有一个隐蔽情况页面上有多个同名元素比如两个提交按钮一个在表单里一个在弹窗里。Agent 如果只按名字找可能点错。解决办法是在元素描述里加入位置和上下文约束比如位于登录表单内的提交按钮。同时感知层要保留元素的层级关系让 Agent 能判断这个按钮属于哪个容器。6.3 视觉相似但语义不同的陷阱有些界面视觉上几乎一样但语义完全不同。比如确认和取消两个按钮颜色和大小可能一样只是文字不同。如果 Agent 主要靠视觉很容易点反。这就是为什么我一直强调视觉和语义要融合。纯视觉会点错纯语义在自定义组件上会失效两者结合才能既准又稳。6.4 上下文丢失多步操作后的失忆长流程测试中Agent 做了十几步操作后可能忘了最初的目标是什么或者忘了当前处于哪个页面。这是上下文管理的问题。我的做法是维护一个显式的状态机记录当前处于哪个测试步骤、已经完成了哪些、下一步该做什么。Agent 每次规划前先读状态机再做决策。这样即使模型本身失忆系统层面也不会乱。7. 让路径规划更稳的几个工程习惯7.1 给每个目标设定明确的完成信号Agent 判断一个目标是否完成不能靠感觉要有明确的信号。比如打开登录界面的完成信号是登录表单可见登录成功的完成信号是URL 变化且用户信息区出现。这些信号要提前定义好写进测试用例里。信号定义得越明确Agent 的验证越可靠。我见过太多因为完成信号模糊导致的误判——Agent 以为完成了其实只是页面碰巧长得像。7.2 路径规划要留逃生通道再好的规划也可能失败所以每条路径都要有回退方案。回退不是简单重来而是回到上一个已知稳定状态换一条路走。这要求系统能快速恢复到某个快照而不是从头开始。实现上我通常在每个目标完成后存一个快照回退时直接加载快照对应的界面状态比如重新导航到那个 URL或重置表单。这样回退成本低Agent 敢于尝试。7.3 日志要能复现整个决策过程Agent 的决策过程是黑盒出了问题很难查。所以日志必须记录每一步感知到了什么、模型输出了什么候选路径、为什么选了这条、执行结果如何。这些日志串起来才能复现整个决策链路。我的日志格式是结构化的每条记录包含时间戳、阶段感知/规划/执行/验证、输入摘要、输出摘要、结果。事后用脚本一跑整个流程一目了然。7.4 定期用回归集检验 Agent 的稳定性Agent 的规划能力会随模型版本、页面改版而波动。所以要建一个回归集包含各种典型场景正常流程、异常分支、边界情况定期跑一遍看通过率有没有下降。回归集不用大但要覆盖关键路径。我一般维护 20-30 个用例每次模型或页面有变动就跑一次能快速发现退化。8. 多模态 Agent 规划 UI 测试路径的边界与取舍8.1 它擅长什么不擅长什么多模态 Agent 擅长的是语义明确、界面规范、流程相对固定的测试场景比如登录、注册、表单提交、列表增删改查。这些场景里界面元素有清晰语义路径规划有章可循。它不擅长的是高度动态、视觉驱动、无明确语义的场景比如拖拽排序、画布绘图、游戏交互。这些场景里Agent 很难从界面理解出该做什么规划也就无从谈起。所以落地时要选对场景别指望 Agent 包打天下。传统脚本 Agent 混合使用往往是最务实的方案。8.2 成本与收益的权衡多模态 Agent 每次规划都要调用模型有推理成本。如果测试用例很多、跑得很频繁成本会上去。所以不是所有用例都值得用 Agent。我的取舍是核心流程、易变界面、维护成本高的用例用 Agent稳定界面、简单校验的用例用传统脚本。这样既享受了 Agent 的灵活性又控制了成本。8.3 人机协作Agent 规划人兜底现阶段完全无人值守的 Agent 测试还不现实。更实际的模式是Agent 负责规划和执行人负责定义测试意图、审核失败现场、处理异常情况。这种协作模式下Agent 承担了最繁琐的找元素、点元素、等加载工作人只需要关注测试逻辑本身。实测下来测试用例的编写和维护效率能提升不少尤其是界面频繁改版的项目。9. 我在这套方案里最看重的两个细节第一个细节是元素索引的稳定性。整套方案能不能长期跑下去很大程度上取决于元素索引会不会频繁失效。我的做法是索引不绑定具体坐标或 DOM 路径而是绑定语义指纹——元素的角色、名称、相对位置、所属容器。只要这些不变索引就有效。页面改版时只要语义没变Agent 照样能找到元素。第二个细节是失败现场的可复现性。Agent 失败不可怕可怕的是失败了查不出原因。所以我强制要求每次失败都打包完整现场并且现场要能重放——用同样的输入重新跑一遍能复现同样的失败。这要求感知层的输入是可序列化的执行层的动作是可重放的。做到这一点调试效率会高很多。这两个细节听起来不起眼但它们是整套方案能不能从 Demo 走向生产的关键。我见过太多方案在 Demo 阶段很惊艳一上生产就崩往往就是栽在这些工程细节上。最后分享一个我常用的小技巧在 Agent 规划路径时让它同时输出这条路径的置信度和如果失败最可能的原因。前者帮你决定要不要试这条路径后者帮你快速定位问题。这个技巧不增加多少成本但对调试帮助很大。