智谱 AutoGLM：让模型替你点手机屏幕

大多数 AI 产品给你一段回答，AutoGLM 给你一次操作记录：它打开了哪个 App、点了哪里、填了什么、最后停在哪一页。这个差别决定了它解决的不是"想不想得到"，而是"愿不愿意自己去点"。

它做的事情，是替你在屏幕上动作

装好之后要开三个权限：无障碍、悬浮窗、录屏。无障碍让它能模拟点击和输入，录屏让它能看见屏幕内容，悬浮窗用来随时中断。这三项是它工作的前提，也解释了它的能力边界——凡是系统不允许无障碍接管的地方，它都做不了。

任务下达之后，它做的第一件事是把一句话拆成步骤。比如"帮我订一杯附近评分最高的美式"，会拆成：打开外卖应用、定位、搜索咖啡、按评分排序、进店选品、加购、结算。然后逐步执行，每一步执行完都重新看一眼屏幕，确认页面确实变了，再决定下一步。

这个"看—做—验"的循环，是 GUI Agent 和 API 调用的根本区别。API 是确定性的：调一个接口，返回一个结果。GUI 是不确定的：按钮位置会变、弹窗会插进来、加载会变慢。所以它必须每一步都重新观察，而不能把整套动作预先写死。

为什么它跑在云端的手机上

AutoGLM 的执行环境是一台云端设备，不是你的手机本地。这带来两个直接好处：不占本地算力，任务跑着的时候你还能正常用手机；以及跨应用切换更稳定，不会因为你切走而被打断。

代价是登录态。云端设备要能操作你常用的 App，就得在上面登录；授权弹窗、短信验证这些环节会频繁打断流程。官方的建议是提前在云手机里登录好常用应用，减少中途授权。这句话背后的现实是：跨应用自动化的难点不在点击，而在身份。

另一个现实限制是平台。目前它以 Android 与网页为主，iOS 端能力受限；微信这类对自动化有严格限制的应用，部分操作（比如直接发消息、转账）并不支持。这些不是暂时的 bug，而是平台策略决定的边界。

三个必须停下来的位置

图 1　执行环与三个必须由人接手的位置

支付、验证码、隐私授权，这三类操作它会停下来等人确认。这个设计不是产品保守，而是必要：一旦让模型自主完成支付，责任归属就说不清了。

对使用者来说，这意味着"全自动"其实是"半自动"。你可以让它把商品加进购物车、把信息填完，但最后一步付款要自己点。理解这一点，才不会对它的能力产生错误预期。

对设计者来说，这也是一条可复用的经验：Agent 的自主度不是越高越好，而是要在"不可逆的动作"前面设卡。关于这条原则，OpenAI 对失控 Agent 的处置机制讲得更系统。

它擅长什么，不擅长什么

擅长的是三类事。

一是生活里的琐碎操作：点外卖、打车、订酒店、查快递、比价。这些事单次耗时不多，但频率高、打断注意力。

二是跨应用的长链路：一个任务要在三个 App 之间来回，人做起来最烦的就是切换，它反而没有切换成本。

三是重复性的界面操作：每天固定时间签到、领券、批量点赞这类，配好一次可以反复跑。

不擅长的是另外三类。

一是高频稳定的流程。如果一件事每天要跑几百次、且接口可用，那应该用 API 和自动化平台，而不是让模型去点屏幕——后者的成功率和成本都不划算。这类需求的正确工具是 n8n 这样的执行层。

二是对时效敏感的操作。抢票、秒杀这类场景，界面操作的延迟是硬伤。

三是需要判断的复杂任务。它能把步骤执行完，但"该不该买""这个价格是否合理"仍然要人来定。

和另外两类 Agent 的区别

和编码 Agent 比，它操作的是界面而不是代码库；前者依赖版本控制和测试来验证，后者依赖屏幕和人工确认。两者的可靠性来源完全不同。

和通用任务 Agent 比，它的边界更窄但更硬：Manus 那类产品交付的是文件和报告，AutoGLM 交付的是"某件事在某个 App 里被做完了"。一个偏信息加工，一个偏界面执行。两者都会有"跑完了但结果不对"的情况，但排查方式不同——前者看来源，后者看录屏。如果需求其实是"把一套流程固化成能反复跑的服务"，那既不该用它，也不该用通用 Agent，而应该看扣子这类可编排的平台。

值得先想清楚的一件事

这类工具最容易被误用的地方，是把它当成"全自动助手"。实际上它的价值在于"帮你把不想点的步骤点掉"，而不是"替你做决定"。

如果你的日常里有大量重复的界面操作，它能省下真实的时间；如果你期待的是"说一句话，所有事都办完"，那大概率会失望——不是因为模型不够强，而是因为支付、验证、授权这些环节，本来就不该交给机器。

AutoGLM 目前在中国区免费开放，这在国产 Agent 里并不常见。免费意味着可以低成本试错，也意味着它的定位更偏"先让用户用起来"，而不是"先卖订阅"。对使用者来说这是好事：你可以用一周时间，看看它到底能替你省下多少点击。