想做AI自动化测试Agent，这些原理是必须要掌握的

AI自动化测试Agent这事，不是调个大模型API就能跑通的。很多人试了一把——Agent执行到一半跑偏、断言结果飘忽不定、Excel用例生成出来没法用——然后得出"AI测试不靠谱"的结论。但说句实在话，问题大概率不在模型，在于背后的原理没搞清楚。

01 Agent Loop：不是调一次API，是转一个圈

AI测试Agent的运转方式是一个循环，不是一次调用。你给它一个任务，它不是直接给你结果，而是：看一眼当前屏幕→想想要干嘛→执行一步操作→再看结果→再想下一步……一直转到任务完成。

这个循环有四个阶段，少了哪个都不转：

感知阶段：截图当前界面，获取设备信息，构建多模态消息。看着简单，但截图时机很讲究——截早了页面没加载完，Agent看到的是半成品；截晚了白白浪费时间。而且截图要跟当前APP包名一起传给模型，模型得知道自己在哪个App里，不然判断会偏。

决策阶段：把截图和任务描述一起发给视觉语言模型，模型输出下一步动作指令。这一步是整个循环的大脑，输出质量直接决定Agent的行为。

执行阶段：解析模型返回的动作指令，转成设备能识别的操作。点击就调点击、滑动就调滑动、输入就调输入——每一步都得映射到底层自动化框架的具体方法上。

判断阶段：检查这一步执行完是任务完成了还是得继续。任务完成了就退出循环，没完成就把新的截图和上下文塞回去，开始下一轮。当然还有保护机制——步数超限了也得退出，防止死循环。

这里面有个容易被忽视的设计点：上下文管理。Agent的每一轮决策都依赖之前的对话历史，模型要知道自己上一步干了什么、现在在哪个页面。但如果对话历史无限增长，token消耗会炸。所以要么做滑动窗口裁剪只保留最近几轮，要么定期归档旧上下文，这个权衡得做。

很多人第一次做Agent测试，上来就写"请帮我完成登录测试"，然后等模型一次性输出完整结果。不可能的。手机屏幕上的状态是动态的，每一步操作都会改变界面，Agent必须根据当前状态来决策下一步。你没法提前预知每一步的界面长什么样，所以必须走循环——这是Agent测试和传统脚本测试最大的区别。

02 前置操作+AI验证：两大设计思想

这是我在搭框架的过程中，觉得最有价值的设计思想——不是我自己发明的，是在实战中逐步提炼出来的。

思想一：前置操作执行体 + 多模态大模型验证执行体结果

什么意思？跑测试用例之前，得先进入正确的页面。比如测"退出登录"，你得先保证当前是已登录状态。这个"先进入正确页面"就是前置操作。

传统做法是写固定脚本做前置准备，但不同设备、不同网络环境、不同账号状态下，前置操作的执行结果可能不一样。你没法保证脚本一定能成功进入目标页面。

我的做法是：让Agent执行前置操作，执行完之后调多模态大模型验证——截图当前界面，问模型"当前是否已经进入我的页面"，模型判断是否符合预期。符合就继续跑主测试，不符合直接终止，不浪费后续执行时间。

思想二：测试步骤执行体 + 多模态大模型分步骤验证步骤执行结果

把一条测试用例拆成多个独立步骤，Agent每执行一步，立刻调模型验证这一步的结果。某一步失败了就立即终止，不需要跑完所有步骤再告诉你失败了。

比如"点击设置→点击退出登录→点确认"这三个步骤，如果第二步就点错了，传统方案会一直跑下去最后给你一个"测试失败"，你还得手动排查哪一步出了问题。分步验证的方案在第二步就告诉你"点击退出登录失败了，当前页面仍在设置页"，排查效率完全不一样。

这两个设计思想说白了就是：执行的归执行，验证的归验证。执行交给Agent的循环去跑，验证交给多模态模型去看。两者独立运作，又互相配合。理解了这两个思想，后面所有的模块设计都是在为它们服务。

03 坐标系统：从"看懂屏幕"到"点对位置"有多远

多模态模型看完截图，告诉你"登录按钮在坐标(540, 1200)"。问题来了——这个坐标是基于什么的？

我用的开源手机操作执行端，它的坐标空间是归一化的：所有坐标都是0-999的值，不管设备实际分辨率是多少。Agent输出的指令类似do(action="Tap", element=[450, 280])，执行端再根据设备实际分辨率把0-999映射回去。

这个设计的好处是Agent的输出跟设备无关，换一台手机不用改指令。但前提是你得理解归一化的原理和映射方式，不然出了偏差根本查不到原因。

归一化坐标到真实坐标的转换大概是这样：

真实X = 归一化X × (设备宽度 / 999) 真实Y = 归一化Y × (设备高度 / 999)

