一、引言:从“手动搬运”到“一句话存档”
试想这样一个场景:你在刷公众号、知乎或资讯App时,看到一篇深度好文,想存到电脑Word里慢慢研读、做笔记或存档。以往,你需要反复截图、复制粘贴、手动排版、调整格式……一篇长文整理下来,少说五分钟,灵感早已跑光。
现在,你只需要对着电脑说一句话:
“把手机正在浏览的这篇文章保存到Word文档,发到我电脑上。”
然后,你放在桌上的手机屏幕自动亮起,页面自动滚动、截图、识别标题和正文、过滤广告和干扰元素——片刻之后,一份排版干净、结构完整的Word文档已经出现在你的电脑桌面上。
这并非科幻电影,而是基于 Mobile AI Use 这类AI Agent技术已经可以实现的效果。
那么,这背后究竟是怎样的一套技术体系?本文将从架构到实现,为你拆解“手机文章 → 电脑Word”的完整技术链路。
二、整体架构:从文章到Word的四层闭环
要实现“手机文章一键转Word”,需要一套完整的“感知-理解-提取-生成”闭环。其核心架构可分为四个层次:
| 层级 | 核心功能 | 关键技术 |
|---|---|---|
| 设备连接层 | 建立浏览器与手机的通信桥梁 | WebUSB + WebADB协议 |
| 屏幕感知层 | 获取并理解手机屏幕内容 | 视觉语言模型(VLM)+ UI树 |
| 内容提取层 | 从界面中识别文章主体并清洗 | Agent规划 + 多模态理解 + 内容净化 |
| 文档生成层 | 生成Word并交付到电脑端 | DOCX生成库 + 跨设备同步 |
以“提取文章生成Word”为例,整个流程可以直观地表示为:
graph TD
A[用户: “保存文章到Word”] --> B[AI Agent接收指令];
B --> C[截取当前手机屏幕];
C --> D[VLM分析屏幕内容];
D --> E{识别文章结构};
E --> F[提取标题];
E --> G[提取正文段落];
E --> H[识别作者/时间等元数据];
F --> I[组装结构化数据];
G --> I;
H --> I;
I --> J[清洗: 过滤广告/导航/推荐];
J --> K[生成Word文档];
K --> L[交付到电脑端];接下来,我们深入每一层的具体实现。
三、关键技术拆解
1. 设备连接层:WebUSB + WebADB,浏览器直连手机
要控制手机,首先需要建立电脑与手机之间的通信桥梁。传统方式需要安装驱动和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,都可以直接在浏览器里执行。
浏览器端发送 CNXN 握手包完成认证,即可与手机上的 adbd 守护进程建立连接。这种“浏览器即客户端”的模式,实现了“零安装、即连即用”的体验——打开一个网页,连上手机,就能执行几乎所有的ADB操作。
对于开发者而言,这意味着可以将复杂的手机控制逻辑封装为一个网页应用,用户无需安装任何本地软件即可使用。
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如何从文章中“提炼”精华
这是整个方案的核心环节。当用户下达“保存文章到Word”的指令后,Agent需要完成从“看到文章”到“理解内容”再到“清洗净化”的完整转换。
3.1 Agent框架
一个成熟的手机文章提取Agent通常包含以下角色:
- 规划者(Planner) :将用户的复杂指令分解为子目标。例如:“保存文章” → “滚动获取完整内容” → “识别标题和正文” → “过滤干扰元素” → “生成Word”。
- 执行者(Executor) :根据当前屏幕状态,决定下一个具体的原子动作,如滑动、截图、点击。
- 反思者(Reflector) :在执行动作后评估是否成功,如“是否滚动到了文章底部?”如果失败则触发重试。
这个多角色协作的框架,使得AI能够通过“观察 → 思考 → 行动 → 验证”的循环,稳健地完成文章提取任务。
3.2 文章提取的两种路径
| 路径 | 实现方式 | 适用场景 |
|---|---|---|
| UI树提取 | 直接解析AccessibilityService返回的UI层级,提取文本节点 | 文章结构清晰、以纯文本形式呈现 |
| VLM视觉提取 | 将截图发送给多模态模型,让模型理解并提取文章内容 | 存在图片、富文本、复杂排版等场景 |
实际实现中,两者往往结合使用——UI树提供精确的文本和坐标,VLM提供对复杂布局和语义的理解能力。
对于文章内容,Agent会识别出:
- 标题:通常位于页面顶部、字号较大
- 作者/发布时间:位于标题下方的元信息区域
- 正文段落:连续的文本块,构成文章主体
- 图片/图表:作为文章内容的补充
3.3 内容清洗:过滤“噪音”
手机文章页面往往包含大量干扰元素——广告、导航栏、推荐位、浮窗、底部弹出等。Agent在提取内容后,需要进行智能清洗:
- 识别并过滤广告区块(通常带有“广告”、“推广”等标识)
- 移除导航栏和侧边栏内容
- 过滤推荐位(“你可能还喜欢”、“相关阅读”等)
- 剔除浮窗和弹窗元素
- 保留文章的主体内容,确保输出的纯净度
4. 文档生成与交付层:从结构化数据到Word文档
内容提取和清洗完成后,最后一步是生成Word文档并交付到电脑端。
4.1 Word文档生成
结构化数据通过文档处理库生成标准的 .docx 文件。目前业界主要有以下几种技术路径:
| 方案 | 实现方式 | 特点 |
|---|---|---|
| python-docx / OpenXML SDK | 通过Python或JavaScript操作Office Open XML标准 | 精细控制格式,适合复杂文档 |
| Markdown → DOCX | 先将内容转为Markdown,再通过Pandoc等工具转换 | 流程清晰,易于调试 |
| Blob + MIME | 在前端直接构造符合Office Open XML标准的Blob对象 | 纯前端方案,无需后端 |
生成的Word文档通常包含:
- 标题:作为文档的一级标题
- 元信息:作者、发布时间、来源等,作为文档属性或脚注
- 正文:保留段落结构、字号、行距等基本格式
- 图片:如果文章包含配图,也可以一并嵌入
4.2 跨设备交付
生成的文件可以通过多种方式交付到电脑:
- 云端同步:在云端虚拟手机中完成操作,文件直接在电脑端可访问
- 本地传输:通过ADB的
adb pull命令将文件从手机传输到电脑 - Web下载:在浏览器界面中直接提供文件下载
四、完整执行流程:以“保存公众号文章”为例
让我们结合上述技术,看看一次完整的文章提取任务是如何执行的:
- 指令输入:用户在Web界面输入“把手机正在浏览的这篇文章保存到Word文档,发到我电脑上”。
- 设备连接:Web页面通过WebUSB与开启USB调试的手机建立连接。
- 循环开始(Agent Loop) :
- 感知:系统截取手机当前屏幕,将截图和UI树信息一同发送给视觉语言模型。
- 规划:Agent的“规划者”分析当前屏幕,判断这是一个文章页面,规划出子目标:“滚动加载完整内容” → “识别文章结构” → “提取数据” → “生成文档”。
- 执行:系统通过ADB发送
adb shell input swipe命令模拟滑动,滚动页面以加载更多内容。 - 反思:再次截屏,确认是否已滚动到文章底部。
- 内容提取:Agent识别出文章中的标题、作者、正文段落等元素,提取为结构化数据。
- 内容清洗:过滤广告、推荐位、导航栏等干扰元素。
- Word生成:通过文档处理库生成
.docx文件。 - 文件交付:文件通过云端同步或Web下载的方式出现在电脑端。
整个过程中,用户只需要说一句话,剩下的全部由Agent自动完成。
五、技术挑战与展望
尽管技术前景广阔,当前阶段的手机文章提取Agent仍面临一些挑战:
- UI多样性:不同App(公众号、知乎、头条、浏览器等)的页面结构差异巨大。VLM需要具备强大的泛化能力,才能适应各种排版风格。
- 内容识别准确性:需要准确区分“正文”和“广告/推荐”,避免提取到无关内容。
- 长文章处理:长文章需要多次滚动加载,Agent需要具备“滚动-截屏-拼接”的完整能力。
- 性能与成本:每次操作都需调用云端VLM,对网络和计算资源有较高要求。
- 格式保真度:从屏幕提取的内容需要尽可能保留原文的段落结构、标题层级、加粗/斜体等格式。
不过,随着多模态模型能力的持续增强和Agent框架的日益成熟,这些挑战正在被逐步克服。Mobile AI Use类工具,正是这场变革的先行者——Mobile Use SDK支持通过自然语言描述进行数据抓取和结构化输出,并在AndroidWorld基准测试中取得了开源方案第一的成绩。