清华、哈工深联手小米，让AI同时搞定电脑和手机操作？这个"老师带学生"的训练方法有点意思

这项由清华大学深圳国际研究生院、哈尔滨工业大学（深圳）、小米、浙江大学及鹏城实验室联合完成的研究，以预印本形式发布于2026年7月，论文编号为arXiv:2607.04425，感兴趣的读者可通过该编号检索完整论文。

你有没有想过，未来的AI助手能像真人一样，既能熟练操作电脑上的Word、浏览器、文件夹，又能灵活地在手机上点击、滑动、回复消息？这听起来理所当然，但实现起来却远比我们以为的难得多。研究团队在探索这个问题时，发现了一个颇为有趣的困境，并为此设计了一套独特的解决方案。

故事要从一个基本问题说起：AI怎么学会"用软件"？和人类学技能的方式类似，AI需要大量的"示范操作"来学习，比如看着人类怎么打开文件、怎么填写表单、怎么在手机上发微博。这些示范操作就是所谓的"交互轨迹"。然而，同时让AI学会在电脑和手机上都能灵活操作，研究团队碰到了两道难关。

第一道难关是数据太少且质量参差不齐。现有的示范操作数据大多只覆盖单一平台，而且里面混有很多无效操作、错误的步骤记录，或者任务描述和实际操作对不上的情况，就像一本食谱里有的步骤写的是"加盐"，但配图却是在切菜，让人看得一头雾水。

第二道难关则更为微妙：电脑和手机的操作习惯根本不一样。在电脑上，"返回上一步"通常意味着关闭当前窗口或按Ctrl+Z撤销；但在手机上，同样的意图却是点击屏幕左下角的"返回"按钮。把这两套截然不同的操作逻辑混在一起训练，AI很容易"混乱"，不知道该按哪套规矩来。这就好像同时让一个人学用筷子和刀叉，结果他拿着刀叉去捞汤里的面条，又用筷子去切牛排——两边都没学好。

为了破解这两道难关，研究团队做了两件事。一是亲手整理了一套高质量的跨平台操作数据集，命名为Uni-GUI；二是提出了一种名为UI-MOPD的训练方法，让一个"学生AI"同时向两位专门的"老师AI"学习，并且根据当前是在操作电脑还是手机，自动决定听哪位老师的话。最终，这个学生AI在电脑任务上的成功率达到了38.2%，在手机任务上也达到了12.0%，相比出发点分别提升了约12.7%和55.8%，而且两个平台的能力都没有相互拖累。

一、先把"教材"做好：Uni-GUI数据集的诞生

要培养一个能同时在电脑和手机上工作的AI，首先得有足够好的练习材料。研究团队为此搭建了一套统一的"数据采集流水线"，可以理解为一座同时拥有电脑实验室和手机测试间的训练工厂，而且两个车间用的是同一套记录格式，方便后续统一处理。

整个数据采集过程分为四个环节，环环相扣。第一步是"出题"，团队让两个强大的AI模型分别负责电脑和手机端的题目生成。具体来说，电脑端的题目由Kimi-K2.6来出，它会先在电脑操作环境里扫描有哪些真实可用的功能，再根据这些功能生成合理的用户任务，比如"把LibreOffice表格里的数据复制到Writer文档里，并保存为price.docx"。手机端的题目则由Gemini-3.1-Pro来出，它同样从真实的手机应用环境里提取可操作的功能点，再生成自然的用户指令。这种"先摸清环境、再出题"的方式，大大降低了出现"鸡同鸭讲"——也就是任务要求和实际环境对不上——的情况。

第二步是"解题"，让这两个AI模型在真实的电脑和手机环境里，按照生成的题目一步一步执行操作，并把每一步的截图、操作动作、中间思考过程都记录下来，形成原始轨迹。

然而原始轨迹里噪音很多，所以第三步是严格的"清理"。团队制定了一套多层过滤标准：首先剔除结构不完整的轨迹，比如步骤不连续或有重复步骤的；然后过滤掉包含学生AI无法执行的操作类型的轨迹；接着去掉超过40步的过长轨迹，因为这类轨迹往往包含低效探索或错误积累；再删除任务描述与实际环境不符的轨迹。最后，用Gemini-3.1-Pro充当"质检员"，逐条评估轨迹是否真正完成了任务。评估时，质检员会先把每个任务拆解成一系列子任务，然后逐步骤检查每个子任务是否被完成，只有全部子任务都通过才算合格。这种细粒度的质检方式，比一次性判断整条轨迹好坏要精确得多。

