1. 项目概述为什么我们需要一个专门的中文移动GUI智能体评测基准在移动应用开发与测试领域自动化智能体GUI Agents正扮演着越来越重要的角色。无论是自动化测试、无障碍交互还是新兴的“AI玩手机”应用这些智能体都需要理解屏幕上的图形用户界面GUI并执行精准的操作。然而长期以来衡量这些智能体能力的“标尺”——评测基准Benchmark——存在一个明显的短板它们大多基于英文环境构建。无论是Rico、Android in the Wild还是更学术化的数据集其界面描述、任务指令、乃至底层控件的语义理解都深深烙印着英文的思维和表达习惯。这就带来了一个核心痛点一个在英文基准上表现优异的智能体面对中文应用时其性能可能会大打折扣。原因在于中文GUI有其独特的复杂性。从界面布局上中文的排版密度、字体样式与英文截然不同从文本语义上中文的词汇多义性、成语俗语、以及网络流行语的频繁使用对自然语言理解NLU模块提出了更高要求从控件识别上中文按钮的文本可能更简短、更具概括性甚至包含图标与文字的组合。此外国内移动应用生态的独特性如超级App微信、支付宝内的小程序、复杂的活动页面、以及特有的交互模式如“上拉加载”、“下拉刷新”的本地化变体都构成了独特的挑战。因此GUI-CEval的出现正是为了填补这一空白。它不仅仅是将现有基准“翻译”成中文而是构建了一个层次化、综合性的中文移动GUI智能体评测体系。这个项目旨在回答几个关键问题一个真正“懂中文”的GUI智能体应该具备哪些能力我们如何系统、量化地评估这些能力以及当前的技术离完美解决中文GUI交互还有多远对于从事移动端AI、自动化测试、人机交互研究的开发者和研究者而言GUI-CEval提供了一个不可或缺的“练兵场”和“度量衡”。2. 基准设计的核心思路与层次化架构解析GUI-CEval的设计哲学是“从易到难从通用到特定”。它没有采用单一维度的任务集合而是构建了一个金字塔式的层次化评估框架。这种设计确保了基准既能评估智能体的基础通用能力又能深入检验其在复杂、特定场景下的表现。2.1 能力层次划分构建评估的金字塔基准的核心是定义了四个逐级递进的能力层次每一层都对应着智能体需要解决的一类核心问题。第一层基础控件感知与操作这是智能体的“基本功”。在这一层基准评估智能体是否能准确识别屏幕上的基本UI元素并执行对应的原子操作。这包括识别按钮、文本框、复选框、开关、列表项、图片等。操作点击、长按、滑动、输入文本、滚动。评估重点定位准确性能否找到正确的控件、操作正确性是否执行了预期的动作、以及对控件状态的理解如判断复选框是否已被勾选。这一层的任务通常较为孤立例如“点击‘登录’按钮”或“在搜索框输入‘天气预报’”。它主要检验智能体的计算机视觉CV和基础指令跟随能力。第二层单页面任务规划与执行当多个控件组合在一个页面内时智能体需要理解任务逻辑和操作序列。这一层评估智能体的规划能力。典型任务“在设置中开启蓝牙并连接名为‘MySpeaker’的设备”。这个任务涉及多个步骤进入设置、找到蓝牙菜单、开启蓝牙开关、在设备列表中查找并点击目标设备。评估重点任务分解的合理性、操作步骤的顺序是否正确、以及处理中间状态的能力例如开启蓝牙后需要等待扫描结果。第三层跨应用工作流协调真实用户任务常常需要多个应用协同完成。这一层模拟了更复杂的现实场景评估智能体的跨应用协调与上下文管理能力。典型任务“将微信聊天中朋友发来的图片保存到手机相册然后用美图秀秀添加滤镜最后分享到微博”。这涉及微信、系统相册、美图秀秀、微博四个应用间的切换和数据传递。评估重点跨应用意图理解、数据流转的正确性如图片是否成功保存和传递、以及在不同应用间保持任务目标一致性的能力。第四层复杂语义与模糊指令理解这是最高挑战层级旨在评估智能体的“真智能”。任务指令不再是直白的操作描述而是包含模糊性、隐含需求或需要常识推理的自然语言。典型任务“帮我清理一下手机感觉有点卡”或“我想看看最近有什么划算的东西”。对于前者智能体需要理解“清理手机”可能意味着清理存储空间、关闭后台应用、或清理缓存并做出合理决策。对于后者它需要判断用户可能想打开电商App如淘宝、京东浏览促销信息。评估重点语义理解的深度、常识推理能力、在不确定环境下的决策能力以及与用户的潜在交互如询问澄清问题是否合理。2.2 场景与领域覆盖确保综合性除了纵向的能力层次GUI-CEval在横向上也力求全面覆盖了中文移动生态中最核心和高频的应用场景。系统应用设置、通讯录、短信、文件管理、相机等。这些应用控件相对标准是测试基础能力的良好起点。社交与通讯微信、QQ、微博等。挑战在于复杂的聊天界面、公众号、小程序嵌套以及丰富的上下文。电商与生活服务淘宝、京东、美团、支付宝。特点是有大量的列表页、商品详情页、复杂的促销活动组件和支付流程。内容与娱乐抖音、B站、网易云音乐等。涉及视频流、评论互动、内容搜索与推荐等交互。工具与效率WPS Office、百度地图、天气应用等。需要处理文档编辑、路径规划等更专业的任务。通过这种“纵横交错”的设计GUI-CEval能够对GUI智能体进行立体、全方位的评估精准定位其能力长板和短板。3. 基准构建的关键技术与实操要点构建一个高质量、可复现的基准远非收集一些截图和编写任务描述那么简单。GUI-CEval的背后涉及一系列严谨的技术选型和工程实践。3.1 数据采集与标注真实性与多样性的平衡基准的基石是数据。GUI-CEval的数据来源强调真实设备、真实应用、真实交互。设备与环境使用多款不同品牌、型号、分辨率和Android版本的手机以覆盖碎片化的安卓生态。通过自动化框架如Appium、UIAutomator2驱动设备并同时捕获屏幕截图、布局文件UI Hierarchy/XML和操作日志。应用选择从上述各大场景中选取Top 100的中文应用并确保涵盖其核心功能页面。不仅包括应用商店版本对于一些频繁更新的应用如微信还会考虑不同版本间的UI差异。任务设计每个任务都由领域专家设计确保其符合用户真实使用习惯。一个任务包含自然语言指令用中文描述任务目标。初始状态任务开始时App所处的具体页面和状态如已登录某个账号。预期执行轨迹一套或多套可接受的成功操作序列考虑到操作的多样性。成功标准明确界定任务何时算完成如跳转到特定页面、出现特定文本、完成某个网络请求。注意在标注“预期执行轨迹”时必须考虑操作的容错性。例如从主页到设置页可能通过点击“我的”再点“设置”进入也可能通过侧边栏菜单进入。基准应容纳这些合理的多样性而不是规定唯一路径。3.2 评估指标设计超越简单的成功率如果仅用“任务成功率”作为指标会丢失大量有价值的信息。GUI-CEval采用了一套组合指标任务完成率最基础的指标任务是否在限定步骤内达到成功标准。步骤效率完成同一任务智能体所用的操作步骤与专家标注的最优或平均步骤数的比值。比值越低效率越高。泛化能力得分将任务在指令表述上做同义改写如“登录”改为“输入账号密码进入”或轻微改变UI布局如按钮位置变化测试智能体表现的稳定性。得分下降越小泛化能力越强。可解释性评估对于智能体的每一步决策记录其选择的控件和理由如果智能体提供。人工评估这些理由是否合理这有助于诊断失败原因和改进模型。3.3 基线系统与工具链搭建为了让大家能快速上手评估自己的智能体GUI-CEval项目通常会提供或推荐一套完整的基线系统Baseline和工具链。环境封装提供Docker镜像或详细的依赖列表requirements.txt封装好Android SDK、模拟器/真机连接工具、Python环境等实现“一键搭建评测环境”。基线智能体实现一个基于“OCR 大语言模型LLM”的经典架构作为基线。视觉感知模块使用PaddleOCR或MMOCR等开源工具从截图中提取所有文本及其位置。页面表示将OCR结果和从UI XML中提取的控件类型、边界框等信息组合成一段结构化的文本描述输入给LLM。例如“屏幕顶部有一个标题为‘设置’的TextView。下方是一个ListView第一项是‘WLAN’其右侧有一个状态为‘已连接’的TextView...”。决策与执行模块将任务指令和页面表示一起输入给大语言模型如ChatGLM、Qwen、GPT等要求模型输出下一个操作的动作如CLICK [坐标或文本]、INPUT [文本] [内容]、SCROLL [方向]。然后由执行器解析并执行该动作。自动化评测脚本核心工具。它能够自动加载任务定义。控制基线智能体或接入用户自定义的智能体在模拟器/真机上执行任务。监控执行过程记录每一步的屏幕状态和操作。根据成功标准自动判断任务结果并计算各项评估指标。生成详细的评测报告JSON格式包括每个任务的执行轨迹、成功与否、用时、步骤数等。4. 基于GUI-CEval的智能体开发实战与核心环节假设我们现在要开发一个自己的GUI智能体并利用GUI-CEval进行评测和迭代。以下是核心的实现流程。4.1 环境准备与基准接入首先我们需要在本地复现评测环境。# 1. 克隆GUI-CEval项目仓库假设开源在GitHub上 git clone https://github.com/xxx/GUI-CEval.git cd GUI-CEval # 2. 安装依赖项目通常会提供脚本 pip install -r requirements.txt # 3. 准备Android测试环境 # 启动一个Android模拟器如通过Android Studio的AVD Manager # 或者确保有一台开启了开发者选项和USB调试的安卓真机通过ADB连接到电脑 adb devices # 应能看到设备列表 # 4. 下载基准数据集 # 数据集可能包含任务定义文件JSON和对应的App安装包APK或状态快照 ./scripts/download_data.sh接下来理解基准的接口。我们的智能体需要实现一个标准的Agent类通常包含一个act方法。这个方法接收当前的屏幕截图和任务指令然后返回一个动作。# 示例智能体基类接口 class BaseAgent: def __init__(self, model_pathNone): # 初始化模型、OCR引擎等 self.ocr_engine PaddleOCR(use_angle_clsTrue, langch) self.llm load_llm(model_path) # 加载本地或云端LLM self.device AndroidDevice() # 封装ADB操作 def act(self, screenshot_pil, instruction, current_stateNone): :param screenshot_pil: PIL.Image对象当前屏幕截图 :param instruction: str当前任务的自然语言指令 :param current_state: dict可选当前任务的一些状态信息 :return: action_dict例如 {action_type: CLICK, target: [x, y]} # 1. 视觉感知分析屏幕 ocr_result self.ocr_engine.ocr(np.array(screenshot_pil), clsTrue) ui_elements self._parse_ocr_to_elements(ocr_result) # 2. 构建页面描述Prompt工程的关键 page_description self._construct_page_prompt(ui_elements) # 3. 调用LLM进行决策 llm_prompt f 你是一个手机助手。当前屏幕描述如下 {page_description} 用户的要求是{instruction} 请根据屏幕内容决定下一步操作。你只能进行以下操作之一 - CLICK [元素描述或坐标]: 点击某个元素 - INPUT [元素描述或坐标] [文本]: 向输入框输入文本 - SCROLL [UP|DOWN|LEFT|RIGHT]: 向某个方向滑动 - BACK: 按返回键 - ENTER: 按回车键 - WAIT: 等待一段时间 请直接输出操作指令不要有其他解释。 例如CLICK [登录按钮] llm_response self.llm.generate(llm_prompt) action self._parse_llm_response(llm_response) # 4. 将动作转化为ADB命令并执行评测脚本通常会处理执行这里智能体只需返回动作描述 return action4.2 核心模块深度优化Prompt工程与页面表示基线系统的性能瓶颈往往在于LLM是否真正“理解”了屏幕。因此页面描述Page Description的构建是优化的重中之重。粗糙的OCR文本拼接会让LLM困惑。优化策略一结构化与优先级排序不要简单罗列所有OCR文本。将屏幕划分为逻辑区域如顶栏、内容区、底栏Tab并为元素添加语义标签和优先级。def _construct_page_prompt(self, ui_elements): # 对元素进行简单分类和过滤 interactive_elements [] # 按钮、输入框等 informational_elements [] # 标题、说明文本等 for elem in ui_elements: if elem[text] in [登录, 搜索, 下一步, 确定, 取消] or elem[area] 5000: # 假设大区域可能是按钮 interactive_elements.append(elem) else: informational_elements.append(elem) # 按位置从上到下从左到右排序符合阅读习惯 interactive_elements.sort(keylambda x: (x[bbox][1], x[bbox][0])) prompt 当前屏幕可交互元素\n for i, elem in enumerate(interactive_elements): prompt f{i1}. 文本“{elem[text]}”位于屏幕{elem[position_hint]}坐标约{elem[bbox][:2]}\n prompt \n当前屏幕信息性文本\n .join([e[text] for e in informational_elements[:5]]) # 取前几个关键信息 return prompt优化策略二融入视觉线索与上下文对于复杂UI纯文本描述不够。可以添加控件类型结合UI Hierarchy通过adb shell uiautomator dump获取获得更准确的控件类型android.widget.Button。描述相对位置“搜索栏下方有一个列表列表第一项是‘微信’。”引入历史在act方法的current_state中带入之前几步的操作和页面关键信息帮助LLM理解任务进程。4.3 执行、评测与结果分析将开发好的智能体接入评测脚本。# 运行评测指定要测试的任务子集例如只测“基础操作”层 python evaluate.py --agent my_agent.MyAgent --task_set basic --output results/basic_eval.json # 运行完整评测时间较长 python evaluate.py --agent my_agent.MyAgent --task_set all --output results/full_eval.json评测结束后会生成详细的报告。分析报告是改进的关键查看总体指标首先关注任务完成率和平均步骤效率。如果完成率很低问题可能出在基础感知或简单指令理解上。逐任务分析失败案例打开失败任务的执行轨迹日志。是OCR没识别出关键文本是LLM输出了无法解析的指令还是执行了错误操作案例任务“在微信中搜索联系人‘张三’并发送‘你好’”。智能体成功搜索并进入聊天框但输入“你好”后没有点击发送按钮。分析发现页面描述中提到了“发送按钮”但LLM可能认为输入后会自动发送或者“发送”按钮的文本在OCR中被识别为图标而遗漏。解决方案强化对“确认性操作”发送、完成、确定按钮的识别和Prompt强调。对比不同层级表现如果智能体在“基础操作”层表现良好但在“单页面任务规划”层骤降说明问题不在感知而在任务分解和规划逻辑。可能需要为LLM提供更清晰的思维链Chain-of-Thought提示或引入专门的规划模块。分析泛化能力对比同一任务不同表述下的成功率。如果波动大说明智能体对指令的语义理解脆弱。可以通过数据增强使用更多同义句微调LLM或改进指令的编码方式来提升。5. 常见问题、挑战与避坑指南在实际使用GUI-CEval进行研究和开发的过程中我遇到了不少典型问题以下是一些实录和解决方案。5.1 视觉感知的稳定性问题问题OCR在复杂背景、艺术字体、低对比度或动态加载内容上识别率低导致页面描述缺失关键信息。案例一个促销按钮上的文字“限时抢购”是渐变艺术字OCR完全漏检。排查检查评测日志中失败任务步骤的截图和OCR原始输出。可视化OCR识别框看是否覆盖了关键文本。解决多OCR引擎融合同时使用PaddleOCR、EasyOCR等取并集或投票决策。图像预处理对截图进行对比度增强、二值化等操作提升文本区域显著性。利用UI Hierarchy优先信任从uiautomator dump获取的控件文本它通常比OCR更稳定。将OCR作为Hierarchy的补充专门捕捉那些动态生成、非标准控件内的文本。模型微调针对中文移动端UI的字体和布局收集数据对OCR模型进行微调。5.2 大语言模型的“幻觉”与指令跟随问题LLM可能会忽略屏幕内容“幻想”出不存在按钮或者输出的动作格式不符合规范导致解析失败。案例LLM输出“CLICK [蓝色的确认按钮]”但屏幕上根本没有蓝色按钮或者有多个蓝色元素。排查查看LLM接收到的完整Prompt和它的回复。检查页面描述是否足够清晰无歧义。解决强化Prompt约束在Prompt中明确强调“必须严格基于上述屏幕描述进行操作描述中未出现的元素不能操作”。要求输出格式极度规范化例如“ACTION: CLICK, TARGET: 登录”。后处理与验证解析LLM输出的动作后与当前屏幕的实际元素进行匹配验证。如果“蓝色的确认按钮”无法匹配任何元素则触发重试或启用一个保守的备选策略如请求更详细的描述。少样本示例Few-shot在Prompt中提供几个正确响应的例子让LLM更好地理解任务格式和决策逻辑。5.3 状态管理与跨步骤依赖问题在多步骤任务中智能体容易“遗忘”之前的状态或无法处理操作带来的动态变化。案例任务“将系统语言改为英文”。步骤是设置 - 系统和更新 - 语言和输入法 - 语言。智能体成功进入“语言和输入法”页面后却开始寻找根本不存在的“系统语言”选项因为它“忘记”了当前页面已经是子页面。排查检查每个act调用时传入的current_state是否包含了必要的任务进度信息。解决显式状态跟踪在Agent类内部维护一个任务状态机或历史记录。将“当前所在页面的名称或特征”、“已完成的关键步骤”等信息作为上下文的一部分输入给LLM。屏幕差分Screen Diff比较当前屏幕与上一步屏幕的显著变化如新出现的弹窗、页面标题变更并将这个变化描述给LLM帮助它感知操作效果。子目标分解对于复杂任务可以设计一个上层规划器先将任务分解为明确的子目标序列如[进入设置页 进入系统菜单 找到语言项 选择英语]然后让底层执行器逐个完成。这样每个子目标内的上下文更简单。5.4 性能与效率瓶颈问题每步都需要OCRLLM推理耗时很长无法满足实时交互需求。解决缓存与重用对于静态或变化不大的页面如应用主页可以缓存其页面描述下次直接使用无需重复OCR和LLM分析。轻量级模型在确保效果的前提下探索更小的OCR模型和参数更少的LLM如7B/13B参数的本地模型或使用模型蒸馏、量化技术。异步流水线将OCR识别、LLM推理、动作执行设计成异步流程当LLM在推理当前步骤时设备可以并行执行上一步已确定的动作如果安全的话。GUI-CEval作为一个严谨的基准其价值不仅在于提供一个分数排名更在于它通过层次化的任务设计和细致的评估指标为我们揭示了构建实用中文GUI智能体所面临的核心挑战与解决路径。从精准的视觉感知到深度的语义理解从稳健的单步操作到复杂的跨应用规划每一个环节都需要精心设计和持续优化。这个基准就像一面镜子清晰地照出了我们当前技术的边界也指明了未来前进的方向。对于任何想在这个领域深耕的团队来说深入理解和利用好GUI-CEval无疑是取得突破的关键一步。