1. 项目概述当大语言模型“看”手机屏幕时发生了什么如果你尝试过用ChatGPT或者Claude来帮你写邮件、改代码你可能会惊叹于它们处理文本任务的能力。但如果我们想让这些“大脑”去操作手机App呢比如让它帮你把下周的会议安排进日历或者从一堆照片里找出三年前的老照片做个合集。这听起来像是科幻电影里的场景但已经是当前AI研究的前沿课题——移动端UI自动化智能体。这个领域的核心挑战在于“理解”。一个纯文本的大语言模型LLM就像是一个闭着眼睛的顶级指挥家它能听懂乐谱指令但看不到乐手和乐器手机屏幕上的按钮、图标、布局。传统的方法是给这位指挥家一份“文字版乐谱”也就是从Android或iOS应用的UI层次结构UI Hierarchy中提取出的文本描述比如“这是一个按钮ID是‘com.example:id/submit’文本是‘提交’”。这份乐谱在大多数情况下是准确的但它可能遗漏关键信息那个“提交”按钮是不是被一个红色的警告图标盖住了那个看起来像列表的区域实际上是一个可以横向滑动的卡片流这些视觉上下文对于人类来说一目了然但对于只“听”文本的模型来说却是盲区。于是一个很自然的问题就出现了为了让大语言模型更好地完成移动端任务我们有必要让它“看见”屏幕截图吗视觉信息究竟是锦上添花还是雪中送炭这正是我们这次要深入探讨的核心。我们基于一个名为DailyDroid的综合性移动任务基准进行了一系列对比实验。DailyDroid覆盖了从简单的“设置闹钟”到复杂的“在Facebook上发布带标签和好友的动态”等数十个真实场景横跨生产力、工具、通讯、娱乐等多个类别并将任务难度分为简单、中等、困难三个等级为我们提供了一个绝佳的测试场。简单来说我们想搞清楚在移动应用这个视觉信息极其丰富的战场上给大语言模型配上“眼睛”多模态能力到底能带来多大的性能提升哪些任务因此受益最大背后的原因又是什么这不仅是一个有趣的学术问题更直接关系到未来AI助手能否真正无缝融入我们的数字生活替我们处理那些繁琐但必要的手机操作。2. 核心思路拆解文本UI与视觉信息的博弈要理解视觉信息是否必要我们首先得弄明白模型在操作手机时面临的到底是什么样的信息环境以及两种信息源各自的优劣。2.1 文本UI高效但“失明”的抽象地图文本UI通常是通过Android的uiautomator或iOS的XCUITest等无障碍服务或测试框架从应用底层抓取到的UI元素树状结构。你可以把它想象成网站的HTML DOM树但针对的是原生应用。它通常包含以下关键信息组件类型Button,TextView,ImageView,EditText等。资源ID类似com.android.settings:id/wifi_switch的唯一标识符但很多应用元素ID是动态或空的。文本内容按钮上显示的文字如“确定”、“取消”。描述为无障碍功能准备的描述文本有时比text更准确。坐标与边界框元素在屏幕上的位置和大小。可操作状态是否可点击、可滚动、已选中等。优势显而易见结构化与精准信息以结构化数据呈现模型可以精确地定位到“提交”按钮并知道调用click()动作。高效稳定提取速度快不受屏幕分辨率、颜色主题、动态加载动画的影响。只要应用UI层次结构稳定信息就稳定。隐含逻辑组件类型本身携带了交互语义EditText意味着输入Switch意味着开关。然而其“失明”的缺陷在复杂场景下会被放大视觉语义丢失一个红色的感叹号图标可能意味着“错误”或“警告”但文本UI可能只将其描述为一个ImageView资源ID是ic_warning。模型无法理解这个图标的情感或紧急色彩。布局与分组信息模糊文本UI能告诉你屏幕上有10个TextView但它无法直观告诉你哪几个TextView属于同一个卡片组件或者哪些元素在视觉上被一个分割线隔开形成了不同的功能区。人类靠视觉分组瞬间完成的理解模型需要从杂乱的元素列表中费力推理。内容截断与溢出一个长文章标题在文本UI中可能被截断为“这是一篇关于人工智能未...”而截图里完整显示“这是一篇关于人工智能未来发展的长文”。模型失去了关键上下文。动态与自定义组件很多现代应用使用高度自定义的UI组件它们在UI树中的表示可能非常扁平或怪异难以理解。但视觉上它们可能是非常直观的卡片、瀑布流或轮播图。2.2 视觉信息丰富但“嘈杂”的真实世界影像屏幕截图就是手机屏幕的像素级快照。它包含了文本UI所包含的一切视觉信息甚至更多。它的核心价值在于补充了文本UI的盲区完整的视觉上下文图标样式、颜色编码、空间布局、元素间的相对位置、阴影、圆角等设计语言。这些是理解界面意图和状态的关键。解决歧义文本UI中两个Button可能都叫“确认”但一个在绿色背景上一个在灰色不可用状态。截图一目了然。捕获文本UI提取失败的内容如附录B中的例子在某些模拟器或特定应用场景下UI层次结构提取可能不完整只得到寥寥几个元素而截图完整地展示了所有设置选项网络、应用、通知等。这时视觉信息就成了救命稻草。但视觉信息并非万能它带来新的挑战信息密度与噪声一张1080P的截图有超过200万个像素点包含大量与当前任务无关的细节如状态栏时间、壁纸、广告横幅。模型需要从中筛选出相关部分计算负担和干扰都很大。非结构化模型需要从像素中“解读”出按钮、文本、图标这个过程视觉理解本身就有误差远不如直接读取结构化的文本标签精准。对视觉模型能力的依赖多模态大语言模型如GPT-4V、Gemini Pro Vision的视觉理解能力并非完美对小图标、模糊文字、复杂布局的识别可能出错。成本高昂处理高分辨率图像所需的计算资源和时间远超处理文本。2.3 我们的实验假设结合才是王道基于上述分析我们的核心思路不再是“文本 vs. 视觉”的二选一而是探究“文本 视觉”是否优于“仅文本”。我们假设对于依赖视觉上下文、布局理解或图标识别的任务补充屏幕截图将显著提升大语言模型智能体的任务完成率和鲁棒性而对于那些元素清晰、逻辑直接的任务纯文本UI可能就足够了增加视觉信息带来的收益有限甚至可能因引入噪声而适得其反。为了验证这个假设我们在DailyDroid基准上构建了一个对比实验框架在同一个任务自动化引擎基于AutoTask上运行两套配置。一套仅接收文本UI描述作为输入另一套则同时接收文本UI和当前屏幕的截图。让同一个大语言模型我们使用了GPT-4系列模型作为推理核心在这两种信息模式下去尝试完成所有任务并严格记录每一步的预测、执行和结果。3. 实验平台与任务基准深度解析要让大语言模型操作手机光有模型本身不够还需要一个能让它“动手”的环境以及一套衡量它“动手能力”的标尺。3.1 自动化引擎基于AutoTask的扩展我们选择在开源的AutoTask框架上进行扩展。AutoTask本身是一个设计精良的移动端AI智能体框架其核心工作流程是环境感知通过ADB连接到Android模拟器获取当前屏幕的UI层次结构文本。决策将UI文本和任务指令一起构成提示词Prompt发送给大语言模型。行动模型返回需要执行的动作如click(‘id/login_button’),type(‘id/username_input’, ‘Alice’),scroll(directionDOWN)。执行与验证框架将动作转化为ADB命令执行然后观察新屏幕状态进入下一轮循环。我们的扩展点主要在两个地方视觉信息注入在每一步获取UI文本的同时我们通过ADB命令adb exec-out screencap -p捕获当前屏幕的PNG格式截图并保存下来。多模态提示词工程对于启用视觉的实验组我们在发送给模型的提示词中除了包含结构化的UI文本还会附加一条指令并指明提供了当前UI的截图。模型需要是多模态版本如GPT-4V就能同时处理两种模态的信息。附录C中的提示词片段展示了我们如何简洁地引入视觉上下文“A screenshot of the current UI is provided. Use it to ground your actions...”这个设计确保了除了输入信息的不同两个实验组在其他所有条件模型版本、任务指令、环境状态、动作空间上都保持一致使得性能差异可以明确归因于“是否使用了视觉信息”。3.2 DailyDroid基准一个贴近真实的移动任务考场DailyDroid是我们为此次研究整理的一个综合性基准它的设计目标就是模拟真实用户在日常使用手机时遇到的各类任务。如附录A中的表格所示它有几个突出特点1. 任务类别广泛且实用生产力与工具日历管理、邮件处理、笔记、文件管理、待办事项。这些都是信息工作的核心。工具与系统联系人管理、闹钟/计时器、系统设置、应用管理、计算器。涉及系统层交互。信息获取维基百科、网页搜索、地图导航、商家信息查询、新闻阅读。考验信息检索与筛选能力。媒体与娱乐音乐播放、视频观看、播客、电子书、照片管理。涉及内容发现与多媒体操作。通讯与社交Facebook发帖、Reddit互动、Google Meet会议、短信/电话、Instagram分享。模拟复杂的社交互动流程。2. 任务难度梯度分明简单任务通常是单一步骤、目标明确的原子操作。例如“在Google日历中添加一个明天下午2点的‘医生预约’事件”。模型只需要找到“添加事件”按钮填写几个固定字段即可。中等任务涉及多个步骤或需要理解一些上下文。例如“在Gmail中搜索关键词‘GitHub’并打开最旧的那封邮件”。这需要模型执行“搜索”和“在结果列表中识别并打开最旧项”两个关联操作。困难任务往往是多步骤、有条件判断、需要跨应用或处理非结构化数据的复合任务。例如“在Google Keep中创建一个名为‘旅行计划’的笔记添加一个清单...从相册中选取最近的一张图片附件并添加标签‘#travel’”。这需要模型理解清单结构、操作图库选择图片、并应用标签系统。3. 任务描述自然语言化所有任务都以自然语言指令形式给出例如“给{某人}分享你的实时位置然后发一条消息说‘这是讲座幻灯片’并附上文件中的PDF文档”。这要求模型真正理解用户的意图而不是执行预设的脚本。这样的基准设计确保了我们的评测结果能够全面反映智能体在真实世界中的综合能力而不仅仅是某个特定角落的表现。4. 结果分析视觉信息在哪里真正起作用经过大量实验我们得到了一个清晰的结论视觉信息的价值并非均匀分布它高度依赖于任务的“视觉依赖度”。我们可以将任务大致分为三类。4.1 视觉信息收益显著的任务类型在这些任务中提供截图带来了成功率两位数的提升有时甚至是纯文本UI无法完成的任务。1. 依赖图标识别与视觉状态的任务典型案例调整系统设置如“关闭蓝牙”、“将屏幕亮度调到50%并关闭深色模式”。原因分析系统设置中充满了图标开关Toggle。在文本UI中一个蓝牙开关可能被描述为Switch组件其状态checked可能是true或false。这看起来足够。但是当界面中有多个Switch如蓝牙、Wi-Fi、飞行模式紧密排列时仅凭有限的文本描述可能只有“蓝牙”这个标签来精准对应模型容易混淆。截图能清晰显示哪个开关对应哪个标签以及开关的物理位置左关右开提供了双重验证。对于“关闭深色模式自动切换”这类更复杂的选项其视觉呈现可能是一个子菜单或复选框在文本UI中可能更难解析。2. 依赖空间布局与元素分组理解的任务典型案例社交媒体发帖如Instagram创建帖子添加滤镜、标签、好友、文件管理“按大小排序并删除最大的文件”。原因分析在Instagram发帖流程中点击“创建”按钮后会进入一个全新的编辑界面这里有滤镜选择栏、文字输入框、标签输入区、好友按钮、发布按钮等。文本UI会列出所有这些元素但它们是平铺直叙的。截图能立刻告诉模型滤镜是一排可横向滚动的图标在顶部标签和是输入框内的特定功能按钮主要的操作按钮在右下角。这种视觉分组极大地简化了模型的导航决策。在文件管理器中“排序”通常是一个下拉菜单或某个按钮的隐藏选项其视觉表现形式一个小的箭头图标或“更多”图标在截图中比在文本描述中更容易被识别和定位。3. 文本UI提取不完整或歧义的任务典型案例任何在特定环境如某些模拟器、游戏或重度自定义UI的应用下运行的任务。原因分析正如附录B所揭示的UI层次结构提取并非100%可靠。在某些情况下由于应用使用的渲染技术如游戏引擎、大量自定义View、模拟器兼容性问题或权限限制提取出的文本UI可能只有寥寥几个顶层容器节点丢失了几乎所有可交互元素。此时截图成了唯一可靠的信息源。模型虽然需要费力地从像素中识别按钮和文字OCR但至少有了完成任务的可能性。纯文本UI在这种情况下会直接导致智能体“失明”而失败。4. 涉及非文本内容选择的任务典型案例从相册选择特定照片、在音乐播放列表中选择某一首歌曲。原因分析当任务要求“选择最近的一张照片”或“播放Taylor Swift的《Folklore》专辑”时文本UI对于图片库或音乐列表的表示可能只是一系列带有通用ID如com.android.gallery3d:id/thumbnail的ImageView或者是一系列TextView显示歌曲名。模型很难从“第3个ImageView”推断出它就是“最近的照片”因为顺序可能变化。截图虽然不能直接给出“最近”的语义但它展示了缩略图内容结合多模态模型的图像理解能力模型可以识别出哪张图片看起来最新比如内容识别或者直接看到“Folklore”的专辑封面从而做出更准确的点击选择。4.2 视觉信息收益有限甚至无收益的任务类型并非所有任务都需要“看”。1. 逻辑清晰、元素定位唯一的简单表单填写任务典型案例创建日历事件、添加联系人、发送简单短信。原因分析这类任务界面通常简洁表单字段有明确的文本标签如“标题”、“时间”、“姓名”、“电话”。文本UI能提供精准的EditText组件ID和提示文字。模型只需要做简单的“匹配-填充”即可。截图提供的额外视觉信息如输入框的边框样式、页面背景色对于决策没有帮助反而可能因为图像编码和理解的额外开销略微增加响应时间或引入不必要的干扰。2. 深度依赖应用内搜索或导航的任务典型案例在维基百科中搜索并跳转到特定章节、在Google新闻中搜索特定主题文章。原因分析这类任务的核心动作是“在搜索框输入关键词”和“在结果列表中点击目标链接”。搜索框在文本UI中几乎总是有独特的ID或描述目标链接的文本内容在UI树中也清晰可见。模型的关键能力是理解自然语言指令并将其转化为正确的关键词和链接文本匹配这个过程主要依赖语义理解而非视觉。截图中的搜索结果列表布局对点击哪个链接的决策影响不大。3. 纯逻辑或计算任务典型案例使用计算器进行运算包括切换科学模式。原因分析计算器按钮的排布是高度标准化的。文本UI可以明确给出每个按钮的文本“1”, “2”, “”, “sin”和位置。模型需要的是数学知识来解析“50 25 × 3”并规划点击序列。视觉信息无法帮助它理解运算优先级反而可能因为计算器皮肤的不同而产生混淆。4.3 混合型任务与视觉信息的“保险丝”作用很多中等和困难任务属于混合型。例如“在Google Keep中创建带清单、图片和标签的笔记”。其中“创建笔记”、“输入标题”、“添加标签”是文本友好型步骤而“从图库添加最近图片”则高度依赖视觉或至少需要模型理解“附件按钮”的图标和图片选择界面的布局。在这种情况下视觉信息就像一个“保险丝”它可能不直接提升简单步骤的效率但能防止智能体在视觉依赖环节“卡住”或出错从而保障了整个复杂流程的成功率。我们的实验数据表明在DailyDroid的“困难”级别任务中多模态文本视觉智能体的整体成功率比纯文本智能体平均高出约15-25%。这个提升主要就来自于上述那些视觉依赖环节的突破。而在“简单”任务中两者的差距通常在5%以内甚至有时纯文本更快更稳定。5. 实操启示与系统设计建议基于以上发现如果你正在设计或开发一个基于大语言模型的移动端自动化智能体以下是一些可以直接参考的实操建议5.1 何时启用视觉一个决策框架不要无差别地为所有任务提供截图。这既浪费计算资源也可能增加不确定性。建议采用分层或动态策略第一层任务意图分类。在接收到用户指令时先用一个轻量级模型或规则对任务进行预分类。将任务归入“高视觉依赖”类别如涉及系统设置、图片/媒体选择、复杂UI布局操作、社交媒体发布和“低视觉依赖”类别如表单填写、简单搜索、明确导航。第二层环境状态检测。即使对于“低视觉依赖”任务也需要一个故障检测机制。可以设置一个“文本UI置信度”指标例如如果当前屏幕提取到的可交互元素少于3个或者关键目标元素的文本/ID为空则立即判定文本UI质量低下自动切换到多模态模式请求截图作为补充。动态切换智能体在执行过程中可以持续监控。如果连续几步模型都输出低置信度的动作例如反复点击无效坐标或者环境反馈与预期不符可以触发“视觉辅助请求”临时捕获并分析截图以突破僵局。5.2 多模态提示词工程要点当决定使用视觉信息时如何有效地在提示词中整合它至关重要。我们的经验是明确指令像我们使用的指令“A screenshot of the current UI is provided. Use it to ground your actions...”就很好。它明确告诉模型有一张截图它的作用是“落地”你的行动并解决文本描述中的“歧义”。避免使用模糊的“这里有一张图片”。结构化信息优先在提示词中仍然优先放置结构化的文本UI信息。因为对于模型来说解析“ID为submit的按钮”比从图片中识别一个绿色按钮要直接和准确得多。截图应作为补充和验证的参考。引导关注点对于特别复杂的界面可以在指令中稍作引导例如“请特别注意截图顶部的标签栏布局”或“图标颜色可能指示状态”。但这需要谨慎避免过度干预模型的自主观察。5.3 性能与成本的权衡引入视觉模型如GPT-4V必然带来更高的API调用成本和更长的延迟。在系统设计中需要考虑缓存策略对于相对静态的应用界面如设置主页面如果智能体需要多次分析同一界面可以缓存该界面的视觉特征提取结果或分析结论避免重复调用昂贵的视觉模型。图像预处理在将截图发送给模型前可以进行降采样如将屏幕截图缩小到合理分辨率如640x640、裁剪只保留应用主体区域去除状态栏和导航栏或转换为灰度图以减少输入令牌数降低成本。模型选型并非所有任务都需要最强的GPT-4V。对于一些图标识别、简单布局理解的任务可能更小、更快的开源多模态模型如Qwen-VL、LLaVA就能达到不错的效果成本却低得多。可以根据任务类型动态选择模型。5.4 常见失败模式与排查即使结合了视觉信息智能体依然会失败。以下是我们实验中常见的坑动态加载与等待模型点击一个按钮后新内容可能不会立即加载。智能体需要具备“等待”逻辑直到检测到UI发生稳定变化文本UI更新或截图内容变化后再进行下一步。纯文本模式下可以检测新元素的出现多模态模式下可以结合视觉变化检测如屏幕差异比对。OCR识别错误模型从截图中读取文字OCR可能出错尤其是艺术字体、小字号或低对比度文字。这会导致它找不到“Project Sync”事件而实际上事件就在那里。应对策略永远以文本UI提取的文字为首要信源截图文字仅作为备份或歧义消除之用。对“完成”状态的误判例如创建日历事件后模型可能看到“保存”按钮变成了灰色或消失就认为任务完成。但实际上可能还有一个二级确认弹窗。应对策略定义更严谨的任务完成状态验证不仅看当前屏幕还要检查任务指定的结果是否真正达成例如通过查询日历数据库确认事件是否存在。模拟器与真机差异我们的实验主要在模拟器中进行。真机的UI渲染、性能、预装应用可能存在差异导致文本UI结构或截图外观不同。关键建议任何在模拟器上开发调试的智能体在部署到真机环境前必须在真机上进行充分的回归测试重点关注那些依赖视觉细节的任务。6. 未来展望与思考这次探索清晰地表明在移动端任务自动化这个赛道上纯文本的UI理解已经遇到了天花板。要让AI智能体真正像人一样流畅操作手机赋予其视觉感知能力不是可选项而是必选项。但这不意味着要抛弃文本UI——两者是互补的黄金搭档文本提供精准的“坐标”视觉提供丰富的“地图”和“路况”。未来的方向可能在于更深度的融合端到端的多模态UI理解模型训练一个统一的模型直接接收截图和可选的原始UI层次结构数据输出对界面元素的联合理解包括类型、位置、状态、关系甚至直接输出动作序列。这可以减少当前“文本分析视觉分析决策”管道中的信息损耗。技能抽象与复用智能体不应该每次都从像素和文本中重新学习如何“发Instagram帖子”。它可以逐渐积累和抽象出“在Feed页点击右下角加号按钮”、“选择图片源”、“进入编辑界面”等一系列可复用的“技能”。视觉信息可以帮助它更好地泛化这些技能到不同应用的不同UI变体上。人机协作与示教学习最有效的学习可能来自观察。未来用户可能只需要在手机上操作一遍智能体通过录屏视觉流和UI事件流文本流就能学会这个任务并能在类似场景中举一反三。回到我们最初的问题Do LLMs Need to See Everything?答案或许是不需要看到“一切”但为了可靠地完成那些我们人类依赖视觉直觉的任务它们必须学会“看”关键的部分。这场给大语言模型“开眼”的实验不仅提升了任务成功率更让我们向构建真正通用、实用的数字生活助手迈进了坚实的一步。下一次当你对手机助手说“帮我把上周旅行的照片做成合集发到朋友圈”时或许它真的能看懂屏幕并完美执行。
大语言模型操作手机：视觉信息如何提升UI自动化任务成功率
发布时间：2026/6/1 16:25:49
1. 项目概述当大语言模型“看”手机屏幕时发生了什么如果你尝试过用ChatGPT或者Claude来帮你写邮件、改代码你可能会惊叹于它们处理文本任务的能力。但如果我们想让这些“大脑”去操作手机App呢比如让它帮你把下周的会议安排进日历或者从一堆照片里找出三年前的老照片做个合集。这听起来像是科幻电影里的场景但已经是当前AI研究的前沿课题——移动端UI自动化智能体。这个领域的核心挑战在于“理解”。一个纯文本的大语言模型LLM就像是一个闭着眼睛的顶级指挥家它能听懂乐谱指令但看不到乐手和乐器手机屏幕上的按钮、图标、布局。传统的方法是给这位指挥家一份“文字版乐谱”也就是从Android或iOS应用的UI层次结构UI Hierarchy中提取出的文本描述比如“这是一个按钮ID是‘com.example:id/submit’文本是‘提交’”。这份乐谱在大多数情况下是准确的但它可能遗漏关键信息那个“提交”按钮是不是被一个红色的警告图标盖住了那个看起来像列表的区域实际上是一个可以横向滑动的卡片流这些视觉上下文对于人类来说一目了然但对于只“听”文本的模型来说却是盲区。于是一个很自然的问题就出现了为了让大语言模型更好地完成移动端任务我们有必要让它“看见”屏幕截图吗视觉信息究竟是锦上添花还是雪中送炭这正是我们这次要深入探讨的核心。我们基于一个名为DailyDroid的综合性移动任务基准进行了一系列对比实验。DailyDroid覆盖了从简单的“设置闹钟”到复杂的“在Facebook上发布带标签和好友的动态”等数十个真实场景横跨生产力、工具、通讯、娱乐等多个类别并将任务难度分为简单、中等、困难三个等级为我们提供了一个绝佳的测试场。简单来说我们想搞清楚在移动应用这个视觉信息极其丰富的战场上给大语言模型配上“眼睛”多模态能力到底能带来多大的性能提升哪些任务因此受益最大背后的原因又是什么这不仅是一个有趣的学术问题更直接关系到未来AI助手能否真正无缝融入我们的数字生活替我们处理那些繁琐但必要的手机操作。2. 核心思路拆解文本UI与视觉信息的博弈要理解视觉信息是否必要我们首先得弄明白模型在操作手机时面临的到底是什么样的信息环境以及两种信息源各自的优劣。2.1 文本UI高效但“失明”的抽象地图文本UI通常是通过Android的uiautomator或iOS的XCUITest等无障碍服务或测试框架从应用底层抓取到的UI元素树状结构。你可以把它想象成网站的HTML DOM树但针对的是原生应用。它通常包含以下关键信息组件类型Button,TextView,ImageView,EditText等。资源ID类似com.android.settings:id/wifi_switch的唯一标识符但很多应用元素ID是动态或空的。文本内容按钮上显示的文字如“确定”、“取消”。描述为无障碍功能准备的描述文本有时比text更准确。坐标与边界框元素在屏幕上的位置和大小。可操作状态是否可点击、可滚动、已选中等。优势显而易见结构化与精准信息以结构化数据呈现模型可以精确地定位到“提交”按钮并知道调用click()动作。高效稳定提取速度快不受屏幕分辨率、颜色主题、动态加载动画的影响。只要应用UI层次结构稳定信息就稳定。隐含逻辑组件类型本身携带了交互语义EditText意味着输入Switch意味着开关。然而其“失明”的缺陷在复杂场景下会被放大视觉语义丢失一个红色的感叹号图标可能意味着“错误”或“警告”但文本UI可能只将其描述为一个ImageView资源ID是ic_warning。模型无法理解这个图标的情感或紧急色彩。布局与分组信息模糊文本UI能告诉你屏幕上有10个TextView但它无法直观告诉你哪几个TextView属于同一个卡片组件或者哪些元素在视觉上被一个分割线隔开形成了不同的功能区。人类靠视觉分组瞬间完成的理解模型需要从杂乱的元素列表中费力推理。内容截断与溢出一个长文章标题在文本UI中可能被截断为“这是一篇关于人工智能未...”而截图里完整显示“这是一篇关于人工智能未来发展的长文”。模型失去了关键上下文。动态与自定义组件很多现代应用使用高度自定义的UI组件它们在UI树中的表示可能非常扁平或怪异难以理解。但视觉上它们可能是非常直观的卡片、瀑布流或轮播图。2.2 视觉信息丰富但“嘈杂”的真实世界影像屏幕截图就是手机屏幕的像素级快照。它包含了文本UI所包含的一切视觉信息甚至更多。它的核心价值在于补充了文本UI的盲区完整的视觉上下文图标样式、颜色编码、空间布局、元素间的相对位置、阴影、圆角等设计语言。这些是理解界面意图和状态的关键。解决歧义文本UI中两个Button可能都叫“确认”但一个在绿色背景上一个在灰色不可用状态。截图一目了然。捕获文本UI提取失败的内容如附录B中的例子在某些模拟器或特定应用场景下UI层次结构提取可能不完整只得到寥寥几个元素而截图完整地展示了所有设置选项网络、应用、通知等。这时视觉信息就成了救命稻草。但视觉信息并非万能它带来新的挑战信息密度与噪声一张1080P的截图有超过200万个像素点包含大量与当前任务无关的细节如状态栏时间、壁纸、广告横幅。模型需要从中筛选出相关部分计算负担和干扰都很大。非结构化模型需要从像素中“解读”出按钮、文本、图标这个过程视觉理解本身就有误差远不如直接读取结构化的文本标签精准。对视觉模型能力的依赖多模态大语言模型如GPT-4V、Gemini Pro Vision的视觉理解能力并非完美对小图标、模糊文字、复杂布局的识别可能出错。成本高昂处理高分辨率图像所需的计算资源和时间远超处理文本。2.3 我们的实验假设结合才是王道基于上述分析我们的核心思路不再是“文本 vs. 视觉”的二选一而是探究“文本 视觉”是否优于“仅文本”。我们假设对于依赖视觉上下文、布局理解或图标识别的任务补充屏幕截图将显著提升大语言模型智能体的任务完成率和鲁棒性而对于那些元素清晰、逻辑直接的任务纯文本UI可能就足够了增加视觉信息带来的收益有限甚至可能因引入噪声而适得其反。为了验证这个假设我们在DailyDroid基准上构建了一个对比实验框架在同一个任务自动化引擎基于AutoTask上运行两套配置。一套仅接收文本UI描述作为输入另一套则同时接收文本UI和当前屏幕的截图。让同一个大语言模型我们使用了GPT-4系列模型作为推理核心在这两种信息模式下去尝试完成所有任务并严格记录每一步的预测、执行和结果。3. 实验平台与任务基准深度解析要让大语言模型操作手机光有模型本身不够还需要一个能让它“动手”的环境以及一套衡量它“动手能力”的标尺。3.1 自动化引擎基于AutoTask的扩展我们选择在开源的AutoTask框架上进行扩展。AutoTask本身是一个设计精良的移动端AI智能体框架其核心工作流程是环境感知通过ADB连接到Android模拟器获取当前屏幕的UI层次结构文本。决策将UI文本和任务指令一起构成提示词Prompt发送给大语言模型。行动模型返回需要执行的动作如click(‘id/login_button’),type(‘id/username_input’, ‘Alice’),scroll(directionDOWN)。执行与验证框架将动作转化为ADB命令执行然后观察新屏幕状态进入下一轮循环。我们的扩展点主要在两个地方视觉信息注入在每一步获取UI文本的同时我们通过ADB命令adb exec-out screencap -p捕获当前屏幕的PNG格式截图并保存下来。多模态提示词工程对于启用视觉的实验组我们在发送给模型的提示词中除了包含结构化的UI文本还会附加一条指令并指明提供了当前UI的截图。模型需要是多模态版本如GPT-4V就能同时处理两种模态的信息。附录C中的提示词片段展示了我们如何简洁地引入视觉上下文“A screenshot of the current UI is provided. Use it to ground your actions...”这个设计确保了除了输入信息的不同两个实验组在其他所有条件模型版本、任务指令、环境状态、动作空间上都保持一致使得性能差异可以明确归因于“是否使用了视觉信息”。3.2 DailyDroid基准一个贴近真实的移动任务考场DailyDroid是我们为此次研究整理的一个综合性基准它的设计目标就是模拟真实用户在日常使用手机时遇到的各类任务。如附录A中的表格所示它有几个突出特点1. 任务类别广泛且实用生产力与工具日历管理、邮件处理、笔记、文件管理、待办事项。这些都是信息工作的核心。工具与系统联系人管理、闹钟/计时器、系统设置、应用管理、计算器。涉及系统层交互。信息获取维基百科、网页搜索、地图导航、商家信息查询、新闻阅读。考验信息检索与筛选能力。媒体与娱乐音乐播放、视频观看、播客、电子书、照片管理。涉及内容发现与多媒体操作。通讯与社交Facebook发帖、Reddit互动、Google Meet会议、短信/电话、Instagram分享。模拟复杂的社交互动流程。2. 任务难度梯度分明简单任务通常是单一步骤、目标明确的原子操作。例如“在Google日历中添加一个明天下午2点的‘医生预约’事件”。模型只需要找到“添加事件”按钮填写几个固定字段即可。中等任务涉及多个步骤或需要理解一些上下文。例如“在Gmail中搜索关键词‘GitHub’并打开最旧的那封邮件”。这需要模型执行“搜索”和“在结果列表中识别并打开最旧项”两个关联操作。困难任务往往是多步骤、有条件判断、需要跨应用或处理非结构化数据的复合任务。例如“在Google Keep中创建一个名为‘旅行计划’的笔记添加一个清单...从相册中选取最近的一张图片附件并添加标签‘#travel’”。这需要模型理解清单结构、操作图库选择图片、并应用标签系统。3. 任务描述自然语言化所有任务都以自然语言指令形式给出例如“给{某人}分享你的实时位置然后发一条消息说‘这是讲座幻灯片’并附上文件中的PDF文档”。这要求模型真正理解用户的意图而不是执行预设的脚本。这样的基准设计确保了我们的评测结果能够全面反映智能体在真实世界中的综合能力而不仅仅是某个特定角落的表现。4. 结果分析视觉信息在哪里真正起作用经过大量实验我们得到了一个清晰的结论视觉信息的价值并非均匀分布它高度依赖于任务的“视觉依赖度”。我们可以将任务大致分为三类。4.1 视觉信息收益显著的任务类型在这些任务中提供截图带来了成功率两位数的提升有时甚至是纯文本UI无法完成的任务。1. 依赖图标识别与视觉状态的任务典型案例调整系统设置如“关闭蓝牙”、“将屏幕亮度调到50%并关闭深色模式”。原因分析系统设置中充满了图标开关Toggle。在文本UI中一个蓝牙开关可能被描述为Switch组件其状态checked可能是true或false。这看起来足够。但是当界面中有多个Switch如蓝牙、Wi-Fi、飞行模式紧密排列时仅凭有限的文本描述可能只有“蓝牙”这个标签来精准对应模型容易混淆。截图能清晰显示哪个开关对应哪个标签以及开关的物理位置左关右开提供了双重验证。对于“关闭深色模式自动切换”这类更复杂的选项其视觉呈现可能是一个子菜单或复选框在文本UI中可能更难解析。2. 依赖空间布局与元素分组理解的任务典型案例社交媒体发帖如Instagram创建帖子添加滤镜、标签、好友、文件管理“按大小排序并删除最大的文件”。原因分析在Instagram发帖流程中点击“创建”按钮后会进入一个全新的编辑界面这里有滤镜选择栏、文字输入框、标签输入区、好友按钮、发布按钮等。文本UI会列出所有这些元素但它们是平铺直叙的。截图能立刻告诉模型滤镜是一排可横向滚动的图标在顶部标签和是输入框内的特定功能按钮主要的操作按钮在右下角。这种视觉分组极大地简化了模型的导航决策。在文件管理器中“排序”通常是一个下拉菜单或某个按钮的隐藏选项其视觉表现形式一个小的箭头图标或“更多”图标在截图中比在文本描述中更容易被识别和定位。3. 文本UI提取不完整或歧义的任务典型案例任何在特定环境如某些模拟器、游戏或重度自定义UI的应用下运行的任务。原因分析正如附录B所揭示的UI层次结构提取并非100%可靠。在某些情况下由于应用使用的渲染技术如游戏引擎、大量自定义View、模拟器兼容性问题或权限限制提取出的文本UI可能只有寥寥几个顶层容器节点丢失了几乎所有可交互元素。此时截图成了唯一可靠的信息源。模型虽然需要费力地从像素中识别按钮和文字OCR但至少有了完成任务的可能性。纯文本UI在这种情况下会直接导致智能体“失明”而失败。4. 涉及非文本内容选择的任务典型案例从相册选择特定照片、在音乐播放列表中选择某一首歌曲。原因分析当任务要求“选择最近的一张照片”或“播放Taylor Swift的《Folklore》专辑”时文本UI对于图片库或音乐列表的表示可能只是一系列带有通用ID如com.android.gallery3d:id/thumbnail的ImageView或者是一系列TextView显示歌曲名。模型很难从“第3个ImageView”推断出它就是“最近的照片”因为顺序可能变化。截图虽然不能直接给出“最近”的语义但它展示了缩略图内容结合多模态模型的图像理解能力模型可以识别出哪张图片看起来最新比如内容识别或者直接看到“Folklore”的专辑封面从而做出更准确的点击选择。4.2 视觉信息收益有限甚至无收益的任务类型并非所有任务都需要“看”。1. 逻辑清晰、元素定位唯一的简单表单填写任务典型案例创建日历事件、添加联系人、发送简单短信。原因分析这类任务界面通常简洁表单字段有明确的文本标签如“标题”、“时间”、“姓名”、“电话”。文本UI能提供精准的EditText组件ID和提示文字。模型只需要做简单的“匹配-填充”即可。截图提供的额外视觉信息如输入框的边框样式、页面背景色对于决策没有帮助反而可能因为图像编码和理解的额外开销略微增加响应时间或引入不必要的干扰。2. 深度依赖应用内搜索或导航的任务典型案例在维基百科中搜索并跳转到特定章节、在Google新闻中搜索特定主题文章。原因分析这类任务的核心动作是“在搜索框输入关键词”和“在结果列表中点击目标链接”。搜索框在文本UI中几乎总是有独特的ID或描述目标链接的文本内容在UI树中也清晰可见。模型的关键能力是理解自然语言指令并将其转化为正确的关键词和链接文本匹配这个过程主要依赖语义理解而非视觉。截图中的搜索结果列表布局对点击哪个链接的决策影响不大。3. 纯逻辑或计算任务典型案例使用计算器进行运算包括切换科学模式。原因分析计算器按钮的排布是高度标准化的。文本UI可以明确给出每个按钮的文本“1”, “2”, “”, “sin”和位置。模型需要的是数学知识来解析“50 25 × 3”并规划点击序列。视觉信息无法帮助它理解运算优先级反而可能因为计算器皮肤的不同而产生混淆。4.3 混合型任务与视觉信息的“保险丝”作用很多中等和困难任务属于混合型。例如“在Google Keep中创建带清单、图片和标签的笔记”。其中“创建笔记”、“输入标题”、“添加标签”是文本友好型步骤而“从图库添加最近图片”则高度依赖视觉或至少需要模型理解“附件按钮”的图标和图片选择界面的布局。在这种情况下视觉信息就像一个“保险丝”它可能不直接提升简单步骤的效率但能防止智能体在视觉依赖环节“卡住”或出错从而保障了整个复杂流程的成功率。我们的实验数据表明在DailyDroid的“困难”级别任务中多模态文本视觉智能体的整体成功率比纯文本智能体平均高出约15-25%。这个提升主要就来自于上述那些视觉依赖环节的突破。而在“简单”任务中两者的差距通常在5%以内甚至有时纯文本更快更稳定。5. 实操启示与系统设计建议基于以上发现如果你正在设计或开发一个基于大语言模型的移动端自动化智能体以下是一些可以直接参考的实操建议5.1 何时启用视觉一个决策框架不要无差别地为所有任务提供截图。这既浪费计算资源也可能增加不确定性。建议采用分层或动态策略第一层任务意图分类。在接收到用户指令时先用一个轻量级模型或规则对任务进行预分类。将任务归入“高视觉依赖”类别如涉及系统设置、图片/媒体选择、复杂UI布局操作、社交媒体发布和“低视觉依赖”类别如表单填写、简单搜索、明确导航。第二层环境状态检测。即使对于“低视觉依赖”任务也需要一个故障检测机制。可以设置一个“文本UI置信度”指标例如如果当前屏幕提取到的可交互元素少于3个或者关键目标元素的文本/ID为空则立即判定文本UI质量低下自动切换到多模态模式请求截图作为补充。动态切换智能体在执行过程中可以持续监控。如果连续几步模型都输出低置信度的动作例如反复点击无效坐标或者环境反馈与预期不符可以触发“视觉辅助请求”临时捕获并分析截图以突破僵局。5.2 多模态提示词工程要点当决定使用视觉信息时如何有效地在提示词中整合它至关重要。我们的经验是明确指令像我们使用的指令“A screenshot of the current UI is provided. Use it to ground your actions...”就很好。它明确告诉模型有一张截图它的作用是“落地”你的行动并解决文本描述中的“歧义”。避免使用模糊的“这里有一张图片”。结构化信息优先在提示词中仍然优先放置结构化的文本UI信息。因为对于模型来说解析“ID为submit的按钮”比从图片中识别一个绿色按钮要直接和准确得多。截图应作为补充和验证的参考。引导关注点对于特别复杂的界面可以在指令中稍作引导例如“请特别注意截图顶部的标签栏布局”或“图标颜色可能指示状态”。但这需要谨慎避免过度干预模型的自主观察。5.3 性能与成本的权衡引入视觉模型如GPT-4V必然带来更高的API调用成本和更长的延迟。在系统设计中需要考虑缓存策略对于相对静态的应用界面如设置主页面如果智能体需要多次分析同一界面可以缓存该界面的视觉特征提取结果或分析结论避免重复调用昂贵的视觉模型。图像预处理在将截图发送给模型前可以进行降采样如将屏幕截图缩小到合理分辨率如640x640、裁剪只保留应用主体区域去除状态栏和导航栏或转换为灰度图以减少输入令牌数降低成本。模型选型并非所有任务都需要最强的GPT-4V。对于一些图标识别、简单布局理解的任务可能更小、更快的开源多模态模型如Qwen-VL、LLaVA就能达到不错的效果成本却低得多。可以根据任务类型动态选择模型。5.4 常见失败模式与排查即使结合了视觉信息智能体依然会失败。以下是我们实验中常见的坑动态加载与等待模型点击一个按钮后新内容可能不会立即加载。智能体需要具备“等待”逻辑直到检测到UI发生稳定变化文本UI更新或截图内容变化后再进行下一步。纯文本模式下可以检测新元素的出现多模态模式下可以结合视觉变化检测如屏幕差异比对。OCR识别错误模型从截图中读取文字OCR可能出错尤其是艺术字体、小字号或低对比度文字。这会导致它找不到“Project Sync”事件而实际上事件就在那里。应对策略永远以文本UI提取的文字为首要信源截图文字仅作为备份或歧义消除之用。对“完成”状态的误判例如创建日历事件后模型可能看到“保存”按钮变成了灰色或消失就认为任务完成。但实际上可能还有一个二级确认弹窗。应对策略定义更严谨的任务完成状态验证不仅看当前屏幕还要检查任务指定的结果是否真正达成例如通过查询日历数据库确认事件是否存在。模拟器与真机差异我们的实验主要在模拟器中进行。真机的UI渲染、性能、预装应用可能存在差异导致文本UI结构或截图外观不同。关键建议任何在模拟器上开发调试的智能体在部署到真机环境前必须在真机上进行充分的回归测试重点关注那些依赖视觉细节的任务。6. 未来展望与思考这次探索清晰地表明在移动端任务自动化这个赛道上纯文本的UI理解已经遇到了天花板。要让AI智能体真正像人一样流畅操作手机赋予其视觉感知能力不是可选项而是必选项。但这不意味着要抛弃文本UI——两者是互补的黄金搭档文本提供精准的“坐标”视觉提供丰富的“地图”和“路况”。未来的方向可能在于更深度的融合端到端的多模态UI理解模型训练一个统一的模型直接接收截图和可选的原始UI层次结构数据输出对界面元素的联合理解包括类型、位置、状态、关系甚至直接输出动作序列。这可以减少当前“文本分析视觉分析决策”管道中的信息损耗。技能抽象与复用智能体不应该每次都从像素和文本中重新学习如何“发Instagram帖子”。它可以逐渐积累和抽象出“在Feed页点击右下角加号按钮”、“选择图片源”、“进入编辑界面”等一系列可复用的“技能”。视觉信息可以帮助它更好地泛化这些技能到不同应用的不同UI变体上。人机协作与示教学习最有效的学习可能来自观察。未来用户可能只需要在手机上操作一遍智能体通过录屏视觉流和UI事件流文本流就能学会这个任务并能在类似场景中举一反三。回到我们最初的问题Do LLMs Need to See Everything?答案或许是不需要看到“一切”但为了可靠地完成那些我们人类依赖视觉直觉的任务它们必须学会“看”关键的部分。这场给大语言模型“开眼”的实验不仅提升了任务成功率更让我们向构建真正通用、实用的数字生活助手迈进了坚实的一步。下一次当你对手机助手说“帮我把上周旅行的照片做成合集发到朋友圈”时或许它真的能看懂屏幕并完美执行。
