从 AutoGLM 到 豆包手机:GUI Agent 技术探索与对比
引言
这个月,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,进入“本地方案”阶段

尽管 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。以"打开小红书搜索美食攻略"为例,视频和执行日志见下
基础使用
from phone_agent import PhoneAgent
from phone_agent.model import ModelConfig
from phone_agent.agent import AgentConfig
# 配置模型
model_config = ModelConfig(
base_url="http://localhost:8000/v1",
model_name="autoglm-phone-9b",
temperature=0.1
)
# 配置代理
agent_config = AgentConfig(
max_steps=50,
verbose=True,
lang="cn"
)
# 创建代理
agent = PhoneAgent(
model_config=model_config,
agent_config=agent_config
)
# 执行任务
result = agent.run("打开小红书搜索美食攻略")
print(result)
以"打开小红书搜索美食攻略"为例展示完整执行流程:
(base) ➜ Open-AutoGLM git:(main) ✗ # 使用智谱 BigModel
python main.py --base-url https://open.bigmodel.cn/api/paas/v4 --model "autoglm-phone" --apikey "04b0ce49aca64b75a23b84edf106918a.6la2gWxV6vTmgxB" "打开小红书搜索美食攻略"
🔍 Checking system requirements...
--------------------------------------------------
1. Checking ADB installation... ✅ OK (Android Debug Bridge version 1.0.41)
2. Checking connected devices... ✅ OK (1 device(s): AVKY022B22007835)
3. Checking ADB Keyboard... ✅ OK
--------------------------------------------------
✅ All system checks passed!
🔍 Checking model API...
--------------------------------------------------
1. Checking API connectivity (https://open.bigmodel.cn/api/paas/v4)... ✅ OK
--------------------------------------------------
✅ Model API checks passed!
==================================================
Phone Agent - AI-powered phone automation
==================================================
Model: autoglm-phone
Base URL: https://open.bigmodel.cn/api/paas/v4
Max Steps: 100
Language: cn
Device: AVKY022B22007835 (auto-detected)
==================================================
Task: 打开小红书搜索美食攻略
==================================================
💭 思考过程:
--------------------------------------------------
用户要求打开小红书并搜索美食攻略。当前在系统桌面。
我需要:
1. 打开小红书应用
2. 在小红书中搜索"美食攻略"
首先,我需要使用Launch功能打开小红书。小红书在允许的应用列表中。
让我先启动小红书应用。
--------------------------------------------------
🎯 执行动作:
{
"action": "Launch",
"app": "小红书",
"_metadata": "do"
}
==================================================
==================================================
💭 思考过程:
--------------------------------------------------
好的,小红书已经打开了。我可以看到小红书的主界面,显示了"发现"标签页,有各种推荐内容。
现在我需要搜索"美食攻略"。我可以看到右上角有一个搜索图标(放大镜图标)。我需要点击它来进入搜索界面。
搜索图标的位置大约在右上角,坐标大约是 (922, 64)。
--------------------------------------------------
🎯 执行动作:
{
"action": "Tap",
"element": [
922,
64
],
"_metadata": "do"
}
==================================================
==================================================
💭 思考过程:
--------------------------------------------------
很好!搜索界面已经打开了。我可以看到:
1. 顶部有一个搜索框,显示着"iphone air降价"的搜索历史或提示
2. 下方显示"猜你想搜"的建议
3. 有"小红书热点"列表
4. 底部出现了键盘
现在我需要点击搜索框,然后输入"美食攻略"。搜索框的位置大约在顶部,坐标大约是 (448, 64)。
让我点击搜索框。
--------------------------------------------------
🎯 执行动作:
{
"action": "Tap",
"element": [
448,
64
],
"_metadata": "do"
}
==================================================
==================================================
💭 思考过程:
--------------------------------------------------
我看到搜索框还是显示"iphone air降价",键盘已经出现了。现在我需要输入"美食攻略"。根据指南,Type操作会自动清除现有文本并输入新文本,所以我可以直接使用Type操作。
让我输入"美食攻略"。
--------------------------------------------------
🎯 执行动作:
{
"action": "Type",
"text": "美食攻略",
"_metadata": "do"
}
==================================================
==================================================
💭 思考过程:
--------------------------------------------------
太好了!我已经成功输入了"美食攻略",搜索框现在显示"美食攻略"。同时,系统已经显示了一些相关的搜索建议:
- 美食攻略怎么做
- 美食攻略图
- 美食攻略合集
- 杭州美食攻略
- 青岛美食攻略
- 大理美食攻略
- 昆明美食攻略
- 沈阳美食攻略
- 桂林美食攻略
- 顺德美食攻略
现在我需要点击右侧的"搜索"按钮来执行搜索。搜索按钮在右上角,坐标大约是 (911, 64)。
--------------------------------------------------
🎯 执行动作:
{
"action": "Tap",
"element": [
911,
64
],
"_metadata": "do"
}
==================================================
==================================================
💭 思考过程:
--------------------------------------------------
完美!搜索已经成功执行,现在显示了"美食攻略"的搜索结果页面。我可以看到:
1. 顶部搜索框显示"美食攻略"
2. 有筛选选项:全部、用户、商品、图片、问一问
3. 有排序选项:综合、最新、附近、必吃榜、简单做法、北京等
4. 显示了多个美食攻略的笔记/帖子:
- "吃货速码!北京10家让你狂炫的宝藏店..."
- "美食|海鲜大餐做法 厦门美食 我的美食..."
- "北京必吃榜!本地人强推的10家美食 来北..."
- "珠海纯土著分享!!必吃的10家小店!!..."
任务已经完成!我成功打开了小红书并搜索了"美食攻略",现在显示的是搜索结果页面。
--------------------------------------------------
🎯 执行动作:
{
"_metadata": "finish",
"message": "任务完成!我已经成功打开小红书并搜索\"美食攻略\"。现在显示的是搜索结果页面,可以看到各种美食攻略的内容,包括北京、厦门、珠海等地的美食推荐,以及海鲜大餐做法等不同类型的美食攻略帖子。"
}
==================================================
🎉 ================================================
✅ 任务完成: 任务完成!我已经成功打开小红书并搜索"美食攻略"。现在显示的是搜索结果页面,可以看到各种美食攻略的内容,包括北京、厦门、珠海等地的美食推荐,以及海鲜大餐做法等不同类型的美食攻略帖子。
==================================================
Result: 任务完成!我已经成功打开小红书并搜索"美食攻略"。现在显示的是搜索结果页面,可以看到各种美食攻略的内容,包括北京、厦门、珠海等地的美食推荐,以及海鲜大餐做法等不同类型的美食攻略帖子。
(base) ➜ Open-AutoGLM git:(main) ✗
系统架构
| 组件 | 职责 | 文件位置 |
|---|---|---|
| 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 设计
Open-AutoGLM/
├── main.py # CLI 入口,系统检查
├── setup.py # 包安装配置
├── requirements.txt # 依赖列表
├── phone_agent/ # 核心代码包
│ ├── __init__.py # 导出公共接口
│ ├── agent.py # PhoneAgent 主类
│ ├── actions/ # 动作处理模块
│ │ ├── handler.py # ActionHandler 类
│ │ └── __init__.py
│ ├── adb/ # ADB 控制模块
│ │ ├── connection.py # 设备连接管理
│ │ ├── device.py # 设备操作(点击、滑动等)
│ │ ├── input.py # 输入法控制
│ │ ├── screenshot.py # 截图功能
│ │ └── __init__.py
│ ├── model/ # 模型交互模块
│ │ ├── client.py # ModelClient 类
│ │ └── __init__.py
│ └── config/ # 配置模块
│ ├── apps.py # 应用包名映射
│ ├── i18n.py # 国际化文本
│ ├── prompts.py # 系统提示词
│ ├── prompts_en.py # 英文提示词
│ └── prompts_zh.py # 中文提示词
├── examples/ # 使用示例
│ ├── basic_usage.py # 基础用法
│ └── demo_thinking.py # 思考过程演示
├── scripts/ # 工具脚本
│ ├── check_deployment_cn.py # 部署检查
│ └── sample_messages.json # 消息样例
└── resources/ # 资源文件
├── privacy_policy.txt # 隐私政策
└── WECHAT.md # 微信群二维码
动作指令系统中 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)的核心设计理念,以 “界面感知 - 推理决策 - 操作执行 - 状态反馈” 的迭代循环实现移动端界面的自适应交互。
- 状态机模式:每一步都是一个状态转换
- 责任链模式:PhoneAgent → ModelClient → ActionHandler
- 策略模式:不同动作类型对应不同的处理策略
- 观察者模式:通过回调函数通知外部敏感操作
上下文管理:线性累计。
self._context: list[dict[str, Any]] = [
# 第 0 条:系统提示词
{
"role": "system",
"content": "你是一个智能体分析专家..."
},
# 第 1 条:用户任务 + 第一张截图
{
"role": "user",
"content": [
{"type": "text", "text": "打开微信\n\n** Screen Info **\nCurrent App: System Home"},
{"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,..."}}
]
},
# 第 2 条:模型第一次响应
{
"role": "assistant",
"content": "<think>需要启动微信</think><answer>do(action=\"Launch\", app=\"微信\")</answer>"
},
# 第 3 条:执行后的新屏幕
{
"role": "user",
"content": [
{"type": "text", "text": "** Screen Info **\nCurrent App: 微信"},
{"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,..."}}
]
},
# ... 持续循环
]
更受关注的原因
下面是 AutoGLM Phone Agent 支持的 50+ 款主流中文应用,可以看到涉及常用的社交通讯(微信、QQ、微博)、电商购物(淘宝、京东、拼多多)、美食外卖(美团、饿了么、肯德基)、出行旅游(携程、12306、滴滴出行)、视频娱乐(bilibili、抖音、爱奇艺)、音乐音频(网易云音乐、QQ音乐、喜马拉雅)、生活服务(大众点评、高德地图、百度地图)以及内容社区(小红书、知乎、豆瓣)等。

