最近好多人在聊一个话题AI 智能体开始操作真机了。过去一年智能体大多数活在对话框里——你问它答、你让它检索资料顶多帮你调几个 API。而现在一批基于视觉大模型的智能体开始真正接管屏幕拿到一部真机截图、理解界面、点击、滑动、输入像人一样把一整套流程在真实设备上跑完。这个变化不是渐进式的是能力层面的一次跨越意味着智能体从信息处理层下沉到了物理操作层。这篇文章我结合自己折腾过的几个方案——有开源框架也有像扣子这种低代码平台把这件事拆开讲讲真机操作智能体的技术链路是怎么搭起来的、现在到底能干什么、哪些事它还干不了以及如果自己想搭一个模型怎么选、参数怎么配、坑在哪里。各位产品经理、测试工程师、自动化开发还有所有关心 Agent 落地的人这篇应该能给你省不少时间。1. 智能体操作真机这件事本质是在解什么题1.1 核心链路就三层看懂屏、想清楚、做得动所谓操作真机和传统 API 调用的自动化完全是两码事。API 自动化走的是接口层App 有没有界面、界面长什么样它根本不在乎而真机操作智能体是走人的路线——用眼睛看屏幕用脑子想下一步用手去执行。拆开看就是三层第一层是感知也叫视觉理解层。智能体通过截图拿到当前屏幕画面交给多模态大模型去识别。这一层输出的不仅仅是屏幕上有什么而是当前处于什么状态——是在登录页、首页、还是弹窗挡住了关键按钮。这里面有个很要命的细节同一个 App 在不同机型上界面元素的位置和尺寸差异很大模型必须理解的是语义而不只是像素。第二层是决策也就是规划层。模型拿到屏幕状态之后结合用户给的最终目标拆解出下一步动作。这里最常用的是 ReAct 模式——Reasoning 和 Acting 交替进行每一步先推理当前情况是什么、应该做什么再输出一个具体的动作指令比如点击右上角的登录按钮。决策层的关键限制是上下文窗口和推理深度后面我会详细说。第三层是执行叫动作层。决策层输出的是一段结构化指令比如tap(560, 1240)、swipe(400, 800, 400, 300)或者input_text(zhangsanexample.com)。执行层负责把这些指令真正下发到设备上。安卓上最常用的是 ADB 命令和无障碍服务iOS 上走 Appium 或 XCUITest桌面端可以用 pyautogui 或 Playwright。这一层看似简单实际上是坑最多的地方后面实操部分会展开。三层链路循环往复执行完一个动作立刻再截图继续看-想-做直到任务完成或者触发终止条件。整个过程就像一个戴着 VR 眼镜的实习生看一眼屏幕、点一下鼠标、再看一眼一步一步把活干完。1.2 为什么偏偏是现在才火起来真机操作这件事本身一点都不新鲜。RPA机器人流程自动化十几年前就在做屏幕自动化了Appium、UiAutomator 这些测试框架也成熟了快十年。那为什么直到今年大家才觉得智能体操作真机是个大事核心变量是大模型的三项能力同时到位了。多模态理解能力到位了。过去做屏幕自动化靠的是 UiAutomator 这类工具去 dump 界面层级 XML但很多 App 的界面是高度自定义渲染的XML 里拿不到有效信息或者拿到一堆无意义的动态节点传统 RPA 只能靠坐标硬写换个机型就废。现在视觉大模型可以直接看图跳过 XML 解析对界面的鲁棒性提升了一个量级。工具调用能力到位了。大模型不再只是输出文字而是能稳定输出结构化的函数调用参数。OpenAI 的 function calling 和各家大模型配套的 tool use 能力让模型想点击和代码执行点击之间的桥天然就搭好了不再需要写一堆正则去猜模型输出的意图。推理和指令遵循能力到位了。两年前的模型你跟它说等页面加载完再操作它可能截图后立刻就去点击还在 loading 的按钮。现在主流模型对这类隐含指令的理解力强了很多能基本做到先观察、后行动、再确认。三条能力线汇到一起才让真机操作智能体从 demo 变成了可以认真考虑落地的方案。1.3 真机与模拟器环境差异比想象中大很多人在开发阶段图方便直接用雷电模拟器这类安卓模拟器来调试智能体。我自己也这么干过但踩了不少跟头这里必须说清楚模拟器里跑通的东西搬到真机上大概率要返工。首先是性能差异导致的时序问题。模拟器共享宿主机资源App 启动速度、页面加载速度跟真机完全不是一个量级。智能体在模拟器里可能等 1 秒页面就渲染完了到真机上同样的等待时间连启动页都没过去于是后续所有点击全部错位。其次是系统环境差异。模拟器里没有真实的传感器数据、网络状态、来电和通知干扰智能体不会遇到正操作到一半一个微信通知把界面顶上来了这种真实场景。真机上这类突发干扰恰恰是家常便饭处理不好一次长任务基本就废了。再就是硬件能力差异。模拟器跑在 x86 架构上很多图形渲染路径和 ARM 真机不同截图的像素细节、控件边缘的锯齿程度都不一样。视觉模型在模拟器截图上学到的界面特征到了真机截图上的噪点一多识别效果可能直接掉几个点。所以我现在的建议很明确开发阶段可以用模拟器搭链路、调流程但最终验收必须上真机并且至少覆盖两三款不同厂商的机型别偷懒。2. 现阶段真机操作智能体能做什么2.1 手机端最有价值的三类落地场景从我自己试用和观察到的案例来看手机端的真机操作智能体目前集中在三类场景。第一类是自动化测试。这是最成熟的方向。传统的 UI 自动化测试需要为每个用例手写选择器和流程维护成本极高。现在的主流做法是让智能体根据一句自然语言描述——比如走一遍注册流程填写手机号、获取验证码、设置密码、完成注册——自己生成操作路径。像华为云推出的码道检视修复智能体在代码场景能做到 91.3% 的召回率说明AI 驱动自动化在真实工程环境里已经不是概念了而是有明确数字指标的生产力工具。第二类是跨应用的重复性操作。比如自动整理手机相册、批量导入联系人、把某平台的订单同步到另一个应用里。单个操作不复杂但跨应用之间的状态切换和信息搬运非常耗人工智能体恰恰擅长这种不需要创造力但需要耐心的活。第三类是业务操作辅助。门店营业员拿起手机按智能体指引完成会员录入、库存盘点确认、售后工单流转。这种场景的特点是对操作准确性要求没那么变态但对不培训就能上手要求很高智能体把操作变成看着界面自己走本质上降低了业务流程对人工经验的依赖。2.2 桌面端与代码场景的进展桌面端的真机操作智能体热度不亚于手机端。办公场景里最典型的是读取邮件附件里的 Excel → 提取关键字段 → 填入客户管理系统 → 给对应负责人发邮件这类跨应用流程。传统 RPA 做这种事需要提前录制流程、定义好每个字段的位置遇到界面改版就崩智能体打开屏幕就能干活界面变了它也能重新识别这是代际差异。代码场景更值得一提。华为云那类检视修复智能体做的事情本质上也是操作真机——它运行在真实的代码仓库上读取代码、定位问题、生成修复建议甚至直接提交 MR。这个方向的意义在于智能体开始对真实生产环境产生直接作用而不只是在一个沙盒里做演示。企业内部的代码评审、安全扫描、合规检查这些以往必须由人工在真实系统上完成的高成本工作恰恰是智能体最值得切入的增量空间。2.3 内容与电商场景确实有人用它干活热搜里有一条扣子 AI 智能体可以做跨境电商图么说明内容生成与电商运营结合是需求量很大的方向。说句实在的纯做图的能力智能体确实有主流多模态模型都能做到文字生成图像、背景替换、商品图美化。但这里有一个很多人忽略的真相——智能体真正的价值不是做图而是做完图之后还能自己把图传到商品后台、设置尺寸、填好 alt 文案、走完整个上架流程。这才是操作真机在电商场景里的杀手应用。我见过有人用智能体处理一天几百个商品的批量上架截图、识别商品信息、填表、上传图片、提交审核全程不需要人碰电脑。中间遇到某张图尺寸不对智能体还能自己裁剪重传。这类活以前要么养一个运营每天机械操作要么花大价钱定制 RPA 脚本现在一个带视觉能力的智能体就能覆盖大部分。不过我也得泼一盆冷水目前这类应用在批量化稳定跑上还有距离跑个几十个商品没问题跑到上百个就会出现各种意外状态后面第 3 节详细讲。3. 做不到的事能力边界要认清3.1 视觉理解的天花板比想象中低很多人以为大模型能看图 大模型能看懂屏幕这是一个严重的误解。真实屏幕上的信息密度极高而且大量信息是动态的——比如一个按钮没加载出来之前和后加载出来视觉上可能只差几个像素的透明度和纹理再比如视频播放中的画面、不断滚动的数据列表截图只能捕捉某一瞬间模型无法感知前后帧的变化。我实测过让智能体操作一个列表持续刷新的资讯 App它经常会对着一个不断变化的位置反复误点。另一个问题是空间关系的理解。截图是二维的而真实界面有层级、有滚动、有浮层。模型常常分不清这个按钮现在是被弹窗挡住还是本来就在这个位置。腾讯、阿里这些大厂内部都在堆这种数据做专项训练说明这是公认的难点不是换个更大的模型就能轻易解决的。3.2 长流程里的上下文衰减是真正的拦路虎如果你让智能体做一个三两步的小任务比如打开设置把蓝牙关掉现在的主流模型基本都能稳定完成。但如果是整理相册把所有带文字的截图归类到截图文件夹再把多余的照片上传到网盘这种需要二十步以上的任务失败率会急剧上升。原因在于上下文窗口。每一步截图是一张高分辨率图片token 消耗非常大模型能记住的上下文是有限的。走个十几步之后前面的操作就淡出了注意力智能体会出现重复点击已经点过的按钮忘记任务目标开始随机操作这类让人哭笑不得的行为。目前业界用的补救方案是给智能体加一个记忆模块——定期把关键状态写成文字摘要存下来需要的时候再检索。这确实有效但也增加了一层工程复杂度不是开箱即用的能力。3.3 权限、安全与不可逆操作的硬约束这条必须给所有打算上真机的人提个醒。智能体操作真机本质上是把设备控制权交给了一个模型而这个模型并不总是可靠的。它可能在点击删除按钮时毫不手软可能在支付页面上直接点了确认付款。我自己有一个原则凡是涉及资金、删除、发布、发送这类不可逆操作必须在流程里加一道人工确认闸门。具体做法是在智能体的动作列表里加一个动作类型叫require_confirmation模型一旦判断下一个动作是高危操作就暂停执行并把当前界面截图和即将执行的动作发给管理员确认。别嫌麻烦这个机制救过我很多次。权限安全同样要重视。安卓端要让智能体执行点击和滑动最常见的方式是使用无障碍服务AccessibilityService但这个权限能读到屏幕上所有内容包括你在其他应用里输入的密码。如果智能体的底层模型是云端 API意味着截图数据会传到第三方服务器——商业机密、个人隐私这些合规问题在真机操作场景里是全量暴露的。有条件的话建议用端侧模型处理敏感设备的截图或者至少做一层敏感信息脱敏。3.4 反自动化检测与业务风控绕不开智能体操作真机还有一个现实障碍很多应用本身就在严防自动化。验证码只是最基础的一道更麻烦的是行为层面的风控——如果系统检测到你的操作节奏过于规律、点击轨迹过于笔直、停留时间过于均匀就可能触发风险控制。市面上有些教程教人通过改模拟器环境来伪装真机什么雷电模拟器改真机环境之类的说白了就是改设备指纹参数让风控系统认不出来。我的态度很明确这种思路在灰色地带打转且不说稳定性极差——厂商的风控策略更新一次所有伪装全部失效——本身也处在规则和道德的模糊线上。正经做自动化测试和合法业务自动化的团队应该主动走官方 API、白名单机制或者与业务方协商获得授权而不是把精力花在对抗检测上。智能体操作真机这件事要健康地发展前提就是在合规框架内使用。4. 实操自己搭一个能操作真机的智能体4.1 选型低代码平台还是自研框架如果你想快速验证智能体操作真机这件事两条路线可以选。第一条路线是用低代码平台。以扣子Coze为例它已经把视觉识别、意图规划、工具调用封装成了可视化节点你只需要在画布上连起来一个屏幕截图节点接到多模态模型节点再接一个设备操作节点跑通一个最简单的看屏-决策-执行循环可能一个下午就够了。扣子这类平台的最大好处是降低了门槛适合产品经理、运营人员快速验证想法。第二条路线是自研框架适合有工程能力的团队。核心组件大概是这几块设备管理ADB 连接、镜像投屏、视觉模块截图 多模态模型调用、规划模块ReAct 循环 记忆管理、执行模块输入注入 状态校验。框架上可以参考开源项目的思路——斯坦福的 AppAgent、微软的 UFO、国内一些团队开源的手机 Agent 项目都已经把基本链路趟通了直接在它们基础上改比从零造轮子靠谱得多。我的建议是第一次做先走低代码平台把整个流程和坑摸一遍再决定要不要自研。直接用自研框架起步调试成本会让你崩溃。4.2 关键参数和配置要点不管用哪个方案有几个参数是直接影响成败的。模型选择优先选视觉理解能力强、指令遵循稳定的多模态模型。市面上主流的 Qwen-VL 系列、GPT-4o、Claude 系列都可以跑但实际体验差异不小。手机上中文界面居多国产模型对中文 UI 的理解通常更好一些这个可以自己对比测试。温度Temperature决策链路的温度一定要低我一般设置在 0.1 到 0.3 之间。温度太高模型在点击登录按钮和点击注册按钮之间反复横跳任务根本走不下去。最大步数Max Steps给每一步任务设置上限比如 20 步到 30 步。超过步数强制停止并报告失败防止智能体在一个错误状态里无限循环白烧 token。截图间隔Screenshot Interval每次动作执行后等待 800 到 1500ms 再截图给页面一个渲染缓冲期。太快页面还没反应过来截图是旧的太慢一次任务的总耗时又太长。动作校验Action Validation对输出动作做白名单约束比如坐标必须在屏幕分辨率范围内、滑动距离不能超过屏幕高度、文本输入禁止包含特殊字符。这一步能拦截掉大量低级错误。4.3 一个最小可用流程的搭建步骤我用安卓真机 低代码平台的思路给你一个可以直接抄的搭法。第一步准备设备。开启手机的开发者模式和 USB 调试用 USB 线连接到电脑命令行执行adb devices确认设备在线。这一步如果提示 unauthorized先在手机上确认授权弹窗。第二步建立屏幕通路。在平台上搭一个截图节点调用 ADB 的screencap命令把当前屏幕保存成 PNG 并喂给模型。注意手机分辨率超过 1080p 的话建议先压缩到 720p 再传模型识别精度几乎无损但 token 消耗直接减半。第三步搭决策节点。在模型节点里设定系统提示词你是手机操作助手你的目标是什么、每步必须输出一个 JSON 动作、动作只允许 tap、swipe、text、back 四种类型。这里我踩过的坑是提示词里一定要强调不要假设动作已生效必须根据下一步截图判断。第四步搭执行节点。解析模型输出的 JSON映射到 ADB 命令adb shell input tap x y、adb shell input swipe x1 y1 x2 y2 duration、adb shell input text 内容。文本输入这里有个坑——input text 对中文支持很差遇到中文输入建议用剪贴板方式把文本写入剪贴板再长按粘贴。第五步加循环和终止条件。整个流程包在一个重复直到完成或超时的循环里完成条件可以设为模型输出task_complete状态。第五步做完一个最简可用的真机操作智能体就跑起来了。整个搭建时间顺利的话一天内可以完成。4.4 实操中踩过的坑和心得这几个坑是我和团队实际跑的时候真实遇到的每个都耗了不止半天。第一个坑是坐标偏移。ADB 的input tap用的是绝对坐标但不同手机的屏幕分辨率、系统导航栏高度都不一样。解决方法是每次截图后把图片先等比缩放到一个固定尺寸比如模型统一输入 720x1280模型输出的坐标再按比例映射回真实分辨率。不这么做在 2K 屏手机上所有点击都会偏下偏右。第二个坑是中文输入。上面提过input text不支持中文直接打印乱码。我后来是这么做的先用 ADB 把文本通过剪贴板方式设置进去再模拟一次长按弹出粘贴菜单。但长按弹出菜单这个动作在原生键盘和第三方输入法上的表现不一样需要做适配判断。这个问题没有完美解只能尽量让流程少依赖中文输入。第三个坑是弹窗拦截。几乎所有国产应用都有开屏广告、隐私协议弹窗、更新提示。智能体跑自动化的时候这些弹窗随时可能把任务中断。我最终的做法是在任务启动前先让智能体做一次环境清理——把所有能关的弹窗、引导页全部关掉再正式进入任务。这能显著提升成功率。第四个坑是权限回收。安卓系统为了省电会定期回收后台应用的权限无障碍服务有时会莫名失效。跑长任务前必须加一次服务存活检查发现服务掉了就自动重启不然中途一下就断了。5. 常见问题与排查技巧实录5.1 高频问题速查表问题现象可能原因排查方向截图正常但点击没反应坐标映射错误或页面未加载完检查分辨率映射、增加截图前等待模型反复输出相同动作上下文衰减或页面状态未变化缩短任务步数、增加状态变更检测中文文本输入乱码ADB input text 不支持中文改用剪贴板 长按粘贴方案某机型上界面识别率明显下降分辨率、字体大小、深色模式差异换机型测试、统一截图预处理参数任务跑到一半无障碍服务失效系统回收后台服务加服务存活检测与自动重启模型把不可逆操作识别为普通操作提示词缺少高危操作预判增加高危动作拦截清单并强制人工确认token 消耗远超预期截图分辨率过高、步数限制过大压缩截图、收紧 max steps、缓存相似截图5.2 三个屡试不爽的排查技巧第一个技巧是截图回放。任务失败之后把整个流程里所有截图按时间顺序排列回放一遍十有八九一眼就能看出问题在哪一步出的错——是页面没加载完就开始点还是弹窗把按钮挡住了。这个技巧特别朴素但很多人失败后只看日志不看截图方向就错了。第二个技巧是分阶段验证。不要一上来就跑完整任务。先把感知层单独测——只让模型描述屏幕看能不能准确识别状态再测单步决策——给一个截图让它输出一步动作最后才测完整循环。这样定位问题非常快能省掉大量调试时间。第三个技巧是给模型看差异图。如果智能体反复在同一个页面犯错把正常截图和异常截图叠成差异图喂给模型同时问它这两个界面的关键区别是什么往往能逼出模型忽略掉的细节。这招在排查模型以为按钮在 A 位置但实际在 B 位置这类问题时特别有效。6. 我的判断下一步往哪走老实说真机操作智能体现在处在能用但没那么好用的阶段。单步操作的可靠性已经相当高复杂长流程的稳定性还需要大量工程打磨。接下来的几个方向我个人判断会快速成熟一是专门的 UI 操作评估基准和数据集让模型在屏幕理解上有可量化的进步目标二是端侧模型上真机解决截图数据隐私和延迟问题三是智能体 人工的协同模式固化下来让 AI 干 90% 的体力活、人只负责 10% 的关键判断。如果你想入局我建议别等所谓完全成熟先用低代码平台跑一个最小闭环亲手体会一遍从模型说要做到真机真的做了的全过程。那个时刻的感受比任何行业分析都更能帮你建立对这件事的判断。我自己第一次看到智能体在真机上独立完成一整个流程时沉默了好几秒——那一瞬间你会清楚地知道这真的不是另一个聊天机器人级别的进步。