第四步是"格式化"，把留下来的优质轨迹统一改造成学生AI能直接使用的格式。这包括两项工作：一是把原始AI的推理过程重写为标准化的"结构化思维链"格式，因为Kimi和Gemini各有自己的思维表达习惯，直接拿来用可能会干扰学生AI自己的输出习惯；二是为每个需要点击或操作具体界面元素的步骤，重新标注目标区域的边界框坐标，方便后续用规则评估操作是否打在了正确位置上。

经过这套流水线处理，团队最终获得了Uni-GUI数据集。这套数据集包含电脑端约7800条自采轨迹加上约800条来自OpenCUA开源项目的清理轨迹，以及手机端约1000条自采轨迹加上约2700条来自OpenMobile开源项目的清理轨迹，总计约11500条高质量轨迹、约16万个交互步骤。引入OpenCUA和OpenMobile的目的是扩大覆盖的应用类型和任务多样性，但这些开源数据同样经过了同一套清理流程，而非直接拿来就用。

二、"一个学生，两位老师"：UI-MOPD的核心思路

有了高质量的教材，下一步就是设计训练方法。研究团队的核心思路可以用一个直观的比喻来描述：培养一名"全科选手"，让他同时向两位专科老师学习——一位专教电脑操作，一位专教手机操作——而且无论在哪个课堂上练习，都只接受对应专科老师的指导，两位老师的教导不混在一起。

这个训练过程分为两个阶段。第一阶段是"培训老师"。团队把一个通用的大型视觉语言模型Qwen3-VL-32B-Thinking，分别在Uni-GUI的电脑轨迹和手机轨迹上进行监督微调，训练出两个专家级的"老师AI"：电脑老师和手机老师。这两位老师各自积累了深厚的单平台操作经验，电脑老师熟知鼠标点击、键盘快捷键、窗口切换的规矩，手机老师则精通点击、滑动、长按、系统导航的习惯。

第二阶段是"培训学生"。学生AI是一个更轻量的模型Qwen3-VL-8B-Thinking，体量大约是老师AI的四分之一。训练方式融合了两种机制：强化学习和"在线蒸馏"。

强化学习的部分可以这样理解：让学生AI在真实的电脑或手机环境里自己尝试完成任务，每完成一步就根据结果获得反馈评分，成功的操作得正分，部分正确的得小负分，格式错误或完全无效的操作扣大分。这套评分机制让学生AI能在不断试错中逐渐学会哪些操作是有效的。

然而，纯粹靠试错的学习方式有个风险：学生AI可能会走偏，在电脑任务上练得多了，就把手机任务的操作习惯给"覆盖"掉了，反之亦然。这就是"在线蒸馏"发挥作用的地方。

所谓"在线蒸馏"，可以把它理解为老师在学生旁边实时提供参考。学生AI每次自己生成一段操作，老师AI就对同样的输入也给出自己的判断，然后计算两者之间的差距——用一个专业名词来说叫"KL散度"，但通俗来讲就是"学生和老师的回答有多不一样"。训练的目标之一就是让这个差距尽量小，也就是让学生的操作决策往老师靠拢。

关键在于"在线"二字：老师的参考不是预先录好的固定答案，而是在学生实际执行操作时，针对学生当前真正碰到的那些状况实时提供。这就保证了老师的指导能精准覆盖学生真正会犯错的地方，而不是泛泛地让学生去模仿老师在另一些场合下的行为。

更重要的是"平台条件路由"机制：当学生AI在做电脑任务时，只有电脑老师的意见会被纳入约束；当学生AI在做手机任务时，只有手机老师的意见会被纳入约束。两位老师的指导信号不会混在一起，各管各的地盘。这样一来，电脑操作的行为规范和手机操作的行为规范在学生AI的参数空间里形成了各自独立的"锚点"，强化学习驱动学生AI提升任务完成率，而老师的约束则保证这种提升不会以破坏另一平台的操作习惯为代价。

还有一个细节值得一提：研究团队设计了一个"自适应KL遮罩"机制。当学生AI在某类任务上的平均得分已经足够高时，老师的约束信号会自动降低权重，给学生更多自由探索的空间；而在学生表现还不好的任务上，老师的约束则保持较强，防止学生往错误方向乱跑。这就像一个聪明的教练，学生已经掌握的动作就少纠正，学生还在摸索的动作就多盯着。

