lightweight neural app control 华为 AI-Agent

摘要

本文介绍了一种称为“应用代理（app agents）”的全新移动电话控制架构，用于高效地在各种Android应用之间进行交互和控制。提出的轻量级多模态应用控制（LiMAC）系统，以文本目标和一系列先前的移动观察数据（如截图和对应的UI树）作为输入，生成精确的操作。为了解决智能手机本身的计算限制，LiMAC内引入了一个小型的动作转换器（Action Transformer，简称AcT），并集成了一个微调的视觉语言模型（VLM），以实现实时的决策与任务执行。在两个开源移动控制数据集上的评估结果表明，我们的小型架构在性能上明显优于微调后的开源VLM（如Florence2和Qwen2-VL），并大幅超越了基于封闭源基础模型（如GPT-4o）进行的提示工程基线。具体而言，LiMAC将整体操作精度提高了19%，相比提示工程基线高出42%。

引言

智能手机应用代理（app agents）正不断扩展人工智能在智能手机和其他移动设备上的潜在应用。这类代理可以帮助用户完成多种任务，例如安排日程、发送信息、购买商品和预订机票等。应用代理通过观察用户指令，并逐步与智能手机的用户界面（如点击、滚动、输入文本等）互动来实现任务目标。然而，考虑到智能手机的计算资源有限，这类代理必须进行高效优化，使用内存占用少且处理速度快的轻量级模型。

近年来，基础模型的进步使得开发能够理解自然语言指令并在智能手机界面中执行复杂操作的应用代理成为可能。然而，使用基础模型处理每一项操作存在显著缺陷：它们体积庞大、计算复杂，导致资源消耗高，难以在移动设备上长期应用。同时，通过服务器托管基础模型（如GPT-4o或Gemini）处理每个任务，成本极高，不适合日常应用。例如，基于GPT-4o的应用代理需要1-2分钟运行，并平均每个任务花费约1.00美元。

为了解决这些局限，我们提出了一种结合轻量级变换器网络和小型微调VLM的分级架构。任务描述和智能手机状态首先由一个紧凑的模型（约5亿参数）处理，该模型能够有效地处理大多数操作。对于需要自然语言理解的操作（如文本输入或搜索），VLM会生成所需文本。这种混合方法降低了计算需求，提高了响应速度，使执行时间缩短至3秒，快30倍，且准确率显著提升。

在提出的架构LiMAC中，初始处理阶段由动作转换器（AcT）负责，主要作用是根据用户指令预测所需的操作类型。对于绝大多数操作类型（如点击和滚动），AcT可以独立完成任务。针对点击目标的预测，我们采用了AcT输出与每个UI元素嵌入间的对比目标。对于需要文本输入的操作，LiMAC将操作类型和用户目标传递给微调后的VLM生成相应文本内容。这种分工方式使AcT负责简单交互，而VLM则处理复杂的文本生成任务，确保系统既高效又具备复杂的响应能力。

主要贡献

提出了一种兼具效率和自然语言理解的LiMAC架构，通过轻量级变换器和微调VLM的组合，实现高效应用代理。
引入AcT作为LiMAC的子模块，高效地预测操作类型和UI元素交互，特别在点击预测方面设计了创新的对比目标。
微调并评估了两个开源视觉语言模型，专用于处理基于文本的操作，性能接近甚至超越了GPT-4o。
实验结果表明，LiMAC在任务执行时间和准确性上均有提升，相较于GPT-4o和微调后的VLM代理，执行速度快30倍，准确率高40%。

技术背景

2 技术预备知识

2.1 问题表述

我们将手机交互建模为一个顺序决策过程。每个任务包含一个在一轮（episode）内需要完成的目标 $g$ 。在该轮的每个时间步 $t$ ，手机的内部状态表示为 $s_t$ ，而 $o_t$ 表示该状态的观测，包括屏幕截图和用户界面（UI）元素树。在时间步 $t$ 时屏幕上可见的 UI 元素集合定义为 $I_t$ ，其中 $o_{t,i}$ 代表时间步 $t$ 的第 $i$ 个 UI 元素， $i \in I_t$ 。每个 UI 元素 $i$ 由三个不同的组件表示：对应于 UI 元素的图像，用 $o^{\text{img}}_{t,i}$ 表示；对应于 UI 元素的文本，用 $o^{\text{txt}}_{t,i}$ 表示；以及与该 UI 元素相关的属性（例如该元素是否可点击），用 $o^{\text{attr}}_{t,i}$ 表示。因此，每个 UI 元素的表示可以写成：