豆包 AI 手机的爆火,让 GUI Agent 技术从实验室走向大众视野,也带火了一批同类开源项目 —— 智谱 AutoGLM 凭借 “轻量开源 + 手机场景适配” 迅速出圈,而阿里此前 2025.08 发布的 Mobile-Agent-v3(基于 GUI-Owl 模型)却未获得同等关注度(选它仅为举例)。个人理解,这种热度差异并非技术实力的绝对差距,而是技术定位(“手机优先”的轻量化开源 vs “全平台”的重量级框架)、发布时机(踩中“AI 手机风口” vs 提前发布的“认知差困境”)、生态适配(用户需求驱动 vs 技术能力驱动)等共同作用的结果,这里不再展开表述。
豆包 AI 手机黑盒分析
当前手上没有豆包手机及其助手,下面运行示例和原理分析均来自网络。
运行示例
Gif 来自文章自费购买,把豆包AI手机当主力机3天,我的真实体验有些不同,可直接查看。
- 借壳努比亚,操作系统可能自研。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 自主生成优化),同时能动态编排前端界面元素实现透明化交互(前端界面动态编排)。比如
- GUI Agent 感知前端交互需求,向 API Agent 发起接口生成 / 优化请求;
- API Agent 返回适配接口后,GUI Agent 自动编排前端组件完成交互落地;
- 二者通过状态同步接口实现全流程闭环。
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