1. 项目概述为什么我们需要一个中文移动GUI智能体评测基准最近在跟几个做移动端自动化测试和RPA机器人流程自动化的朋友聊天大家普遍有个痛点市面上那些评测AI智能体在图形用户界面GUI上操作能力的基准比如AndroidWorld、AITW清一色都是英文的。这导致一个很现实的问题——我们训练出来的模型在中文App环境里表现总是不尽如人意要么识别不了按钮上的中文文本要么对中文界面特有的布局逻辑比如“我的”页面和“设置”的入口习惯理解偏差。这就像让一个只学过英语交通规则的人来开中国的车路标和习惯都不一样难免磕磕碰碰。“GUI-CEval”这个项目的出现正是为了解决这个核心痛点。它不是一个简单的翻译版基准而是一个层次化、综合性的中文移动GUI智能体评测基准。简单来说它要做三件事第一构建一个覆盖主流中文App、场景丰富多样的真实任务库第二设计一套从基础到复杂、从单步到多步的层次化能力评估体系第三提供一个标准化的评测框架让不同研究团队和工业界的模型能在同一个“中文考场”里公平比试。这对于推动中文场景下的GUI智能体无论是用于自动化测试、无障碍辅助还是新型人机交互从实验室走向实际应用至关重要。2. 基准设计的核心思路与架构拆解2.1 为何“层次化”与“综合性”是关键在设计GUI-CEval时团队没有选择做一个“大杂烩”式的任务集合而是引入了“层次化”和“综合性”两个核心设计原则这背后有深刻的考量。层次化主要体现在任务难度的递进上。一个只能点击“确定”按钮的智能体和一个能完成“在电商App里找到特定商品、加入购物车、并使用优惠券结算”的智能体能力天差地别。GUI-CEval将任务划分为多个层级原子操作层评估最基础的能力如点击、长按、滑动、文本输入。例如“点击‘登录’按钮”、“在搜索框输入‘天气预报’”。这是智能体的“肌肉记忆”。简单任务层由少数几个原子操作组合成的目标明确的任务。例如“在微信中搜索并打开与‘张三’的聊天窗口”。这考验智能体对单个App内基本流程的理解。复杂任务层涉及跨页面、多步骤、需要状态追踪和条件判断的任务。例如“在美团外卖中找到一家评分高于4.5的川菜馆点一份宫保鸡丁并使用红包支付”。这需要智能体具备规划、推理和记忆能力。探索性任务层任务目标更开放路径不唯一甚至需要智能体在界面中“探索”才能发现如何完成。例如“在这个新安装的健身App中设置你的每日运动目标”。这模拟了用户面对陌生App时的真实交互过程。这种分层设计的好处是它能像一份详细的“体检报告”精准地指出一个智能体模型在哪个能力层级上存在短板而不仅仅是给出一个笼统的总分。综合性则体现在评测维度的多元化上。GUI-CEval不仅仅看任务“是否完成”还从多个角度进行综合评价成功率最直接的指标任务是否被正确执行。完成步骤数智能体是否走了最短路径还是绕了远路过多的冗余操作意味着模型对界面效率理解不足。鲁棒性面对网络延迟、页面加载缓慢、弹窗干扰等现实情况智能体能否正确处理泛化能力在训练中未见过的App或界面变体上表现如何通过这套组合拳GUI-CEval能够全面、立体地评估一个GUI智能体的真实水平。2.2 任务构建真实、多样、可扩展基准的“血肉”在于其任务库。GUI-CEval的任务构建遵循“真实场景驱动”的原则。数据来源主要通过对真实中文Android应用进行自动化探索和人工标注相结合的方式获取。自动化工具如基于Accessibility Service的爬虫可以大规模地遍历App截取界面截图并提取UI元素树包括控件的类型、坐标、文本、资源ID等。然后由标注人员为这些界面状态设计合理的任务并标注出完成任务所需的最优动作序列ground-truth trajectory。任务多样性基准覆盖了社交微信、QQ、电商淘宝、京东、内容抖音、小红书、工具支付宝、高德地图、生活服务美团、大众点评等十余个类别的头部中文App。确保任务场景既有共性操作如登录、搜索也有各类App特有的复杂流程如在抖音完成一次视频发布、在12306购买指定车票。可扩展性基准架构支持轻松地添加新的App和任务。社区开发者可以按照标准格式提交新的任务数据这使得GUI-CEval能够持续进化跟上中文App生态快速迭代的步伐。注意在构建或使用此类基准时必须严格遵守相关法律法规和平台用户协议。所有数据采集应在获得授权或使用公开测试环境的前提下进行避免侵犯用户隐私和App运营方的权益。GUI-CEval团队在构建时很可能使用了自动化测试框架在受控环境中运行官方提供的Demo应用或测试包这是合规且常见的做法。3. 评测框架与核心实现细节3.1 评测环境搭建从“虚拟手机”到真实交互要让智能体执行任务首先需要为它提供一个可交互的移动环境。GUI-CEval的评测框架通常构建在Android模拟器如Android Studio自带的Emulator或云真机平台之上。这里以本地模拟器为例阐述核心搭建步骤环境准备安装Android SDK并配置好命令行工具。创建一个与基准任务目标App版本相匹配的Android虚拟设备AVD。确保ADBAndroid Debug Bridge可以正常连接到该设备。设备控制层通过ADB命令或更高级的库如uiautomator2、Appium来实现对模拟器的底层控制。这包括安装/启动App、获取当前屏幕截图、获取当前界面的UI层次结构文件XML dump、以及向屏幕指定坐标或特定UI元素执行点击、滑动等操作。# 示例通过ADB获取当前界面XML布局 adb shell uiautomator dump /sdcard/window_dump.xml adb pull /sdcard/window_dump.xml .状态感知层这是智能体的“眼睛”。框架需要实时获取两种关键状态像素状态即屏幕截图。供基于计算机视觉CV的模型使用。语义状态即从XML dump中解析出的UI元素树。供基于大语言模型LLM或纯结构化数据理解的模型使用。GUI-CEval需要提供统一的接口将这两种状态或其中一种传递给被评测的智能体。动作执行层智能体根据当前状态输出一个动作指令如CLICK(‘id/login_button’)或SWIPE(500, 1000, 500, 500)。评测框架需要接收这个指令将其转化为ADB或uiautomator2能执行的命令并发送给模拟器。任务与评估器框架加载定义好的任务包括初始状态和成功条件。在智能体执行每一步后评估器判断当前是否达到任务成功状态如某个特定界面出现、某个文本被检测到、失败状态如超时、进入死循环或继续状态。3.2 智能体与基准的交互流程一次完整的评测循环其交互逻辑如下任务重置评测框架启动模拟器安装并打开目标App通过一系列预设操作或直接跳转将App状态设置为任务的初始界面。状态获取与传递框架获取当前屏幕的像素状态和/或语义状态将其封装成一个标准化的观测Observation对象传递给被评测的智能体。智能体决策智能体模型可能是一个LLM推理框架也可能是一个训练好的强化学习模型接收观测分析当前界面和任务目标输出一个具体的动作Action。动作执行与状态更新框架执行该动作模拟器界面发生变化框架再次获取新的状态。循环与终止重复步骤2-4直到评估器判定任务成功或失败例如达到最大步数限制。记录与评分记录本次任务执行的轨迹状态-动作序列、总步数、是否成功等信息并根据评估标准计算得分。这个流程确保了评测的自动化和可重复性。3.3 核心指标的计算与解读GUI-CEval的评估报告不会只有一个数字。我们需要理解每个指标的含义任务成功率Task Success Rate成功完成的任务数 / 总任务数。这是最核心的指标直接反映智能体的有效性。平均完成步数Average Steps to Success仅针对成功任务计算其消耗的步数。与任务预设的“最优步数”对比可以衡量智能体的效率。步数远多于最优步数说明智能体可能在“瞎摸索”或走了弯路。泛化得分Generalization Score将任务集按App或界面模板划分为“训练集”和“测试集”。智能体只在“训练集”对应的任务上进行训练或示例学习然后在全新的“测试集”任务上评估成功率。这个得分衡量的是智能体举一反三、适应新情况的能力对于实际部署至关重要。4. 实操基于GUI-CEval基准训练与评估一个简易智能体假设我们现在想尝试一个基于“大语言模型LLM 上下文学习Few-shot Learning”的简单GUI智能体并在GUI-CEval上进行评估。4.1 智能体设计思路我们的智能体由两部分组成感知模块负责理解当前界面。我们选择使用UI元素树XML作为输入因为它包含结构化的文本信息更适合LLM处理。我们会将XML解析成一个简化的、富含文本描述的列表例如[元素1: 类型按钮 文本‘登录’ 边界框[x1,y1,x2,y2] 元素2: 类型编辑框 文本‘请输入手机号’ 边界框...]。决策模块一个LLM例如GPT-4或开源的ChatGLM、Qwen。我们将当前任务描述、当前界面描述、以及少量的成功操作示例Few-shot examples一起构成提示词Prompt输入给LLM让它输出下一步应该执行的动作。4.2 具体实现步骤搭建评测环境按照3.1节所述配置好Android模拟器和ADB连接。从GUI-CEval官方仓库下载基准数据。编写环境封装器创建一个Python类它封装了与模拟器交互的所有细节获取XML、执行动作。这个类的核心方法可能是class GUIEnv: def __init__(self, avd_name): self.device u2.connect() # 连接设备 self.current_activity None def get_observation(self): # 获取XML并解析成结构化描述 xml self.device.dump_hierarchy() ui_description parse_xml_to_description(xml) return ui_description def execute_action(self, action): # 解析action如 CLICK(登录) if action.startswith(CLICK): element_text extract_text(action) self.device(textelement_text).click() # ... 处理其他动作类型 time.sleep(1) # 等待界面稳定构建LLM智能体class LLMAgent: def __init__(self, llm_api): self.llm llm_api self.prompt_template 你是一个手机助手需要根据当前界面完成用户任务。 当前任务{task} 当前界面描述{ui_desc} 请从以下可操作元素中选择一个最合适的来执行下一步动作直接输出动作格式例如 CLICK(登录)。 可操作元素列表{actionable_elements} self.few_shot_examples load_examples() # 加载几个示例 def predict_action(self, task, ui_desc): actionable extract_clickable_elements(ui_desc) prompt self.prompt_template.format(tasktask, ui_descui_desc, actionable_elementsactionable) prompt self.few_shot_examples prompt # 添加上下文示例 response self.llm.generate(prompt) return parse_response_to_action(response)运行评测循环def evaluate_agent(agent, benchmark_tasks): results [] for task in benchmark_tasks: env GUIEnv() env.reset_to_task_start(task) done False steps 0 while not done and steps MAX_STEPS: obs env.get_observation() action agent.predict_action(task.description, obs) env.execute_action(action) steps 1 done env.check_task_success(task.success_condition) results.append({task_id: task.id, success: done, steps: steps}) return results计算与分析指标根据results列表计算成功率、平均步数等并分析智能体在哪些类型的任务上失败率高从而指导后续改进。4.3 实操心得与避坑指南状态同步是魔鬼模拟器执行动作后界面刷新需要时间。execute_action后必须加入足够的等待time.sleep或者更优的做法是循环检测直到某个关键UI元素出现再认为状态稳定。否则智能体会基于一个“过时”的界面做出错误决策。XML解析的噪音直接从uiautomatordump出的XML可能包含大量不可见或无关的控件。在将UI描述喂给LLM前必须进行清洗和过滤例如只保留clickabletrue或visible_to_usertrue的元素否则会严重干扰LLM的判断。LLM提示词工程提示词的设计极大影响性能。除了任务和界面明确告诉LLM输出格式的严格限制如必须为ACTION_TYPE(目标)非常重要。Few-shot示例要精心挑选覆盖不同类型的操作点击、输入、返回。处理非文本控件很多图标按钮没有文本描述只有content-desc或resource-id。需要设计规则将这些非文本信息也转化为LLM能理解的描述例如将resource-idcom.xxx:id/iv_close映射为“关闭按钮”。超时与异常处理评测循环中必须设置最大步数防止智能体陷入死循环。同时要捕获网络超时、元素未找到等异常并记录为任务失败避免整个评测进程崩溃。5. 常见问题与模型优化方向在实际使用GUI-CEval进行评测和研发过程中会遇到一些典型问题以下是一些排查思路和模型可能的优化方向。5.1 评测过程中的常见问题问题现象可能原因排查与解决思路智能体反复点击同一位置毫无进展1. LLM对界面理解错误认为该操作有效。2. 动作执行后界面状态未正确同步给智能体。3. 任务本身有歧义或初始状态设置错误。1.检查观测打印出每一步传给LLM的界面描述看是否准确反映了点击后的变化。2.增加状态同步延迟在动作执行后增加更长的等待时间或实现基于特定元素出现的等待条件。3.人工验证任务手动走一遍任务流程确认在给定初始状态下任务是可完成的。智能体在某个App上表现极差在其他App上尚可1. 该App的UI结构特殊XML解析规则未能很好处理。2. Few-shot示例中缺乏该类App的范例。3. App存在动态加载、弹窗等干扰。1.针对性分析XML对比该App与其他App的UI树结构差异调整解析过滤器。2.补充领域示例在提示词中增加一两个该类别App的成功操作示例。3.增强鲁棒性在智能体决策前加入一个“异常状态检测”模块例如检测并自动关闭常见的权限弹窗、更新提示框等。成功率波动大同一任务多次运行结果不同1. LLM生成本身具有随机性。2. 模拟器或网络环境不稳定导致状态获取时延不一致。3. 任务成功条件判断不够精确。1.固定随机种子如果使用LLM尝试设置temperature0以减少随机性。2.环境隔离确保评测在资源充足的独立环境中进行避免外部干扰。3.细化成功条件使用多个条件如特定Activity出现且关键文本可见来共同判定成功提高容错性。5.2 超越基准模型优化的潜在方向GUI-CEval不仅是一把尺子更是一个指明改进方向的罗盘。根据在基准测试中暴露出的问题可以从以下几个方向优化智能体模型多模态感知融合当前很多模型只使用XML或只使用截图。未来的方向是融合视觉和文本信息。例如使用视觉模型VLM理解图标、图片和复杂布局同时用文本模型解析按钮文字两者结合能更鲁棒地理解界面。这在处理纯图标按钮或富媒体内容时优势明显。引入记忆与状态追踪对于复杂任务智能体需要记住之前做过什么。可以在模型架构中引入外部记忆模块或采用具有长上下文能力的LLM显式地维护一个历史动作和关键状态变化的列表帮助模型进行规划避免重复操作或迷失方向。从模仿学习到强化学习Few-shot学习本质是模仿给定的示例。但对于探索性任务可能需要试错。可以结合强化学习RL让智能体在与环境的大量交互中自行学习到哪些动作序列能更高效地完成任务从而获得超越示例的泛化能力。领域自适应与元学习针对“在新App上表现差”的问题可以研究元学习Meta-Learning算法让模型学会“如何快速学习一个新App的操作模式”。或者构建一个庞大的UI元素基础模型通过预训练学习通用界面交互知识再针对特定App进行轻量微调。GUI-CEval这样一个高质量、针对中文场景的基准为上述所有研究提供了可靠的试验场和衡量标准。它让研究者们不再“盲人摸象”而是能在一个统一的、贴近现实的战场上验证想法推动整个领域向前发展。从我个人的体验来看在中文GUI自动化领域拥有这样一个基准就像在迷雾中点亮了一盏灯塔无论是学术研究还是工业落地路径都清晰了许多。