o_{t,i} = [o^{\text{img}}_{t,i}, o^{\text{txt}}_{t,i}, o^{\text{attr}}_{t,i}].

智能体通过在时间步 $t$ 执行动作 $a_t$ 与手机交互。每个动作由两个组件表征：动作类型 $a^{\text{type}}_t \in A^{\text{type}}$ （例如，点击、向下滚动、输入文本）和动作规格 $a^{\text{spec}}_t \in A^{\text{spec}}$ 。规格的内容取决于动作类型：对于点击动作， $a^{\text{spec}}_t$ 可能表示目标 UI 元素；对于输入动作， $a^{\text{spec}}_t$ 则包含要输入的文本。因此，一个动作可以表示为一个元组 $a_t = (a^{\text{type}}_t, a^{\text{spec}}_t)$ 。这种表述方式能够灵活地表示多种不同的动作，同时保持结构的一致性。

在本研究中，主要目标是学习一个能够最大化动作预测准确率的模型，即正确预测动作类型和动作规格。为实现这一目标，我们训练了 AcT 模型，用于预测 $a^{\text{type}}_t$ 。如果预测的动作类型是点击，AcT 还会预测 $a^{\text{spec}}_t$ ，即 UI 元素目标。我们重点关注点击目标，因为点击是最难预测且最常见的动作之一，而 AcT 的架构能够通过对比学习方法（详见第 3.5 节）轻松地预测这些目标。对于需要自然语言规格的动作（如输入文本），我们使用在相同数据集上微调过的视觉语言模型（VLM）。

2.2 使用 Transformer 进行序列建模

Transformer（Vaswani 等人，2017）在多个领域的序列数据建模和生成方面展现了出色的效果。它们在包括语言、视频处理和决策制定等任务中表现优异（Chen 等人，2021）。不论具体应用，Transformer 都会首先将输入转换为一个向量序列。对于文本，这涉及到将输入进行分词处理，每个词元用一个嵌入向量表示。而对于图像，输入通常被划分为若干图像块，每个块同样用一个向量表示，类似于文本中的分词过程。这些嵌入向量可以在模型训练期间学习，或来自于预训练模型（如 Devlin 等人，2018）。

然而，Transformer 的固有限制之一是将输入视为一组无序的向量，缺乏时间或空间关系的概念。为了解决这一问题，位置嵌入（positional embeddings）被添加到原始的词元或图像块嵌入中，以编码序列中每个元素的位置信息。通过引入这些位置信息，Transformer 能够理解输入的相对顺序。

组合后的嵌入会通过多层多头自注意力（multi-head self-attention）层，这些层设计用于捕捉输入序列中不同嵌入之间的依赖关系和上下文关系。这些自注意力机制使模型在处理每个嵌入时能够关注序列中相关的部分，从而更有效地处理长距离依赖。在通过多层结构后（每层包含自注意力和前馈网络组件），Transformer 最后一层的激活结果会通过一个线性（全连接）层。这个层通常负责将学习到的表示映射到输出空间，无论是用于分类、预测，还是其他特定任务。整个模型端到端地训练，通过反向传播调整自注意力层和最终线性层，以优化目标任务的性能。

3 轻量级多模态应用控制框架

我们的方法通过 AcT 处理用户目标 $g$ 和时间步 $t$ 时的手机状态，以确定动作类型 $a^{\text{type}}_t$ 。如果预测的动作类型是 input-text 或 open-app，则将 $g$ 、 $o_t$ 和 $a^{\text{type}}_t$ 传递给一个微调过的视觉语言模型（VLM），由其负责确定具体的动作 $a^{\text{spec}}_t$ 。对于涉及点击的动作，AcT 直接处理预测，但采用了一种不同的训练目标，通过对比 UI 元素的嵌入来确定最可能的交互目标。因此，本节分为三个部分：预测动作类型、预测文本输入和应用启动的具体动作，以及使用我们新颖的方法预测点击动作来与 UI 元素进行交互。LiMAC 的完整架构在第 3 节呈现。

3.1 模型输入

