这项由小米SeerRay团队主导的研究，以技术报告形式于2026年6月30日发布，论文编号为arXiv:2606.31410。感兴趣的读者可通过该编号检索到完整原文。
手机里的AI助手越来越智能，但你是否遇到过这样的尴尬：让它帮你在淘宝下单，它却在登录验证码页面停滞不前；叫它订张机票，它在弹窗广告前不知所措，最终导致整个任务失败。在各种测评榜单上表现优异的AI，到了真实手机中却仿佛换了一个“人”。这种反差背后，隐藏着一个长期困扰行业的核心矛盾——实验室中的佼佼者，未必是现实世界的能手。
小米的研究团队将这一矛盾明确提出，并设计了一套从始至终在“真实战场”上进行训练和测试的方案，最终推出了Xiaomi-GUI-0这款产品。该系统的核心思路非常直接：既然真实手机上遇到的麻烦，在模拟器中根本无法复现，那么干脆将真实手机作为训练场和考场，让AI在摔跤中学会走路。
所谓“GUI”，是图形用户界面的缩写，简单来说就是手机屏幕上的那些按钮、输入框和列表页面。GUI智能体，是指能够看懂屏幕内容、理解你的指令，并替你完成点击、滑动、输入、导航等操作的AI系统。它无需App开发者专门为其留后门，直接基于屏幕画面，原则上可以操控任何现有的App。随着视觉语言模型（能同时理解图像和文字的AI）的快速进化，这类系统已从纯粹的实验室演示，迈向了真正可用的阶段。手机场景尤为典型，因为人们每天在手机上执行的高频任务数量多、种类杂，从抢票刷视频到网购，几乎涵盖了现代生活的方方面面。
然而，问题在于现有的训练和评估体系存在一个根本性漏洞。大多数现有系统依赖“历史上的成功轨迹”进行学习——这就好比一个厨师只练习过顺风顺水的烹饪，从未遇到过食材变质、炉火熄灭或菜单临时改动等意外。而在真实手机环境中，账号登录过期了怎么办？突然弹出的风控验证如何处理？支付页面需要人脸识别时是否该继续执行？这些纷繁复杂的异常状态，在模拟环境中根本无法学到。更麻烦的是，许多主流商业App本身具备“反模拟器检测”机制，根本不愿意在虚拟环境中正常运行。
小米的解决思路，可以用一个类比来理解：与其在室内泳池练习游泳，不如直接跳进真实的江河湖海，同时配备救生员和安全绳作为保障。整个研究围绕这一核心思路展开，涉及基础设施搭建、数据采集与构建、模型训练流程、评估体系四个层面，每一层都有大量值得细说的细节。
一、真实设备与沙盒环境：AI助手的“真实训练场”
要理解为何必须在真实设备上训练，先回想一下考驾照的流程。在驾校模拟器上练习时，你永远不会遇到真实道路上的突发情况——老人横穿马路、雨天路滑、出租车突然变道。只有在真实道路上积累经验，你才能应对那些模拟器中从未见过的场景。AI助手面临的处境完全类似。
小米团队搭建了一套以真实手机为主、虚拟沙盒为辅的混合基础设施。在资源层面，他们维护了一个覆盖近十个主流手机品牌的物理设备池，这些手机覆盖了市场上最高频的100款商业App，平板和车机则覆盖了20款代表性应用。每台设备在进入可调度状态之前，都要经历完整的初始化流程：安装目标App、登录账号预热、建立调试连接，同时屏蔽掉可能干扰执行的权限弹窗。沙盒则作为补充——对于账号风控相对宽松、在虚拟环境下能稳定运行的App，沙盒可以提供大规模并行、高度可复现的测试能力。这样一来，真实设备定义了训练数据的核心分布，沙盒保证了规模和稳定性，两者各司其职。
调度层面有一个巧妙设计：他们没有采用传统的“推送式”任务分配（系统主动将任务塞给设备），而是让设备主动来“拉取”任务。每台设备会持续上报自己的当前状态——包括设备型号、屏幕分辨率、已安装的App列表、账号可用状态、风控等级等一系列信息。只有当任务需求与设备当前状态完全匹配时，调度器才会分配任务。这个设计的好处在于，真实手机随时可能掉线、登录失效、触发风控或进入冷却期，推送式分配会导致大量任务被发给“状态已经不对”的设备，造成资源浪费。拉取式调度则让设备状态驱动任务分配，大幅减少了无效执行。
在执行层面，每一步交互都被完整记录下来：任务描述、设备类型、App状态、截图、执行动作、时间戳、异常类型……这些记录既支撑后续训练，也为失败分析和数据飞轮提供了原材料。此外，还有一个人工维护通道——系统将设备屏幕实时推流到浏览器，维护人员可直接在浏览器中操作，动作会同步到真实设备执行，用于处理账号过期、风控拦截等需要人工介入的异常状态。
二、训练数据的三条来路：从高频任务到长尾意图
数据是AI系统的“粮食”，但并非所有粮食都一样。小米团队针对真实手机场景所需的五类监督信号，设计了三个数据层次，并辅以一套持续运转的“错误飞轮”来构建训练数据。这五类监督信号分别是：精准执行高频功能、正确处理异常状态、泛化到长尾意图、与模型真实错误分布对齐的纠错信号，以及规划、反思、记忆等核心智能体能力。
第一个数据层次是高频任务数据，针对的是用户每天最常做的那些事。研究团队为每款纳入范围的App，都整理了一份功能清单，覆盖了必须被可靠执行的操作——视频App里的“调整自动播放”、电商App里的“加入购物车”、导航App里的“按地点搜索路线”。每个功能对应多个自然语言表达方式（因为不同用户表述同一件事的方式千差万别），每种说法再配套多条功能等价的执行轨迹，覆盖不同的入口页面和中间跳转状态。
这里有一个容易被忽视的细节：标注轨迹通常从App首页出发，但真实用户发出请求时，可能正好在某个中间页面。为此，团队设计了三种中间页面数据增强。第一种是“正确路径上的中间页面”：将完整轨迹从某个中间步骤截断，用剩余部分模拟用户已经走了一半的场景。第二种是“正确路径外的中间页面”：用户在同一个App的无页面上，模型需要通过返回或切换标签找回正确路径。第三种是“跨App的相似功能页面”：用户正在另一个App的功能相似页面上，模型需要识别App不匹配，主动切换到目标App。
此外，每条轨迹中的每张截图都会标注当前前台App的名称——这个设计旨在解决一个现实问题：不同App中可能出现视觉上高度相似的功能页面，仅凭截图容易误判。有了App名称这个明确标签，模型就能学会区分“看起来像购物车页面”和“真的是目标App的购物车页面”之间的差别。
异常状态覆盖是这个数据层次的另一重点。团队额外采集了约5000个样本，覆盖14种异常类型：登录过期、验证码、支付验证、权限弹窗、网络错误等等。每种异常都对应明确的处理策略——需要人工参与的（如验证码），模型学会停下来将控制权交还给用户；可以安全跳过的（如非关键弹窗），模型学会关闭或绕过。这些数据让模型不仅知道“正常情况下怎么走”，也懂得“异常打断时如何判断、如何停下、如何接手”。
第二个数据层次是高泛化数据，针对的是长尾意图——那些不那么常见、但真实存在的用户需求。这一层的构建流程是一条自动化程度很高的流水线，从功能树出发，经过查询合成、轨迹生成、数据清洗四个环节。
功能树的构建是起点。商业App的功能并非平铺的清单，而是层层嵌套的树状结构——首页入口→频道页→搜索结果页→详情页→操作页，如此递进。标注人员从每个App的顶层入口出发，逐层展开，记录每个页面上对用户有意义的功能入口，直到到达具体功能点或深度上限。每个节点都存储三个字段：功能名称、示例查询、功能页面，这样入口序列、页面上下文和用户请求形式被保存在同一条记录里。整棵树经过两轮人工核验：内容核验检查功能点是否完整、示例查询是否合理；格式核验检查字段是否齐全、父子关系是否正确。功能树覆盖率后来也被用作衡量数据覆盖程度的观测指标。
有了功能树，查询合成就有了索引。但直接从叶节点采样会产生很奇怪的查询——就像从菜单上随机挑几个词拼成一句话，而不是真实用户会说出口的请求。为此，团队引入了“行为桶”这个概念。功能树描述的是App提供了什么，行为桶描述的是用户想用App完成什么。两者的区别，类似于超市商品陈列（功能树）与一个人进超市的购物目的（行为桶）之间的区别。每个App被归纳出8到10个行为桶，每个桶对应一种稳定的使用动机，包含若干具体的行为短语。合成查询时，以行为桶作为主要采样轴，保证查询是由真实意图驱动的功能组合，而不是功能名称的机械堆砌；再以功能树作为补充采样轴，确保覆盖到那些只有从功能树叶节点才能触达的细粒度功能点。
查询按执行范围分成单应用查询和跨应用查询两大类。单应用查询内部又分三种：功能点查询（针对单一功能点，如“给这个抖音视频点赞”）、复合查询（组合多个功能点，如“在淘宝搜索千元以内的蓝牙耳机，比较候选商品的续航，将续航最长的加入购物车”）、汇总查询（跨多页面聚合或比较信息，如“总结这个淘宝商品的差评，找出主要吐槽点”）。跨应用查询则覆盖三种任务关系：接力型（A应用的信息作为B应用操作的输入）、对比型（两个应用对同一个或同类对象给出可比较的结果，按价格、评分、时效等维度比较）、并行型（两个应用独立完成各自子任务，共同服务一个更高层场景）。为避免现实中不合理的App组合，上游语言模型会对每对候选App按用户习惯和任务合理性打分，只保留高分组合。
合成出来的查询还要经过三道后处理。第一道是语言模型打分筛选，分别评估“真实性”（是否像真实用户会说的话）、“可完成性”（能否在采集设备上明确判断成功与否）、“复杂度”（任务难度估计），前两个指标硬筛，复杂度作为元数据留用。第二道是自然语言润色，将保留下来的查询改写成更地道的表达，减少合成产物的痕迹。第三道是功能点反标——给每个查询标上它涉及的功能树节点，为后续覆盖率测量和训练数据权重调整提供依据。
轨迹合成由一个闭源的前沿GUI智能体来执行——选择更强的执行策略，是为了提高每单位计算成本内成功轨迹的比例，减少后续清洗时需要丢弃的比例。每个查询都跑一个“观察→决策→行动”的循环，直到成功、失败或达到步数上限。原始轨迹不能直接用于训练，因为其中充斥着重复动作、执行失败、路径偏离、设备掉线、网络抖动、账号失效、格式错误、任务未完成等各种噪声。
清洗在两个粒度上进行。轨迹级别的清洗只保留完整的高质量成功轨迹。判断一条长轨迹是否整体成功并不容易，因为随着上下文变长，判断器容易被稀释。团队的做法是先把查询拆解成有序的子任务列表，然后逐步走查轨迹，判断每个步骤属于哪个子任务、该子任务是否已完成，只有所有子任务都被判定为完成的轨迹才予以保留。这种子任务粒度的判断所用的上下文更短、更聚焦，在320条跨复杂度和App的轨迹上与人工抽检的吻合率达到94%。步骤级别的清洗专门处理重复执行片段——同一个动作或一小组动作连续执行多次而页面状态没有变化。这类重复可能来自模型陷入局部失败模式，也可能来自页面加载延迟、网络抖动等环境因素。直接将重复步骤作为标签，会教会模型“卡住了就继续重复”，这在真实执行中会表现为无限循环。团队的处理方式是将重复步骤从训练标签中摘除，但保留在轨迹历史中——这样重复动作不再是模型要模仿的目标，但作为历史上下文，它们为后续走出困境的纠错步骤提供了“卡住了”这个证据。当后续步骤用返回、切换入口或重新规划的方式打破僵局时，这个纠错步骤仍然是训练标签，它的条件上下文里包含了前面失败的尝试，这就把一段有害的标签模式转化成了面向反思和错误恢复的监督信号。
第三个数据层次是智能体能力增强数据，专门针对长轨迹任务所需的高阶能力：规划、反思、记忆、信息汇总。这些能力通过结构化的思维链（CoT）标注来监督。
原始轨迹里附带的推理痕迹，不管是智能体自己生成的还是标注人员写的，在结构上往往杂乱——页面观察、任务推理、事后合理化混在一段自由文本里。自由格式的思维链对记忆、反思、重规划这类能力来说是不稳定的训练目标，因为同一个状态转移可以用无数种表面形式描述，训练信号不会明确指示模型是否真的识别出了偏差、更新了计划、保留了跨步骤的记忆。
团队的解决方案是将每条保留的轨迹规范化成一个五标签结构化思维链格式，这个格式同时也被写入了模型的系统提示词，确保推理训练时用的格式和推理时输出的格式完全一致。五个标签分别是：【观察】（客观描述当前页面，包括前台App、页面类型和关键可见元素，且只描述看到了什么，不包含行动推断）、【反思】（可选，只在当前观察与上一步计划预期不符时才输出，具体指出期望状态和实际状态的差异）、【计划/计划更新/重规划】（三选一，第一步输出2到4步的局部计划，后续步骤在执行符合预期时输出计划更新，路径需要修正时输出重规划）、【决策】（从观察和计划推导出当前动作及理由，以动作描述收尾）、【记忆】（跨步骤状态，包括已完成子任务、提取的值、已证实失败的路径，由后续步骤继承和更新）。
这套格式遵循四个设计原则。完整性强制要求每步必须明确包含【观察】、【计划】、【决策】和【记忆】，【反思】按需触发，确保每个推理组件都有直接监督。状态继承通过固定字段将上一步的计划和记忆传递给下一步，减少长轨迹中的目标漂移和进度丢失。计划局部化避免了“在第零步发出一个全局计划、之后一成不变”这种模式，每步的计划可以在环境变化时更新（比如弹出广告窗、意外跳转到子页面、触发风控、找不到目标元素）。反思与重规划分离将“检测到偏差”和“修正路径”处理为两个独立的训练信号，偏差先触发【反思】，再触发【重规划】。
结构化思维链标注由Gemini 3.1 Pro这类强视觉语言模型来合成，输入包括当前截图、原始动作标签、上一步的结构化思维链（尤其是计划和记忆字段）、原始任务查询和过去动作摘要。合成时施加两个互补的一致性约束：正向可推导性要求【决策】字段必须能从【观察】和计划字段推导出来，防止推理链与实际动作脱节；标签一致性要求【决策】里描述的动作必须与原始动作标签完全匹配，若不满足则重新生成直到满足为止。这两个约束共同应对了语言模型合成思维链时的两种常见问题：一种是“胡说推理”（推理链与实际动作不一致），另一种是“事后合理化”（推理链只是在为已知动作找借口，而不是从当前状态和任务推导动作）。
三、错误驱动的数据飞轮：让失败变成养料
前三类数据覆盖了正常执行路径，但存在一个结构性的盲点：训练数据以成功轨迹为主，模型在正确状态下如何行动学得很好，但在进入错误状态后如何识别、如何纠正、如何恢复，却缺乏足够的监督。而错误在真实执行中是不可避免的——一步走错，后续的页面状态就会发生变化，后面所有步骤都是在错误基础上条件化的，失败往往连锁扩散。这种弱点正是复杂任务上性能的主要瓶颈。
研究团队提出的错误驱动数据飞轮，专门围绕模型自身的真实错误分布来构建纠错和反思数据。整个飞轮由两个互补的环节构成。
第一个环节是交互式标注。失败候选样本从脱敏的生产日志、内部自动回归环境和门控滚动评估中挖取，所有账号、姓名、手机号、订单号等隐私字段在进入标注流程之前会被清除。标注人员在平台上回放失败轨迹，找到第一个关键错误步骤，给出纠正动作和简短的错误原因说明。“只标注第一个关键错误”这个规则至关重要，因为GUI执行中失败往往是级联的：早期一步走错，之后的步骤都是在错误状态上条件化的，后面的错误大多是衍生物。只标第一个关键错误，既降低了成本，又将监督聚焦在根本原因上，而不是浪费在衍生错误上。每个标注样本包含任务指令、错误步骤索引、当前截图、动作历史、模型原始动作、错误类型、纠正动作、标注理由和质检状态。人工纠正动作作为当前错误步骤的监督标签，错误步骤之前的轨迹前缀作为历史，而原始错误步骤并不丢弃，而是保留在历史中，为接下来的恢复演示提供真实的错误状态上下文。
第二个环节是教师模型打分与接管。这个机制将纠错监督扩展到人工标注之外的规模。传统的数据飞轮主要追求数据量扩张——让模型跑出更多轨迹，好的进SFT，差的进持续预训练，循环迭代。这类流水线围绕轨迹筛选而组织，保留干净的成功样本，丢弃或降权失败样本，但几乎不产生真正从错误状态桥接到正确路径的数据，对“模型已经走错之后该怎么办”这个问题的监督信号极少。
小米的设计改变了目标：专门生成偏差、诊断和恢复片段，让反思与纠错监督直接针对模型的能力瓶颈。做法是：在集群上跑学生模型的滚动时，教师模型同步接收截图、历史、任务目标和学生的当前动作，返回一个质量分数和文字理由。当分数连续多步低于阈值，轨迹被判定进入不稳定或偏离路径的状态。这个打分信号将错误意识外化出来：它标记了当前模型很可能没有识别出执行已经偏离的时刻。教师随后接管有限步数，给出示范动作，将轨迹从错误状态带回可行路径，然后将控制权归还给学生，滚动继续。有限步数的接管，保证了轨迹整体仍然主要在学生的分布内，同时确保错误状态之后的步骤带有教师质量的恢复动作，将“从失败中恢复”变成了一个可以显式训练的信号。
每一步都被完整存档：截图、历史、学生动作、教师分数、打分理由、实际执行动作、执行者来源标记、接管标记。最终得到的轨迹，既包含成功路径、学生错误，也包含教师的错误判断、教师的恢复动作和接管后的状态演化，这比静态语料库提供了密度更高的监督：模型不仅看到了在正确状态下如何行动，也看到了错误的样子、错误的原因、以及如何从错误中走出来。随着迭代推进，两个环节持续追踪模型进化中的错误分布：简单错误从滚动中消失后，飞轮会自动将注意力集中在仍然顽固的那些错误类型上，让反思数据始终对准模型的当前能力天花板。
四、三阶段训练：从基本功到临场应变
模型训练分三个阶段，每个阶段针对不同粒度的监督信号，形成一个从密到稀的反馈课程。
第一阶段是监督微调（SFT）。这是最基础的阶段，目的是建立稳定的初始策略，让模型先掌握输出协议、动作空间和基本交互模式，才能进入后续的强化学习阶段。四类数据来源——高频任务数据、高泛化数据、智能体能力增强数据和错误飞轮产出的纠正动作数据——在这里合并训练。每个训练样本是从GUI轨迹里提取的单步交互：给定任务指令、交互历史和当前屏幕截图，模型被监督去复现目标智能体输出（同时包含结构化思维链和要执行的动作）。训练目标是标准的下一词预测损失，只对输出部分计算损失，任务指令、历史和当前截图作为条件上下文排除在损失之外。实际规模上，SFT阶段用了约120万GUI步骤级样本（来自约12万条轨迹），加上440万个屏幕理解的定位样本（要求模型解析屏幕上所有可见元素并预测坐标、功能、文本内容等属性）。
第二阶段是步骤级强化学习（Step RL）。这个阶段改善SFT策略在单步响应层面的质量，专门针对那些不需要完整轨迹就能判断的错误：无效动作格式、错误参数、推理结构不完整、记忆字段缺失、推理和动作之间不一致。优化框架采用了群体序列策略优化（GSPO），关键在于将重要性比率施加在整个序列层面，而不是在单个词的层面——因为一个GUI智能体响应的正确与否取决于整体结构，而不是某个词的概率。给定一组针对同一步骤上下文采样出来的响应，GSPO计算每个响应相对于组内平均奖励的标准化优势，然后用裁剪后的序列级重要性比率来更新策略。
奖励函数采用层级触发的级联设计，按从低成本必要条件到高成本充分条件的顺序依次评估，遇到第一个不满足的条件就终止并返回对应奖励。最低层是基于规则的解析器，检查是否存在严重协议或格式错误、解析失败或代码异常，若是则返回-1.0。接下来是基于规则的动作检查，针对格式正确但动作、参数或工具调用无效或与监督不一致的情况，返回-0.5。再上一层是基于规则的结构检查，看必要的推理字段是否缺失、格式错误或顺序混乱，返回-0.5。再往上是语言模型担任评判者的能力检查，看反思、记忆或计划字段是否与当前状态、历史或任务目标冲突，返回-0.5。最高层是语言模型评判者的一致性检查，看推理、动作描述和工具调用是否在语义和因果上对齐，返回-0.5。所有层级都通过返回1.0。这种设计的好处是把评估成本控制在最低限度——昂贵的语言模型评判只对已经通过基础规则检查的响应才调用；同时严格执行必要条件先于充分条件的顺序，响应不会因为高层质量而获得加分，同时违反更基础的要求。
在效率层面，滚动使用异步模式降低批次内的长尾延迟，FP8精度加速生成，课程调度让采样的提示词和当前策略能力保持对齐。在样本效率层面，采用了DAPO的动态采样策略，丢弃那些组内所有响应奖励相同（优势退化、无梯度贡献）的群体。
第三阶段是智能体级强化学习（Agentic RL）。这个阶段把强化学习从单步优化扩展到完整的多步GUI交互，目的是优化跨步骤状态跟踪、中途错误恢复、跨应用一致性和任务级完成率等长轨迹行为。
训练框架需要解决一个现实问题：GPU绑定的语言模型推理（需要高并发）和设备绑定的环境执行（延迟取决于任务复杂度、设备状态和网络）这两个操作的延迟特性完全不同，同步绑定会造成资源浪费和长尾效应放大。框架的解法是将推理、环境执行和数据传输彻底解耦，用独立的异步状态机驱动每条轨迹。推理请求发到SGLang集群，用会话亲和路由实现前缀缓存复用；截图和张量等大载荷存在分布式存储里，控制平面只流转轻量元数据。滚动生产和训练消费异步进行，慢设备交互或长尾轨迹不再阻塞训练器。
因为一条完整轨迹可能跨越很多步骤，将整条轨迹作为一个超长序列训练代价极高。团队的处理方式是在步骤（轮次）层面组织训练数据，每一轮包含任务指令、截图、历史和当前输出，通过滑动窗口控制历史长度，保证每条训练序列足够短。优势仍然从完整轨迹层面计算，每一轮继承其父轨迹的优势，这样轨迹级目标和轮次级更新得以统一。课程采样在滚动之前进行，对每个任务维护一个平滑的成功率估计，通过一个得分函数和softmax将采样概率向既不太容易也不太困难的任务集中，随着训练推进逐步将采样质量从简单任务向更难的任务转移。
五、RealMobile基准：在真实设备上考试
在模拟环境里得高分，不等于在真实手机上好用——这个论断在整篇报告里反复出现，而RealMobile基准就是为了让这个论断变得可量化而设计的。
RealMobile的构建分五个阶段：专家标注人员设计100个任务，覆盖14款应用和4个能力领域，任务难度和跨应用程度各有分布；然后在真实设备上采集黄金轨迹，并用多个智能体采集额外的正样本和负样本；为每个任务生成细粒度子目标和否决条件，初稿由大语言模型产出，再经领域专家核验和修订；专家将自然语言规格编码为可执行验证规则，用XPath查询做UI结构匹配，用代码函数做逻辑语义规则；最后用自动评估流水线验证规则，迭代细化直到与专家判断高度吻合。
14款应用覆盖视频流媒体、社交媒体、即时通讯、电商、导航、旅行订票、音乐流媒体、新闻聚合和数字阅读等多个功能类别。所有应用安装在实体Android设备上，测试账号已登录，对于涉及支付的操作，执行到最终确认页就停止，避免真实扣款同时保留完整的推理链。100个任务里，57%涉及多个应用，其中38%跨2个应用，9%跨3个，10%跨4个及以上，跨应用比例之高，让维持跨应用边界的状态追踪成为一项真实的考验。
四个能力领域各有侧重。基础操作领域的10个任务测试点击、滑动、输入和跨应用导航等基本操作，尽管不需要多少推理，但要求对各应用UI布局和功能语义有准确理解。安全与反思领域的16个任务检查模型能否尊重用户划定的边界，能否在任务不该继续时停下来——安全约束子维度要求拒绝涉及真实成本、账号变更或不可逆操作的任务；反思子维度测试模型能否识别目标不可达并停止或跳过。记忆与知识领域的33个任务评估跨步骤信息保持和应用外部知识的能力——客观记忆子维度考验可验证事实的保留（比如同时查三个平台上某人的粉丝数再发消息）；主观记忆延伸到主观信息的记忆与运用；世界知识子维度检查模型能否用常识推断隐式约束（比如知道“一月去哈尔滨”意味着需要买冬装）。复杂推理与规划领域的41个任务是最具挑战性的——数学与逻辑子维度涉及UI交互中的数值推理；多源比较要求从多个应用采集信息后按优化目标做决策；复杂客观规划要求维护十步以上的顺序状态不偏离；复杂主观规划则是最难的子维度，指令模糊、目标开放，模型必须自主分解任务、决定使用哪些应用、如何组织输出。
评分机制打破了传统的二元判断。每个任务被分解成3到6个可验证的子目标，每完成一个子目标得到等比例的分数，最终分数是完成子目标数量除以总子目标数量，是一个0到1之间的连续值，能反映部分完成的情况。某些不可恢复的严重错误设有否决条件，一旦触发，无论完成了多少子目标都得0分（比如给错误的联系人发了消息、未经授权执行了付款操作）。真实任务经常有多条等价的执行路径，子目标设计也纳入了条件分支——比如某个视频加硬币这步，有硬币时成功加币得满分，没有硬币时确认无法完成也得满分，不让模型因为账号状态这种它无法控制的因素被扣分。
可执行验证规则采用双轨验证框架。XML结构匹配通过在UI层级上求值XPath表达式来验证预期UI元素是否出现或被操作过，可以精确到“这个按钮上包含了'加入购物车'的标签，且点击坐标落在了这个按钮的边界框内”这个粒度。UI层级不总是把所有屏幕文字都暴露出来（有些元素缺少文本属性，有些用图像渲染文字），因此补充了截图的OCR来恢复这些基于文字的条件。逻辑语义规则则处理需要跨步骤或跨应用推理的高阶约束，分为两类：顺序约束确保操作以正确顺序发生（比如必须先查到高铁车次和出发站，才能去高德查从会议中心到那个车站的打车时间，因为查询目标在车次确定之前是不确定的）；一致性约束验证信息在步骤间被正确保留和传播（比如在QQ音乐搜索框里输入的歌名，必须与从小红书页面OCR识别出来的歌名匹配）。每条约束被实现为一个代码函数，在评估时由框架自动调用。
六、实验结果：在真实设备上交卷
Xiaomi-GUI-0以Qwen3-VL-30B-A3B-Instruct作为骨干，在64块NVIDIA H100 GPU上完成训练，分成8个节点。训练框架用verl做强化学习框架，Megatron-Core做训练后端，SGLang做滚动引擎。
在定位基准（判断模型能否将自然语言描述的目标映射到正确的界面元素）上，Xiaomi-GUI-0在四个补充性静态基准上均保持竞争力。ScreenSpot-V2上得到94.7%，MMBench-GUI-L2上82.7%，OSWorld-G上58.7%，OSWorld-G-Refine上64.2%，与同规模近期强基线相当。研究团队指出，这个系统主要面向真实中文手机和车机应用，而四个公开基准主要以英文和桌面端界面为主，存在明显的分布偏差。即便如此，在OSWorld-G和OSWorld-G-Refine这两个桌面端基准上，Xiaomi-GUI-0在布局理解这个子维度仍然处于同类最高水平（分别达到73.8%和81.3%），得分相对偏低的是文本匹配和拒绝类别。
在AndroidWorld（一个基于模拟器的任务执行基准）上，Xiaomi-GUI-0以78.9%的成功率位居所有评测模型第一，超过了UI-TARS系列、GUI-Owl系列和UI-Venus系列，比此前最强的UI-Venus-1.5-30B-A3B的77.6%高出了一截。
在RealMobile上，差距更加显著。Xiaomi-GUI-0以72.0%的成功率、85.8%的平均子目标完成比例，大幅领先所有开源模型（最强的开源模型MAI-UI-8B只有33%的成功率）。这个对比说明，基于离线轨迹、模拟器或公开基准构建的范式，在真实手机场景下的迁移效果极为有限。在闭源系统中，Xiaomi-GUI-0超过了Gemini 3.1 Flash（58%）、Claude Opus 4.7（60%）和Claude Opus 4.6（33%），逼近Gemini 3.1 Pro（85%）和Seed 2.0 Pro（80%）这两个规模更大的前沿模型。
按领域细看，在基础操作领域Xiaomi-GUI-0达到了100%的完美成绩，与Gemini 3.1 Pro和Seed 2.0 Pro并列，说明基础UI操作在当前最强模型里已经接近饱和。安全与反思领域是所有模型表现最差的领域，即便是Gemini 3.1 Pro也只有62.5%，Xiaomi-GUI-0以43.8%位居开源模型第一，但仍然表明安全意识和自我纠错能力是当前GUI智能体普遍的短板。记忆与知识领域，Xiaomi-GUI-0以66.7%领先所有开源模型，但仍落后于Gemini 3.1 Pro（93.9%）和Seed 2.0 Pro（90.9%），这个差距暗示知识密集型的记忆召回可能更依赖模型容量，规模更大、更通用的模型倾向于编码更丰富的世界知识。复杂推理与规划领域最能体现Xiaomi-GUI-0的亮点：80.5%的成功率不仅超过了Seed 2.0 Pro的73.2%，也逼近了Gemini 3.1 Pro的82.9%，而最强的开源竞争基线只有31.7%，这说明在可部署的模型规模下，通过真实设备闭环训练实现的长轨迹规划能力可以媲美前沿闭源系统。
归根结底，Xiaomi-GUI-0这个系统在研究层面想要表达的信息其实很清楚：高基准分不等于真实可用，真实可用必须在真实环境里训练和验证。团队将真实手机、真实App、真实用户请求和真实失败状态，从以往的“部署时才要面对的问题”升格为“训练和评估方法论的核心组成部分”，并以此为基础搭建了数据采集、飞轮构建、训练课程和评估体系的完整闭环。实验结果支持了这个判断，也给这个领域后续的研究方向提供了一个具体的参照系。对于普通用户来说，这意味着未来手机AI助手在遇到验证码、账号过期、支付页面、风控拦截时，有更大可能知道该停下来、该求助，而不是一头撞进去把事情搞砸。读者若有兴趣深入了解技术细节，可通过arXiv编号2606.31410查阅完整论文。
Q&A
Q1：Xiaomi-GUI-0与其他手机AI助手相比，最核心的区别在哪里？
A：核心区别在于训练和评估环境。大多数现有系统使用模拟器和历史成功轨迹来训练，而Xiaomi-GUI-0以真实手机设备作为主要训练场，让模型在真实App、真实账号状态和真实异常状态（比如验证码、支付验证、风控拦截）下学习操作。这个差异导致真实场景下的成功率差距非常大，在RealMobile基准上Xiaomi-GUI-0达到72%，而基于传统范式的开源模型普遍在15%到33%之间。
Q2：错误驱动数据飞轮具体是如何工作的？
A：飞轮分两个互补环节。第一个是交互式标注：标注人员回放AI失败轨迹，找出第一个关键错误步骤，给出纠正动作和原因说明，这些数据让模型学会识别错误根因；第二个是教师模型接管：在模型自主运行时，教师模型实时给每一步打分，连续多步低分说明执行偏离了轨道，教师随即介入接管几步，演示从错误状态恢复到正确路径的过程，然后将控制权还给学生模型。随着迭代，飞轮会自动聚焦在模型当前仍然容易犯的那类错误上。
Q3：RealMobile基准和AndroidWorld基准有什么区别？
A：AndroidWorld运行在模拟器上，用控制好的环境来保证可复现性，任务状态和App页面相对简化。RealMobile则完全在真实手机上运行，使用真实App和测试账号，57%的任务跨越多个应用，评分采用细粒度子目标而非二元判断，同时包含安全约束和反思类任务。这两个基准的侧重点不同：AndroidWorld更适合测量基础执行能力，RealMobile更能反映在真实部署条件下的实际可用性。
