1. Aria-UI 在 AndroidWorld 登顶意味着什么Aria-UI 是一个专为 GUI 交互设计的多模态大模型你可以把它理解成能看懂手机屏幕并直接操作的视觉智能体。它和 Claude Computer Use 属于同一类思路但走了一条更彻底的路线不依赖 HTML 结构、不依赖 Android 的无障碍树AXTree只靠屏幕截图就能判断该点哪里、该滑哪里、该输入什么。这一点对做自动化测试和 GUI Agent 的开发者来说非常关键因为真实 App 里大量控件是自绘的、WebView 嵌套的、甚至动态生成的AXTree 经常拿不到有效节点而纯视觉方案绕开了这个坑。AndroidWorld 是目前公认比较硬的 GUI 智能体评测基准它把任务放在真实 Android 应用里跑比如在设置里改配置、在文件管理器里操作、在浏览器里完成多步流程最终看任务成功率。Aria-UI 在这个基准上拿到 44.8% 的成功率并排到第一这个数字放在 GUI Agent 领域是相当能打的——要知道很多方案还在 20% 到 30% 区间挣扎。它同时是一个 MoE混合专家架构的模型推理速度比同参数量的稠密模型快不少官方在线演示里那种看一眼就点的响应感很大程度来自这个架构选择。适合读这篇的人有三类一是想在自己机器上复现 GUI 多模态推理、验证模型能力的算法工程师二是做 Android 自动化测试、想用视觉方案替代脆弱脚本的测试开发三是研究 GUI Agent、需要一套可跑通的基准测试流程的研究者。这篇不会停留在它很强的层面而是把环境依赖、模型加载配置、AndroidWorld 运行脚本、逐步验证动作全部拆开让你能在自有环境里确认 Aria-UI 到底能不能看懂屏幕、能不能点对位置。需要先说明一个定位Aria-UI 是底层模型官方没有把它封装成开箱即用的 App。这意味着你要自己搭推理服务、自己接 Android 设备或模拟器、自己写动作执行层。这既是门槛也是自由度——你可以把它嵌进自己的测试框架而不是被某个成品工具绑死。下面从环境准备开始一步步来。2. 复现 Aria-UI 推理的前置准备与依赖清单在动手之前先把要准备什么讲清楚否则很容易卡在依赖冲突上。Aria-UI 的推理链路大致是Python 环境加载模型 → 提供 HTTP 或本地调用接口 → AndroidWorld 侧发截图 → 模型返回动作 → 执行层在设备上操作。所以你的环境要同时满足模型推理和 Android 控制两块需求。先说硬件。Aria-UI 是 MoE 多模态模型显存需求取决于你用的精度。实测下来bf16 精度下单卡 24GB 显存可以跑起来但如果要跑 AndroidWorld 的完整任务集建议 40GB 以上或者多卡因为并发任务和截图缓存会额外吃显存。如果显存紧张可以用 4bit 量化加载代价是成功率会有小幅下降做功能验证够用。CPU 推理不推荐多模态模型在 CPU 上慢到没法做基准测试。软件依赖分三层。第一层是 Python 与 CUDA建议 Python 3.10、CUDA 12.1 及以上PyTorch 用 2.2 以上版本因为 MoE 的一些算子在旧版本上支持不好。第二层是模型推理框架transformers 要足够新以支持该模型结构同时装 accelerate 做设备映射。第三层是 Android 控制需要 Android SDK 的 adb 工具以及一个可用的模拟器或真机。AndroidWorld 官方推荐用 Android 模拟器AVD因为可以快速重置状态、并行跑多个实例。这里有个容易忽略的点AndroidWorld 的任务需要 App 处于可控的初始状态所以它依赖一套环境重置机制。你需要确保模拟器镜像里预装了基准测试用到的 App并且 adb 能稳定连接。如果 adb 频繁掉线后面所有任务都会失败排查起来很痛苦所以这一步要单独验证。关于模型权重和推理服务的获取你可以通过 TaoToken 平台来统一管理模型调用与密钥。它的控制台可以创建 API Key接入文档里有标准的 Base URL 和调用示例模型对话页面还能直接试跑多模态输入确认模型对截图的理解是否符合预期。对于需要长期跑编码和 Agent 任务的场景Coding Plan 提供了更稳定的额度方案。这些入口在后面配置环节会具体用到。依赖清单我整理成一张表方便你对照安装组件版本建议作用Python3.10运行推理与基准脚本CUDA12.1GPU 加速PyTorch2.2模型加载与推理transformers最新稳定版模型结构支持accelerate0.30多设备映射Android SDK / adbplatform-tools 最新设备控制Android 模拟器API 33 左右运行基准任务装完这些先别急着跑模型先用adb devices确认设备在线再用一个最小 Python 脚本确认 torch 能识别 GPU。这两步过了再进入模型加载配置能省掉大量到底是环境问题还是模型问题的纠结。3. 可复制的模型加载与 AndroidWorld 运行配置这一节是核心我把模型加载配置和基准运行配置都写成可直接复制的片段。先说模型加载。Aria-UI 作为多模态模型输入是图像加文本指令输出是结构化的动作描述。加载时要注意图像处理器和 tokenizer 的配套以及 MoE 模型的专家并行设置。下面是一个可复制的 Python 加载配置路径和参数按你本地实际情况替换import torch from transformers import AutoProcessor, AutoModelForVision2Seq MODEL_ID your-local-path/Aria-UI DEVICE cuda:0 processor AutoProcessor.from_pretrained(MODEL_ID, trust_remote_codeTrue) model AutoModelForVision2Seq.from_pretrained( MODEL_ID, torch_dtypetorch.bfloat16, device_map{: DEVICE}, trust_remote_codeTrue, ) model.eval() def predict_action(image, instruction): messages [ { role: user, content: [ {type: image}, {type: text, text: instruction}, ], } ] prompt processor.apply_chat_template(messages, add_generation_promptTrue) inputs processor(imagesimage, textprompt, return_tensorspt).to(DEVICE) with torch.no_grad(): output model.generate(**inputs, max_new_tokens128) return processor.decode(output[0], skip_special_tokensTrue)如果你是通过 TaoToken 的 API 方式调用而不是本地加载配置就换成标准的 OpenAI 兼容格式。Base URL 用https://taotoken.net/apiKey 在控制台的 API Keys 页面创建Model ID 填你实际使用的模型标识。这三件套Base URL、Key、Model ID在任何接入场景里都要对齐缺一个就会报 401 或模型找不到。{ base_url: https://taotoken.net/api, api_key: sk-你的密钥, model_id: aria-ui, timeout: 120, max_tokens: 256 }再说 AndroidWorld 的运行配置。AndroidWorld 通常通过一个任务配置文件来指定要跑哪些任务、用哪个 Agent、设备序列号是什么。你需要把 Aria-UI 包装成一个 Agent 类实现step方法接收当前截图和任务描述返回动作。下面是一个简化的 Agent 配置片段class AriaUIAgent: def __init__(self, predictor, device_serial): self.predictor predictor self.device_serial device_serial def step(self, screenshot, task_instruction): action_str self.predictor(screenshot, task_instruction) return parse_action(action_str)运行基准测试时用类似下面的命令启动指定任务集和设备python -m android_world.run \ --agent aria_ui \ --tasks all \ --device emulator-5554 \ --output ./results/aria_ui_run.json这里要提醒一点AndroidWorld 的任务执行是有状态依赖的前一步动作会影响后一步的界面。所以你的 Agent 不能只看当前截图就决策最好把历史动作和任务进度一起作为上下文传给模型否则多步任务很容易在中途迷路。Aria-UI 本身支持多轮视觉输入把前几帧截图拼进 prompt 能明显提升长任务的连贯性。配置写完后先别跑全量任务集挑一个最简单的单步任务验证链路是否通。比如打开设置这种一步到位的任务如果模型能正确输出点击坐标或控件描述说明截图输入、模型推理、动作解析、设备执行这条链路是通的。通了之后再逐步加复杂度。4. 逐步验证 Aria-UI 的 GUI 理解与操作能力配置就绪后验证要分层做不要一上来就跑全量基准那样失败了你根本不知道是哪一层的问题。我把它拆成四个递进的验证动作。第一步验证模型能看懂截图。准备一张手机设置界面的截图给模型一个简单指令比如点击 Wi-Fi 选项看它返回的动作是否指向正确区域。这一步不接设备纯看模型输出。如果模型返回的坐标明显偏离或者描述的是不存在的控件说明图像预处理或 prompt 格式有问题。常见原因是图像分辨率被压缩得太狠或者 chat template 没套对。第二步验证动作解析。模型输出的动作通常是自然语言或半结构化文本比如点击屏幕坐标 (540, 1200)。你需要一个解析器把它转成可执行的动作。这一步单独测喂几条模型真实输出看解析器能不能稳定提取出动作类型和参数。解析器写得太脆是后面任务失败的高频原因比如模型换了个说法你就解析不出来。第三步验证单步设备操作。把解析后的动作通过 adb 执行到模拟器上看界面是否真的发生了变化。比如点击 Wi-Fi 后设置页面是否跳转。这一步验证的是 adb 控制和设备响应和模型无关。如果这步失败问题在设备连接或坐标映射——注意模型看到的截图分辨率和设备实际分辨率可能不一致坐标要按比例换算。第四步验证多步任务。选一个三到五步的任务比如打开设置 → 进入 Wi-Fi → 连接指定网络让 Agent 连续执行观察每一步的截图和动作。这一步最能暴露上下文管理的问题。实测下来多步任务失败往往不是模型看不懂而是历史信息没传好模型在第三步忘了第一步的目标。验证过程中建议把每一步的截图、模型输出、解析后的动作、执行结果都落盘成日志。AndroidWorld 的结果文件里通常有任务级成功率和每步轨迹但你自己加一层详细日志排查效率会高很多。下面是一个日志结构示例{ task_id: settings_wifi_connect, steps: [ {step: 1, screenshot: s1.png, model_output: click Wi-Fi, action: tap(540,1200), result: ok}, {step: 2, screenshot: s2.png, model_output: select network, action: tap(300,800), result: ok} ], success: true }跑完一轮后你会得到自己的成功率数字。它可能和官方 44.8% 有差距这很正常因为设备镜像、App 版本、任务子集都会影响结果。关键是你能定位到差距来自哪一层是模型理解、动作解析、设备执行还是任务编排。定位到了优化就有方向。5. 常见报错与排查对照这一节列几个真实会撞上的报错以及对应的排查路径。GUI 多模态推理的报错往往跨层所以排查时要先确定问题在哪一层。第一个高频报错是 401 未授权。如果你走 API 方式调用出现 401 基本是 Key 不对或没带上。检查三件套Base URL 是否是https://taotoken.net/apiKey 是否从控制台正确复制注意前后空格Model ID 是否和平台上的标识一致。有时候 Key 创建后没启用也会 401去 API Keys 页面确认状态。第二个是local proxy failed或连接超时。这类报错通常出现在请求发不出去的时候。先确认你的网络能正常访问 API 地址再用一个最小 curl 请求测试连通性。如果本地加载模型时出现类似报错那多半是模型权重路径写错或者下载不完整检查文件是否齐全。第三个是reading choices相关的解析错误。这通常发生在你按 OpenAI 兼容格式解析响应但实际返回结构不一致的时候。多模态模型的响应里除了文本还可能带图像相关字段解析时要先打印原始响应看结构再写取值逻辑。别照着文档硬写先看真实返回。第四个是 OAuth 或鉴权流程报错。如果你用的是需要 OAuth 的接入方式报错往往和 token 过期、scope 不足有关。重新走一遍授权流程确认 scope 包含模型调用权限。这类问题在 Coding Plan 场景里也会遇到配置时把鉴权信息集中管理别散落在多个脚本里。第五个是设备侧报错比如device offline或adb server version mismatch。这跟模型无关是 adb 环境问题。重启 adb server确认模拟器镜像和 platform-tools 版本匹配。如果模拟器频繁掉线换一个更稳定的镜像或者降低并发任务数。第六个是显存不足CUDA out of memory。MoE 模型在长序列或多图输入时显存峰值会上去。解决办法有三个降低输入图像分辨率、减少历史帧数量、用 4bit 量化加载。如果都不行就上多卡做设备映射。排查时记住一个原则先隔离层再定位因。把模型推理和设备执行分开测能快速缩小范围。很多看起来像模型问题的报错其实是设备连接或坐标映射的问题。6. 把 Aria-UI 接进你的工作流跑通验证之后下一步是把它接进实际工作流。GUI 多模态模型的价值不在于跑一次基准而在于能持续替你完成重复的界面操作和测试任务。这里给几个落地方向。做 Android 自动化测试的可以把 Aria-UI 作为视觉断言 操作的引擎替代一部分脆弱的 UI 脚本。传统脚本靠控件 ID 定位App 一改版就挂视觉方案靠截图理解抗改版能力强很多。你可以把常用测试用例写成自然语言任务让 Agent 执行并记录结果。做 GUI Agent 研究的AndroidWorld 只是起点。你可以基于这套链路换其他基准或者自建任务集重点观察模型在不同 App 类型上的表现差异。Aria-UI 的纯视觉路线在自绘控件多的场景里优势明显值得针对性做对比实验。需要长期跑编码和 Agent 任务的建议用 Coding Plan 来管理调用额度避免临时 Key 额度不够导致任务中断。模型对话页面适合快速验证单条指令的理解效果接入文档里有完整的参数说明配置时对照着来能少踩坑。最后说一个实用技巧把模型调用和设备操作做成可重放的流水线。每次任务执行都记录截图、模型输出、动作、结果失败时能一键重放某一步。GUI 任务的调试成本很高可重放能帮你把调试时间压下来。这套日志结构前面给过示例直接拿来用就行。Aria-UI 在 AndroidWorld 登顶说明纯视觉 GUI 理解这条路是走得通的而且 MoE 架构让它在速度上有优势。你要做的不是复现那个 44.8% 的数字而是搭起一条自己能控制、能调试、能扩展的推理链路。链路通了模型能力才能真正变成你手里的工具。