三、实验结果：数据说话

研究团队在两个标准化的测试环境中评估了UI-MOPD的表现。OSWorld是一个评估AI完成电脑桌面任务能力的基准测试，包含361个任务；MobileWorld是评估AI完成手机任务能力的基准测试，包含117个任务。

在与一系列对比方案的比较中，UI-MOPD在两个平台上都取得了最均衡的成绩，电脑端达到38.2%，手机端达到12.0%。相比之下，其他方案往往呈现"顾此失彼"的状态。

以"混合监督微调"方案为例：把电脑和手机的训练数据混在一起直接训练同一个模型，结果电脑端35.0%，手机端只有6.4%，两头都没有UI-MOPD好，尤其手机端差距明显。这印证了研究团队最初的担忧：不加区分地混合两套操作习惯，会让模型学出一个"不伦不类"的平均化策略。

"模型合并"方案——也就是分别训练好电脑专家模型和手机专家模型后，通过权重平均或TIES-Merging算法把两个模型的参数合并成一个——的表现也不尽如人意。权重平均方案在电脑端达到36.5%，手机端6.8%；TIES-Merging方案电脑端36.8%，手机端则直接归零，完全失去了手机任务能力。参数合并这个操作，就像把两本菜谱的食材用量简单平均——有些菜或许还凑合，但很多菜会因为配比全乱了而变得难以下咽。

与其他多平台GUI智能体的比较也颇具说服力。GELab-Zero-4B在手机端有10.9%，但电脑端只有31.9%；GUI-Owl-7B电脑端达到34.9%，手机端却只有4.5%。两者都呈现明显的单边偏强特征。

研究团队还做了一组分析，用来衡量学生AI从老师AI那里继承了多少能力。电脑老师（32B规模）单独测试时，电脑端成功率高达46.3%；手机老师单独测试时，手机端成功率为16.2%。学生AI（8B规模）通过UI-MOPD训练后，电脑端达到38.2%，手机端达到12.0%，相比学生AI的起点（电脑33.9%，手机7.7%）有实质性提升。更值得注意的是，学生AI在手机端的表现12.0%已经超过了32B规模基础模型的9.4%，说明方法本身带来的增益不仅仅源于模型规模的差异。

与此形成对比的是，单独在电脑数据上微调学生AI，电脑端提升到35.8%，但手机端直接降到0%——完全忘掉了手机操作；单独在手机数据上微调，手机端达到12.8%，但电脑端的提升幅度不如UI-MOPD。这说明单平台专项训练确实会造成另一平台能力的崩塌，而UI-MOPD能同时在两端保持稳定提升。

四、通用理解能力有没有被"连累"？

在提升交互任务能力的同时，研究团队还关心一个问题：经过这套训练后，模型对GUI界面的静态理解能力——比如识别界面元素、定位按钮位置——是否会有所损失？

他们在四个静态测试基准上做了评估。AndroidControl?是从AndroidControl数据集中提取的一个子集，包含781条安卓操作轨迹共4260个步骤，用于测试模型在静态场景下对手机GUI的理解和操作能力；ScreenSpot-Pro和ScreenSpotV2测试模型能否在截图中准确找到目标界面元素的位置；OSWorld-G则专门评估模型在电脑截图中的视觉定位能力，涵盖文本匹配、元素识别、布局理解等多个子项。

结果显示，UI-MOPD在AndroidControl?上的综合准确率从基础模型的78.73%提升到了80.05%，动作类型预测准确率从85.75%提升至87.02%，定位准确率也略有改善。在ScreenSpot-Pro上，UI-MOPD得到43.14%，接近基础模型的43.71%；在ScreenSpotV2上得90.88%，接近基础模型的91.27%；在OSWorld-G上则从52.13%小幅提升到52.84%。总体来看，UI-MOPD在通用理解能力上几乎没有造成损耗，部分指标还有微小改善。

相比之下，TIES-Merging方案在所有静态评测上都出现了明显退步，ScreenSpot-Pro从43.71%跌至37.13%，OSWorld-G从52.13%跌至47.16%，AndroidControl?的综合准确率从78.73%跌至74.01%。这进一步说明了参数直接合并对模型原有能力的破坏性，而UI-MOPD的在线蒸馏方式则能较好地规避这一问题。