看着就一行代码的事，但它牵出一堆麻烦：

截图分辨率不一定等于设备分辨率。ADB截图的时候，设备可能会自动压缩，截出来的图跟实际屏幕比例不一样。你得先确认截图的真实尺寸，不能假设它就是设备分辨率。

不同平台差异也大。Android点击是touch((x, y))，iOS需要加按压时长touch((x, y), duration=0.5)；Android返回是keyevent('BACK')，iOS是从左侧滑入返回。这些差异得在执行层统一处理，不能让Agent去操心平台的事。

还有个细节：模型返回的坐标有时候就是不准，尤其界面上元素密集的时候。同一张截图，模型可能两次给出不同的坐标。这种情况下可以加一层校验——OCR识别目标文字的位置，跟模型返回的坐标做交叉验证，取交集区域的中心点。准确率会比单靠模型坐标高不少。

坐标转换做不好，Agent的操作就永远是"大概在那个位置点了一下"。测试需要的是精确，偏几十个像素可能就点到了旁边的按钮。这个原理不搞清楚，后面所有执行相关的调试都是在瞎猜。

04 提示词驱动决策：Agent怎么想，取决于你怎么说

Agent的决策质量，很大程度上取决于提示词写得好不好。我在框架里把提示词体系分成了三个层次：

系统提示词（System Prompt）：定义Agent的身份、能力和行为边界。这一层是"宪法"，所有行为都不能违背它。完整的系统提示词包含三个部分——角色定义（你是什么、能干什么）、动作指令集（你可以执行哪些操作、输出什么格式）、执行规则（你必须遵守什么约束）。

动作指令集的格式设计很关键。我用的格式是do(action="Tap", element=[x,y])这种结构化指令，Python端用正则解析。格式不统一，后面所有逻辑都建立在沙滩上。动作类型要覆盖全面但不能冗余——Launch启动App、Tap点击、Swipe滑动、Type输入、Back返回、Home回桌面、Wait等待、Finish完成任务，大概就这些，多了反而让模型选择困难。

执行规则是最容易被忽略但最有用的部分。比如"执行任何操作前先检查当前App是否是目标App，如果不是先Launch"，“页面没加载出内容最多连续Wait三次，否则执行Back重新进入”，“如果进入无关页面先Back”，“购物车操作时先清空已有商品”——这些规则不是靠模型自己悟出来的，得在提示词里写死。

测试用例提示词：驱动Agent执行具体测试步骤。这层提示词的要点是——每一步只做一个动作，做完立刻停止。格式是"就在当前界面做一个动作：点击文字[设置]，看到设置页面最上方显示[设置]两个字则立刻停止"。为什么要加"立刻停止"？因为Agent特别喜欢多做事，你不拦着它，它点完设置还会顺手点进去看看。必须约束它的行为边界：做完这一步就停，别自作主张。

还有一条硬规则必须写在提示词里：“不要擅自处理任何类型的弹窗，如果我没有告诉你处理弹窗的方式，看到弹窗就立刻停止。“这条规则是血的教训换来的——我见过Agent遇到弹窗后自作主张点了"确定”，结果那个确认框是"确认删除所有数据”。

AI验证提示词：用于多模态模型验证执行结果。格式是"请判断实际操作与结果是否符合期望操作与结果，回答格式：<成功> 或 <失败>“。这里面有个细节——前置操作的验证要求"基本符合就行”（因为前置操作只要达到目的就行），而步骤验证要求"部分符合就行"（因为每步的结果可能不完美但整体可接受）。验证标准的松紧要跟场景匹配，一刀切会出问题。

提示词不是一劳永逸的。模型在迭代，业务在变，场景在扩展，提示词也得跟着调。我的做法是提示词模板单独成文件，不跟代码混在一起，改提示词不动代码，改代码不碰提示词。

05 多模态AI断言：截图+模型判断的套路

传统断言是精确匹配——assert element.text == "登录成功"。要么通过，要么失败，没有中间地带。AI测试的断言得换个思路。

多模态断言的做法是：截一张图，把截图转成Base64编码，跟验证提示词一起发给视觉语言模型，模型看了截图之后判断当前界面是否符合预期，输出判断结果。

整个流程是：截图→Base64编码→构建多模态消息（图片+文字）→调用模型API→解析返回结果。说起来顺畅，但实操中有一个大麻烦：模型返回的JSON格式不稳定。

同样一个请求，模型可能返回三种格式：用` ```json ````包裹的、用特殊标记包裹的、或者直接裸JSON。所以解析层做了兼容处理——先尝试提取代码块内容，再尝试提取特殊标记内容，最后尝试直接解析。解析失败还要用json_repair修复。这一层兼容代码看着不优雅，但少了它，断言功能基本没法用。

