多模态Agent如何规划UI测试路径：从原理到落地实践

1. 多模态 Agent 介入 UI 测试的真实动机

UI 测试这件事，做过的人都懂，它属于那种"看起来简单、做起来要命"的典型。一个按钮的位置挪了 3 个像素，一条 toast 提示的文案从"保存成功"改成了"已保存"，一个弹窗的关闭按钮从右上角换到了左上角，这些在开发眼里可能只是"顺手改一下"的小事，但落到自动化测试脚本上，往往就是一片飘红。传统的 UI 自动化方案，无论是基于 DOM 选择器、XPath 还是图像模板匹配，本质上都在做一件事：把"界面长什么样"翻译成机器能识别的确定性规则。问题在于，界面本身是高度不确定的，而规则是死的。

多模态 Agent 的出现，给这个老问题提供了一个新解法。所谓多模态，指的是 Agent 能同时处理文本、图像、结构化数据等多种输入形式；所谓 Agent，指的是它不只是被动执行脚本，而是能感知当前界面状态、做出判断、规划下一步动作。把这两者结合起来，UI 测试路径的规划就从"预先写死每一步"变成了"根据当前看到的界面动态决定下一步"。这个转变的意义很大，它意味着测试脚本可以像人一样，先看一眼屏幕，再决定点哪里、输什么、等多久。

我接触这个方向是从一个很具体的痛点开始的：一个跨平台的桌面应用，同一套业务逻辑在三个不同操作系统上渲染出来的界面差异极大，按钮位置、控件层级、甚至交互反馈的时序都不一样。维护三套 UI 测试脚本的成本高到离谱，每次发版前光是修脚本就要花掉两天。后来尝试用多模态 Agent 来做路径规划，核心思路是让 Agent 自己"看"界面、"理解"当前处于哪个流程节点、"判断"下一步该操作什么元素。这套东西跑通之后，脚本维护量下降了大概七成，剩下的三成主要是业务逻辑变更导致的用例调整，而不是界面适配问题。

这篇文章想聊的就是这套思路的完整拆解：多模态 Agent 到底怎么规划 UI 测试路径，背后的核心技术点是什么，实操中会遇到哪些坑，以及怎么把它落地到自己的项目里。适合有一定 UI 自动化基础、正在被脚本维护成本折磨的测试开发同学，也适合对 Agent 应用感兴趣、想找一个具体落地场景的工程师。我会尽量把原理讲透，把步骤写细，把踩过的坑都摊开来说。

2. 核心思路拆解：为什么是"规划"而不是"执行"

2.1 传统 UI 自动化的根本瓶颈在哪里

要理解多模态 Agent 的价值，得先看清楚传统方案到底卡在哪。传统 UI 自动化工具，不管是 Selenium、Playwright 还是 Appium，它们的核心能力是"定位元素并执行操作"。定位靠的是选择器，选择器依赖的是界面元素的属性，比如 id、class、text、accessibility label。这套机制在界面稳定的时候非常好用，快、准、可重复。但它的脆弱性也恰恰来自这里：选择器和界面实现是强耦合的。

我见过太多这样的场景：开发为了修一个样式 bug，把某个 div 的 class 名从btn-primary改成了button-primary，测试脚本里对应的选择器就失效了。或者前端框架升级，原本的>