一、引言：从“手动搬运”到“一句话搞定”
试想这样一个场景：你正在手机App里浏览一个商品列表、客户名单或数据报表，需要把这些信息整理到电脑的Excel中做进一步分析。以往，你需要反复截图、手动录入、核对数据……一套操作下来，半小时过去了。
现在，你只需要对着电脑说一句话：
“把手机里这个商品列表提取出来，生成Excel发到我电脑上。”
然后，放在桌上的手机屏幕自动亮起，App自动滚动、截图、识别数据，片刻之后，一份结构完整的Excel文件已经出现在你的电脑桌面上。
这并非科幻电影，而是基于 Mobile AI Use 这类AI Agent技术已经可以实现的效果。
那么，这背后究竟是怎样的一套技术体系？本文将从前端工程视角，为你拆解“手机界面列表 → 电脑Excel”的完整技术链路。
二、整体架构：从自然语言到Excel文件的四层闭环
要实现“一句话把手机列表变成Excel”，需要一套完整的“感知-理解-提取-生成”闭环。其核心架构可分为四个层次：
| 层级 | 核心功能 | 关键技术 |
|---|---|---|
| 设备连接层 | 建立浏览器与手机的通信桥梁 | WebUSB + ADB协议 |
| 屏幕感知层 | 获取并理解手机屏幕内容 | 视觉语言模型（VLM）+ UI树 |
| 数据提取层 | 从界面中识别并结构化数据 | Agent规划 + 多模态理解 |
| 数据交付层 | 生成Excel并传输到电脑 | Excel生成库 + 跨设备同步 |
以“提取商品列表生成Excel”为例，整个流程可以直观地表示为：
graph TD
A[用户: “提取列表生成Excel”] --> B[AI Agent接收指令];
B --> C[截取当前手机屏幕];
C --> D[VLM分析屏幕内容];
D --> E{识别列表结构};
E --> F[提取表头字段];
E --> G[提取每行数据];
F --> H[组装结构化数据];
G --> H;
H --> I[生成Excel文件];
I --> J[交付到电脑端];接下来，我们深入每一层的具体实现。
三、关键技术拆解
1. 设备连接层：WebUSB + ADB，浏览器直连手机
要控制手机，首先需要建立电脑与手机之间的通信桥梁。传统方式需要安装驱动和ADB工具集，而Mobile AI Use类工具利用 WebUSB API，直接在浏览器中完成这一过程。
WebUSB 是一个W3C标准，允许网页应用与USB设备直接通信。用户只需在浏览器弹窗中授权，网页即可获得手机的控制权。
ADB（Android Debug Bridge） 是谷歌官方的调试桥接工具。在WebUSB之上，工具通过 WebADB 实现了“浏览器中的ADB客户端”——在浏览器中重建了ADB Client和部分Server的功能。这意味着所有ADB命令，如 adb shell input tap、adb exec-out screencap -p，都可以直接在浏览器里执行。
WebADB通过WebUSB声明设备的ADB接口（class 0xFF, subclass 0x42, protocol 0x01），直接读写批量数据包来完成通信。浏览器端发送 CNXN 握手包完成认证，即可与手机上的 adbd 守护进程建立连接。
这种“浏览器即客户端”的模式，实现了“零安装、即连即用”的体验。
WebADB的核心优势：无需安装任何驱动或软件，打开一个网页就能执行几乎所有的ADB操作。对于团队协作场景，只需发一个链接：“用Chrome打开这个页面，连上手机，点这里就行”。
2. 屏幕感知层：视觉语言模型如何“看懂”手机界面
要让AI像人一样从手机界面中提取数据，它必须能“看懂”屏幕。这依赖于视觉语言模型（Vision-Language Model, VLM） 。
2.1 感知方式
系统通过ADB持续截取手机屏幕（adb exec-out screencap -p），将截图发送给VLM。VLM主要有两种感知方式：
- 像素级理解：模型直接“看”截图，理解图标、文字和布局的含义。
- UI树辅助：通过Android的无障碍服务（AccessibilityService） 获取当前页面的UI层级结构（View Hierarchy）。这就像给AI提供了一份当前页面的“地图”，标明了每个UI元素的坐标、文本和属性。
实际实现中，Agent会同时利用截图和UI树信息，发送给视觉模型时附带当前App、设备状态、完整已安装应用列表和历史步骤等上下文。
2.2 坐标系统
模型返回的动作需要精确定位到屏幕上的元素。目前主流方案支持两种坐标格式：
- 像素坐标：直接使用截图像素值（如
{"action": "tap", "x": 540, "y": 960}） - 归一化坐标：使用0-1000的归一化坐标（Vision-Pointer风格），更便于模型泛化
系统会自动解析、规范化并校验模型返回的动作。
3. 数据提取层：Agent如何从列表中“读懂”数据
这是整个方案的核心环节。当用户下达“提取列表生成Excel”的指令后，Agent需要完成从“看到列表”到“理解数据结构”的转换。
3.1 Agent框架
一个成熟的手机数据提取Agent通常包含以下角色：
- 规划者（Planner） ：将用户的复杂指令分解为子目标。例如：“提取列表” → “滚动页面获取完整列表” → “识别表头” → “逐行提取数据” → “结构化输出”。
- 执行者（Executor） ：根据当前屏幕状态，决定下一个具体的原子动作，如滑动、截图、点击。
- 反思者（Reflector） ：在执行动作后评估是否成功，如“页面是否加载了更多数据？”如果失败则触发重试。
这个多角色协作的框架，使得AI能够通过“观察 → 思考 → 行动 → 验证”的循环，稳健地完成数据提取任务。
3.2 数据提取的两种路径
| 路径 | 实现方式 | 适用场景 |
|---|---|---|
| UI树提取 | 直接解析AccessibilityService返回的UI层级，提取文本节点 | 列表结构清晰、数据以文本形式存在 |
| VLM视觉提取 | 将截图发送给多模态模型，让模型理解并提取结构化数据 | UI复杂、存在图片/图标等非文本元素 |
实际实现中，两者往往结合使用——UI树提供精确的文本和坐标，VLM提供对复杂布局的理解能力。
对于列表数据，Agent会识别出重复的UI模式（如商品卡片、列表项），提取每个条目的字段（如名称、价格、评分），并将其组装为结构化数据。
值得一提的是：mobile-use项目在AndroidWorld基准测试中完成了100%的任务，位列榜首，证明了这套技术方案在真实场景中的可行性。
4. 数据交付层：从结构化数据到Excel文件
数据提取完成后，最后一步是生成Excel并交付到电脑端。
4.1 Excel生成
结构化数据通过Excel处理库（如Python的 openpyxl、JavaScript的 SpreadJS 等）生成标准的 .xlsx 文件。生成的Excel可以包含：
- 表头（从UI中识别的字段名）
- 数据行（逐条提取的内容）
- 基本的格式（列宽、字体、数字格式等）
4.2 跨设备交付
生成的文件可以通过多种方式交付到电脑：
- 云端同步：在云端虚拟手机中完成操作，文件直接在电脑端可访问
- 本地传输：通过ADB的
adb pull命令将文件从手机传输到电脑 - Web下载：在浏览器界面中直接提供文件下载
四、完整执行流程：以“提取商品列表”为例
让我们结合上述技术，看看一次完整的数据提取任务是如何执行的：
- 指令输入：用户在Web界面输入“把手机里这个商品列表提取出来，生成Excel发到我电脑上”。
- 设备连接：Web页面通过WebUSB与开启USB调试的手机建立连接。
- 循环开始（Agent Loop） ：
- 感知：系统截取手机当前屏幕，将截图和UI树信息一同发送给视觉语言模型。
- 规划：Agent的“规划者”分析当前屏幕，判断这是一个列表页面，规划出子目标：“滚动加载全部数据” → “识别列表结构” → “提取数据”。
- 执行：系统通过ADB发送
adb shell input swipe命令模拟滑动，加载更多数据。 - 反思：再次截屏，确认是否已滚动到列表底部。
- 数据提取：Agent识别出列表中的重复模式，提取每个条目的字段（名称、价格、评分等），组装为结构化数据。
- Excel生成：通过
openpyxl等库生成.xlsx文件。 - 文件交付：文件通过云端同步或Web下载的方式出现在电脑端。
整个过程中，用户只需要说一句话，剩下的全部由Agent自动完成。
五、技术挑战与展望
尽管技术前景广阔，当前阶段的手机数据提取Agent仍面临一些挑战：
- UI多样性：不同App的UI风格差异巨大，VLM需要具备强大的泛化能力。
- 数据准确性：自动提取的数据需要校验，特别是数字格式、日期格式等。部分方案会加入校验步骤来确保数据质量。
- 性能与成本：每次操作都需调用云端VLM，对网络和计算资源有较高要求。
- 安全性：涉及数据提取时，需确保用户数据的隐私和安全。
不过，随着多模态模型能力的持续增强和Agent框架的日益成熟，这些挑战正在被逐步克服。Mobile AI Use这类工具，正是这场变革的先行者，为我们展示了“手机数据自动驾驶”的雏形——从“人找数据”到“数据找人”，效率的提升将是指数级的。