在实际使用中，我总结了几条断言设计的经验：

断言描述要具体，不要模糊。“页面正常显示"这种断言等于没写。改成"页面顶部显示用户昵称，底部Tab栏选中首页图标”——有具体可观测的视觉特征，模型的判断就会稳定很多。

多模态验证和文本分析要配合用。视觉模型看截图判断界面状态，文本分析模型判断执行结果描述是否符合预期。两者互补：视觉模型能发现截图里的异常，文本模型能发现语义上的偏差。两者都通过才算真正通过，漏判概率大幅下降。

关键断言双重验证。P0级别的断言，AI判断完之后再用传统方式二次确认。AI判pass+脚本验证也pass，才算真正通过。

断言这块是AI测试和传统测试差异最大的地方，也是最容易引起争议的地方。不要指望AI断言完全替代传统断言，两种方式互补，各取所长。

06 智能弹窗处理：测试里的"灰色地带"

弹窗是Agent测试最头疼的问题。权限申请、登录过期、网络异常、版本更新、营销广告——弹窗种类太多，传统规则匹配永远补不全。

我在框架里做了一套基于OCR的弹窗处理方案，分两层：

规则层：用OCR识别屏幕文字，匹配预定义的弹窗规则。每条规则是"触发文字+操作文字"的组合——检测到"打开蓝牙"就点"允许"，检测到"隐私协议"就点"同意"，检测到"限时优惠"就点"关闭"。这些是最常见的系统弹窗，处理逻辑是固定的，不需要Agent每回都去"思考"，规则匹配又快又稳。

监控层：启动一个连续监控进程，每隔零点几秒扫描一次屏幕，检测有没有匹配的弹窗。支持多种退出条件——检测到特定文字时停止、连续N次没检测到弹窗时停止、超时停止。还有OCR缓存机制，0.5秒内不重复识别同一张截图，避免性能浪费。

弹窗规则的定义很有讲究。每条规则包含：触发文字（检测弹窗的标志）、操作文字（点击的按钮）、OCR置信度阈值（低于这个值不处理）、操作后等待时间、是否模糊匹配。模糊匹配很重要——"位置服务"和"位置权限"其实是同一类弹窗，模糊匹配能兜住这种差异。

但OCR弹窗处理也有边界。它只能处理"看文字就能判断"的弹窗，对于那些纯图标弹窗或者图形化弹窗，OCR识别不了。这时候就得交给Agent看图判断了。

弹窗处理还有个容易翻车的地方：不可逆操作。涉及删除、支付、退出登录这类弹窗，Agent不应该自己点，必须停下来等人工确认。这条边界要在提示词里写死——“不要擅自处理任何类型的弹窗”，不留灰色地带。

07 结构化用例设计：从Excel到自动化的桥梁

很多人觉得AI Agent测试就是"说一句话，它自己去跑"。确实可以，但这种模式下Agent的行为完全不可控、不可重复、不可回归。稍微严肃一点做测试，还是需要结构化用例。

我的做法是用Excel模板定义用例，模板有9个核心字段：用例ID、测试模块、测试描述、前置操作、测试步骤、预期结果、优先级、用例状态、备注。Excel的门槛最低，谁都能填，不要求写代码。

其中最有设计含量的是三个字段：

前置操作的编写公式：定位目标 + 备选方案 + 判定条件

“在系统桌面找到文字为天气的软件，没找到就左右滑动尝试寻找，找到后点击进入”——定位目标是"文字为天气的软件"，备选方案是"左右滑动寻找"，判定条件是"找到后点击进入"。三个要素缺一不可：没有备选方案，Agent找不到就卡死了；没有判定条件，Agent不知道自己进没进对页面。

测试步骤的编写公式：做xxx操作，看到xxx

“点击文字[设置]，看到设置页面最上方显示[设置]两个字”——操作是"点击设置"，预期是"页面顶部显示设置"。每个步骤只做一件事，做完有明确的视觉验证点。步骤太长Agent理解会偏，步骤太短又拆得太碎。

备注里的APP主页判定标准

这是最容易被忽视但最有用的字段。在备注里写清楚"APP主页长什么样"——比如"天气APP主页包含城市名称、PM2.5与UV指数、天气状况与温度范围、未来几天天气预报"。Agent验证前置操作结果时，就靠这个判定标准来确认自己是否进对了页面。

写好Excel用例之后，Python端读取Excel、解析结构化数据、自动生成pytest测试脚本。每个用例生成一个测试函数，函数里自动编排"前置操作→分步执行→AI验证"的流程。改用例不用改代码，换执行引擎不用改用例，用例和执行完全解耦。

