AutoGLM 核心工作原理解析——从一张截图到一次点击

主循环概览

AutoGLM Agent 的本质是一个不停循环的状态机。每一轮循环做四件事：

截图 → 理解 → 规划 → 执行 → 回到截图

用户给一条自然语言指令（"打开美团搜索附近的火锅店"），Agent 进入循环。每次循环产出一个结构化的操作，由设备控制层翻译成真实的点击或滑动，直到模型判断任务已完成。

第一层：设备截图

Agent 每一轮都要获取设备的当前屏幕快照。这不是通过无障碍服务的 DOM 树，而是真正的像素截图。截图有几种获取方式：

• ADB screencap：Android 设备最通用的方式，兼容性最好
• ADB exec-out screencap -p：直接输出 PNG 二进制，不走磁盘文件，速度更快
• HDC screenshot：HarmonyOS NEXT 的对应命令
• WebDriverAgent：iOS 通过 WDA 的截图 API

截图拿到后作为图片输入，直接传给视觉语言模型。

第二层：视觉理解

这一步由 AutoGLM-Phone-9B 多模态模型完成。模型同时接收三样输入：

1. 当前屏幕截图（图片）
2. 用户的原始任务指令（文本）
3. 之前几步的历史动作和思考链（文本）

模型做两件事：

① 感知屏幕上有什么——识别按钮、文字、图标、导航栏、弹窗、加载动画。这部分能力来自视觉编码器（Vision Encoder）对截图像素的处理。

② 结合任务理解当前上下文——"我要搜索火锅店，现在打开的是美团首页，屏幕上有搜索框"。这部分来自语言模型组件的推理。

第三层：动作规划

模型看完截图后，输出两个东西：

思考过程（think）：推理步骤、失败后的回退策略、对下一个动作的判断
执行动作（answer）：一个结构化的 JSON，包含操作类型和参数

结构化动作的 JSON 形如：

{
  "action": "Tap",
  "element": [540, 960],
  "_metadata": "do"
}

或者：

{
  "action": "Type",
  "text": "附近的火锅店",
  "_metadata": "do"
}

模型不会直接输出"点击搜索"这样的自然语言，而是输出一套固定的动作语言（10 种原子操作）。这套中间接口的设计是 AutoGLM 论文里的核心洞察之一——把规划（需要灵活和错误恢复）和执行（需要精确）分开。

第四层：设备执行

Phone Agent 框架拿到模型输出的动作 JSON，交给对应的设备控制层翻译成真实的系统调用：

• Tap [540, 960] → adb shell input tap 540 960
• Type "附近的火锅店" → 通过 ADB Keyboard 注入文本（Android 原生不支持 ADB 直接输入中文）
• Swipe → adb shell input swipe x1 y1 x2 y2 duration
• Launch "美团" → adb shell am start -n com.sankuai.meituan/.MainActivity
• Take_over → 触发人工接管回调（登录验证码等场景）

Android / HarmonyOS / iOS 各自有独立的适配层，对外暴露统一的操作接口。

循环终止条件

Agent 不会无限循环。终止条件有三个：

1. 模型输出任务完成——JSON 中的动作变成 Done 或模型明确返回任务已完成的判断
2. 达到最大步数——默认 100 步，可通过配置调整，防止死循环
3. 人工接管后超时——登录/验证码场景触发 Take_over，人工完成后恢复循环或标记失败

中间接口设计的意义

AutoGLM 论文里提到一个关键洞察：规划和执行需要的能力是不同的。

• 规划需要灵活和错误恢复——当点击失败、页面跳转了、出现弹窗干扰时，规划层要能重新看屏幕、换路线、重试
• 执行需要精确——坐标差几个像素就点不到目标，输入多一个字符就搜不到结果

把两者用结构化动作 JSON 解耦后，优化路径就清晰了：规划能力靠强化学习（MobileRL / ComputerRL），执行精度靠设备控制层的工程调优。

性能表现参考

通用评测成功率低是正常现象——AndroidLab 覆盖的场景更复杂、App 也更小众。89.7% 的中文主流 App 任务成功率说明 AutoGLM 对日常高频场景已经非常实用。

相关阅读

• 视觉语言模型 AutoGLM-Phone-9B
• 10 种原子操作
• Agent 配置项详解