1. 项目概述与核心问题最近在折腾大语言模型驱动的手机自动化代理发现一个挺有意思的现象很多团队都在一股脑地往模型里塞屏幕截图觉得“所见即所得”肯定比冷冰冰的UI结构文本强。但截图真的那么万能吗或者说为了那可能只有几个百分点的成功率提升我们付出的隐私泄露风险和激增的计算成本到底值不值这就是DailyDroid这个基准测试想搞清楚的核心问题。它不是一个简单的“跑分”工具而是一把手术刀专门用来解剖移动代理在真实日常任务中究竟是怎么“死”的。我们构建了涵盖25个主流安卓应用、75个任务的测试集模拟了从设置闹钟到规划路线、从查找信息到管理日程的真实场景并且把任务分成了简单、中等、困难三个等级。然后我们让GPT-4o和o4-mini这两位“选手”分别只用UI结构文本我们称之为“纯文本”输入和“文本截图”的组合即“多模态”输入去执行这些任务总共跑了300轮。结果有点反直觉多模态输入的整体成功率确实高那么一点点大约4-5%但远没有大家想象的那么“碾压”。更关键的是我们通过逐帧分析失败案例整理出了一本厚厚的“失败手册”。这本手册告诉我们移动代理的“翻车”原因五花八门很多根子上的问题——比如App压根没给无障碍服务提供完整的界面信息或者UI设计逻辑反人类——根本不是多看一眼截图就能解决的。相反盲目依赖截图反而可能让代理在复杂的视觉信息中“迷路”或者因为处理图片的巨大开销而变得更慢、更贵。所以这篇文章我想和你深入聊聊这次测试的里里外外。我会拆解DailyDroid是怎么设计的为什么这些日常任务反而更能暴露问题会详细对比两种输入模态下模型具体是怎么“思考”和“行动”的它们的瓶颈分别在哪里更重要的是我会分享我们从那几百次失败中总结出的“避坑指南”和设计启示。无论你是正在开发这类代理的工程师还是关心未来人机交互方式的产品经理或者只是对AI如何“使用”手机感到好奇相信这些来自一线的、带着“硝烟味”的发现都能给你带来一些实实在在的启发。2. DailyDroid基准测试为什么是“日常任务”在聊具体结果之前得先说说我们为什么费这么大劲搞这么一个基准。市面上已有的移动代理测试集不少但它们大多有个共同点为了追求可复现性和自动化评估往往选用的是相对静态、功能单一或者专门为测试定制的应用。这当然有其价值能快速验证核心算法。但问题在于当代理走出实验室面对我们手机里那些日活上亿、界面复杂、动不动就弹窗更新的“真实”App时之前没暴露的问题就全冒出来了。2.1 设计哲学从真实世界汲取任务灵感DailyDroid的设计初衷很明确贴近真实暴露摩擦。我们不想测试代理在理想环境下的“极限性能”而是想看看它在处理你我每天都会碰到的手机操作时到底靠不靠谱。为此我们走了三步棋。第一步是数据驱动。我们爬取了Google Play商店各大应用类别的下载量数据用大模型辅助归纳出五大最高频的日常使用场景生产力与工具如日历、邮件、系统与工具如设置、天气、信息获取如浏览器、地图、媒体与娱乐如音乐、视频、社交沟通如消息、社交App。这确保了我们的测试范围覆盖了用户真实的时间花费。第二步是应用选择。在每个类别里我们挑了五个最具代表性、用户基数最大的App。比如“社交沟通”里我们选了Facebook、Reddit、会议软件、短信和Instagram。选择标准就三条真实世界广泛使用、交互模式有代表性涵盖列表、搜索、表单、媒体控制等、能进行可重复的自动化测试避免需要付费或涉及极度个人隐私的操作。所有App都从公开渠道获取同一版本确保每个人都能复现我们的实验。第三步也是最花心思的一步任务设计。我们为每个App设计了三个任务对应简单、中等、困难三个等级。但这个“难度”不是我们拍脑袋定的而是有一套清晰的操作化定义简单任务通常在一个屏幕或一个功能内就能完成操作路径是线性的。例如“在时钟App里设置一个下午3点的闹钟”。中等任务需要跨屏幕导航并且至少包含一个决策点。例如“在谷歌地图中搜索‘埃菲尔铁塔’并查看附近的酒店信息”。这里“搜索”是一个步骤“查看酒店”是另一个并且界面可能提供多种信息酒店、餐厅、照片代理需要正确识别并选择“酒店”标签。困难任务操作链条长包含多个决策点或者任务描述本身有一定模糊性需要代理理解上下文或系统状态。例如“在Spotify中找到我上周二添加的名为‘Workout’的歌单并将其分享到Reddit的一个相关社区”。这涉及应用内历史记录查找、跨应用分享以及对“相关社区”的模糊理解。2.2 基准的独特价值不止于跑分DailyDroid和以往基准的关键区别在于它被设计成一个诊断性工具而不仅仅是评估性工具。它关注三个以往被忽视的维度暴露日常摩擦我们特意包含了那些在“干净”测试中容易被忽略但实际使用中高频出现的“坑”。比如应用权限弹窗“是否允许访问相册”、动态加载的内容流不断刷新的新闻列表、不同App间切换的依赖关系、以及那些UI元素标签语焉不详的按钮一个只显示图标没有文字说明的“分享”按钮。这些才是拖垮代理的“元凶”。正视隐私与成本的权衡截图输入带来的隐私风险是实实在在的。想象一下一个需要全局屏幕访问权限的助手随时可能把你的聊天记录、银行账户余额截下来发给云端模型。我们的测试将“纯文本”输入作为一个严肃的对比基线就是想量化在牺牲多少性能的前提下我们可以通过更保守、更隐私友好的方式仅依赖系统提供的UI结构文本来实现可接受的自动化水平提供可复现的分析资源我们不仅记录了任务成功与否还完整保存了每一次运行的日志每一步的屏幕文本、截图如果用了、模型生成的指令、实际执行的操作、以及模型的“内心独白”推理过程。更重要的是我们对所有失败案例进行了人工编码和归类形成了一份结构化的“失败手册”。这为社区后续的研究提供了“显微镜”大家可以基于相同的失败轨迹分析原因迭代改进而不是各说各话。这套设计让DailyDroid像一个高保真的“压力测试场”专门寻找移动代理在真实世界中的软肋。接下来我们就看看代理们在这个考场里的实际表现。3. 核心对决纯文本 vs. 多模态输入实验的核心是比较两种输入模态纯文本Screentext和多模态Screentext Screenshot。为了控制变量我们基于开源的AutoTask框架进行改造确保除了输入信息不同其他环节如规划逻辑、执行器、回溯机制完全一致。3.1 输入模态的具象化它们到底“看”到了什么理解结果的前提是搞清楚模型到底接收到了什么信息。纯文本输入这并非用户看到的屏幕文字而是通过Android无障碍服务Accessibility Service抓取到的UI视图树。你可以把它理解为整个屏幕的“源代码”或“骨架”。它是一个XML/HTML-like的结构化文本记录了每个UI元素的类型如Button、TextView、ID、类名、是否可点击、描述文本等属性。它的优势是轻量、结构化、无隐私泄露风险不包含实际图像内容。但缺点也很明显首先不是所有屏幕上可见的内容都能被正确抓取特别是那些自定义绘制或游戏内的元素其次这个“骨架”可能非常冗长复杂最后它丢失了所有视觉布局、颜色、图标样式和空间相对位置信息。一个按钮在左上角还是右下角它是红色的警示按钮还是绿色的确认按钮纯文本无从得知。多模态输入在纯文本的基础上额外附加上当前屏幕的完整截图。这相当于给了模型一双“眼睛”。理论上模型可以结合结构信息和视觉信息更准确地理解界面。例如它能通过图标认出“分享”功能能通过颜色区分选中和未选中的状态能理解卡片式布局和列表布局的差异。在我们的实验中两种模态接收的“纯文本”部分是经过相同管道处理和简化的确保公平对比。多模态组只是在每次模型决策前多收到一张压缩后的PNG格式截图。3.2 性能数据微弱的优势与高昂的代价我们分别使用GPT-4o作为强大的多模态基线和o4-mini强调推理能力的新模型在两种模态下运行了所有75个任务。关键数据对比如下模型输入模态任务成功率平均步骤数平均总耗时 (秒)平均单次任务LLM成本 (美元)GPT-4o纯文本26.7%6.30141.920.0947多模态32.0%5.71144.862.4593o4-mini纯文本29.3%7.36204.970.0077多模态33.3%7.00220.390.1906核心发现一多模态的优势比预期小得多。无论是GPT-4o还是o4-mini采用截图输入后任务成功率仅提升了约4-6个百分点。这个提升是存在的但绝非革命性的。在某些中等难度、依赖视觉线索如图标识别的任务上截图确实有帮助。但在大量任务中尤其是那些失败原因根植于逻辑理解或系统限制的任务截图并没能成为“救世主”。核心发现二成本飙升是致命伤。这是最触目惊心的数字。对于GPT-4o使用截图会使单次任务的API调用成本暴增近26倍对于o4-mini也增加了近25倍。这背后的原因很简单一张截图经编码后会转化为大量的视觉Token。这些Token不仅本身计费高还会显著增加模型的上下文长度拖慢响应速度API延迟增加。在我们的测试中多模态输入的平均API等待时间比纯文本高出约50-70秒。这意味着为了换取那一点点成功率的提升你需要付出巨大的经济和效率代价。核心发现三步骤数减少但效率未必提升。多模态输入下模型完成任务的平均步骤数略有下降约0.6-0.36步。这说明视觉信息有时能帮助模型更快地定位目标元素减少一些无效的探索点击。然而由于每一步的决策时间因处理图片而大幅增加总耗时并没有减少反而因为o4-mini本身推理更慢而有所增加。这形成了一个有趣的悖论模型“想”得更准了但“想”得更慢了。实操心得成本估算不能拍脑袋很多团队在原型设计阶段只关注效果忽略了成本。我们的实验给出了一个量化的参考一旦引入截图你的推理成本将从“分”级别跃升至“元”级别。在规划一个需要高频调用或服务大量用户的移动代理产品时这个成本模型必须在第一天就纳入考量。否则一个在实验室里效果惊艳的Demo可能在规模化时因成本失控而瞬间死亡。3.3 深入场景截图何时有用何时是累赘数据是冰冷的场景是鲜活的。通过分析具体任务的执行日志我们发现截图的价值高度依赖于任务类型截图显效的场景图标识别与功能映射例如在Spotify中“点赞”和“添加到歌单”可能都是心形图标但位置和颜色微差。纯文本可能只显示两个ImageView而截图能让模型结合上下文如歌曲信息区分它们。理解非标准控件一些自定义的滑动开关、评分控件、图像选择器其状态在UI树中描述不清但视觉上一目了然。处理富媒体内容比如在Gallery应用中从一堆缩略图中找到“包含狗的图片”这纯文本完全无法做到。截图无力或反作用的场景系统级失败面前人人平等如果App的无障碍服务根本没提供某个按钮的clickable属性或描述文本那么截图里即使能看到这个按钮模型也无法生成正确的操作指令如tap(button_id)因为button_id是空的。这是基础设施问题视觉信息无法弥补。复杂文本布局的干扰在信息密集的新闻或Reddit界面截图包含了大量无关的文本、图片广告。模型可能被这些冗余视觉信息分散注意力反而忽略了UI树中清晰标注的核心操作元素。动态元素的误导加载动画、滚动提示条、浮动广告。这些在截图里是静止的模型可能会误认为它们是可交互的稳定元素从而做出错误点击。一个典型案例是在“通信”类任务中让代理在Messenger中找到一个特定的群聊并发送消息。纯文本输入失败了因为群聊列表项的无障碍标签只显示了“群聊”没有具体的群名。多模态输入成功了因为模型从截图里“读”到了群名。然而在另一个“系统工具”任务中让代理在设置中开启“深色模式”两种输入都失败了。失败原因是该手机型号的设置菜单路径与标准不同且“深色模式”的切换开关在UI树中被错误地标记为不可点击clickablefalse。截图清晰地显示了那个开关但模型受限于UI树的结构化指令依然无法操作它。这引出了我们最关键的发现很多失败的根本原因不在于模型“看”得不够清楚而在于它“理解”和“操作”世界的基础设施——UI可访问性——本身是残缺的。接下来我们就翻开那本用失败写成的“手册”。4. 失败手册移动代理的“死法”百科全书我们对所有300次运行中失败的任务进行了根因分析归纳出了一套两级分类的“失败手册”。这套手册的价值在于它像一份“故障代码表”能帮助开发者快速定位问题属于系统层还是代理层从而采取正确的应对策略。4.1 系统级失败基础设施的“硬伤”系统级失败是指代理在尝试执行任务之初或早期就遇到了无法逾越的障碍导致任务被强制终止我们设定了人工审查机制在发现此类致命错误时提前结束以节省资源。这类失败约占所有失败的40%-43%而且无论用纯文本还是多模态输入发生率几乎完全相同。这强烈表明问题出在更底层。失败类别子类具体表现与原因典型案例与影响UI检索失败无法获取完整UI无障碍服务无法抓取特定应用或特定屏幕的视图树。常见于游戏、金融类App或深度定制的系统界面。代理“眼前一黑”无法获取任何界面信息任务在第一步即宣告失败。多模态输入在此完全无用因为截图需要与UI树坐标对齐才能生成操作指令。UI解析失败解析或识别组件失败虽然获取到了UI树但关键组件的属性缺失、错误或过于冗杂导致无法准确定位。例如按钮的resource-id为空或为通用值如android:id/button1content-desc描述文本缺失。代理知道要“点击搜索按钮”但在UI树里找不到一个明确的、可操作的搜索按钮对象。截图能看到按钮但代理无法将其映射到一个可执行的操作上。UI逻辑失败界面设计反直觉UI本身的设计对人类而言就难以理解或存在歧义。例如一个完成操作的按钮被命名为“取消”或者操作流程不符合常规心智模型。即使人类也需要反复尝试才能成功。代理基于常规逻辑进行的推理很可能出错。这类失败挑战的是交互设计本身而非代理能力。执行失败动作执行错误代理正确识别了目标如一个按钮的坐标但发出的执行指令如tap(x, y)因设备延迟、坐标漂移、或动作空间不支持如需要长按、双指缩放而失败。这是“最后一公里”的问题。代理规划正确但“手”没跟上。避坑指南优先解决系统级问题如果你的移动代理项目刚起步遇到大量失败请首先排查系统级问题。投入大量精力优化模型视觉能力之前先确保你的无障碍服务能稳定、完整地获取目标应用的UI树。与App开发团队合作推动他们完善无障碍元数据如为关键按钮添加唯一的resource-id和清晰的content-desc这可能是提升代理成功率性价比最高的投资。对于UI逻辑失败可能需要建立一套针对反常设计的特殊规则库。4.2 代理级失败模型与规划的“软肋”代理级失败发生在系统运行正常但代理在规划、决策或反思环节出了错。这类失败占比约26%-32%多模态输入在这里显示出一定的缓解作用平均降低约4-5%但未能根除。失败类别子类具体表现与原因多模态的影响分析LLM预测失败理解屏幕但做出错误决策模型看懂了界面但选择了错误的操作。例如在购物App中应该点击“加入购物车”却点了旁边的“收藏”。或者在有多页的列表中过早停止了滚动。多模态略有帮助。视觉信息能辅助区分外观相似但功能不同的元素如图标微差。但对于需要深层语义理解的选择如在一堆新闻中找出“科技类”新闻帮助有限。LLM反思失败未能识别任务完成或步骤错误代理已经完成了任务目标如成功发送了消息但反思模块没有检测到状态变化认为任务未完成继续执行冗余操作。或者在操作出错后如点进了错误页面未能及时回溯纠正。影响中性。反思能力更多依赖于任务完成状态的定义和模型的内在推理逻辑与输入模态关系不大。达到最大步数效率低下或陷入循环代理在任务中兜圈子或在一条正确但非常低效的路径上花费过多步骤触发了我们设置的最大步数10步限制。多模态有时反而更糟。o4-mini在多模态下“达到最大步数”的失败率更高。推测原因是视觉信息增加了推理的复杂性导致模型在某些步骤上“犹豫不决”思考时间过长在步数限制内无法走完流程。不可能任务任务设计本身模糊或不可行由于任务描述存在二义性或当前应用状态无法支持如要求分享一个不存在的文件导致任何代理都无法完成。与模态无关。这是基准测试设计需要规避的问题。(代理层) UI检索/解析/逻辑/执行失败同系统级但发生在执行过程中与系统级失败原因相同但发生在任务执行的中后期。例如在任务进行到一半时跳转到了一个UI检索失败的新页面。同系统级多模态无法解决。一个典型的代理级失败案例发生在“信息获取”类任务“在维基百科App中搜索‘人工智能’找到‘历史’章节并朗读该章节的第一段。” 纯文本输入下代理成功搜索并进入了词条但在冗长的目录中它错误地将“发展历史”这个小节标题当成了目标导致后续操作失败。多模态输入下代理凭借截图对章节标题的视觉突出感知正确找到了“历史”这个主章节但在尝试执行“朗读”操作时由于该App的朗读按钮是一个没有任何文本标签的纯图标按钮且UI树中其content-desc为空代理再次失败。这里多模态解决了导航问题但没能解决最终的执行问题。5. 设计启示与未来方向基于DailyDroid的测试结果和失败分析我们可以为移动代理、应用开发者和UI设计者提炼出一些切实可行的建议。5.1 对移动代理开发者的启示重新评估输入模态的性价比不要默认将截图作为必选项。在项目初期优先采用纯文本UI树输入进行开发和测试。这能让你以极低的成本快速验证核心规划与执行逻辑并暴露出最多的系统级和逻辑性错误。将截图视为一种“增强模式”或“降级备用方案”仅在纯文本信息明显不足如处理富媒体、图标界面且任务价值足够高时启用。实施分层感知与决策策略设计一个智能的输入模态调度器。例如代理可以首先尝试仅用UI树进行决策如果置信度低如遇到大量未标记的图标或任务明确需要视觉理解“找到红色封面的书”再主动请求截图进行分析。这种混合策略能在成本、隐私和性能间取得更好平衡。强化对“系统级失败”的鲁棒性代理需要具备检测和处理基础设施故障的能力。例如当发现UI树为空或关键属性缺失时不应盲目重试而应触发特定的错误处理流程如记录日志、通知用户、尝试备用操作路径。可以建立一个常见App的UI特征库针对已知的“坑”提前编写适配逻辑。优化反思与状态追踪机制很多代理级失败源于对任务状态的误判。需要设计更精细、更多元的状态验证机制而不仅仅依赖模型的自我反思。可以结合屏幕变化检测前后截图对比、特定UI元素出现/消失、甚至设备通知监听等方式来交叉验证任务是否真的完成。5.2 对应用程序开发者的启示将无障碍支持提升为高优先级特性移动代理本质上是“超级无障碍用户”。一个对代理友好的App必然也是对视力障碍、行动不便用户友好的App。请务必为所有可交互的UI元素提供唯一、稳定、语义清晰的resource-id和content-desc。避免使用android:id/button1这类通用ID。对于图标按钮content-desc至关重要如android:contentDescription搜索。保持UI结构的一致性与可预测性频繁变化的UI布局、动态生成的控件ID会给依赖UI树的代理带来灾难。在迭代设计时考虑为核心功能区域保持稳定的布局结构和组件标识。提供清晰的反馈与状态指示任务完成后界面应有明确的变化如弹出“发送成功”Toast或页面跳转。这有助于代理和所有用户确认操作结果。5.3 对操作系统与UI设计标准的启示推动更丰富、更标准的UI元数据规范当前的Android无障碍API主要服务于辅助功能信息粒度较粗。未来可能需要一套面向自动化代理的增强型UI描述标准在不泄露隐私的前提下提供更丰富的语义信息如元素的功能类型、在业务流程中的角色、与其他元素的关系等。探索“结构化视觉信息”的中间道路完全传输截图隐私风险高纯文本信息损失大。是否可以探索一种折中方案例如由设备端轻量级模型先将截图转化为不包含原始像素隐私的、结构化的视觉描述如“屏幕顶部有一个蓝色导航栏中间是一个包含3个卡片的列表第一个卡片带有购物车图标…”再将这个描述文本发送给大模型。这既保留了视觉布局信息又保护了隐私。设计原生的“自动化友好”模式操作系统是否可以提供一个安全沙箱或特殊模式在此模式下App向授权的自动化代理提供比普通无障碍服务更精确、更稳定的界面信息和操作接口这需要平衡安全、隐私和功能但可能是根本性提升自动化可靠性的方向。这次深入DailyDroid基准测试的经历让我深刻体会到让AI“用好”手机远不是把最强的视觉模型接上屏幕那么简单。它是一场需要算法、工程、产品设计、甚至操作系统生态共同参与的“交响乐”。当前阶段我们或许过于关注乐队首席大模型的独奏能力而忽略了乐谱UI可访问性、乐器执行环境乃至音乐厅声学系统设计的配合。这份“失败手册”不是一个终点而是一份路线图。它告诉我们在追求更智能的移动代理的道路上那些看似枯燥的基础设施完善工作其重要性丝毫不亚于在模型层面刷新的那几个百分点。
移动AI代理成本效益分析：纯文本与多模态输入的基准测试
1. 项目概述与核心问题最近在折腾大语言模型驱动的手机自动化代理发现一个挺有意思的现象很多团队都在一股脑地往模型里塞屏幕截图觉得“所见即所得”肯定比冷冰冰的UI结构文本强。但截图真的那么万能吗或者说为了那可能只有几个百分点的成功率提升我们付出的隐私泄露风险和激增的计算成本到底值不值这就是DailyDroid这个基准测试想搞清楚的核心问题。它不是一个简单的“跑分”工具而是一把手术刀专门用来解剖移动代理在真实日常任务中究竟是怎么“死”的。我们构建了涵盖25个主流安卓应用、75个任务的测试集模拟了从设置闹钟到规划路线、从查找信息到管理日程的真实场景并且把任务分成了简单、中等、困难三个等级。然后我们让GPT-4o和o4-mini这两位“选手”分别只用UI结构文本我们称之为“纯文本”输入和“文本截图”的组合即“多模态”输入去执行这些任务总共跑了300轮。结果有点反直觉多模态输入的整体成功率确实高那么一点点大约4-5%但远没有大家想象的那么“碾压”。更关键的是我们通过逐帧分析失败案例整理出了一本厚厚的“失败手册”。这本手册告诉我们移动代理的“翻车”原因五花八门很多根子上的问题——比如App压根没给无障碍服务提供完整的界面信息或者UI设计逻辑反人类——根本不是多看一眼截图就能解决的。相反盲目依赖截图反而可能让代理在复杂的视觉信息中“迷路”或者因为处理图片的巨大开销而变得更慢、更贵。所以这篇文章我想和你深入聊聊这次测试的里里外外。我会拆解DailyDroid是怎么设计的为什么这些日常任务反而更能暴露问题会详细对比两种输入模态下模型具体是怎么“思考”和“行动”的它们的瓶颈分别在哪里更重要的是我会分享我们从那几百次失败中总结出的“避坑指南”和设计启示。无论你是正在开发这类代理的工程师还是关心未来人机交互方式的产品经理或者只是对AI如何“使用”手机感到好奇相信这些来自一线的、带着“硝烟味”的发现都能给你带来一些实实在在的启发。2. DailyDroid基准测试为什么是“日常任务”在聊具体结果之前得先说说我们为什么费这么大劲搞这么一个基准。市面上已有的移动代理测试集不少但它们大多有个共同点为了追求可复现性和自动化评估往往选用的是相对静态、功能单一或者专门为测试定制的应用。这当然有其价值能快速验证核心算法。但问题在于当代理走出实验室面对我们手机里那些日活上亿、界面复杂、动不动就弹窗更新的“真实”App时之前没暴露的问题就全冒出来了。2.1 设计哲学从真实世界汲取任务灵感DailyDroid的设计初衷很明确贴近真实暴露摩擦。我们不想测试代理在理想环境下的“极限性能”而是想看看它在处理你我每天都会碰到的手机操作时到底靠不靠谱。为此我们走了三步棋。第一步是数据驱动。我们爬取了Google Play商店各大应用类别的下载量数据用大模型辅助归纳出五大最高频的日常使用场景生产力与工具如日历、邮件、系统与工具如设置、天气、信息获取如浏览器、地图、媒体与娱乐如音乐、视频、社交沟通如消息、社交App。这确保了我们的测试范围覆盖了用户真实的时间花费。第二步是应用选择。在每个类别里我们挑了五个最具代表性、用户基数最大的App。比如“社交沟通”里我们选了Facebook、Reddit、会议软件、短信和Instagram。选择标准就三条真实世界广泛使用、交互模式有代表性涵盖列表、搜索、表单、媒体控制等、能进行可重复的自动化测试避免需要付费或涉及极度个人隐私的操作。所有App都从公开渠道获取同一版本确保每个人都能复现我们的实验。第三步也是最花心思的一步任务设计。我们为每个App设计了三个任务对应简单、中等、困难三个等级。但这个“难度”不是我们拍脑袋定的而是有一套清晰的操作化定义简单任务通常在一个屏幕或一个功能内就能完成操作路径是线性的。例如“在时钟App里设置一个下午3点的闹钟”。中等任务需要跨屏幕导航并且至少包含一个决策点。例如“在谷歌地图中搜索‘埃菲尔铁塔’并查看附近的酒店信息”。这里“搜索”是一个步骤“查看酒店”是另一个并且界面可能提供多种信息酒店、餐厅、照片代理需要正确识别并选择“酒店”标签。困难任务操作链条长包含多个决策点或者任务描述本身有一定模糊性需要代理理解上下文或系统状态。例如“在Spotify中找到我上周二添加的名为‘Workout’的歌单并将其分享到Reddit的一个相关社区”。这涉及应用内历史记录查找、跨应用分享以及对“相关社区”的模糊理解。2.2 基准的独特价值不止于跑分DailyDroid和以往基准的关键区别在于它被设计成一个诊断性工具而不仅仅是评估性工具。它关注三个以往被忽视的维度暴露日常摩擦我们特意包含了那些在“干净”测试中容易被忽略但实际使用中高频出现的“坑”。比如应用权限弹窗“是否允许访问相册”、动态加载的内容流不断刷新的新闻列表、不同App间切换的依赖关系、以及那些UI元素标签语焉不详的按钮一个只显示图标没有文字说明的“分享”按钮。这些才是拖垮代理的“元凶”。正视隐私与成本的权衡截图输入带来的隐私风险是实实在在的。想象一下一个需要全局屏幕访问权限的助手随时可能把你的聊天记录、银行账户余额截下来发给云端模型。我们的测试将“纯文本”输入作为一个严肃的对比基线就是想量化在牺牲多少性能的前提下我们可以通过更保守、更隐私友好的方式仅依赖系统提供的UI结构文本来实现可接受的自动化水平提供可复现的分析资源我们不仅记录了任务成功与否还完整保存了每一次运行的日志每一步的屏幕文本、截图如果用了、模型生成的指令、实际执行的操作、以及模型的“内心独白”推理过程。更重要的是我们对所有失败案例进行了人工编码和归类形成了一份结构化的“失败手册”。这为社区后续的研究提供了“显微镜”大家可以基于相同的失败轨迹分析原因迭代改进而不是各说各话。这套设计让DailyDroid像一个高保真的“压力测试场”专门寻找移动代理在真实世界中的软肋。接下来我们就看看代理们在这个考场里的实际表现。3. 核心对决纯文本 vs. 多模态输入实验的核心是比较两种输入模态纯文本Screentext和多模态Screentext Screenshot。为了控制变量我们基于开源的AutoTask框架进行改造确保除了输入信息不同其他环节如规划逻辑、执行器、回溯机制完全一致。3.1 输入模态的具象化它们到底“看”到了什么理解结果的前提是搞清楚模型到底接收到了什么信息。纯文本输入这并非用户看到的屏幕文字而是通过Android无障碍服务Accessibility Service抓取到的UI视图树。你可以把它理解为整个屏幕的“源代码”或“骨架”。它是一个XML/HTML-like的结构化文本记录了每个UI元素的类型如Button、TextView、ID、类名、是否可点击、描述文本等属性。它的优势是轻量、结构化、无隐私泄露风险不包含实际图像内容。但缺点也很明显首先不是所有屏幕上可见的内容都能被正确抓取特别是那些自定义绘制或游戏内的元素其次这个“骨架”可能非常冗长复杂最后它丢失了所有视觉布局、颜色、图标样式和空间相对位置信息。一个按钮在左上角还是右下角它是红色的警示按钮还是绿色的确认按钮纯文本无从得知。多模态输入在纯文本的基础上额外附加上当前屏幕的完整截图。这相当于给了模型一双“眼睛”。理论上模型可以结合结构信息和视觉信息更准确地理解界面。例如它能通过图标认出“分享”功能能通过颜色区分选中和未选中的状态能理解卡片式布局和列表布局的差异。在我们的实验中两种模态接收的“纯文本”部分是经过相同管道处理和简化的确保公平对比。多模态组只是在每次模型决策前多收到一张压缩后的PNG格式截图。3.2 性能数据微弱的优势与高昂的代价我们分别使用GPT-4o作为强大的多模态基线和o4-mini强调推理能力的新模型在两种模态下运行了所有75个任务。关键数据对比如下模型输入模态任务成功率平均步骤数平均总耗时 (秒)平均单次任务LLM成本 (美元)GPT-4o纯文本26.7%6.30141.920.0947多模态32.0%5.71144.862.4593o4-mini纯文本29.3%7.36204.970.0077多模态33.3%7.00220.390.1906核心发现一多模态的优势比预期小得多。无论是GPT-4o还是o4-mini采用截图输入后任务成功率仅提升了约4-6个百分点。这个提升是存在的但绝非革命性的。在某些中等难度、依赖视觉线索如图标识别的任务上截图确实有帮助。但在大量任务中尤其是那些失败原因根植于逻辑理解或系统限制的任务截图并没能成为“救世主”。核心发现二成本飙升是致命伤。这是最触目惊心的数字。对于GPT-4o使用截图会使单次任务的API调用成本暴增近26倍对于o4-mini也增加了近25倍。这背后的原因很简单一张截图经编码后会转化为大量的视觉Token。这些Token不仅本身计费高还会显著增加模型的上下文长度拖慢响应速度API延迟增加。在我们的测试中多模态输入的平均API等待时间比纯文本高出约50-70秒。这意味着为了换取那一点点成功率的提升你需要付出巨大的经济和效率代价。核心发现三步骤数减少但效率未必提升。多模态输入下模型完成任务的平均步骤数略有下降约0.6-0.36步。这说明视觉信息有时能帮助模型更快地定位目标元素减少一些无效的探索点击。然而由于每一步的决策时间因处理图片而大幅增加总耗时并没有减少反而因为o4-mini本身推理更慢而有所增加。这形成了一个有趣的悖论模型“想”得更准了但“想”得更慢了。实操心得成本估算不能拍脑袋很多团队在原型设计阶段只关注效果忽略了成本。我们的实验给出了一个量化的参考一旦引入截图你的推理成本将从“分”级别跃升至“元”级别。在规划一个需要高频调用或服务大量用户的移动代理产品时这个成本模型必须在第一天就纳入考量。否则一个在实验室里效果惊艳的Demo可能在规模化时因成本失控而瞬间死亡。3.3 深入场景截图何时有用何时是累赘数据是冰冷的场景是鲜活的。通过分析具体任务的执行日志我们发现截图的价值高度依赖于任务类型截图显效的场景图标识别与功能映射例如在Spotify中“点赞”和“添加到歌单”可能都是心形图标但位置和颜色微差。纯文本可能只显示两个ImageView而截图能让模型结合上下文如歌曲信息区分它们。理解非标准控件一些自定义的滑动开关、评分控件、图像选择器其状态在UI树中描述不清但视觉上一目了然。处理富媒体内容比如在Gallery应用中从一堆缩略图中找到“包含狗的图片”这纯文本完全无法做到。截图无力或反作用的场景系统级失败面前人人平等如果App的无障碍服务根本没提供某个按钮的clickable属性或描述文本那么截图里即使能看到这个按钮模型也无法生成正确的操作指令如tap(button_id)因为button_id是空的。这是基础设施问题视觉信息无法弥补。复杂文本布局的干扰在信息密集的新闻或Reddit界面截图包含了大量无关的文本、图片广告。模型可能被这些冗余视觉信息分散注意力反而忽略了UI树中清晰标注的核心操作元素。动态元素的误导加载动画、滚动提示条、浮动广告。这些在截图里是静止的模型可能会误认为它们是可交互的稳定元素从而做出错误点击。一个典型案例是在“通信”类任务中让代理在Messenger中找到一个特定的群聊并发送消息。纯文本输入失败了因为群聊列表项的无障碍标签只显示了“群聊”没有具体的群名。多模态输入成功了因为模型从截图里“读”到了群名。然而在另一个“系统工具”任务中让代理在设置中开启“深色模式”两种输入都失败了。失败原因是该手机型号的设置菜单路径与标准不同且“深色模式”的切换开关在UI树中被错误地标记为不可点击clickablefalse。截图清晰地显示了那个开关但模型受限于UI树的结构化指令依然无法操作它。这引出了我们最关键的发现很多失败的根本原因不在于模型“看”得不够清楚而在于它“理解”和“操作”世界的基础设施——UI可访问性——本身是残缺的。接下来我们就翻开那本用失败写成的“手册”。4. 失败手册移动代理的“死法”百科全书我们对所有300次运行中失败的任务进行了根因分析归纳出了一套两级分类的“失败手册”。这套手册的价值在于它像一份“故障代码表”能帮助开发者快速定位问题属于系统层还是代理层从而采取正确的应对策略。4.1 系统级失败基础设施的“硬伤”系统级失败是指代理在尝试执行任务之初或早期就遇到了无法逾越的障碍导致任务被强制终止我们设定了人工审查机制在发现此类致命错误时提前结束以节省资源。这类失败约占所有失败的40%-43%而且无论用纯文本还是多模态输入发生率几乎完全相同。这强烈表明问题出在更底层。失败类别子类具体表现与原因典型案例与影响UI检索失败无法获取完整UI无障碍服务无法抓取特定应用或特定屏幕的视图树。常见于游戏、金融类App或深度定制的系统界面。代理“眼前一黑”无法获取任何界面信息任务在第一步即宣告失败。多模态输入在此完全无用因为截图需要与UI树坐标对齐才能生成操作指令。UI解析失败解析或识别组件失败虽然获取到了UI树但关键组件的属性缺失、错误或过于冗杂导致无法准确定位。例如按钮的resource-id为空或为通用值如android:id/button1content-desc描述文本缺失。代理知道要“点击搜索按钮”但在UI树里找不到一个明确的、可操作的搜索按钮对象。截图能看到按钮但代理无法将其映射到一个可执行的操作上。UI逻辑失败界面设计反直觉UI本身的设计对人类而言就难以理解或存在歧义。例如一个完成操作的按钮被命名为“取消”或者操作流程不符合常规心智模型。即使人类也需要反复尝试才能成功。代理基于常规逻辑进行的推理很可能出错。这类失败挑战的是交互设计本身而非代理能力。执行失败动作执行错误代理正确识别了目标如一个按钮的坐标但发出的执行指令如tap(x, y)因设备延迟、坐标漂移、或动作空间不支持如需要长按、双指缩放而失败。这是“最后一公里”的问题。代理规划正确但“手”没跟上。避坑指南优先解决系统级问题如果你的移动代理项目刚起步遇到大量失败请首先排查系统级问题。投入大量精力优化模型视觉能力之前先确保你的无障碍服务能稳定、完整地获取目标应用的UI树。与App开发团队合作推动他们完善无障碍元数据如为关键按钮添加唯一的resource-id和清晰的content-desc这可能是提升代理成功率性价比最高的投资。对于UI逻辑失败可能需要建立一套针对反常设计的特殊规则库。4.2 代理级失败模型与规划的“软肋”代理级失败发生在系统运行正常但代理在规划、决策或反思环节出了错。这类失败占比约26%-32%多模态输入在这里显示出一定的缓解作用平均降低约4-5%但未能根除。失败类别子类具体表现与原因多模态的影响分析LLM预测失败理解屏幕但做出错误决策模型看懂了界面但选择了错误的操作。例如在购物App中应该点击“加入购物车”却点了旁边的“收藏”。或者在有多页的列表中过早停止了滚动。多模态略有帮助。视觉信息能辅助区分外观相似但功能不同的元素如图标微差。但对于需要深层语义理解的选择如在一堆新闻中找出“科技类”新闻帮助有限。LLM反思失败未能识别任务完成或步骤错误代理已经完成了任务目标如成功发送了消息但反思模块没有检测到状态变化认为任务未完成继续执行冗余操作。或者在操作出错后如点进了错误页面未能及时回溯纠正。影响中性。反思能力更多依赖于任务完成状态的定义和模型的内在推理逻辑与输入模态关系不大。达到最大步数效率低下或陷入循环代理在任务中兜圈子或在一条正确但非常低效的路径上花费过多步骤触发了我们设置的最大步数10步限制。多模态有时反而更糟。o4-mini在多模态下“达到最大步数”的失败率更高。推测原因是视觉信息增加了推理的复杂性导致模型在某些步骤上“犹豫不决”思考时间过长在步数限制内无法走完流程。不可能任务任务设计本身模糊或不可行由于任务描述存在二义性或当前应用状态无法支持如要求分享一个不存在的文件导致任何代理都无法完成。与模态无关。这是基准测试设计需要规避的问题。(代理层) UI检索/解析/逻辑/执行失败同系统级但发生在执行过程中与系统级失败原因相同但发生在任务执行的中后期。例如在任务进行到一半时跳转到了一个UI检索失败的新页面。同系统级多模态无法解决。一个典型的代理级失败案例发生在“信息获取”类任务“在维基百科App中搜索‘人工智能’找到‘历史’章节并朗读该章节的第一段。” 纯文本输入下代理成功搜索并进入了词条但在冗长的目录中它错误地将“发展历史”这个小节标题当成了目标导致后续操作失败。多模态输入下代理凭借截图对章节标题的视觉突出感知正确找到了“历史”这个主章节但在尝试执行“朗读”操作时由于该App的朗读按钮是一个没有任何文本标签的纯图标按钮且UI树中其content-desc为空代理再次失败。这里多模态解决了导航问题但没能解决最终的执行问题。5. 设计启示与未来方向基于DailyDroid的测试结果和失败分析我们可以为移动代理、应用开发者和UI设计者提炼出一些切实可行的建议。5.1 对移动代理开发者的启示重新评估输入模态的性价比不要默认将截图作为必选项。在项目初期优先采用纯文本UI树输入进行开发和测试。这能让你以极低的成本快速验证核心规划与执行逻辑并暴露出最多的系统级和逻辑性错误。将截图视为一种“增强模式”或“降级备用方案”仅在纯文本信息明显不足如处理富媒体、图标界面且任务价值足够高时启用。实施分层感知与决策策略设计一个智能的输入模态调度器。例如代理可以首先尝试仅用UI树进行决策如果置信度低如遇到大量未标记的图标或任务明确需要视觉理解“找到红色封面的书”再主动请求截图进行分析。这种混合策略能在成本、隐私和性能间取得更好平衡。强化对“系统级失败”的鲁棒性代理需要具备检测和处理基础设施故障的能力。例如当发现UI树为空或关键属性缺失时不应盲目重试而应触发特定的错误处理流程如记录日志、通知用户、尝试备用操作路径。可以建立一个常见App的UI特征库针对已知的“坑”提前编写适配逻辑。优化反思与状态追踪机制很多代理级失败源于对任务状态的误判。需要设计更精细、更多元的状态验证机制而不仅仅依赖模型的自我反思。可以结合屏幕变化检测前后截图对比、特定UI元素出现/消失、甚至设备通知监听等方式来交叉验证任务是否真的完成。5.2 对应用程序开发者的启示将无障碍支持提升为高优先级特性移动代理本质上是“超级无障碍用户”。一个对代理友好的App必然也是对视力障碍、行动不便用户友好的App。请务必为所有可交互的UI元素提供唯一、稳定、语义清晰的resource-id和content-desc。避免使用android:id/button1这类通用ID。对于图标按钮content-desc至关重要如android:contentDescription搜索。保持UI结构的一致性与可预测性频繁变化的UI布局、动态生成的控件ID会给依赖UI树的代理带来灾难。在迭代设计时考虑为核心功能区域保持稳定的布局结构和组件标识。提供清晰的反馈与状态指示任务完成后界面应有明确的变化如弹出“发送成功”Toast或页面跳转。这有助于代理和所有用户确认操作结果。5.3 对操作系统与UI设计标准的启示推动更丰富、更标准的UI元数据规范当前的Android无障碍API主要服务于辅助功能信息粒度较粗。未来可能需要一套面向自动化代理的增强型UI描述标准在不泄露隐私的前提下提供更丰富的语义信息如元素的功能类型、在业务流程中的角色、与其他元素的关系等。探索“结构化视觉信息”的中间道路完全传输截图隐私风险高纯文本信息损失大。是否可以探索一种折中方案例如由设备端轻量级模型先将截图转化为不包含原始像素隐私的、结构化的视觉描述如“屏幕顶部有一个蓝色导航栏中间是一个包含3个卡片的列表第一个卡片带有购物车图标…”再将这个描述文本发送给大模型。这既保留了视觉布局信息又保护了隐私。设计原生的“自动化友好”模式操作系统是否可以提供一个安全沙箱或特殊模式在此模式下App向授权的自动化代理提供比普通无障碍服务更精确、更稳定的界面信息和操作接口这需要平衡安全、隐私和功能但可能是根本性提升自动化可靠性的方向。这次深入DailyDroid基准测试的经历让我深刻体会到让AI“用好”手机远不是把最强的视觉模型接上屏幕那么简单。它是一场需要算法、工程、产品设计、甚至操作系统生态共同参与的“交响乐”。当前阶段我们或许过于关注乐队首席大模型的独奏能力而忽略了乐谱UI可访问性、乐器执行环境乃至音乐厅声学系统设计的配合。这份“失败手册”不是一个终点而是一份路线图。它告诉我们在追求更智能的移动代理的道路上那些看似枯燥的基础设施完善工作其重要性丝毫不亚于在模型层面刷新的那几个百分点。
