大模型驱动手机操作：AutoGLM智能体从屏幕理解到自主执行

2024年下半年AI自动操作手机这件事突然从一个实验室概念变成了普通人也能直接上手试玩的东西。我在拿到AutoGLM的体验资格之后第一反应不是“哇好酷”反而是松了一口气。因为我之前试过用无障碍服务写脚本自动打卡、自动同步数据那种维护成本高到怀疑人生几乎每次App改版都要跟着改一遍选择器。但凡你经历过这种“为一个简单的自动点击写几百行脆弱代码”的痛苦就会立刻明白——一个能看懂屏幕、自己决定怎么点的AI Agent到底解决的是什么层面的问题。AutoGLM来自智谱AI定位很明确手机上的自主智能体。它跟传统语音助手的最大区别是你能用一句自然语言让它完整操作你的手机。比如“帮我把这条消息里的地址提取出来存到备忘录里”它会自己打开微信、定位到目标会话、截图识别内容、跳转到备忘录、新建笔记、把地址粘贴进去、保存。整个过程不需要任何人工介入。这篇文章我会把它里面几个关键问题拆开讲AutoGLM在手机智能体赛道里到底承担什么角色实际跑起来表现如何它背后的“屏幕理解”和“操作决策”大致是什么逻辑以及现阶段有哪些让人又爱又恨的边界。如果你在做AI Agent相关方向的产品或者纯粹想了解大模型怎么控制手机这篇内容应该能提供一个比较完整的参考视角。1. AutoGLM想解决的核心问题为什么“能聊”不等于“能办”1.1 手机操作智能体的行业位置过去几年我们见过太多“对话式AI”产品你问它天气它查API你问它某家餐厅评分它给你一段摘要你说“帮我设个明天七点的闹钟”它调系统接口把闹钟建好。这类能力本质上都是“自然语言转API调用”没有跳出软件边界。但真实生活里的大量需求根本没开放接口。比如你想把微信聊天记录里的待办事项整理成一张表格想让人工客服少填几个表单想在钉钉里批量审批流程——这些操作依赖的具体界面、按钮位置、交互流程全是各自App私有的。没有API给你调用也没有统一标准可以套。AutoGLM的思路是绕开API这层直接模拟一个“人”去操作手机。它把手机屏幕当作环境输入把点击、滑动、输入当作执行动作用大模型的语言理解和视觉理解能力替代传统脚本里的规则和选择器。这个方向在业内一般叫“UI Agent”或者“手机操作智能体”也是大模型从“对话工具”走向“行动代理”的关键一步。1.2 比起无障碍脚本、RPA这类方案到底强在哪做移动端自动化的人对下面三条技术路线应该都不陌生无障碍服务脚本通过读取控件树拿到按钮ID和文本再用系统接口模拟点击。运行效率高但相对脆弱。App只要改个资源ID或者把TextView换成了自定义View脚本当场失效。而且很多App的核心区域根本不在无障碍树节点里暴露。移动端RPA通过录制操作轨迹、识别界面元素来执行任务胜在稳定但部署成本高定制门槛高更适合企业内部对少量标准化业务流程做自动化普通用户很难自己搭一套。云真机/群控批量控制大量手机常见于测试或批量账号运营场景。它更多是“并发操作同一套动作”不是针对每个用户的实际意图动态调整。AutoGLM这一类视觉驱动智能体的优势在于它摆脱了对控件树和固定规则的依赖。它只看屏幕图像通过模型判断“这里的‘发送’按钮是一个可点击的元素”。哪怕App改了布局、换了图片、按钮没有文字只要视觉上依然像“发送”模型就能猜出来。这种基于语义理解的泛化能力是传统自动化脚本完全不具备的。2. 真实跑一遍AutoGLM在手机上执行任务的长什么样2.1 装好环境前的几个关键权限AutoGLM目前集成在智谱清言App里Android端用起来比较顺手。首次使用需要先打开辅助功能权限和通知读取权限。辅助功能权限是它执行操作的基础。Android系统要求应用在“无障碍服务”里声明自己能看到的窗口类型用户授权后AutoGLM才能拿到界面交互能力。系统弹窗的措辞比较吓人大致是“该应用可以监控并操作你的屏幕”这主要针对恶意软件设计的安全提醒。如果你比较在意隐私我的建议是只在需要测试的时段开启用完就关保持最小授权原则。通知读取权限用于感知一些异步状态。比如打车App弹出“司机已到达”这种系统通知时模型需要把它当成任务推进的触发信号。没有这个权限它就只能靠轮询截图来猜。2.2 三个让我印象深刻的真实场景拿到之后我试的第一件事是让它“帮我在大众点评里给刚才那家餐厅写一条五星好评”。这句指令跟日常说话完全一样它确实一步一步往下走了解锁屏幕、打开点评、搜索餐厅名、点进商户主页、选择评分、跳转到评价输入页、在输入框里打出我提前让它准备的评语、提交。第二个场景是统计群聊里某段对话出现的次数。我说的是“看看咱们昨天在群里聊了多少条关于‘预算’的消息”。它打开微信找到对应的群往上翻聊天记录逐屏截图识别文字最后圈出关键内容汇总数量。虽然中间有一次滑动过头又反向滑了回来但整体结果是对的。第三个是跨App操作也是最考验模型的一环。我让它“把相册最近一张截图发给微信置顶联系人并附一句话‘这是你要的资料’”。它需要先在相册定位最新截图再跳转微信找到置顶联系人唤醒会话输入框把图片以“非原图”形式发送再补一条文字消息。这条链路跨了两个App、涉及五个以上中间状态中间任何一步点错都会导致任务失败。它完成得不算完美但确实走完了整个流程。2.3 失败和翻车哪些环节最容易出错体验过程中最常翻车的点是界面元素没有明显视觉特征的时候。比如某些页面的“确认”按钮是一个纯色无边框的圆角方块模型看不出它是按钮再比如弹窗和下半屏遮罩同时出现模型容易忽略被遮住的关键信息导致下一步点在了错误位置。高频坑还有输入法的联想词。大部分中文输入法都有候选词条AutoGLM在输入过程中如果误点了联想框里的某个词后面整段文字都会变。它不是每次都能意识到打错了然后自己修正在长文本输入时尤其明显。第三个是加载等待判断。模型点了按钮之后屏幕不是立刻刷新。如果按钮触发了网络请求页面短暂停留在旧界面模型可能误以为点击没有生效于是又点了一次结果造成重复提交。3. 拆解工作机制屏幕是怎么被“看懂”的操作又是怎么被决定的3.1 屏幕语义地图视觉感知的输入转换AutoGLM对屏幕的感知底层是视觉语言模型。输入是当前屏幕截图输出是对屏幕内容的结构化理解。这个过程有点像人看一眼新App界面能在几秒内判断出“哪里是标题、哪里是按钮、哪里是列表数据”。模型要完成的不只是“认字”还包括空间关系理解。比如“购物车”图标通常位于底部Tab栏右侧“发送”按钮通常在输入框右下方“更多”菜单通常藏在右上角的三个点里。大模型在前置训练阶段积累了海量屏幕认识经验所以迁移到新App上也能猜个八九不离十。专业点说它会把手机屏幕划分成空间网格结合文字识别与图标理解构造出一张“屏幕语义地图”。地图上每个区域被标注了功能语义比如“这是一个可点击的头像”、“这是可编辑的文本输入框”、“这是当前页面的广告区域应忽略”。有了这张语义地图模型就能在复杂的真实界面中找到任务相关元素。3.2 基础行动空间能做的操作其实就那几类AutoGLM的行动空间并不是一个无限制的自由动作集合它主要依赖Android系统无障碍服务提供的基础操作权限。归纳下来大致是点击类单击、长按、双击。单击是最常用的长按用于唤出上下文菜单或移动图标双击在部分图片缩放场景会用到。滑动类向上/向下滚动、向左/向右翻页、指定坐标滑动。上下滚动几乎贯穿所有长列表任务。输入类文本键入、删除字符、回车触发搜索。输入法联想词的问题是自动输入时最大的干扰项。系统类返回键、Home键、多任务切换、屏幕唤醒与关闭。这几类基础动作恰恰覆盖了人操作手机的绝大多数手势。AI能把它们组合用好就已经足够完成大部分日常生活场景中的UI任务。值得留意的是模型每次决策只选择其中一个动作而不是一次生成一长串连续操作这样可以随时根据屏幕变化调整策略。3.3 感知-行动循环长任务是靠多步决策串起来的当用户给出自然语言指令后AutoGLM会经历这样一个工作循环感知截取当前屏幕视觉模型分析得到屏幕语义地图。推理结合原始任务目标和当前状态判断下一步应该做什么。执行调用无障碍服务执行对应的点击、滑动或输入动作。观察等待一定时间后再次截图确认操作是否生效。如果页面没有变化则回到第二步如果任务已完成则结束。这套循环跟人类操作手机的过程有相似之处看一眼屏幕决定点哪里点了之后再看一眼变化调整下一步。为了降低长链路任务的错误累积模型还会在关键节点做确定性检查。比如输入完文字后它可能会再拖动一下屏幕确认输入框里的内容和预期一致才继续下一步。从模型架构角度看这是大模型套上一层“执行器”和“观察器”形成的智能体闭环。执行器负责把模型输出的动作翻译成系统指令观察器负责把新屏幕状态反馈给模型。两者协同才能支撑起十几步、几十步的长链条任务。4. 真实使用中的边界、踩坑与规避策略4.1 误触、重复点击与“看不见的按钮”误触是这类方案目前最难彻底解决的问题。我遇到过的典型情况是页面上有悬浮窗广告把真实的关闭按钮盖住了模型识别到“关闭”二字但点下去的坐标其实是广告热区结果跳转到了推广页。另一个情况是按钮点击后页面有短暂动画过渡模型在动画未完成时又截了一次图误以为点击没生效于是重复点击。应对策略是任务描述里尽量加入“等待页面内容加载完成后再继续”这类约束同时保持网络环境的稳定。手机端也建议关闭所有可能弹出悬浮窗的应用比如各种加速球、悬浮收割机、消息气泡。我发现只要把前台应用通知权限关闭误触率会明显下降。4.2 长文本输入的失控瞬间让AutoGLM输入长文字是最容易出现“灾难现场”的场景。它每键入一个字符输入法都会弹出联想候选词模型很容易把第一个候选词当成自己输入的扩展结果一段话越打越长语义完全跑偏。我自己试过让它“把这段三百字的产品简介打到备忘录里”结果有一个地方误触了候选词整段文字变成重复句和无意义符号的拼接。模型删除部分字符后尝试自行修复但越修越乱最后我只能手动终止。解决思路是把长文本放在任务描述里作为明确上下文让模型理解“完整输出不要依赖输入法联想”或者在输入前先关闭输入法的个性化联想功能。目前AutoGLM对输入法联想的防御能力依然有限短期建议用短文本高频场景为主。4.3 隐私、授权与安全操作边界手机操作智能体的权限相当于拿走了你对手机的完全控制权。因此隐私和安全一定是优先于体验的。我给自己定了一条规则涉及密码输入、支付确认、验证码获取、人脸识别这类场景一律手动操作。下面的原因很现实——模型面对一个“同意并继续”的按钮它判断的是“这个元素是否点击能推进任务”而不会衡量点击之后的法律风险或隐私后果。在某些极端场景下它可能为了完成任务在一个无关页面上替你点了一个“同意”协议而这些恰恰是你最不想同意的那个。从产品角度AutoGLM这类工具也正在做一些安全策略。比如检测到输入框类型为密码时主动停止向云侧请求或者要求用户手动输入。但从使用者的角度最稳妥的做法永远是“把AI放在普通任务区把敏感操作留在自己手里”。4.4 系统版本与App兼容性的隐性差异不同品牌、不同Android版本对无障碍服务的支持差异很大。一些国产定制系统会在后台限制无障碍服务的运行导致AutoGLM执行到一半与系统服务断开连接进程被系统“智能化”杀掉。而且部分App会针对辅助功能服务做反制比如检测到开启无障碍时拒绝展示某些页面内容或者强制启用本地加密组件。这种兼容性问题没有银弹只能具体设备具体调试。如果你在某个特定机型上频繁失败可以先检查辅助功能服务是否仍然连接、系统是否开启了省电策略、App是否处在后台受限列表中。这三个原因占到了我实测环境里将近八成的中断问题。5. 思路延伸围绕手机智能体还有哪些可做的方向5.1 个人效率自动化的新玩法对我来说AutoGLM最大的价值是让我看到了个人效率工具的新边界。过去我想在手机上实现“每天定时聚合了几条新闻摘要发给自己”项目维护周期短则三天长则三周遇到App界面调整就废了。现在基于手机操作智能体我可以把需求描述清楚让模型自己适应界面变化免去了维护之苦。你可以尝试几个方向跨App信息聚合让AI去不同App里读取数据汇总后写入备忘录或表格。定时任务虽然没有到自动化调度器的程度但结合系统闹钟或通知入口也能实现相当程度的定点执行。重复工作批处理比如连续给多个联系人发送同一段说明文字、批量查看群消息摘要这类任务只要描述足够明确模型的完成度会远超预期。5.2 产业应用的可能性从行业视角看这类手机操作智能体的想象空间非常大。客服行业提到的“人机协同”很多时候不是机器人直接回答问题而是人工客服需要同时打开多个系统查询信息、录入工单。如果能用操作智能体替代这些繁琐的界面操作客服只需要负责审核和异常处理效率提升会非常显著。另一个方向是移动端UI回归测试。现在移动端自动化测试仍然靠脚本框架用例维护成本高且对界面改版敏感。视觉驱动的智能体能天然降低这类成本因为它判断的是屏幕视觉语义而不是绑定控件ID。新一代自动化测试工具很可能会走向“用自然语言描述测试步骤让智能体自动执行”的方向。还有一个值得关注的方向是老人与残障人士的智能辅助。对视力障碍或行动不便的用户来说自动操作手机的帮助不是“少点点几次屏幕”而是“很多事情真的能独立完成了”。这个群体的需求被长期低估。5.3 模型层与系统层的演进方向站在更长远的角度手机操作智能体的瓶颈不在模型智商本身而在执行环境的高度动态性。业内大概在往这几个方向推进更细粒度的屏幕理解区分当前页面的主内容区和广告区识别动态视频画面和静态UI元素的边界。记忆与反思机制让AI在任务失败之后能主动调整策略而不是机械地重复同一操作。也包括跨会话记忆比如记住用户偏好使用哪种输入法、哪个界面布局。端侧推理能力把更多视觉理解和决策推理放到手机本地跑减少截图上云的延迟与隐私风险。Arm平台的算力持续提升端侧小模型会越来越可行。操作系统层面Google和各家厂商也在探索更规范的“智能体接口”。将来如果系统原生提供应用能力描述和可控操作API而不再靠无障碍服务模拟人手调度这类工具的能力上限还会再上一个台阶。站在当前阶段回看手机智能体给出的真实价值从AutoGLM发布到现在我自己的判断没有变过手机AI操作已经进入“日常可以帮忙但需要监督”的阶段。如果你抱着用它完全代替手机操作的想法大概率会失望但如果你把它视作一个能替你执行重复、琐碎、低风险任务的AI同事把注意力放在需要决策的事情上体验会好很多。最后分享一个非常实用的小技巧关键任务执行前把手机调成“不熄屏”状态并关闭所有可能弹出悬浮窗的应用。AutoGLM在任务执行中如果突然遇到来电、通知横幅或者系统更新弹窗外部干扰很容易让模型判断失焦轻则中断任务重则整条链路跑偏。我在实际测试中踩了几次坑之后已经习惯性地在任务前开启专注模式。这类细节官方手册不会写但恰恰是决定实际体验好坏的隐藏因素。如果你正准备做类似的手机智能体产品我的建议是先想清楚一个问题解决什么场景下的什么问题比上多复杂的算法更重要。AutoGLM这类方案真正的护城河从来不只在于模型有多聪明还在于对用户场景的理解深度、对失败情况的兜底能力以及对安全边界的清醒认知。技术会持续迭代但这条路上最值钱的永远是那些用最朴素方式解决了真实问题的环节。