香港中文大学出手：让手机AI助手不再"脑子小"，这个图谱知识框架让4B小模型打败72B大模型

这项由香港中文大学多媒体实验室（CUHK MMLab）联合华为研究院共同完成的研究，于2026年5月以预印本形式发布，论文编号为arXiv:2605.29534。研究团队来自香港中文大学、深圳前海环港研究院以及InnoHK创新香港研究资助局，感兴趣的读者可通过该编号查阅完整原文。

手机已经成为我们生活的延伸，但很多人可能还没有意识到，现在有一种叫做"GUI智能体"的技术，它能像一个助手一样在你手机上自动帮你完成各种任务——比如帮你搜索酒店价格、填写订单、或者调整手机设置。然而，现实情况是，这类助手要做得好，背后往往需要依赖极其庞大的AI模型，这些模型大到根本无法直接运行在手机上，要么得联网调用昂贵的云端服务。这就产生了一个两难困境：要么花大钱、耗流量，用大模型来做事；要么把小模型装进手机，但小模型往往"脑子不够用"，遇到复杂任务就出错。

这支研究团队决定打破这个局面。他们提出了一套名为"UI-KOBE"（全称Knowledge-Oriented Behavior Exploration，知识导向行为探索）的框架，其核心思路是：与其每次都让小模型从头想清楚整件事，不如提前给它准备好一张"地图"，让它照着地图走。这张地图记录了一款手机应用里的所有重要界面和操作路径，小模型在执行任务时只需对照地图做出局部决策，不用再凭空规划整条路线。实验结果相当出色——搭载这套框架的4B参数小模型（4B意味着只有40亿个参数，属于相当轻量的规模），在权威测试集上的表现甚至超越了参数量是它好几十倍的大模型。

一、手机AI助手的现实困境：大脑不够用，或者太贵用不起

要理解这项研究解决的问题，可以用一个旅行者的困境来类比。假设你是一个第一次去陌生城市的游客，要从火车站走到目的地。如果完全凭记忆和即时判断，你可能每走一步都要停下来环顾四周、思考方向，这既费时间又容易走错。但如果你手里有一张详细的地图，你只需要对照地图，每到一个路口做个简单判断，就能顺利抵达目的地。

手机GUI智能体面临的正是类似处境。所谓GUI（图形用户界面），就是我们手机屏幕上能看到、能点击的那些按钮、图标、文字框等等。智能体的任务就是通过识别这些界面元素来操作手机完成指定的任务。目前主流的做法是"端对端"规划：每次看到当前屏幕，模型就要综合考虑任务目标、当前状态、历史操作，然后决定下一步做什么。这对大模型来说还凑合，因为它的"脑容量"足够大，能记住并处理大量复杂信息。

但对于能塞进手机芯片里的小模型（通常在4亿到40亿参数之间），这种要求就太苛刻了。小模型的"工作记忆"有限，面对需要连续十几二十步操作的复杂任务，往往到中途就"迷路"了——不记得自己做到哪一步，或者判断错了当前所处的界面位置，然后开始乱操作。这就是为什么现有的轻量级手机AI助手总是不太可靠。

另一方面，用大模型固然效果好，但麻烦也不少。运行一个几百亿参数的大模型需要强大的算力，手机根本跑不动，必须把数据发到云端服务器处理。这意味着你的操作记录、应用内容等敏感信息都要离开手机，存在隐私泄露风险。而且调用云端大模型的API费用也不便宜，大规模部署成本高昂。

正因如此，研究团队认为，解决方案不应该是"让小模型变得更聪明"，而应该是"给小模型提供更好的外部支撑"，让它在有了"地图"的情况下，用有限的能力完成复杂的任务。

二、核心创新：先画地图，再按图索骥

UI-KOBE框架的精髓在于将两件原本搅在一起的事情彻底分开：一是"了解这款应用"，二是"执行具体任务"。就像厨师和食谱的关系——食谱是提前写好的，记录了所有烹饪步骤和食材搭配；厨师做菜时只需按照食谱操作，不必每道菜都从头发明做法。

这张"食谱"，在UI-KOBE里被称为"应用知识图谱"（App Knowledge Graph）。它是一张有向图，由节点和边两种元素构成。节点代表应用里的各个界面状态，比如酒店预订应用的首页、日期选择页、搜索结果页、房间详情页、订单确认页等等；边则代表从一个界面到另一个界面的可执行操作，比如"点击搜索按钮"从首页跳转到搜索结果页，或者"选择入住日期"从日期选择页返回首页。

