1. 从点按钮到看懂界面多模态 Agent 做 UI 测试到底难在哪UI 自动化测试这件事做过的人都懂一个尴尬脚本写得再漂亮界面一改版就集体阵亡。传统方案靠的是选择器——id、class、XPath、无障碍标签本质上是在猜界面元素的身份。可一旦产品经理把按钮从左边挪到右边、把文案从提交改成确认提交选择器就失效了测试用例跟着一起躺平。多模态 Agent 的出现让这件事有了另一种解法。它不再只盯着 DOM 树而是像人一样看界面截图进来模型理解这个页面长什么样、有哪些可交互区域、当前处于什么状态然后决定下一步点哪里、输入什么、怎么验证。这就是标题里说的规划 UI 测试路径——不是执行一条写死的脚本而是根据当前界面动态生成一条通往测试目标的路径。关键词其实就藏在标题里多模态视觉文本可能的语音/结构信息、Agent有感知、有决策、有行动循环、UI 测试路径规划从起点状态到目标验证点的动作序列。这三者叠在一起解决的是同一个核心痛点让测试脚本具备界面理解能力从而在界面变化时依然能跑通。这篇文章适合谁看如果你正在做自动化测试、质量保障或者对 Agent 落地感兴趣想搞清楚多模态模型怎么真正用起来而不是停留在 demo那这篇就是给你写的。我会从路径规划的核心机制讲起拆到感知层、决策层、执行层的具体设计再聊实测中那些文档里不会写的坑最后给一套可以照着搭的最小可行方案。全程按从业者视角来不绕弯子。先说一个反直觉的结论多模态 Agent 做 UI 测试最难的不是看懂界面而是知道什么时候该停。模型能识别按钮、能读文案这些能力现在的多模态模型基本都具备。真正让测试跑不稳的是路径规划里的终止条件判断、状态验证、以及异常分支处理。后面会重点展开。2. 路径规划的核心机制Agent 是怎么想出下一步的2.1 感知-决策-执行的三段式循环多模态 Agent 规划 UI 测试路径底层是一个不断重复的循环我习惯把它拆成三段感知Perceive拿到当前界面的多模态输入。通常包括一张截图视觉、一份可交互元素列表结构来自无障碍树或 DOM 精简信息、以及当前测试上下文文本比如我现在要验证登录失败提示。决策Decide把感知结果喂给多模态大模型让它输出下一步动作。动作空间一般定义成有限的几种点击某坐标/某元素、输入文本、滑动、等待、断言某状态、结束。执行Act把模型输出的动作翻译成真实的设备操作ADB 命令、WebDriver 调用、Playwright 动作等执行后再回到感知进入下一轮。这个循环听起来简单但每一段都有讲究。感知阶段最关键的是信息取舍截图给多大分辨率DOM 信息要不要全给给多了 token 爆炸、推理变慢给少了模型看不清。我的经验是截图按设备原生分辨率给但 DOM 只给可交互元素的精简列表每个元素保留类型、文案、坐标、是否可点击这样既省 token 又保留了关键结构信息。决策阶段的核心是动作空间设计。动作空间太大模型容易输出无效动作太小又覆盖不了复杂场景。我一般会定义这么几类动作类型参数典型用途click元素索引或坐标点击按钮、链接、输入框input元素索引 文本填写表单swipe起止坐标滚动列表、翻页wait毫秒数或条件等待加载、动画结束assert断言类型 期望值验证文案、元素存在性finish结果说明路径结束执行阶段最容易被忽略的是动作后的稳定性等待。界面点击后往往有动画、网络请求、渲染延迟如果立刻截图进入下一轮模型看到的是中间态决策就会错乱。我的做法是执行动作后先等一个网络空闲 无动画的信号再截图实在拿不到信号就固定等 500ms 到 1s宁可慢一点也别让模型看花眼。2.2 为什么用视觉结构双通道而不是纯视觉有人会问既然多模态模型能看图为什么还要喂 DOM 结构信息纯视觉不行吗实测下来纯视觉方案在简单页面上没问题但遇到这几类场景就吃力一是密集列表几十个长得差不多的条目模型很难精确区分第 3 个和第 4 个二是小图标按钮截图里就十几个像素模型识别不稳定三是动态文案模型读图可能读错字。而结构信息无障碍树恰好能补上这些——它明确告诉你这里有个按钮文案是删除坐标在 (x, y)。所以双通道的本质是互补视觉负责理解整体布局和语义这个页面是干嘛的、当前在哪个流程结构负责精确定位和操作。两者结合路径规划的准确率比单通道高出一大截。这也是多模态三个字在 UI 测试场景里最实在的落地方式——不是炫技是真的有用。2.3 路径规划里的目标分解逻辑一个完整的 UI 测试任务比如验证用户能用错误密码登录并看到提示对 Agent 来说不是一步到位的需要分解成子目标定位到用户名输入框输入正确用户名定位到密码输入框输入错误密码定位到登录按钮点击等待响应验证页面上出现密码错误类提示Agent 的规划能力体现在它不需要你把这五步写死而是给它一个高层目标验证错误密码登录提示它自己根据当前界面推断出下一步该做什么。这背后靠的是大模型的任务分解 状态追踪能力。模型在每一轮都会重新评估我现在离目标还差什么然后选一个动作。这里有个关键设计把高层目标作为每轮决策的固定上下文。也就是说不管循环到第几轮模型每次都能看到我的总目标是什么和我已经做了哪些动作。这样它才不会跑偏——比如点了登录之后忘了要验证提示直接去点别的。我见过不少 demo 就是因为没把历史动作和目标一起喂进去Agent 跑着跑着就失忆了。3. 感知层设计截图、结构树和上下文怎么喂给模型3.1 截图预处理分辨率、压缩与标注截图是感知层最重的输入。直接给原图有两个问题一是 token 消耗大二是模型对超大图的分辨能力反而下降。我的处理流程是这样的缩放把长边缩到 1280 到 1568 像素之间不同模型的最优区间不一样需要实测。太小的图看不清小字太大的图推理慢且容易丢细节。压缩用 JPEG 质量 80 左右PNG 在截图场景下体积太大没必要。标注这是关键一步。我会在截图上把可交互元素用带编号的框标出来编号和结构树里的索引一一对应。这样模型看到图上的3 号框就能直接对应到结构里的3 号元素定位精度大幅提升。标注框这个技巧是我踩坑之后才加的。早期不标注模型经常说点击右上角的按钮但页面上右上角有好几个按钮执行层就懵了。加了编号之后模型的输出直接是click 元素 7歧义消失。3.2 结构树精简只留有决策价值的信息无障碍树Accessibility Tree信息很全但全量喂给模型是灾难。我一般做三层过滤只保留可交互节点可点击、可输入、可滚动的其他装饰性节点全砍。保留关键属性类型button/input/text、文案、坐标、是否可用enabled、是否选中。扁平化把树结构压成列表每个元素带一个索引。模型不需要理解层级只需要知道有哪些元素、分别是什么。精简之后一个中等复杂页面的结构信息大概几十到一两百个 token完全可控。这里有个细节坐标要归一化。不同设备分辨率不同直接给绝对像素模型很难形成空间感。我一般归一化到 0 到 1000 的相对坐标模型理解起来更稳。3.3 上下文注入把测试意图讲清楚光有界面信息还不够模型得知道我在测什么。上下文一般包含三块总目标一句话描述这次测试要验证什么。历史动作之前每一步做了什么、结果如何。这个要精简不能把每轮的完整截图都塞进去一般只保留动作文本序列。当前约束比如不要点击删除类按钮最多执行 20 步。把这三块和感知信息拼成一个结构化的 prompt模型就能在理解界面 记住历史 对齐目标的基础上做决策。我实测下来上下文里历史动作的表述方式对结果影响很大。用已点击登录按钮页面跳转到首页这种自然语言描述比用action: click, target: 5这种机器格式模型的任务连贯性更好。提示上下文不是越多越好。我试过把每轮截图都保留在历史里结果 token 迅速爆掉而且模型被历史截图干扰反而看不清当前界面。历史只留文本动作序列当前界面只留最新截图这个组合最稳。4. 决策层让模型输出可执行的动作序列4.1 动作空间的边界设计决策层最容易翻车的地方是模型输出了执行层无法理解的动作。比如模型说滚动到页面底部但你的执行层只支持滑动指定坐标。所以动作空间必须先定死再让模型在这个空间里选。我的做法是用结构化输出JSON Schema 或函数调用约束模型。给模型一个动作列表每个动作有明确的参数定义模型只能从中选。这样执行层拿到的永远是合法动作不用做容错解析。但约束太死也有问题遇到动作空间覆盖不到的场景模型会硬套一个不合适的动作。所以我会留一个other动作让模型在实在无法用现有动作表达时输出自然语言说明由人工介入或记录为待扩展场景。这个other动作在早期迭代阶段特别有用能帮你发现动作空间的缺口。4.2 多步规划 vs 单步决策Agent 规划路径有两种模式单步决策每轮只看当前界面决定下一步。优点是简单、容错好走错一步下一轮能纠正。缺点是短视可能走进死胡同。多步规划一次性输出未来几步的动作序列。优点是全局性好缺点是界面一变后面几步全废。UI 测试场景我强烈推荐单步决策为主辅以轻量前瞻。原因是界面状态变化太快多步规划的前提界面按预期变化经常不成立。轻量前瞻的意思是让模型在决策时顺便说一句我这一步的目的是什么、预期界面会怎么变但不强制它输出后续步骤。这样既有全局意识又不会因为界面变化导致整条路径作废。实测对比过纯多步规划在稳定页面上效率高但一旦有弹窗、加载延迟、A/B 测试导致的界面差异失败率飙升。单步决策虽然步数多但鲁棒性好得多综合下来更划算。4.3 状态验证Agent 怎么判断我成功了这是整个路径规划里最被低估的环节。很多 demo 只关注能不能点到不关注点完之后对不对。但测试的本质是验证不是操作。Agent 判断成功一般靠这几种信号视觉信号截图上出现了预期文案或元素。比如登录失败后出现红色提示。结构信号无障碍树里出现了某个特定节点。状态信号URL 变化、页面标题变化、某个元素从 disabled 变 enabled。我的经验是优先用结构信号视觉信号做兜底。结构信号稳定、精确不受渲染样式影响视觉信号灵活能捕捉结构里没有的视觉反馈比如颜色变化、图标状态。两者结合验证的可靠性最高。这里有个坑验证时机。点完按钮立刻验证往往验证的是旧状态。必须等界面稳定后再验证。我的做法是把等待稳定作为验证动作的前置条件执行层确认界面无变化连续两次截图一致后才触发验证。5. 执行层与稳定性从模型输出到真实设备操作5.1 动作翻译与重试机制执行层拿到模型的动作要翻译成真实操作。这一步看似简单实则暗藏玄机。以点击为例模型给的是元素索引执行层要从结构树里查到该元素的坐标把归一化坐标还原成设备像素调用设备点击接口确认点击生效比如元素状态变化任何一步失败都要重试。重试策略我一般设三次间隔递增200ms、500ms、1s。三次都失败就把这个动作标记为失败反馈给决策层让模型重新规划。这里有个细节点击坐标的偏移。有些元素的可点击区域和视觉区域不一致直接点中心可能点不中。我的做法是优先用元素中心如果连续失败尝试在元素区域内随机偏移几个点。这个技巧在处理某些自定义控件时特别管用。5.2 界面变化的检测与等待前面反复提到等界面稳定具体怎么实现我的方案是截图差分执行动作后每隔 200ms 截一张图连续两张图的差异小于阈值比如 1% 像素变化认为界面稳定最多等 5 秒超时则强制进入下一轮这个方案简单有效但要注意两点一是有些页面有持续动画比如 loading 转圈永远等不到稳定所以要设超时二是差分阈值要调太敏感会把微小渲染差异当成变化太迟钝会漏掉真实变化。我一般从 1% 开始调根据实际页面微调。5.3 异常分支弹窗、广告、权限请求真实环境里Agent 跑着跑着就会遇到意外系统弹窗、广告、权限请求、网络错误页。这些不在测试路径里但会阻断路径。处理方式有两种预置处理规则提前定义常见弹窗的关闭动作Agent 遇到就执行。比如检测到权限请求弹窗点击允许。交给模型决策把弹窗也作为界面的一部分让模型判断这个弹窗是否影响我的目标是否需要处理。我倾向于两者结合高频、固定的弹窗用规则处理快且稳低频、不确定的交给模型灵活。纯规则方案维护成本高纯模型方案在紧急场景下反应慢结合最实用。注意异常分支的处理一定要有放弃机制。有些弹窗关不掉或者页面卡死Agent 不能无限重试。设一个最大重试次数超了就标记测试失败并截图存档方便人工排查。6. 实测踩坑那些文档里不会写的经验6.1 模型幻觉点击不存在的元素这是最常见的坑。模型看着截图自信地说点击确认按钮但页面上根本没有这个按钮或者按钮在屏幕外。原因是模型基于训练数据的先验脑补了一个应该有的按钮。解决办法有两个一是强制模型只能从结构树里选元素结构树里没有的不能点二是在 prompt 里明确要求如果目标元素不存在输出 wait 或 finish 并说明。我两个都用效果明显。特别是第二个给了模型一个承认找不到的出口它就不会硬编一个动作出来。6.2 长路径下的目标漂移测试路径一长比如超过 15 步模型容易忘记最初的目标开始做一些无关操作。我遇到过 Agent 在验证登录的流程里突然去点设置页面的场景。根因是上下文里历史动作太多稀释了总目标的权重。解决办法每轮都把总目标放在 prompt 的最前面并用强调标记。另外历史动作做滑动窗口只保留最近 8 到 10 步更早的压缩成一句摘要已完成登录表单填写。这样目标始终清晰历史又不至于太长。6.3 动态内容导致的验证误判有些页面有动态内容时间戳、随机推荐、轮播图。Agent 验证时如果把这些算进去就会误判。比如验证页面加载成功结果因为时间戳变了截图差分一直不稳定。处理方式是验证时聚焦关键区域。不要让 Agent 验证整个页面而是验证特定元素或特定区域。比如验证标题栏文案是订单详情而不是验证页面和预期一致。聚焦之后动态内容的干扰就小多了。6.4 成本与速度的平衡多模态模型推理不便宜每轮都要传截图token 消耗可观。一个 20 步的测试如果每步都调模型成本不低。我的优化思路简单动作规则化像等待滚动固定距离这种不用调模型直接执行。缓存界面理解如果连续几轮界面没变模型对界面的理解可以复用只重新决策。分级模型简单决策用小模型复杂决策用大模型。实测能省不少。这些优化不是必须的但如果你要把方案用到 CI 里天天跑成本必须考虑。7. 搭一套最小可行方案从零到跑通7.1 技术选型与依赖一套最小可行的多模态 UI 测试 Agent需要这些组件组件作用选型建议设备控制截图、点击、输入移动端用 ADB/uiautomatorWeb 用 Playwright结构提取拿无障碍树移动端 uiautomator dumpWeb 用 accessibility snapshot多模态模型理解界面、决策支持图像输入的大模型按预算选编排框架管理循环、状态自己写个状态机就够不用上重型框架结果存储截图、日志、报告本地文件 简单 HTML 报告选型原则能用现成的就别自己造。设备控制和结构提取都有成熟工具把精力放在决策逻辑和稳定性上。7.2 核心循环的伪代码整个 Agent 的主循环大概长这样def run_agent(goal, max_steps30): history [] for step in range(max_steps): # 感知 screenshot capture_screen() elements extract_interactive_elements() annotated annotate(screenshot, elements) # 决策 action model_decide( goalgoal, screenshotannotated, elementselements, historyhistory[-10:] ) # 终止判断 if action.type finish: return action.result # 执行 execute(action) wait_until_stable() # 记录 history.append(describe(action)) return max_steps_reached这个骨架不到 30 行但涵盖了核心逻辑。实际落地时每个函数内部都有大量细节但结构就是这么简单。不要一上来就搞复杂架构先跑通这个循环再逐步加稳定性处理。7.3 验证与迭代方法搭好之后怎么验证方案有效我的做法是准备一组回归用例简单用例单页面、单动作验证基础能力中等用例多步流程验证路径规划困难用例含弹窗、动态内容、异常分支验证鲁棒性每改一次 prompt 或动作空间就跑一遍回归看通过率变化。这个过程中失败用例的截图和模型决策日志是最有价值的资产它们直接告诉你模型在哪类场景下会犯错。迭代节奏上我建议先追求简单用例 100% 通过再逐步加难度。很多方案死在贪多一上来就想覆盖所有场景结果哪个都不稳。8. 这套方案适合什么场景不适合什么场景多模态 Agent 做 UI 测试不是银弹。它适合的场景有几个特征界面变化频繁、选择器难维护、测试路径需要一定灵活性。比如快速迭代的产品、多端适配的页面、需要视觉验证的场景。不适合的场景也很明确对执行速度和确定性要求极高的场景。比如性能测试、需要毫秒级精确操作的场景传统脚本依然更合适。另外纯接口测试根本用不上 UI Agent别为了用而用。我个人的体会是这套方案最适合作为传统自动化的补充而不是替代。核心流程用脚本保证稳定和速度易变的、需要视觉判断的、探索性的测试交给 Agent。两者配合覆盖率和维护成本都能兼顾。最后分享一个实操小技巧让 Agent 在每次测试结束后输出一份路径总结用自然语言描述它走了哪些步骤、每步的意图是什么。这份总结对排查失败特别有用——你能一眼看出 Agent 是在哪一步想歪了比翻几十张截图高效得多。这个功能实现起来也简单就是把历史动作序列丢给模型让它总结一下成本很低收益很高。
1. 从点按钮到看懂界面多模态 Agent 做 UI 测试到底难在哪UI 自动化测试这件事做过的人都懂一个尴尬脚本写得再漂亮界面一改版就集体阵亡。传统方案靠的是选择器——id、class、XPath、无障碍标签本质上是在猜界面元素的身份。可一旦产品经理把按钮从左边挪到右边、把文案从提交改成确认提交选择器就失效了测试用例跟着一起躺平。多模态 Agent 的出现让这件事有了另一种解法。它不再只盯着 DOM 树而是像人一样看界面截图进来模型理解这个页面长什么样、有哪些可交互区域、当前处于什么状态然后决定下一步点哪里、输入什么、怎么验证。这就是标题里说的规划 UI 测试路径——不是执行一条写死的脚本而是根据当前界面动态生成一条通往测试目标的路径。关键词其实就藏在标题里多模态视觉文本可能的语音/结构信息、Agent有感知、有决策、有行动循环、UI 测试路径规划从起点状态到目标验证点的动作序列。这三者叠在一起解决的是同一个核心痛点让测试脚本具备界面理解能力从而在界面变化时依然能跑通。这篇文章适合谁看如果你正在做自动化测试、质量保障或者对 Agent 落地感兴趣想搞清楚多模态模型怎么真正用起来而不是停留在 demo那这篇就是给你写的。我会从路径规划的核心机制讲起拆到感知层、决策层、执行层的具体设计再聊实测中那些文档里不会写的坑最后给一套可以照着搭的最小可行方案。全程按从业者视角来不绕弯子。先说一个反直觉的结论多模态 Agent 做 UI 测试最难的不是看懂界面而是知道什么时候该停。模型能识别按钮、能读文案这些能力现在的多模态模型基本都具备。真正让测试跑不稳的是路径规划里的终止条件判断、状态验证、以及异常分支处理。后面会重点展开。2. 路径规划的核心机制Agent 是怎么想出下一步的2.1 感知-决策-执行的三段式循环多模态 Agent 规划 UI 测试路径底层是一个不断重复的循环我习惯把它拆成三段感知Perceive拿到当前界面的多模态输入。通常包括一张截图视觉、一份可交互元素列表结构来自无障碍树或 DOM 精简信息、以及当前测试上下文文本比如我现在要验证登录失败提示。决策Decide把感知结果喂给多模态大模型让它输出下一步动作。动作空间一般定义成有限的几种点击某坐标/某元素、输入文本、滑动、等待、断言某状态、结束。执行Act把模型输出的动作翻译成真实的设备操作ADB 命令、WebDriver 调用、Playwright 动作等执行后再回到感知进入下一轮。这个循环听起来简单但每一段都有讲究。感知阶段最关键的是信息取舍截图给多大分辨率DOM 信息要不要全给给多了 token 爆炸、推理变慢给少了模型看不清。我的经验是截图按设备原生分辨率给但 DOM 只给可交互元素的精简列表每个元素保留类型、文案、坐标、是否可点击这样既省 token 又保留了关键结构信息。决策阶段的核心是动作空间设计。动作空间太大模型容易输出无效动作太小又覆盖不了复杂场景。我一般会定义这么几类动作类型参数典型用途click元素索引或坐标点击按钮、链接、输入框input元素索引 文本填写表单swipe起止坐标滚动列表、翻页wait毫秒数或条件等待加载、动画结束assert断言类型 期望值验证文案、元素存在性finish结果说明路径结束执行阶段最容易被忽略的是动作后的稳定性等待。界面点击后往往有动画、网络请求、渲染延迟如果立刻截图进入下一轮模型看到的是中间态决策就会错乱。我的做法是执行动作后先等一个网络空闲 无动画的信号再截图实在拿不到信号就固定等 500ms 到 1s宁可慢一点也别让模型看花眼。2.2 为什么用视觉结构双通道而不是纯视觉有人会问既然多模态模型能看图为什么还要喂 DOM 结构信息纯视觉不行吗实测下来纯视觉方案在简单页面上没问题但遇到这几类场景就吃力一是密集列表几十个长得差不多的条目模型很难精确区分第 3 个和第 4 个二是小图标按钮截图里就十几个像素模型识别不稳定三是动态文案模型读图可能读错字。而结构信息无障碍树恰好能补上这些——它明确告诉你这里有个按钮文案是删除坐标在 (x, y)。所以双通道的本质是互补视觉负责理解整体布局和语义这个页面是干嘛的、当前在哪个流程结构负责精确定位和操作。两者结合路径规划的准确率比单通道高出一大截。这也是多模态三个字在 UI 测试场景里最实在的落地方式——不是炫技是真的有用。2.3 路径规划里的目标分解逻辑一个完整的 UI 测试任务比如验证用户能用错误密码登录并看到提示对 Agent 来说不是一步到位的需要分解成子目标定位到用户名输入框输入正确用户名定位到密码输入框输入错误密码定位到登录按钮点击等待响应验证页面上出现密码错误类提示Agent 的规划能力体现在它不需要你把这五步写死而是给它一个高层目标验证错误密码登录提示它自己根据当前界面推断出下一步该做什么。这背后靠的是大模型的任务分解 状态追踪能力。模型在每一轮都会重新评估我现在离目标还差什么然后选一个动作。这里有个关键设计把高层目标作为每轮决策的固定上下文。也就是说不管循环到第几轮模型每次都能看到我的总目标是什么和我已经做了哪些动作。这样它才不会跑偏——比如点了登录之后忘了要验证提示直接去点别的。我见过不少 demo 就是因为没把历史动作和目标一起喂进去Agent 跑着跑着就失忆了。3. 感知层设计截图、结构树和上下文怎么喂给模型3.1 截图预处理分辨率、压缩与标注截图是感知层最重的输入。直接给原图有两个问题一是 token 消耗大二是模型对超大图的分辨能力反而下降。我的处理流程是这样的缩放把长边缩到 1280 到 1568 像素之间不同模型的最优区间不一样需要实测。太小的图看不清小字太大的图推理慢且容易丢细节。压缩用 JPEG 质量 80 左右PNG 在截图场景下体积太大没必要。标注这是关键一步。我会在截图上把可交互元素用带编号的框标出来编号和结构树里的索引一一对应。这样模型看到图上的3 号框就能直接对应到结构里的3 号元素定位精度大幅提升。标注框这个技巧是我踩坑之后才加的。早期不标注模型经常说点击右上角的按钮但页面上右上角有好几个按钮执行层就懵了。加了编号之后模型的输出直接是click 元素 7歧义消失。3.2 结构树精简只留有决策价值的信息无障碍树Accessibility Tree信息很全但全量喂给模型是灾难。我一般做三层过滤只保留可交互节点可点击、可输入、可滚动的其他装饰性节点全砍。保留关键属性类型button/input/text、文案、坐标、是否可用enabled、是否选中。扁平化把树结构压成列表每个元素带一个索引。模型不需要理解层级只需要知道有哪些元素、分别是什么。精简之后一个中等复杂页面的结构信息大概几十到一两百个 token完全可控。这里有个细节坐标要归一化。不同设备分辨率不同直接给绝对像素模型很难形成空间感。我一般归一化到 0 到 1000 的相对坐标模型理解起来更稳。3.3 上下文注入把测试意图讲清楚光有界面信息还不够模型得知道我在测什么。上下文一般包含三块总目标一句话描述这次测试要验证什么。历史动作之前每一步做了什么、结果如何。这个要精简不能把每轮的完整截图都塞进去一般只保留动作文本序列。当前约束比如不要点击删除类按钮最多执行 20 步。把这三块和感知信息拼成一个结构化的 prompt模型就能在理解界面 记住历史 对齐目标的基础上做决策。我实测下来上下文里历史动作的表述方式对结果影响很大。用已点击登录按钮页面跳转到首页这种自然语言描述比用action: click, target: 5这种机器格式模型的任务连贯性更好。提示上下文不是越多越好。我试过把每轮截图都保留在历史里结果 token 迅速爆掉而且模型被历史截图干扰反而看不清当前界面。历史只留文本动作序列当前界面只留最新截图这个组合最稳。4. 决策层让模型输出可执行的动作序列4.1 动作空间的边界设计决策层最容易翻车的地方是模型输出了执行层无法理解的动作。比如模型说滚动到页面底部但你的执行层只支持滑动指定坐标。所以动作空间必须先定死再让模型在这个空间里选。我的做法是用结构化输出JSON Schema 或函数调用约束模型。给模型一个动作列表每个动作有明确的参数定义模型只能从中选。这样执行层拿到的永远是合法动作不用做容错解析。但约束太死也有问题遇到动作空间覆盖不到的场景模型会硬套一个不合适的动作。所以我会留一个other动作让模型在实在无法用现有动作表达时输出自然语言说明由人工介入或记录为待扩展场景。这个other动作在早期迭代阶段特别有用能帮你发现动作空间的缺口。4.2 多步规划 vs 单步决策Agent 规划路径有两种模式单步决策每轮只看当前界面决定下一步。优点是简单、容错好走错一步下一轮能纠正。缺点是短视可能走进死胡同。多步规划一次性输出未来几步的动作序列。优点是全局性好缺点是界面一变后面几步全废。UI 测试场景我强烈推荐单步决策为主辅以轻量前瞻。原因是界面状态变化太快多步规划的前提界面按预期变化经常不成立。轻量前瞻的意思是让模型在决策时顺便说一句我这一步的目的是什么、预期界面会怎么变但不强制它输出后续步骤。这样既有全局意识又不会因为界面变化导致整条路径作废。实测对比过纯多步规划在稳定页面上效率高但一旦有弹窗、加载延迟、A/B 测试导致的界面差异失败率飙升。单步决策虽然步数多但鲁棒性好得多综合下来更划算。4.3 状态验证Agent 怎么判断我成功了这是整个路径规划里最被低估的环节。很多 demo 只关注能不能点到不关注点完之后对不对。但测试的本质是验证不是操作。Agent 判断成功一般靠这几种信号视觉信号截图上出现了预期文案或元素。比如登录失败后出现红色提示。结构信号无障碍树里出现了某个特定节点。状态信号URL 变化、页面标题变化、某个元素从 disabled 变 enabled。我的经验是优先用结构信号视觉信号做兜底。结构信号稳定、精确不受渲染样式影响视觉信号灵活能捕捉结构里没有的视觉反馈比如颜色变化、图标状态。两者结合验证的可靠性最高。这里有个坑验证时机。点完按钮立刻验证往往验证的是旧状态。必须等界面稳定后再验证。我的做法是把等待稳定作为验证动作的前置条件执行层确认界面无变化连续两次截图一致后才触发验证。5. 执行层与稳定性从模型输出到真实设备操作5.1 动作翻译与重试机制执行层拿到模型的动作要翻译成真实操作。这一步看似简单实则暗藏玄机。以点击为例模型给的是元素索引执行层要从结构树里查到该元素的坐标把归一化坐标还原成设备像素调用设备点击接口确认点击生效比如元素状态变化任何一步失败都要重试。重试策略我一般设三次间隔递增200ms、500ms、1s。三次都失败就把这个动作标记为失败反馈给决策层让模型重新规划。这里有个细节点击坐标的偏移。有些元素的可点击区域和视觉区域不一致直接点中心可能点不中。我的做法是优先用元素中心如果连续失败尝试在元素区域内随机偏移几个点。这个技巧在处理某些自定义控件时特别管用。5.2 界面变化的检测与等待前面反复提到等界面稳定具体怎么实现我的方案是截图差分执行动作后每隔 200ms 截一张图连续两张图的差异小于阈值比如 1% 像素变化认为界面稳定最多等 5 秒超时则强制进入下一轮这个方案简单有效但要注意两点一是有些页面有持续动画比如 loading 转圈永远等不到稳定所以要设超时二是差分阈值要调太敏感会把微小渲染差异当成变化太迟钝会漏掉真实变化。我一般从 1% 开始调根据实际页面微调。5.3 异常分支弹窗、广告、权限请求真实环境里Agent 跑着跑着就会遇到意外系统弹窗、广告、权限请求、网络错误页。这些不在测试路径里但会阻断路径。处理方式有两种预置处理规则提前定义常见弹窗的关闭动作Agent 遇到就执行。比如检测到权限请求弹窗点击允许。交给模型决策把弹窗也作为界面的一部分让模型判断这个弹窗是否影响我的目标是否需要处理。我倾向于两者结合高频、固定的弹窗用规则处理快且稳低频、不确定的交给模型灵活。纯规则方案维护成本高纯模型方案在紧急场景下反应慢结合最实用。注意异常分支的处理一定要有放弃机制。有些弹窗关不掉或者页面卡死Agent 不能无限重试。设一个最大重试次数超了就标记测试失败并截图存档方便人工排查。6. 实测踩坑那些文档里不会写的经验6.1 模型幻觉点击不存在的元素这是最常见的坑。模型看着截图自信地说点击确认按钮但页面上根本没有这个按钮或者按钮在屏幕外。原因是模型基于训练数据的先验脑补了一个应该有的按钮。解决办法有两个一是强制模型只能从结构树里选元素结构树里没有的不能点二是在 prompt 里明确要求如果目标元素不存在输出 wait 或 finish 并说明。我两个都用效果明显。特别是第二个给了模型一个承认找不到的出口它就不会硬编一个动作出来。6.2 长路径下的目标漂移测试路径一长比如超过 15 步模型容易忘记最初的目标开始做一些无关操作。我遇到过 Agent 在验证登录的流程里突然去点设置页面的场景。根因是上下文里历史动作太多稀释了总目标的权重。解决办法每轮都把总目标放在 prompt 的最前面并用强调标记。另外历史动作做滑动窗口只保留最近 8 到 10 步更早的压缩成一句摘要已完成登录表单填写。这样目标始终清晰历史又不至于太长。6.3 动态内容导致的验证误判有些页面有动态内容时间戳、随机推荐、轮播图。Agent 验证时如果把这些算进去就会误判。比如验证页面加载成功结果因为时间戳变了截图差分一直不稳定。处理方式是验证时聚焦关键区域。不要让 Agent 验证整个页面而是验证特定元素或特定区域。比如验证标题栏文案是订单详情而不是验证页面和预期一致。聚焦之后动态内容的干扰就小多了。6.4 成本与速度的平衡多模态模型推理不便宜每轮都要传截图token 消耗可观。一个 20 步的测试如果每步都调模型成本不低。我的优化思路简单动作规则化像等待滚动固定距离这种不用调模型直接执行。缓存界面理解如果连续几轮界面没变模型对界面的理解可以复用只重新决策。分级模型简单决策用小模型复杂决策用大模型。实测能省不少。这些优化不是必须的但如果你要把方案用到 CI 里天天跑成本必须考虑。7. 搭一套最小可行方案从零到跑通7.1 技术选型与依赖一套最小可行的多模态 UI 测试 Agent需要这些组件组件作用选型建议设备控制截图、点击、输入移动端用 ADB/uiautomatorWeb 用 Playwright结构提取拿无障碍树移动端 uiautomator dumpWeb 用 accessibility snapshot多模态模型理解界面、决策支持图像输入的大模型按预算选编排框架管理循环、状态自己写个状态机就够不用上重型框架结果存储截图、日志、报告本地文件 简单 HTML 报告选型原则能用现成的就别自己造。设备控制和结构提取都有成熟工具把精力放在决策逻辑和稳定性上。7.2 核心循环的伪代码整个 Agent 的主循环大概长这样def run_agent(goal, max_steps30): history [] for step in range(max_steps): # 感知 screenshot capture_screen() elements extract_interactive_elements() annotated annotate(screenshot, elements) # 决策 action model_decide( goalgoal, screenshotannotated, elementselements, historyhistory[-10:] ) # 终止判断 if action.type finish: return action.result # 执行 execute(action) wait_until_stable() # 记录 history.append(describe(action)) return max_steps_reached这个骨架不到 30 行但涵盖了核心逻辑。实际落地时每个函数内部都有大量细节但结构就是这么简单。不要一上来就搞复杂架构先跑通这个循环再逐步加稳定性处理。7.3 验证与迭代方法搭好之后怎么验证方案有效我的做法是准备一组回归用例简单用例单页面、单动作验证基础能力中等用例多步流程验证路径规划困难用例含弹窗、动态内容、异常分支验证鲁棒性每改一次 prompt 或动作空间就跑一遍回归看通过率变化。这个过程中失败用例的截图和模型决策日志是最有价值的资产它们直接告诉你模型在哪类场景下会犯错。迭代节奏上我建议先追求简单用例 100% 通过再逐步加难度。很多方案死在贪多一上来就想覆盖所有场景结果哪个都不稳。8. 这套方案适合什么场景不适合什么场景多模态 Agent 做 UI 测试不是银弹。它适合的场景有几个特征界面变化频繁、选择器难维护、测试路径需要一定灵活性。比如快速迭代的产品、多端适配的页面、需要视觉验证的场景。不适合的场景也很明确对执行速度和确定性要求极高的场景。比如性能测试、需要毫秒级精确操作的场景传统脚本依然更合适。另外纯接口测试根本用不上 UI Agent别为了用而用。我个人的体会是这套方案最适合作为传统自动化的补充而不是替代。核心流程用脚本保证稳定和速度易变的、需要视觉判断的、探索性的测试交给 Agent。两者配合覆盖率和维护成本都能兼顾。最后分享一个实操小技巧让 Agent 在每次测试结束后输出一份路径总结用自然语言描述它走了哪些步骤、每步的意图是什么。这份总结对排查失败特别有用——你能一眼看出 Agent 是在哪一步想歪了比翻几十张截图高效得多。这个功能实现起来也简单就是把历史动作序列丢给模型让它总结一下成本很低收益很高。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