AcT 是负责预测动作类型（以及后续的点击目标，如第 3.5 节所述）的模型，基于典型的 Transformer 架构构建。然而，不同于标准的 Transformer，其中的 token 代表单词或字符，我们的“token”是映射到 Transformer 隐藏维度的预训练嵌入。这些 token 代表三个关键组件：用户的目标 $g$ 、手机屏幕上的 UI 元素 $o_{t,i}$ 以及可能的动作。通过将这些预训练的嵌入作为输入，我们让模型能够有效捕捉用户意图、界面当前状态和可用动作之间的关系。我们将每个关键组件（UI 元素、动作和目标）编码为 Transformer 可处理的嵌入。下面，我们描述每种输入类型的编码过程。

目标（Goal）：我们使用一个句子编码器对用户的文本目标 $g$ 进行编码，得到嵌入 $e_g = f_{\text{txt}}(g)$ 。此嵌入表示用户的意图，作为传递给 Transformer 的第一个 token。

UI 元素（UI Elements）：每个时间步 $t$ 下的 UI 元素观测表示 $o_{t,i}$ 被转换为向量 $e^{\text{ui}}_{t,i}$ ，通过一系列嵌入函数完成。首先，文本组件使用句子编码器（例如 BERT）进行编码，得到 $e^{\text{txt}}_{t,i} = f_{\text{txt}}(o^{\text{txt}}_{t,i})$ ，图像则使用微调过的 CLIP 视觉编码器（Radford 等人，2021）编码，得到 $e^{\text{img}}_{t,i} = f_{\text{img}}(o^{\text{img}}_{t,i})$ 。此外，其他属性（例如是否可点击、可编辑、嵌套等）被编码为 $e^{\text{attr}}_{t,i} = f_{\text{attr}}(o^{\text{attr}}_{t,i})$ 。每个 UI 元素的最终嵌入是这些向量的拼接：

e^{\text{ui}}_{t,i} = [e^{\text{attr}}_{t,i}; e^{\text{txt}}_{t,i}; e^{\text{img}}_{t,i}].

我们使用标准的对比学习目标（Radford 等人，2021）微调 CLIP，通过观测的截图和相关的 UI 树来适应应用控制数据集。此外，我们添加一个位置编码 $p_i \in \mathbb{R}^d$ 以表示 UI 元素的顺序或嵌套关系，得到：

e^{\text{ui}}_{t,i} = e^{\text{ui}}_{t,i} + p_i.

该过程如图 1 所示。为了使视觉编码器 $f_{\text{img}}$ 适应我们的任务，我们使用 InfoNCE 损失（Oord 等人，2018）在数据集上进行微调，使 UI 元素的图像和文本表示对齐。

动作（Actions）：每个动作由两个嵌入表示：动作类型嵌入 $e^{\text{type}}$ ，以及对于需要规格的动作（例如点击动作的目标）的规格嵌入 $e^{\text{spec}}$ 。根据动作类型，动作规格嵌入的计算方式不同（例如，对于文本动作，使用句子嵌入；对于点击目标，使用映射到 UI 元素 ID 的可学习嵌入；对于没有规格的情况，则使用一个特殊的 token）。每个动作在 Transformer 的输入序列中贡献两个 token，将动作类型和其参数明确区分开来。

位置嵌入（Positional Embeddings）：为了表示时间信息，我们还为每个时间步的所有嵌入添加一个可学习的位置编码 $p_t$ 。

3.2 构建输入序列

在生成目标、UI元素和动作嵌入后，我们将它们组织成一个表示整个episode的序列。数据集中每个episode被编码为一个嵌入序列 $x$ ，并输入到transformer中。序列以目标嵌入 $e_g$ 开始，接着是时间步 $t=0$ 的UI元素嵌入 $e_{ui}^{0,i}$ 。在所有UI元素编码完成后，会添加一个特殊的结束标记 $e_{end}$ 。然后附加时间步 $t=0$ 的动作类型嵌入 $e_{type}^{0}$ 和动作规格嵌入 $e_{spec}^{0}$ 。这个过程对每个后续时间步重复进行：编码UI元素，添加 $e_{end}$ ，再添加动作嵌入。对于包含 $H$ 个时间步的episode，最终的序列表示为：

在训练过程中，完整的序列被输入到transformer中。而在推理时，对于时间步 $t$ ，只处理直到第 $t$ 个观察的序列，利用隐藏状态 $h_t$ （直到 $e_{end}$ ）来预测动作。

3.3 动作类型预测