五、从细节看方法的可靠性：案例与实现

论文还通过两个具体的任务执行案例，展示了UI-MOPD在实际操作中的表现。

手机端的案例是：找到一个分享过希腊食物慕萨卡（Moussaka）的美食用户，回复他的帖子，内容为"Nice sharing, i love it"。模型需要先从主界面找到社交软件入口，点进去找到对应的帖子，进入回复界面，输入指定文字，最后确认发送。整个过程中模型展示了"观察当前屏幕→制定计划→预判结果→执行操作"的结构化思维方式，步骤之间衔接有条理，能识别文件浏览器里的目标文件并正确点击。

电脑端的案例是：把LibreOffice Calc当前工作表中的数据复制到LibreOffice Writer的表格里，保留原有格式，并将文件保存为桌面上的price.docx。这个任务需要在两个不同的办公软件之间切换、复制粘贴表格内容，并通过文件保存对话框指定文件名和保存路径。案例中还展示了模型在菜单点击失误后的自我调整——它观察到多次尝试后"另存为"菜单仍未出现，判断是点击坐标与菜单项位置存在微小偏差，于是再次尝试，最终成功完成任务。这种在执行过程中观察反馈、调整策略的能力，是GUI智能体在真实环境中有效工作的重要前提。

在工程实现层面，整个训练系统运行在64块NVIDIA H100 GPU上，分布在8个节点中，每个节点8块GPU。训练框架使用verl，Megatron-Core负责模型训练，SGLang负责推理采样，vLLM负责评估阶段的模型部署。学生AI采用2路张量并行、32路数据并行的方式分布运行，老师AI则采用8路张量并行、8路数据并行。每个训练提示采样8条输出，最大输入序列长度8192个标记，最大输出长度512个标记。训练时，视觉输入只使用当前截图；推理时，则使用4张历史截图加当前截图，配合完整的历史操作文本，给模型提供更丰富的上下文信息。学习率设定为一百万分之一，在线蒸馏的KL损失系数为0.01，整个训练过程只跑一个完整轮次。

说到底，这项研究的核心贡献在于提出了一个相对直接但在GUI智能体领域此前尚未有人系统尝试的想法：不要让不同平台的训练信号混在一起互相干扰，而是给每个平台安排专门的老师，让学生AI在每次练习时只向对应平台的老师看齐，同时通过在线强化学习持续提升实际任务完成能力。这套思路叫做"多教师在线策略蒸馏"，配合精心整理的Uni-GUI数据集，实现了在一个8B规模的轻量模型上同时提升电脑和手机两个平台的任务执行能力，并且没有损害模型对界面的基础理解能力。

当然，目前38.2%和12.0%的成功率离"能帮人真正干活"的门槛还有相当距离，手机端的绝对表现尤其还有很大的提升空间。不过，在单个紧凑模型上同时实现两个平台的均衡提升，同时保持通用理解能力，已经是一个有说服力的起点。随着跨平台操作数据的进一步积累，以及训练方法的持续迭代，这类技术或许能逐渐走向真正可用的跨平台AI助手。有兴趣深入了解技术细节的读者，可以通过arXiv:2607.04425查阅完整论文。

Q&A

Q1：Uni-GUI数据集和其他GUI训练数据集有什么区别？

A：Uni-GUI最核心的不同在于它同时覆盖电脑和手机两个平台，并且经过严格的多层清理流程，包括剔除无效操作、过滤格式错误、用AI质检员做子任务级别的成功验证，最终保留约11500条高质量轨迹。相比之下，现有数据集大多只针对单一平台，且质量控制力度参差不齐。

Q2：UI-MOPD训练出来的模型在用的时候需要同时加载两个老师模型吗？

A：不需要。两个老师模型只在训练阶段参与，用于提供平台对应的参考信号。训练完成后，实际使用时只需要部署学生模型这一个模型，不会增加推理阶段的资源消耗或系统复杂度。

Q3：为什么模型合并方法在手机任务上会直接归零？

A：TIES-Merging等参数合并方法在处理电脑和手机两个专家模型时，会对参数进行某种"平均化"或冲突裁剪操作。电脑端数据量远多于手机端（约95K对17K自采步骤），手机端的参数特征在合并后很可能被大幅稀释甚至覆盖，导致模型完全丧失手机操作能力。这也说明单纯依靠参数合并无法保留体量较小一方的专项能力。