从 AutoGLM 到 豆包手机:GUI Agent 技术探索与对比

AI AgentGUI AgentAutoGLM豆包手机
2025-12-22

引言

这个月,AI Agent 赛道接连出现两个关键动作,引发了技术圈的密切关注:先是字节的“豆包手机”作为全球首款 AI 原生硬件亮相;紧接着,被誉为“首个具备 Phone Use 能力”的智谱 AutoGLM 模型宣布开源。它们共同指向并加速了一个超越内容生成的新趋势:AI 正从“创作助理”迈向“操作代理”,直接操作我们的数字设备。

这一趋势并非一蹴而就。以 AutoGLM 为例,其背后是智谱 AI 长达 32 个月的持续探索:从 2023.04 开始探索 AI Agent,到 2024.10 发布首个能在真机上稳定完成复杂操作链路的版本,直至 2025.12.09 宣布全面开源AutoGLM开源:每台手机,都可以成为AI手机,喊出“让每台手机成为 AI 手机”的口号。

官方时间线(2023.04 启动 → 2025.12 开源)
  • 2023-04 项目立项,目标“让 AI 像人一样使用手机”
  • 2024-10 首次在真机跑通完整操作链路(AI 自己发出人类历史上第一个手机红包)
  • 2024-11 GLM OpenDay 上对外小范围内测,代号 AutoGLM 1.0
  • 2025-03-31 发布「AutoGLM 沉思」版,具备深度研究与操作双能力,同时宣布 4-14 开源。
  • 2025-04-14 核心模型(GLM-Z1-Rumination + AutoGLM-Phone-9B)与工具链按 MIT/Apache-2.0 协议正式开源。
  • 2025-08-20 推出 AutoGLM 2.0 公众版,基于国产 GLM-4.5 & GLM-4.5V,支持 iOS、安卓、网页三端
  • 2025-12-09 “深夜开源”事件——把整套 Phone-Use 能力、50+ 中文 App Demo、Android 适配层全部托管到 GitHub,进入“本地方案”阶段