在我们的流程中，下一步动作的预测从确定动作类型开始。动作类型 $a_{type}^{t}$ 的预测可以看作是一个分类问题，在本研究使用的数据集中定义了十种不同的动作类型。这些动作类型代表了各种可能的交互方式，如点击（click）、打开应用（open-app）、向下滚动（scroll-down）、输入文本（input-text）或其他基本命令。我们使用一个专门的头部（head）来实现动作类型预测。动作类型head记为 $f_{type}$ ，它将transformer的最终隐藏状态 $h_t$ （在 $e_{end}$ 标记之后）转换为可能的动作类型的概率分布，即 $p(a_{type}^{t} | h_t) = f_{type}(h_t)$ 。该任务的学习目标是最小化预测和实际动作类型之间的交叉熵损失。给定数据集 $D$ ，动作类型预测的交叉熵损失定义为：

L_{type} = -\mathbb{E}_{a_{type},x \in D} [ \log(p(a_{type} | h)) ]

这里， $h$ 表示transformer在动作预测之前对应的最终隐藏状态，取数据集中所有观测的平均值。这个损失函数确保模型根据前一步嵌入序列正确分类动作类型。

3.4 利用微调的VLM进行动作执行中的文本生成

如前一节所述，我们的智能体首先预测动作类型。在十种动作类型中，有两种动作特别需要文本规格：i）输入文本（input-text）动作，其中规格是要输入到文本框中的文本，ii）打开应用（open-app）动作，其中规格是要打开的应用程序名称。对于这些动作，我们依赖于使用应用控制数据集微调的视觉语言模型（VLM）。数据集提供类似字典格式的动作数据，例如：{"action-type":"open-app","app-name":"Chrome"}，其中一个键对应动作类型，另一个键对应动作规格。VLM被训练以生成与每个动作成功执行相对应的正确token序列，优化基于每个时间步的观察生成适当token的可能性。