这张图谱不是人工手绘的，而是由一个"探索智能体"自动构建的。这个探索过程发生在正式执行用户任务之前，相当于提前派一个侦察员把整个应用的内部构造摸清楚，然后画成地图存档。之后每次有新任务要执行，直接拿出这张地图使用，不用再重新侦察。

研究团队对节点的定义颇为讲究。他们强调，一个节点代表的是一种"功能角色相同的界面状态"，而不是某一张特定的截图。以搜索结果页为例，不管你搜索的是北京酒店还是上海酒店，结果页的布局和功能是一样的，它们应该对应同一个节点。但反过来，即使两个页面视觉上看起来很相似，如果它们的功能不同（比如"出发地选择"和"目的地选择"这两个页面，界面几乎一模一样，但实际用途不同），就必须被识别为不同的节点。这种语义级别的抽象，让图谱能够真正捕捉应用的功能逻辑，而不仅仅是记录一堆截图。

边的设计同样有细致的区分。有些操作会让界面跳转到一个全新的页面，这对应的是连接不同节点之间的边。还有些操作只改变当前页面的某个局部内容，比如在搜索框里输入文字、或者切换日期，界面的整体框架没有变化，这类操作形成的是"自循环边"，指向节点自身。对于自循环边，系统还会记录一个"状态变化描述"，说明这次操作改变了界面上的哪些具体内容。

三、自动建图的完整流程：探索、记录与精炼

探索智能体构建图谱的过程可以分为四个循环往复的步骤，就像一个认真的旅行者在一座陌生城市里系统性地探索街道和建筑一样。

每次循环开始时，探索智能体首先观察当前手机屏幕，生成对这个页面的语义描述（这个页面是干什么用的）、结构化的状态快照（页面上有哪些动态内容，比如当前显示的日期、价格等），以及可交互元素的列表（有哪些按钮、输入框、链接可以操作）。

接着，系统要判断当前屏幕对应图谱里的哪个节点。这个判断分两步走：先把当前页面描述的文本向量（一种数学上的语义表示）和图谱中已有节点的描述向量进行相似度比较，找出最相似的候选节点；然后再做第二层确认，把当前截图和候选节点的参考截图进行视觉对比，让模型最终判断这两个页面是否真的是同一种界面。这两步结合的做法是为了避免"光看文字描述相似就误判为同一节点"的错误——因为两个功能不同的页面有时候文字描述确实比较接近。如果找到了匹配的节点，就更新该节点的信息；如果没有匹配，就创建一个新节点。

节点确认后，智能体要规划下一步操作。它查看当前节点已经探索过的出边，以及还没有被探索过的可交互元素，然后选择一个尚未探索的操作来执行。每次只执行一个动作（点击某个按钮、输入某段文字、或者向上滑动屏幕等），执行完毕后再进入下一轮观察。单步执行的设计使得每次记录的转换关系清晰明确，出错时也更容易定位问题所在。

执行动作后，系统再次观察新出现的屏幕，识别对应节点，然后在图谱里记录这条边：从哪个节点来，到了哪个节点，执行的是什么操作，预期的结果是什么。整个图谱在每一步都会及时保存，这样即使探索中途被打断，也可以从上次停下的地方继续，不用从头再来。

原始探索得到的图谱难免有些瑕疵，所以系统还设计了一套"审计和精炼"机制。首先是图谱审计：检测可能的重复节点（用语义相似度和截图对比来判断）、标记可疑的错误边（比如操作结果和预期不符的那些），确认重复的就合并，错误的就标记等待重新探索。其次是边的规范化：探索时记录的操作指令往往非常具体，比如"输入星巴克"，但这类指令其实可以被抽象成"输入查询词"这样的通用模板，使得图谱能复用于不同的查询场景。第三是覆盖率导向的重新探索：为避免只沿着一条路径深入探索而遗漏其他分支，系统会周期性地选择覆盖率不足的节点进行补充探索，通过重放已知路径到达那些节点，然后从那里继续往外探索。

四、有了地图，小模型怎么用它完成任务

图谱构建完成后，就轮到运行时的GUI智能体登场了。这个运行时智能体可以是一个参数量很小的模型，比如4B或9B规模的模型。有了图谱的辅助，它不再需要从一张截图里凭空推断整个应用的结构，而是只需要做两件简单的事：认清自己在哪，然后从图谱提供的选项里挑一个合适的下一步。

当用户给出一个任务（比如"查一下希尔顿时代广场明天的价格"），智能体先看当前截图，然后在图谱里寻找对应的节点。这个搜索过程也是分两步：先用视觉相似度快速筛出几个候选节点，再让模型做最终判断，确认哪个节点和当前屏幕最匹配，或者判断图谱里根本没有覆盖当前屏幕。