这种解耦让整个系统可维护、可迭代、可回归。没有这个标准化，AI生成用例也好、人工写用例也好，格式五花八门，谁都接不住。

08 混合架构：框架管确定性，Agent管灵活性

纯Agent方案我试过，不好用。纯脚本方案也试过，遇到变化就废。后来想通了：为什么非得二选一？

测试这件事，说到底就是两种工作的混合：一种是确定性操作——加载用例、按步骤执行、收集结果、生成报告，这些流程是固定的，不需要智能判断；另一种是灵活性决策——弹窗怎么处理、定位失败了怎么办、断言结果是bug还是环境问题，这些需要根据上下文现场判断。

混合架构的思路就是让适合的工具干适合的活：

框架（比如pytest）负责确定性工作：用例加载和解析、测试步骤的编排和执行顺序、前置条件准备和后置清理、结果收集、断言执行、报告生成。这些交给框架做又快又稳。

Agent负责灵活性决策：页面弹窗怎么关、元素找不到怎么换策略、断言失败是bug还是环境问题、没见过的异常怎么恢复。这些场景没有标准答案，需要根据实际情况判断。

判断标准很简单：能不能写成if-else。能写的，框架干；写不出来的，Agent干。

边界不是固定的。一开始某个场景交给Agent处理，后来发现处理逻辑稳定了，就可以固化成规则交给框架。这是混合架构的迭代过程——从灵活到确定，从Agent到框架。

在框架里，每个测试用例的执行流程都是这样的：pytest加载用例→检查有没有前置操作→有的话调Agent执行前置操作→调多模态模型验证前置结果→通过则进入步骤执行→每步调Agent执行→每步调模型验证→所有步骤通过则整体验证→生成报告。整个流程由pytest编排，Agent只在需要"看"和"判断"的时候出场。

混合架构比纯Agent模式稳定性高出一个量级。差别就在于：不该Agent干的事别让Agent干，省下的推理开销和出错概率都是实打实的。

09 多模型协同：三种模型各管一摊

搭AI测试Agent，光靠一个模型是不够的。我的框架里用了三种模型，各司其职：

Agent模型：负责"看屏幕、想策略、做动作"。它接收截图和任务描述，输出结构化的动作指令——点击哪里、输入什么、滑动到哪。这是Agent Loop里"决策"环节的引擎，调用频次最高。

多模态视觉模型：负责"看截图、判结果"。Agent执行完一步，截图发给它，问"当前界面是否符合预期"。它不负责决策怎么操作，只负责判断结果对不对。输出格式是结构化的判断结果加原因说明。

文本分析模型：负责"看描述、判语义"。它不看截图，只分析文本——Agent的执行结果描述是否符合预期、步骤之间的逻辑是否自洽、失败原因的分析。它和多模态模型互补，一个看图一个看文字，交叉验证的准确率比单模型高很多。

三种模型可以分别部署——在线调API或者本地跑Ollama都行。Agent模型因为调用频次最高，建议在线API保证响应速度；文本分析模型本地部署就够了，省API费用。

配置管理上也有讲究。不同环境（开发/测试/生产）的API地址、密钥、模型版本都应该分开管理，不要把生产密钥写在代码里。我用环境变量或者独立配置文件的方式隔离，改环境只改配置不改代码。

10 这些原理不是看看就懂的，得动手跑

坐标转换看着简单，我第一次做的时候直接拿模型返回的坐标去点击，偏了几十个像素，点到旁边的按钮上，排查了半天才发现是归一化坐标没做映射。提示词写不好，Agent跑着跑着就开始自己"发挥"，该测登录的跑去检查设置了。弹窗处理没分层，Agent遇到"确认删除"弹窗直接点了确定，测试数据全没了。混合架构的边界怎么划、异常怎么分层，也是调了很多轮才定下来的。

这些经验不是看文章就能真正理解的，得拿真实项目跑一遍，翻一遍，才能变成自己的东西。

我自己把这些原理和实战经验整理成了一套系统课程——AI纯视觉自动化测试框架（高级），12个章节从Agent Loop的感知决策执行循环到坐标归一化映射，从提示词三层体系到多模态断言的JSON兼容解析，从OCR弹窗处理到Excel模板驱动的脚本自动生成，每个原理都配了可跑的项目代码，不是PPT讲概念，是跟着做就能跑起来那种。

课程覆盖的几个重点：前置操作+AI验证和步骤执行+分步验证两大设计思想的完整实现、归一化坐标系统与多平台适配的代码实操、结构化Excel用例模板的设计方法和自动生成流程、智能弹窗处理的规则匹配+连续监控方案、混合架构的落地细节和异常分层策略。适合在做移动端自动化测试、想低成本引入AI能力但不知道从哪下手的同行。
欢迎私信交流！！！