在推理过程中，在AcT预测出动作类型后，它会指导VLM使模型的响应从预测的动作类型开始。例如，如果AcT预测动作类型为input-text，则VLM会强制其响应以以下token模式开始：{"action-type":"input-text","text":。然后模型完成规格生成，产生一个 $spec_t$ ，即动作所需的文本内容。完整的动作选择流程如图2所示。

3.5 使用对比目标实现高效点击目标选择

在前面介绍了文本类动作的规格生成后，我们接下来讨论点击动作的情况，其中规格是要交互的UI元素。为了预测点击动作的正确UI元素，我们使用了一种基于对比学习的方法，该方法在整个episode上运行，使用余弦相似度和一个可学习的温度参数。由于不同时间步和episode的UI元素数量不一，对比方法比分类更适合，后者在处理测试时遇到比训练中更多的UI元素时可能会出现类别不平衡问题。令 $h_{type}^{t}$ 表示transformer的隐藏状态（直到嵌入 $e_{type}^{t}$ ）， $f_{target}$ 表示一个仿射变换，用于将隐藏状态投影到一个嵌入空间。同时，将transformer对应的UI元素嵌入的隐藏状态 $h_{ui}$ 也投影到同一个嵌入空间：

q_{type} = f_{target}(h_{type}^{t}) \quad \text{和} \quad p_{ui} = f_{target}(h_{ui})

假设嵌入空间在 $\mathbb{R}^d$ 中，查询嵌入 $q_{type}^{t}$ 的维度为 $1 \times D$ ，而矩阵 $p_{ui}$ （表示所有UI元素）则为 $K \times D$ ，其中 $K$ 是episode中UI元素的总数。目标是通过余弦相似度作为对齐度量来训练模型，使得 $q_{type}^{t}$ 与时间步 $t$ 的正确UI元素嵌入紧密对齐。为此，我们采用了带有InfoNCE损失（Oord et al., 2018）的对比训练技术。首先计算查询嵌入 $q_{type}^{t}$ 与所有UI元素嵌入之间的相似度矩阵，并通过一个可学习的参数 $\tau$ 进行缩放（如Radford等人，2021）。缩放后的余弦相似度矩阵定义为：

S = \frac{q p^T}{\|q\| \cdot \|p\|_r \tau}

其中 $\|p\|_r$ 是 $p$ 的每一行的L2范数。为简化，我们在公式中省略了上标。整个episode中UI元素选择的InfoNCE损失计算为：

L_{elem} = -\mathbb{E} \left[ \log \frac{\exp(S^+)}{\sum_{i=1}^K \exp(S_i)} \right]

这里， $S^+$ 是transformer输出与点击动作对应的正确UI元素之间的缩放相似度，而 $S_i$ 表示输出与所有其他UI元素之间的相似度。在推理过程中，对于每个需要目标元素的动作，选择相似度最高的UI元素作为交互目标。该对比方法通过将episode中的所有其他UI元素作为负样本，帮助AcT有效学习在点击动作中应交互的UI元素。余弦相似度的使用侧重于嵌入的方向对齐，而可学习的温度参数 $\tau$ 在训练过程中调整相似度分布的锐度，从而实现更灵活和精确的UI元素选择。

4 实验

4.1 实验设置

数据集：我们的实验集中在两个公开的手机控制数据集上，即AndroidControl（Li等人，2024）和Android-in-the-Wild（AitW）（Rawles等人，2023）。这两个数据集包含了大量人类演示的手机导航操作，涵盖了各种任务。在AndroidControl中，每个操作片段（episode）由特定的目标定义，包含一系列观察和操作。每次观察包括手机的截图及其对应的UI树。而在AitW中，观察内容不包含UI树，因此需要使用OCR系统来提取UI树，识别出所有UI元素，并为每个元素提供简要描述。关于每个数据集的目标格式、观察空间和操作空间的更多细节请参见附录A。

GPT-4基线：我们将我们的方法与四个基于GPT-4的提示工程基线进行比较，这些基线在评估数据集上生成操作。首先，我们评估由Rawles等人（2024）提出的两个基线：文本型的T3A和多模态的M3A。在T3A中，观察被表示为一个UI元素列表，而M3A则包含观察的截图。此外，我们还评估了SeeAct代理（Zheng等人，2024）的两个变体，适用于移动应用控制任务（Rawles等人，2024）。具体来说，我们评估了SeeAct的两个变体：SeeAct choice和SeeAct ann，分别使用UI树文本和观察截图来确定正确的操作。关于提示工程基线的更多细节请参见附录B。

视觉语言模型（VLMs）：我们在实验中微调了两个视觉语言模型。第一个是Florence2（Xiao等人，2024），一个拥有820M参数的VLM，输入为标注了编号边界框的截图以及自然语言形式的任务目标。Florence2经过训练以最大化数据集中正确操作的对数似然。同样地，我们使用LoRA适配器（Hu等人，2021）微调了Qwen2-VL（Bai等人，2023），一个拥有2B参数的VLM。Qwen2-VL的流程与 Florence2 相同，输入为标注截图和任务目标，并通过正确操作的监督进行训练。在大部分实验中，这些微调后的VLM与AcT结合使用（形成LiMAC）。

4.2 评估流程

我们在两个数据集的测试集上进行评估，所有模型的评估过程相同，仅观察格式和模型调用不同。对于每个时间步，我们调用模型并使用相应的观察格式生成一个操作。VLMs被训练为返回特定格式的操作，而预训练模型则使用包含观察内容的详细提示，如Rawles等人（2024）所述。

可以通过直接比较返回的操作与真实值来计算严格精度。然而，在本研究中，我们放宽了该指标，以提供更实际的评估。在放宽版本中，如果UI元素的边界框在目标元素内，则认为其是正确的（Li等人，2024）。对于输入文本的操作，如果其Jaccard指数分数至少达到0.5，则认为正确，以反映在搜索框中类似输入的功能等价性。我们仅报告放宽后的准确率指标，见表1和表2。

在第4.5节中，我们还评估了模型的操作类型准确率和点击目标准确率。操作类型准确率反映了模型预测正确操作类型的能力，而不考虑具体的文本内容或目标元素。点击目标准确率衡量了在已知操作类型的情况下，模型预测点击操作的正确目标的准确性。计算点击目标准确率需要重新对整个数据集进行评估，模型输出被限制为预测点击操作并指定目标元素。需要注意的是，总体准确率的提升不一定依赖于更高的操作类型或点击目标准确率。这是因为点击目标准确率是单独计算的，而且并非所有操作类型对提高总体准确率都具有同等优势。实际上，对于那些需要额外具体化的操作，即使预测了正确的操作类型，也不保证能够提升总体结果。因此，一种操作类型准确率略低，但优先选择无需具体化的操作的方法，可能获得更高的总体准确率。例如，正确预测“wait”操作将直接转化为成功的时间步，而预测“input-text”则仍然依赖于准确的文本内容。

4.3 测量端到端准确率

在本节中，我们展示了我们方法的总操作准确率，以及基线模型的准确率。表 1 分别展示了在 AndroidControl 和 AitW 数据集上的动作预测准确率。在这两个数据集中，我们观察到 LiMAC 在动作预测准确率方面始终优于基线模型 Florence2、Qwen2-VL 和基于 GPT-4o 的方法，显示出其在保留测试集上的更优泛化能力。LiMAC 在 AndroidControl 数据集上准确率的整体提升可以归因于训练集和测试集之间更紧密的对齐，因为测试集包含了相同的指令集，只是应用于具有不同特性（如屏幕尺寸和 Android 版本）的移动设备。此外，我们还观察到基于文本的基线模型（如 T3A）和基于图像-文本的模型（如 M3A 和 SeeAct）的性能显著下降。AitW 数据集中缺乏原始 UI 树的存在可能是导致这种下降的原因。由于 UI 树需要通过注释工具从图像中提取，因此通常会引入不准确性，这会降低依赖文本输出条件的模型的性能。这凸显了 LiMAC 的一个关键优势，即即使 UI 树不准确或完全缺失（如表 4 所示），其性能也几乎不受影响，表现出较强的鲁棒性。

4.4 组合不同模块

LiMAC 是一个模块化架构，允许集成不同的模块来完成诸如预测动作类型、识别点击动作中的目标元素，以及为“open-app”和“input-text”生成文本等任务。在该架构中，我们主要使用 AcT 来预测动作类型和点击动作的目标元素。然而，也可以使用其他模块来进行这些预测。在表 2 中，我们展示了不同模型的组合，排除了因整体准确率较低的 SeeAct，并比较了它们在两个数据集上的性能表现。

在 AndroidControl 数据集中，我们观察到使用 M3A 来预测点击动作的目标元素比单独使用 AcT 提升了性能。这表明，当提示指定动作为“click”时，GPT-4o 在识别正确的目标元素方面非常有效。当然，这以调用 GPT-4o 为代价，显著增加了推理时间。当使用 LiMAC 预测动作类型，M3A 用于目标元素预测，T3A 用于文本生成时，达到了最高的整体准确率。在 AitW 数据集中，LiMAC 与 Florence 组合用于文本生成，取得了最高的准确率。这一结果是预料之中的，因为在该数据集中，M3A 和 T3A 的准确率显著较低（见表 1）。

4.5 消融研究

表 3 展示了在两个数据集上，不同模块组合的动作类型、点击目标和文本的准确率。结果显示，LiMAC，尤其是 AcT 模块，在动作类型预测方面达到了最佳性能。在 AndroidControl 数据集中，M3A 和 T3A 在点击目标和文本预测方面表现良好，但在动作类型准确率上表现欠佳，并且在自动注释的 AitW 数据集中表现不佳。总体而言，LiMAC 中的 AcT 在点击目标预测方面表现出色，同时模型规模显著较小。最终，我们的 Florence 微调在文本预测方面表现出色，在 AitW 数据集中显著优于基于 GPT-4o 的基线，并在 AndroidControl 数据集中保持竞争力。

最后，我们进行了三项消融研究，以进一步探讨 AcT 的设计选择。AcT 的核心特征是其能够将每个 UI 元素作为一个独立的嵌入在 transformer 中处理，该嵌入是通过将相应 UI 元素的图像、文本和属性嵌入连接起来创建的。为了评估图像和文本模态的影响，以及 CLIP 微调对 LiMAC 性能的影响，我们对比了三个消融版本：一个排除图像组件，一个在嵌入过程中省略 UI 文本，另一个使用原始的 CLIP 对图像嵌入进行编码而非微调版本。这些比较的评估指标在 AndroidControl 数据集上，使用 Florence2 进行文本生成，如表 4 所示。

结果表明，移除图像嵌入会显著降低所有指标的准确率，强调了视觉信息在 AcT 中的关键作用。相比之下，省略文本嵌入仅对性能产生轻微影响，这表明 AcT 仅使用观察的截图即可有效运行，而无需访问 UI 树。此外，我们观察到对 CLIP 的微调（参见第 3.1 节）是提升 LiMAC 总体准确率的重要因素。这些发现突显了视觉特征的重要性以及微调预训练模型（如 CLIP）在我们场景中的益处。移除文本嵌入的轻微影响表明，LiMAC 即使在文本信息有限或不可用的情况下也具备较强的鲁棒性，这在 UI 树无法访问或不完整的情况下具有优势。未来的工作可以探索集成其他模态或进一步优化嵌入过程，以提升性能。

5 相关工作：应用控制

尽管图形用户界面（GUI）控制最初主要集中在基于 Web 的数据集和基础模型代理上（Shi et al., 2017; Liu et al., 2018; Yao et al., 2022a; Deng et al., 2023; Furuta et al., 2023; Gur et al., 2023; Zheng et al., 2024），但最近对手机控制的关注显著增加。这一趋势可以通过 Android 导航数据集和环境的快速发展（Rawles et al., 2023; 2024; Li et al., 2024），以及移动控制代理的发展（Yang et al., 2023; Wang et al., 2024b;a; Wen et al., 2023; Hong et al., 2024; Rawles et al., 2024; Li et al., 2024; Bai et al., 2024）来证明。尽管许多代理发布时都带有各自的特定评估数据，但诸如 Android-in-the-Wild（Rawles et al., 2023）或 AndroidControl（Li et al., 2024）等流行数据集经常被用作基准。

为此任务开发的代理可以分为两种明确的输入类型：基于文本的代理，使用 UI 可访问性树或 XML 信息描述屏幕，和基于图像的代理。基于图像的代理需要视觉模型来直接处理图像输入，通常以 VLMs（Visual Language Models）为支持。另一方面，基于文本的代理依赖于经典的 LLMs（Large Language Models）。使用 VLMs 的图像型代理通常会将文本和图像组合输入到模型中。许多移动控制代理提出了复杂的提示方法，这些方法往往依赖于现成的、通常是专有的 LLMs，例如 GPT-4（Rawles et al., 2024; Yang et al., 2023; Wang et al., 2024b;a; Wen et al., 2023; Zheng et al., 2024）。虽然这种方法几乎不需要训练，但可能既慢又昂贵。此外，这些模型无法进一步调整和训练以适应特定任务。因此，另一种方法是围绕 Android 控制数据集（如 AitW 或 AndroidControl）上的基础模型微调来构建移动控制代理。

首先，AitW 和 AndroidControl 都在其数据集上展示了微调后的 LLM 的结果。例如，Li et al. (2024) 在其数据集上训练了不同的 PaLM 2（Anil et al., 2023）模型。然而，这些模型是专有的，并且规模较大，据报道基本 PaLM 2 模型有超过 300B 的参数。CogAgent（Hong et al., 2024）也在一个规模为 18B 的 VLM 上进行了微调。Bai et al. (2024) 提出了另一种方法，称为 DigiRL，使用强化学习（RL）来训练其 1.3B 参数的 VLM。这种方法取得了较强的性能，但也存在自身的局限性，特别是数据收集成本和模拟难度，使得该模型仅在 AitW 的一个小子集上表现良好。

6 结论

总之，我们提出了 LiMAC，这是一个轻量级框架，旨在解决应用控制任务。LiMAC 从每个手机截图中提取 UI 元素，并使用专门的视觉和文本模块对其进行编码。这些 UI 元素的编码作为嵌入传递给 AcT，后者预测下一步操作的类型和具体信息。AcT 专注于操作的两个关键方面：操作类型和在预测操作为“click”时的目标元素。对于需要生成文本的操作，LiMAC 使用微调的 VLM 以确保成功完成操作。我们将 LiMAC 与六个由最先进的基础模型支持的基线进行了比较，并在两个开源数据集上进行了评估。结果表明，LiMAC 在训练和推理所需的计算时间显著减少的情况下，能够优于这些基线模型。这表明 LiMAC 能够在计算能力有限的设备上处理任务完成。

该方法的主要局限之一是训练数据的有限性。LiMAC 仅在 AndroidControl 和 AitW 上分别使用了 13K 和 18K 个 episode 进行训练。缺乏任何预训练进一步限制了该模型在更复杂任务上提升性能的能力。未来，我们计划通过引入在线学习技术（如强化学习）来提升模型的性能。在本研究所展示的初始训练阶段之后，LiMAC 可以与 Android 模拟器交互，以生成更多的数据。通过使用适当的奖励函数，甚至可以借助 GPT-4 来评估生成的轨迹并分配奖励（Bai et al., 2024），我们可以对 LiMAC 进行微调，以提高任务的完成率。

目录