一旦确认了当前节点，智能体就能从图谱里拿到这个节点的"出边列表"——也就是从这个界面出发可以做的那些有记录的操作。系统给智能体提供四种选择：执行一个自循环操作（改变当前页面的某个内容，不跳转页面）、执行一个跳转到邻近节点的操作（导航到另一个页面）、判断任务已经完成（比如已经找到了所需信息）、或者执行一个图谱里没有记录的自由操作（作为后备选项）。

每条边都附带了自然语言描述的操作说明和预期效果，这让小模型的决策负担大大降低——它不需要自己去想"我下一步应该做什么"，只需要从几个有明确说明的选项里判断"哪个选项最符合当前任务需要"。这就好比你在城市里迷路时，有一个当地人直接告诉你"左边是商场，右边是公园，直走是车站"，你只需要选一个方向，不必自己重新规划整条路线。

智能体还配备了一个轻量级的"记忆模块"，用来追踪任务进度。每完成一步操作，模型都会把这次操作的结果和从屏幕上提取到的任务相关信息记录下来，比如"搜索框已填入目的地"、"已看到价格结果"等。这个记忆防止了智能体反复执行同样的操作，也帮助它判断任务是否已经完成。

当遇到图谱里没有覆盖的界面状态时，系统会切换到"回退规划"模式：由智能体自己生成一个具体的下一步操作指令，就像普通的端对端规划一样。但这个回退模式只负责给出下一步的一个具体指令，不要求模型规划完整的任务序列，从而把风险控制在最小范围内。一旦应用回到图谱中有记录的界面，智能体就自动恢复到图谱引导模式。

五、实验结果：数字背后的真实差距

研究团队在两个权威的手机GUI测试基准上验证了UI-KOBE的效果，分别是AndroidWorld和A3。AndroidWorld是一个模拟真实Android设备操作的测试集，用任务完成率（Success Rate）来衡量成绩。A3则是一个更贴近真实在线应用场景的测试集，同时衡量"关键状态达成率"（ESAR，表示任务中各个重要中间步骤的完成程度）和"完整任务成功率"（Overall SR，表示整个任务从头到尾全部完成）。

构建图谱的工作量方面，系统对每款应用进行了300步的自动探索，平均下来每个应用构建的审计后图谱包含54个节点和226条边，构建耗时约3.2小时，费用约6.2美元。这个一次性的投入，就能让该应用上的所有后续任务都受益。

在AndroidWorld上，没有图谱辅助的原始Qwen3.5-4B模型的任务成功率是58.6%。加入UI-KOBE框架后，同一个模型的成功率跳升至70.7%，提高了整整12个百分点。考虑到这个模型本身的参数量只有40亿，这个提升幅度相当显著。更令人印象深刻的是，这个搭载了UI-KOBE的4B小模型，已经超过了不少参数量大得多的模型的裸机表现——比如参数量397亿的Qwen3.5-Plus在没有图谱辅助时只有66.8%，比4B的UI-KOBE还低。也就是说，外部图谱知识让一个只有对方十分之一参数量的小模型实现了反超。

把UI-KOBE换上更大的底座模型，成绩还能继续提升。9B版本的UI-KOBE达到72.4%，397B的Plus版本更是达到77.6%，超过了表格中所有其他的单一模型和智能体框架，包括使用GUI-Owl-32B作为基础的Mobile-Agent-v3（73.3%）。

A3测试集上的提升幅度更为惊人，因为这个数据集的任务本身就更复杂、更贴近真实使用场景。同样是4B的Qwen3.5模型，在没有图谱辅助时，ESAR只有43.7分，完整任务成功率只有26%；加了UI-KOBE之后，ESAR跃升至71.5分，完整任务成功率提升到61%——后者几乎翻了一倍多。9B版本的UI-KOBE在A3上的ESAR是75.7分，完整任务成功率67%，比原始9B模型分别提升了19.8分和36个百分点。最大版本的UI-KOBE（Qwen3.5-Plus）在A3上的ESAR达到84.8分，完整任务成功率78%，甚至超过了使用Google最新强大模型Gemini-2.5-pro的T3A框架（后者ESAR为66.4，成功率53%）。

这些数字共同说明了一个道理：当面对需要多步骤规划的真实手机任务时，外部结构化的应用知识远比简单地堆砌模型参数更有效率。

六、为什么还不完美：两类主要失误