无独有偶,一周前的 2025.12.01 [豆包手机助手发布技术预览版](https://mp.weixin.qq.com/s/deusnrynccsaIQvF6TW7uQ),字节跳动发布的“豆包手机”以操作系统级合作实现跨 App 自动化操作,从产品端印证了这一方向。其助手能通过简单指令,实现网页阅读、购物、点外卖、订酒店、评论和点赞朋友圈、发微信等行为,甚至可以跨 APP 完成循环任务。

尽管 AutoGLM(开源技术框架)与豆包手机助手(封闭消费产品)同属图形用户界面智能体 GUI Agent 阵营(GUI Automation + LLM Agent),底层实现仍存在差异:前者以跨平台适配层降低硬件依赖,后者则深度绑定操作系统权限。但 AI 操作设备的故事,并非只有 GUI Agent 一条主线。苹果 Apple Intelligence 及其 App Intents 框架所呈现的 “API Agent” 特征,正以另一种逻辑重构人机交互:通过标准化语义接口让 App 主动暴露功能,Agent 以结构化调用完成任务,在可靠性、隐私保护与执行效率上形成独特优势。

为厘清技术本质,本文将采取 “双向切入 + 范式对比” 的方式:一方面以 AutoGLM 为样本,通过实践体验与源码分析进行 “白盒” 拆解,还原 GUI Agent 的“感知 - 推理 - 执行”闭环;另一方面结合豆包手机助手的测评和逆向,推测其操作系统级合作的实现逻辑,分析背后的 UI-TARS 模型,简析带来的行业争议。最终,回归技术核心,引入 API Agent 作为参照系展开范式对比,探讨两大范式的融合趋势以及 GUI Agent 技术与业务场景和软件开发中的潜在结合点。

AutoGLM 开源分析

Open-AutoGLM 是一个基于视觉语言模型(VLM)的智能手机自动化框架。它能够接收简单的文字/语音指令,理解用户意图并模拟人的操作,自动控制 Android 设备完成复杂任务,实现“用嘴发指令”操作手机。在研究 Open-AutoGLM 的开源实现时,很容易会产生 “其架构远比想象中简洁” 的直观感受 —— 框架本身仅承担模型指令的调用与解析,并未在工程层陷入繁杂的全链路自研逻辑,以轻量化的模块化设计搭建核心链路:设备交互复用安卓 ADB 工具、模型推理集成 SGLang 等成熟框架、接口适配遵循 OpenAI 标准化格式,Agent 决策控制层也仅负责流程串联、敏感操作校验等基础调度,没有复杂的状态管理逻辑;同时框架还提供了 CLI 和 Python API 双入口,大幅降低了使用门槛,整体代码结构清晰且耦合度低。而其核心竞争力(GUI Agent 理解与操作规划),则集中在自研的 AutoGLM-Phone-9B 这类多模态模型上,模型需要经过大量手机 UI 数据训练,才能实现 “看懂屏幕、理解意图、规划操作” 的核心诉求,最终达到 “工程层复用简化、核心能力自研聚焦” 的设计平衡(见下文豆包 UI-TARS 论文中提到的 GUI Agent 发展演进路径总结)。

本地运行示例

本地启动以及环境配置等,参考智谱 Github:Open-AutoGLM。以"打开小红书搜索美食攻略"为例,视频和执行日志见下

基础使用

python

以"打开小红书搜索美食攻略"为例展示完整执行流程:

plain

系统架构

组件职责文件位置
PhoneAgent任务编排、状态管理、循环控制phone_agent/agent.py
ModelClient与 VLM 模型通信,解析响应phone_agent/model/client.py
ActionHandler执行具体动作,处理回调phone_agent/actions/handler.py
ADB 模块设备控制、截图、输入phone_agent/adb/
Config 模块系统提示词、应用配置phone_agent/config/

源码分析和 Agent 设计

plain

动作指令系统中 16 种指令

动作类型格式说明
启动应用do(action="Launch", app="微信")快速启动目标应用
点击do(action="Tap", element=[x, y])点击屏幕坐标
敏感点击do(action="Tap", element=[x, y], message="支付确认")需要用户确认的敏感操作
输入文本do(action="Type", text="内容")输入文本(自动清除已有内容)
输入人名do(action="Type_Name", text="张三")输入人名(特殊输入处理)
滑动do(action="Swipe", start=[x1,y1], end=[x2,y2])滑动操作(滚动、翻页)
长按do(action="Long Press", element=[x, y])长按操作(上下文菜单)
双击do(action="Double Tap", element=[x, y])双击操作(放大、选择)
返回do(action="Back")返回上一页
主页do(action="Home")返回桌面
等待do(action="Wait", duration="3 seconds")等待页面加载
交互选择do(action="Interact")多选项时询问用户如何选择
记录页面do(action="Note", message="True")记录当前页面内容
总结评论do(action="Call_API", instruction="总结要点")总结或评论已记录的内容
接管do(action="Take_over", message="需要登录")请求人工介入(登录、验证码)
完成finish(message="任务已完成")结束任务

从技术架构来看,PhoneAgent 的任务调度流程遵循 ReAct(Reasoning + Acting)的核心设计理念,以 “界面感知 - 推理决策 - 操作执行 - 状态反馈” 的迭代循环实现移动端界面的自适应交互。

plain
ReAct 循环:
┌─────────────────────────────────────────────┐
│  1. Observe (观察)                           │
│     └─ 获取当前屏幕截图 + 应用状态            │
├─────────────────────────────────────────────┤
│  2. Reason (推理)                            │
│     └─ VLM 分析 → 生成思考过程 (Think)       │
├─────────────────────────────────────────────┤
│  3. Act (行动)                               │
│     └─ 解析并执行动作 (Action)               │
├─────────────────────────────────────────────┤
│  4. Reflect (反思)                           │
│     └─ 记录结果到上下文 → 回到步骤 1          │
└─────────────────────────────────────────────┘
  • 状态机模式:每一步都是一个状态转换
  • 责任链模式:PhoneAgent → ModelClient → ActionHandler
  • 策略模式:不同动作类型对应不同的处理策略
  • 观察者模式:通过回调函数通知外部敏感操作

上下文管理:线性累计。

python

更受关注的原因

下面是 AutoGLM Phone Agent 支持的 50+ 款主流中文应用,可以看到涉及常用的社交通讯(微信、QQ、微博)、电商购物(淘宝、京东、拼多多)、美食外卖(美团、饿了么、肯德基)、出行旅游(携程、12306、滴滴出行)、视频娱乐(bilibili、抖音、爱奇艺)、音乐音频(网易云音乐、QQ音乐、喜马拉雅)、生活服务(大众点评、高德地图、百度地图)以及内容社区(小红书、知乎、豆瓣)等。

豆包 AI 手机的爆火,让 GUI Agent 技术从实验室走向大众视野,也带火了一批同类开源项目 —— 智谱 AutoGLM 凭借 “轻量开源 + 手机场景适配” 迅速出圈,而阿里此前 2025.08 发布的 Mobile-Agent-v3(基于 GUI-Owl 模型)却未获得同等关注度(选它仅为举例)。个人理解,这种热度差异并非技术实力的绝对差距,而是技术定位(“手机优先”的轻量化开源 vs “全平台”的重量级框架)、发布时机(踩中“AI 手机风口” vs 提前发布的“认知差困境”)、生态适配(用户需求驱动 vs 技术能力驱动)等共同作用的结果,这里不再展开表述。

豆包 AI 手机黑盒分析

当前手上没有豆包手机及其助手,下面运行示例和原理分析均来自网络。

运行示例

  • 借壳努比亚,操作系统可能自研。Obric UI的系统包内部发现了许多锤子科技的遗留字样(来源:微博用户wuxianlin);系统的UI也有很明显的“锤子味儿”。
  • 让豆包手机助手打开汽车充电 App,查看充电记录, 并告知用户。
  • 让豆包手机助手帮我们把空调给打开
  • 豆包手机点外卖,支付时选择接管(担心豆包操作支付宝导致封号)

原理分析

豆包手机 AI 自动化功能的底层工作机制来自该视频 https://www.bilibili.com/video/BV1rNmHBLEN1/

核心系统进程解析:豆包手机有多个关键常驻系统进程(见下图),aivoice和assistantaiagent是语音助手前端入口;aikernel是端侧AI核心进程,其 Native 堆占用 160M,Binder 数量极高,是本地AI推理框架且为系统级服务;autoaction 是 AI 自动操作的核心 APK,是研究重点。

AI 读屏机制揭秘:AI 并非通过普通截图或录屏读取屏幕,而是依靠 READ_FRAME_BUFFER 权限直接读取 GPU 渲染的图形缓冲区原始 Bitmap(见下图一,核心区别之一),还拥有 CAPTURE_SECURE_VIDEO_OUTPUT 权限可绕过银行类 App 的防截屏限制,且是在专属虚拟屏幕中完成读屏(见下图二),不干扰物理屏幕操作。AI 如何捕获屏幕内容则可在具体渲染日志中查看(见下图三)。但后来豆包手机助手已出来辟谣,表示并没有使用技术说明:豆包手机助手使用系统原生截屏接口,无法截屏银行键盘等受保护内容

AI自动操作原理:AI 自动操作不走无障碍 API,而是通过调用系统隐藏 API injectInputEvent 直接向虚拟屏幕注入输入事件来实现控制(见下图一,核心区别之二),可通过 adb 抓取到对应的注入事件日志作为佐证(见下图二),其与普通 AI RPA 工具的本质区别在于底层系统权限。

本地与云端AI分工逻辑:因证书锁定无法通过常规抓包获取通信信息,从本地日志发现,手机会每隔 3-5 秒向 obriccloud 的字节服务器发送 250K 左右的单帧图片数据(见下图一),云端接收后返回1K左右的操作指令,指令共 7 种,分别为打开应用、点击屏幕、输入文本、等待、滑动屏幕、记笔记等(见下图二),本地仅执行指令,推理和路径规划由云端完成。

技术底座 UI-TARS

2025 年初,字节跳动与清华大学联合发布的 UI-TARS 论文,提出了 “纯视觉输入、端到端执行” 的 GUI Agent 架构,可以看到,思路与智谱 AutoGLM 一致。而根据量子位等媒体披露起底“豆包手机”:核心技术探索早已开源,GUI Agent布局近两年,“全球首款真正的AI手机”豆包 AI 手机使用的是 UI-TARS 的闭源商业版本。

这里看下该论文在模型训练上的创新点,核心创新体现在四方面:其一,构建大规模 GUI 截图数据集,设计元素描述、密集字幕等五大感知任务,强化界面理解与元素识别能力;其二,定义跨平台统一动作空间,结合标注轨迹与开源数据,提升多步骤执行与精准定位水平;其三,爬取 600 万份 GUI 教程并为动作轨迹注入任务分解、反思等 System 2 推理模式(System 2 推理是慢思考、刻意且结构化的分析型认知过程,区别于 System 1 的快速直觉决策,它要求模型在执行动作前生成显式思考链),实现感知与动作的精准衔接;其四,依托数百台虚拟机开展在线轨迹自举与反思调优,通过 DPO 训练让模型从错误中迭代优化。

此外,该论文中还提到了 “GUI Agent 发展演进路径(Evolution Path of GUI Agents)”,按照 GUI Agent 发展遵循人类干预程度递减、泛化能力递增的脉络,可划分为四个核心阶段,其能力边界随技术范式迭代持续突破:

  • 基于规则驱动 Rule-based Agents:GUI Agent 雏形阶段,以 RPA 系统为典型代表,核心逻辑是通过预定义规则和 API 调用复现人类重复性操作,仅适用于结构化、流程固定的场景。
  • 模块化框架 Modular Agent Framework:依托大模型理解与推理能力,整合视觉解析、记忆存储、工具调用等独立模块,通过专家定制的提示词和工作流协调模块运作,典型如 AutoGPT、LangChain 等。
  • 原生模型 Native Agent Model:原生模型以纯视觉截图为唯一输入,将感知、推理、动作、记忆能力统一嵌入模型参数,通过大规模 GUI 交互数据实现 “数据驱动” 的自主学习。(也回答了上文为什么 AutoGLM “简单”)
  • 主动终身学习 Active and Lifelong Agent:属于未来展望,GUI Agent 终极演进方向,可主动发起任务、评估执行效果、生成自奖励信号,无需人工标注即可持续优化能力。

行业争议

首先,豆包手机助手调整了 AI 操作手机的能力关于调整AI操作手机能力的说明

豆包 AI 手机引起现有移动互联网商业模式和行业发展讨论:

  • 对移动互联网商业模式的冲击:豆包手机带来的深层启示,或许在于其对移动互联网入口逻辑的潜在重塑。当用户习惯以自然语言任务为导向,而非主动寻找并操作特定 APP 时,传统的应用分发、广告投放和用户粘性模型都将面临挑战。这并非立即颠覆,而是意味着产业的价值重心可能从占据用户手机屏幕,转向占据 AI 助手的“服务清单”与“信任权重”。
  • 行业争议与未来发展探讨:豆包手机引发的行业震荡(腾讯、阿里等平台对豆包的围追堵截),揭示了技术变革期的典型矛盾:基于旧范式构建的庞大生态与酝酿新范式的“颠覆火种”之间的冲突。这场竞争远非单纯的产品之争,更是关乎下一代数字世界交互入口、服务分发权和生态主导权的卡位战。同时,我们也看到技术演进中会伴随着新的挑战:AI 作为强大的信息与行动中介,是否会形成新的权力集中?我们的业务又应如何在技术、伦理与监管的动态平衡中,找到自己的进化之路?

GUI Agent vs API Agent

在数字环境自动化领域,智能体的操作范式主要分为 GUI Agent(基于图形界面的智能体)和 API Agent(基于应用程序接口的智能体)两类,二者在交互逻辑、适用场景与核心优势上存在显著差异。

GUI Agent vs API Agent

本节介绍二者定义、优劣势对比、选择不同范式的标准以及融合路径。

  • GUI Agent:在 GUI 环境中运行,以 LLM 为核心推理与认知引擎,能够灵活且自适应地生成、规划并执行操作的智能体。其本质是将 LLM 作为核心认知与推理引擎,能够在 GUI 环境中自主解析界面元素、理解用户意图并执行交互操作的智能系统,核心是 “感知 - 规划 - 执行 - 反馈” 的闭环。近年来 GUI Agents 面向不同交互平台(Web 网页端、Mobile 移动端、Computer 桌面端和 Cross 跨平台)的演变与发展见下图,可以看到最近比较火的 Mobile Agent、AutoGLM、Operater、UI-TARS 等在列。
  • API Agent:利用 LLM 作为认知引擎,调用一个或多个预定义的应用或系统的原生 API 来自动满足用户请求/完成任务的智能体,其核心逻辑是 “指令 - API 调用 - 结果返回”。这类 Agent 依赖 API 文档提供的功能描述、参数规范与调用示例,操作过程本质是对接口的精准调用。例如,Apple Intelligence 可依托 App Intents 框架,将邮件中的会议信息直接写入日历并设置提醒,全程无需打开应用可视化界面,仅通过后台接口串联即可完成;传统场景中,调用 Outlook API 也可直接发送邮件,无需模拟点击、输入等界面操作。

下面两个表格分别是两种范式不同维度的对比以及选择不同 Agent 范式的标准。可以看到,两者展现出互补的优势——API Agent 在速度、安全性和可靠性方面表现出色,而 GUI Agent 则具备灵活性、广泛适用性和透明度——这使它们有望在未来实现混合与融合。

两种不同范式的不同维度对比

选择不同 Agent 范式的标准

下表展现二者的融合路径(混合式方案)

  • GUI 工作流的 API 封装:为 GUI 应用增加 “无头模式” 或脚本接口,将多步 GUI 操作抽象为结构化 API 命令
  • 统一编排工具:可自动为任务选择执行方式,优先调用 API 完成高可靠性步骤(如查询信用评分),无 API 时切换为 GUI Agent 操作(如更新 CRM 系统)
  • 低代码 / 无代码方案:通过拖拽组件实现自动化流程,后台自动适配 API 或 GUI 执行

从 Agent 技术的长期演进视角来看,API Agent 与 GUI Agent 的无缝整合还可能催生全新形态的软件:可自主完成后端 API 的生成与迭代以保障服务效能(后端 API 自主生成优化),同时能动态编排前端界面元素实现透明化交互(前端界面动态编排)。比如

  1. GUI Agent 感知前端交互需求,向 API Agent 发起接口生成 / 优化请求;
  2. API Agent 返回适配接口后,GUI Agent 自动编排前端组件完成交互落地;
  3. 二者通过状态同步接口实现全流程闭环。

GUI Agent 技术分析

结合上文对 AutoGLM 和豆包手机助手的分析可见,GUI Agent 本质是通过 “界面感知 - 模型推理 - 操作执行 - 状态反馈” 的闭环迭代循环,实现对各类界面的自适应交互。下图则全面呈现了 LLM 驱动的 GUI 智能体(LLM-powered GUI Agent)从接收用户需求到落地完成任务的核心架构与端到端工作流,展现了各组件间的协同逻辑,也进一步奠定了 “以自然语言为入口、以环境感知为基础、以迭代推理为核心” 的核心设计范式。

其中

  • 界面感知可以通过截图(Screenshots)和控件树(Widget Tree)等捕获当前状态;
  • 模型推理(大脑)依赖 LLM 基于提示输出 “任务规划 + 具体行动 + 辅助解释”,实现 “从语言到行动” 的转化;
  • 操作执行(手脚)将 LLM 生成的行动指令转化为实际 GUI 操作(如 UI 操作、API 调用),核心解决 “如何精准执行” 的问题;
  • 状态反馈是行动后的 “结果验证” 机制,通过截图更新对比、UI 结构变化等确保 Agent 知晓操作是否成功。

GUI Agent 局限与未来

最后,概述 GUI Agent 的主要局限性,并提出克服这些挑战的未来研究方向(主要来自微软的 GUI Agents 综述论文)。

隐私问题尤为突出。GUI Agent 通常需要访问用户的敏感数据——例如截图、交互历史、个人凭证和机密文档——才能有效地感知图形用户界面环境并与之交互。在许多情况下,这些数据必须传输到远程服务器进行模型推理,尤其是在依赖基于云的 LLM 时。这种方式带来了重大的隐私风险,包括数据泄露、未授权访问以及个人信息的滥用。当敏感输入通过第三方API传输或在设备外处理时,这些担忧会进一步加剧,从而产生合规性和安全性漏洞,可能阻碍其在实际场景中的应用。这一问题的潜在解决方案:端侧模型。

安全性和可靠性风险。 GUI Agent 能够直接操控用户界面——点击按钮、删除文件、提交表单或启动系统级操作——动作生成过程中的错误可能会造成不可逆转的后果。这些后果可能包括数据损坏、意外发送消息、应用程序崩溃或未授权访问敏感系统组件,LLM 输出中固有的不确定性和非确定性加剧了此类风险:Agent 可能会虚构动作、误解用户界面上下文,或在不同会话中表现不一致。潜在解决方案:需要强大的错误检测与处理机制,如整合验证步骤,在执行前验证推断动作的正确性,建立回滚程序等。

人机交互(Human-Agent Inteaction)冲突。GUI Agent 给人机交互带来了挑战,Agent 和用户在一个动态界面内操作,任何用户干预(例如移动鼠标、更改窗口状态或修改输入)都可能无意中干扰Agent 的持续执行,进而可能导致冲突、意外操作或任务流程中断。在这一问题的解决上,豆包手机助手给出的一种可行解决方案是通过虚拟屏幕。此外,用户指令的模糊性进一步使这种交互变得复杂:自然语言命令可能含糊不清、不够具体或依赖上下文,从而导致误解或不完整的任务计划。GUI Agent 还可能遇到运行时的不确定性——例如意外弹窗、缺失输入或冲突的用户界面状态——这需要它们寻求用户的澄清或反馈。人机协作系统允许在任务执行过程中进行人工干预,让用户能在必要时指导或纠正智能体的决策。

参考文献

Open-AutoGLM

AutoGLM: Autonomous Foundation Agents for GUIs

UI-TARS

UI-TARS: Pioneering Automated GUI Interaction with Native Agents

Mobile-Agent-v3: Fundamental Agents for GUI Automation

Large Language Model-Brained GUI Agents: A Survey

API Agents vs. GUI Agents: Divergence and Convergence

加载中...
加载评论中...