研究团队非常诚实地分析了UI-KOBE仍然会失败的情况，主要可以归结为两类问题。

第一类是图谱本身存在缺陷。探索阶段使用的操作执行模型有时候并不能完全按照计划指令行动——比如计划是点击某个特定按钮，实际执行时却误触了旁边的元素，导致记录下来的这条边是一个错误的转换关系。这种错误在事后审计时很难发现，因为从节点到节点的连接表面上看起来没问题。另外，即使经过审计，图谱里仍然可能存在一些没被合并的重复节点。这种情况通常发生在两次访问同一个界面时，由于页面上显示的动态内容不同（比如两次搜索结果不同），生成的描述文字也不同，导致审计系统误以为是两个不同的节点，把原本应该统一的出边信息拆散了，减弱了图谱引导的效果。

第二类是图谱覆盖范围不完整。探索过程是有步数限制的（300步），一些不常见的操作路径可能没有被探索到。当任务恰好需要这些未记录的操作时，智能体只能依赖回退的自由规划模式，而小模型在这种情况下的表现就没那么稳定了。研究团队还举了一个具体的例子：当任务需要的操作不在当前节点的出边列表里时，4B模型的回退规划往往给出错误指令，把应用引向了错误的界面，之后的操作就完全偏轨了；但9B和Plus版本的模型在同样的情况下能给出正确的回退指令，并在应用回到已知界面后顺利恢复图谱引导模式。这也解释了为什么在有图谱辅助的情况下，大模型仍然比小模型表现更好——图谱覆盖范围内的任务大家都差不多，但一旦执行到图谱边界之外，模型本身的能力差异就显现出来了。

七、还没解决的问题和下一步方向

研究团队坦率地列出了这套框架目前的几个局限性，这些都是未来需要继续攻克的方向。

当应用更新版本、大幅修改界面或导航逻辑时，原有的图谱可能会部分失效，需要进行局部修复或重新探索，这意味着图谱需要一定的维护成本。另外，虽然UI-KOBE的目标之一是在手机上本地运行，但目前图谱检索和节点匹配这个环节仍然依赖一个外部的向量嵌入模型（用于计算截图的视觉相似度），这让完全离线、完全本地的部署还无法实现。此外，整个框架目前只在手机Android应用上进行了测试，是否同样适用于网页应用或PC端的桌面软件，还有待验证。这些都是研究团队明确计划在后续工作中探索的问题。

说到底，UI-KOBE这套框架传递的是一个朴素但有力的理念：把"先学会用一款应用"和"用这款应用完成特定任务"这两件事分开来做，前者做一次，后者反复受益。这和人类的学习方式其实非常相似——我们第一次用一个新软件时，总要花时间摸索各个功能在哪里；但一旦熟悉了，每次打开都能快速找到需要的功能，不必重新探索。UI-KOBE就是把这个"熟悉过程"自动化、结构化地为AI助手完成了。

对于普通用户来说，这项研究预示着一个可能性：未来手机上的AI助手或许真的可以在不联网、不上传数据的情况下，帮你完成更复杂的手机操作任务。你的私密信息留在手机里，助手的能力却不会因此打折扣。当然，从实验室的原型到真正的消费级产品，还有很长的路要走——图谱的维护、本地嵌入模型的轻量化、以及跨平台扩展，都是需要继续攻克的挑战。但这项研究至少证明了，这条路是走得通的。

Q&A

Q1：UI-KOBE框架的应用知识图谱需要为每款App单独构建吗？

A：是的，UI-KOBE目前为每款应用单独构建一个知识图谱。系统通过自动探索生成图谱，每款应用平均耗时3.2小时，花费约6.2美元。这个成本是一次性的，构建完成后可以反复用于该应用上的不同任务，不需要重复探索。

Q2：UI-KOBE构建的图谱能用在不同用户的任务上吗？

A：可以。UI-KOBE构建的图谱记录的是应用本身的界面结构和操作路径，属于应用级别的通用知识，不包含任何特定用户的数据。因此，同一个图谱可以跨任务、跨用户复用，不同用户在使用同一款应用时都可以受益于同一份提前构建好的图谱。

Q3：UI-KOBE框架用4B小模型为什么能超过比它大十几倍的模型？

A：核心原因是图谱把"规划整条路径"这个最难的部分拆解成了"从几个有记录的选项里选一个"这样的简单判断。没有图谱时，小模型需要在每一步都从头推断整个任务的走向，容易出错；有了图谱，小模型只需要认出当前在哪个界面，再从图谱提供的出边选项里挑最合适的一步，难度大幅降低。