1. 当智能体第一次摸到真机它到底在摸什么很多人对AI 智能体操作真机这件事的第一反应是不就是自动化脚本换了个壳吗以前用 Appium、用 Playwright、用影刀现在换成大模型来驱动本质不还是点按钮、填输入框、滑屏幕这个判断对了一半。传统自动化脚本的核心是我预先知道每一步该点哪里坐标写死、控件 ID 写死、流程写死一旦界面改版、弹窗顺序变化、网络加载慢半拍脚本立刻崩。而智能体操作真机的核心变化在于它不再依赖预先写死的路径而是靠看当前屏幕 理解任务目标 决定下一步动作这个循环来推进。这个差别听起来只是实现方式不同实际影响是数量级的。我拿一个真实场景举例给一个购物 App 做搜索商品、加入购物车、走到结算页但不付款的流程验证。传统脚本要处理登录态、首页弹窗、搜索框定位、结果列表滚动加载、商品详情页的规格选择、加购成功提示、购物车角标更新……每一步都要单独写定位和等待逻辑维护成本极高。而智能体模式下你只需要告诉它目标它自己截图、识别当前处于哪个页面、判断下一步该做什么。界面小改版对它来说往往不构成致命打击因为它本来就不是靠固定坐标活的。但这里必须先把预期拉正智能体操作真机目前能稳定做的是有明确终态的短流程任务做不到的是长链路、强状态依赖、需要精确数值判断的复杂业务。这个边界如果不清楚上手就会踩大坑。我见过太多团队一上来就想让智能体跑完整的下单支付链路结果卡在验证码、卡在风控、卡在支付密码最后得出这东西不能用的结论。问题不在智能体在于任务选错了。这篇文章我想把这件事讲透智能体操作真机的技术底座是什么、它和传统自动化框架的本质区别在哪、哪些任务现在就能落地、哪些任务现阶段别碰、以及真上手时那些文档里不会写的坑。适合正在评估这类方案的测试工程师、自动化从业者以及想用智能体做重复性手机操作的产品和运营同学。2. 智能体操作真机的技术底座拆解2.1 从坐标驱动到感知-决策-执行闭环传统自动化的执行模型是线性的脚本第 1 行找元素 A第 2 行点击 A第 3 行等待元素 B 出现第 4 行输入文本……它假设世界是按剧本走的。智能体的执行模型是循环的通常叫Perceive-Act 循环或者更完整的ReActReasoning Acting模式观察当前屏幕状态结合任务目标做一次推理输出一个动作执行动作后再观察新状态如此往复直到任务完成或判定失败。这个循环里最关键的三个能力是屏幕理解、动作空间定义、终止条件判断。屏幕理解决定了它看得懂多少——是把界面当成一张图去理解还是能拿到控件树的结构化信息。动作空间决定了它能做什么——是只能点击和输入还是能滑动、长按、返回、多指操作。终止条件决定了它什么时候停——是靠模型自己判断任务完成还是靠外部规则校验。我实测下来屏幕理解这一环是决定成败的分水岭。纯视觉方案只给模型截图在界面元素密集、文字小而多的情况下识别率会明显下降尤其是列表项里那些长得几乎一样的条目。而如果能同时拿到系统的控件树类似 Appium 的 page source把结构化信息和截图一起喂给模型定位准确率会有肉眼可见的提升。这也是为什么现在主流的真机智能体方案底层往往还是复用了 Appium、Maestro 这类成熟的设备控制层只是在决策这一层换成了大模型。2.2 设备控制层为什么绕不开 Appium 和 Maestro很多人以为智能体操作真机是全新的一套东西其实设备控制这一层几乎没有革命性变化。你要在真机上点击、滑动、输入底层无非是几条路Android 走 ADB 和 UiAutomatoriOS 走 WebDriverAgent 或 XCUITest。Appium 把这些封装成了统一的 WebDriver 协议Maestro 则用更简洁的 YAML 声明式语法做了上层封装对移动端 UI 自动化的支持更轻量。智能体方案通常不会自己重造这一层而是站在这些框架的肩膀上。原因很实际设备连接、驱动安装、权限授予、多设备管理这些脏活累活Appium 生态已经踩了快十年的坑你重新做一遍纯属浪费。所以你会看到很多真机智能体产品的架构是上层大模型决策 中层动作编排 底层 Appium/Maestro 执行。这里有个容易忽略的细节动作执行的延迟和稳定性直接决定了智能体循环的效率。如果每次点击都要等 2 秒才返回结果一个需要 30 步的任务就要跑一分多钟而且中间任何一步超时都会让整个循环卡住。所以底层控制层的超时设置、隐式等待、元素可见性判断这些传统自动化里的老问题在智能体场景下反而更重要了因为智能体的步数通常比脚本多得多。2.3 大模型在循环里到底负责哪一段把大模型放进这个循环它承担的核心工作是把当前屏幕状态和任务目标翻译成下一个动作。具体来说包括判断当前在哪个页面、识别可交互元素、决定点哪个、决定输入什么内容、判断任务是否已完成。这里有个反直觉的点大模型不需要记住整个操作历史它只需要当前屏幕 任务目标 最近几步的动作记录。因为真机操作是强状态的屏幕本身就反映了历史操作的结果。你点了搜索框屏幕就显示键盘和光标你输入了关键词屏幕就显示文字。所以给模型的上下文里截图和控件树的信息量远大于历史动作文本。我试过把历史动作堆得很长结果模型反而容易被干扰开始回忆一些已经过时的界面状态。另一个关键设计是动作的原子化。不要让模型输出完成登录并进入首页这种复合动作而是让它每次只输出一个原子动作点击坐标 (x, y)、输入文本 xxx、向上滑动、按返回键。原子动作的好处是可验证、可回滚、可重试。如果模型一次输出一串动作中间某步失败了你根本不知道从哪恢复。3. 现阶段能稳定落地的四类真机任务3.1 冒烟测试与回归验证智能体最舒服的战场冒烟测试的特点是流程短、终态明确、对精确数值不敏感。比如打开 App确认首页能正常加载进入个人中心确认昵称显示正常——这类任务智能体做起来非常顺手。它不需要你写任何定位代码只要用自然语言描述目标它自己走完流程并给出结论。我拿一个电商 App 的冒烟场景实测过任务是打开 App搜索蓝牙耳机确认搜索结果页有商品展示返回首页。传统脚本要写搜索框定位、输入、点击搜索按钮、等待结果、判断列表非空、点返回大概 40 行代码界面一改就要调。智能体模式下我把任务描述丢进去它自己完成了整个流程中间还自动处理了一个开屏广告弹窗——这个弹窗在传统脚本里是经典的偶发失败来源因为它的出现时机不固定。回归验证也是同理。每次发版后跑一批核心路径的智能体任务确认主流程没断这个价值很直接。而且因为智能体不依赖固定定位它对 UI 微调的容忍度比脚本高得多维护成本能降下来一大截。3.2 跨应用流程智能体真正拉开差距的地方传统自动化框架最头疼的就是跨应用操作。Appium 虽然支持切换 context但跨 App 的流程编排非常繁琐而且不同 App 的控件体系不一样定位策略要分别处理。智能体在这方面有天然优势因为它本来就是靠看屏幕来决策的从 App A 跳到 App B对它来说只是屏幕内容变了决策逻辑不变。典型场景比如从聊天 App 里复制一个地址打开地图 App 搜索这个地址再回到聊天 App 回复结果。这种流程用脚本写要处理剪贴板、应用切换、前后台状态非常容易出问题。智能体做起来就自然很多它能看到当前在哪个 App知道下一步该切到哪个 App。不过这里有个前提跨应用流程对设备的权限和后台管理要求更高。Android 上要确保目标 App 没有被系统杀掉iOS 上要处理应用切换动画的等待。这些细节不处理好智能体会在切过去发现是白屏的状态下反复重试最后超时失败。3.3 数据采集与信息核对适合结构化程度高的场景让智能体去 App 里采集特定信息比如打开某 App进入订单列表把最近 5 笔订单的金额和状态读出来这类任务在数据结构清晰、页面规整的情况下是可行的。它的价值在于不需要为每个 App 单独写爬取逻辑用自然语言描述要什么就行。但这里必须泼一盆冷水智能体做数据采集的准确率目前还达不到生产级要求。它可能把199.00读成199可能漏掉一条订单可能在滚动加载时重复读取。如果你的场景对数据准确性要求极高智能体只能作为辅助最终还是要靠结构化接口或者人工核对。我个人的经验是智能体采集适合做初筛和巡检比如每天扫一遍关键页面确认没有异常数据而不是做精确的财务对账。3.4 重复性人工操作的替代运营场景的甜点区运营同学每天要做的很多手机操作其实非常适合智能体。比如批量给内容点赞、批量关注、批量发送固定话术的消息、定时签到领积分。这些操作的特点是步骤固定、单次耗时短、重复次数多人做起来枯燥且容易出错。智能体在这里的优势是描述即执行。运营同学不需要懂代码用自然语言把操作描述清楚智能体就能跑。我见过一个内容团队用智能体做多账号的日常维护把原本需要一个人花两小时的操作压缩到十几分钟而且不会因为疲劳漏操作。但这类场景有个红线必须注意涉及平台规则的操作要谨慎评估合规性。批量操作、自动化互动这类行为很多平台是明确限制的。技术上能做不代表业务上该做。这一点在落地前一定要和业务方对齐清楚别技术跑通了结果账号被封得不偿失。4. 现阶段别碰的三类任务4.1 涉及支付和资金的操作这是最硬的一条线。智能体操作真机现阶段绝对不要碰任何涉及真实资金流转的环节支付密码输入、银行卡绑定、转账确认、下单付款。原因有三层第一支付环节通常有额外的安全校验短信验证码、生物识别、设备指纹智能体很难稳定通过第二一旦出错就是真金白银的损失容错成本极高第三很多支付流程有风控系统自动化操作容易触发拦截导致账号异常。我见过有团队想用智能体做下单但不支付的流程验证走到收银台就停。这个边界是合理的因为不涉及真实扣款。但只要再往前一步到确认支付风险就完全不一样了。建议把智能体的操作范围严格限制在只读和无资金影响的动作内涉及钱的环节一律人工接管。4.2 强依赖精确数值判断的任务智能体擅长看个大概不擅长算得精确。比如确认账户余额等于 1234.56 元这种任务智能体可能因为截图清晰度、字体渲染、小数点识别等问题给出错误判断。再比如确认列表里第 3 条商品的价格是 99 元它可能数错条目也可能把相邻商品的价格读串。这类任务的正确做法是智能体负责导航到目标页面精确判断交给结构化数据。也就是说让智能体走到能看到余额的页面然后通过接口或者页面源码提取精确数值用代码做比对。智能体做它擅长的找路代码做它擅长的算数各司其职。4.3 长链路、多分支的复杂业务流一个完整的业务流可能有十几个分支登录态失效要重新登录、弹窗要关闭、网络异常要重试、库存不足要换商品、优惠券过期要重新选……这种复杂度下智能体的决策循环很容易在某一步走偏而且一旦走偏后面全是错的。传统脚本处理分支靠的是 if-else 显式判断虽然写起来烦但逻辑是确定的。智能体处理分支靠的是模型推理灵活但不确定。对于分支多、状态复杂的流程我的建议是拆解成多个短任务每个任务有明确的起止状态而不是让智能体一口气跑完整个业务流。比如把下单拆成登录检查商品搜索加入购物车进入结算页四个独立任务每个任务单独验证失败了也容易定位。5. 真机智能体落地的实操链路5.1 环境搭建设备、驱动、框架的选型顺序上手第一步是环境。我的建议顺序是先确定设备类型Android 还是 iOS真机还是模拟器再装对应的驱动最后选控制框架。Android 真机相对简单装好 ADB、开启 USB 调试、授权即可。iOS 真机麻烦一些需要处理开发者证书、WebDriverAgent 的签名和信任这一步卡住的人最多。如果只是验证智能体能力Android 真机或模拟器是更省事的选择。控制框架方面Appium 生态最成熟、资料最多适合需要精细控制的场景Maestro 更轻量YAML 写起来快适合快速验证。智能体方案如果自带设备控制层通常底层就是这两者之一你不需要重复造轮子但要确认它支持的设备和系统版本范围。提示iOS 真机调试时设备信任和 WDA 签名是最容易卡住的环节建议先用一台设备把链路完全跑通再考虑多设备。5.2 任务描述怎么写智能体才不容易跑偏这是实操中最影响成功率的一环也是文档里最不会写的。任务描述不是越详细越好而是要把目标说清楚把路径留给智能体。反面例子点击首页右上角的搜索图标在搜索框输入蓝牙耳机点击搜索按钮等待结果加载确认有商品。这种写法把路径写死了智能体一旦发现首页布局和描述不符就懵了。正面例子在购物 App 中搜索蓝牙耳机确认搜索结果页有商品展示。目标清晰路径开放智能体自己决定怎么走。几个实操心得第一终态要可验证。确认有商品展示比完成搜索好因为前者有明确的判断依据。第二一次只给一个目标。不要在一句话里塞多个任务。第三对容易歧义的词做限定。比如搜索可能指搜索框也可能指搜索按钮描述时尽量用在搜索框中输入并提交这种无歧义表达。5.3 失败重试与人工接管的设计智能体不可能 100% 成功所以失败处理机制必须提前设计。我的做法是三层单步重试、任务重试、人工接管。单步重试针对的是偶发问题比如点击没响应、页面加载慢。给每个原子动作设置重试次数通常 2-3 次重试时重新截图判断状态。任务重试针对的是整个任务失败比如中途走错页面可以重置到起始状态重跑。人工接管是兜底当重试都失败时把当前屏幕状态和失败原因推给人工让人来决定怎么处理。这里有个细节重试不是无脑重复每次重试前要重新观察状态。如果智能体点了一个按钮没反应直接再点一次可能还是没反应因为它可能压根没点到正确位置。正确做法是重新截图确认当前状态再决定下一步。5.4 结果校验别让智能体自己说我完成了这是最容易被忽略、也最危险的一点。智能体判断任务完成靠的是模型推理而模型是会自信地犯错的。它可能觉得任务完成了实际上只完成了一半也可能觉得失败了其实已经成功。所以结果校验必须独立于智能体本身。做法是任务结束后用代码去检查客观状态。比如任务目标是加入购物车校验方式不是问智能体完成了吗而是去读购物车的商品数量或者检查页面上是否出现了已加入的标识。这个校验逻辑是确定性的不依赖模型判断。我踩过的坑就是早期太信任智能体的自我判断结果它报告任务成功实际购物车是空的。后来加了独立校验才发现它在商品详情页误点了一个相似按钮以为加购成功了。智能体负责执行代码负责验收这个分工不能乱。6. 那些文档里不会写的坑6.1 截图延迟导致的看到的是上一帧智能体循环里截图和动作之间有时间差。如果截图后界面还在变化比如动画、加载模型基于旧截图做的决策就会作用在新界面上导致点错位置。这个问题在页面切换、弹窗弹出时特别明显。解决办法是在截图前等待界面稳定。具体做法可以是等待一段时间无变化或者等待特定元素出现。Appium 里的隐式等待、Maestro 里的断言等待都是这个思路。智能体方案如果没内置这个机制你需要在动作编排层自己加。6.2 输入法弹窗遮挡关键元素在真机上输入文本时软键盘会弹出来遮挡屏幕下半部分。如果智能体接下来要点击的元素正好被键盘挡住它就会点空。这个问题在传统自动化里也存在但智能体因为看的是整屏更容易被键盘干扰。处理方式有两种输入完成后主动收起键盘或者让智能体知道键盘区域不可点击。前者更可靠通常通过按返回键或点击键盘外的区域实现。但要注意有些 App 的返回键会直接退出页面所以收起键盘的方式要针对具体 App 测试。6.3 模型对相似元素的脸盲列表里一排长得几乎一样的条目模型很容易点错。比如商品列表里多个相似商品、聊天列表里多个相似头像。纯视觉方案在这种情况下准确率会明显下降。缓解办法是给模型更多区分信息。如果控制层能提供控件树把每个条目的文本内容一起给模型它就能靠文字区分。如果只有截图可以在任务描述里加上区分条件比如点击标题包含降噪的那个商品。但根本上这类场景还是建议用结构化定位更稳。6.4 多设备并发时的资源竞争单设备跑通不代表多设备能跑通。多台设备同时跑智能体任务时会出现设备连接抢占、ADB 端口冲突、截图资源竞争等问题。而且智能体任务通常比脚本耗时更长并发时的资源占用更明显。我的建议是先单设备把任务调稳再逐步增加并发不要一上来就铺开。并发数要根据机器性能和任务复杂度来定通常一台控制机带 3-5 台设备是比较稳的区间再多就要考虑分布式了。6.5 任务超时设置的两难超时设短了正常任务会被误杀设长了真卡住的任务会浪费大量时间。这个平衡很难一次调好。我的经验是按任务类型分别设置冒烟类短任务给 1-2 分钟跨应用流程给 3-5 分钟数据采集类根据数据量给。而且超时后不要直接判失败先截图记录当前状态方便事后分析是卡在哪一步。7. 我对这套东西的真实判断用了几个月下来我的判断是智能体操作真机现在是一个特定场景下非常好用、但远没到通用的工具。它在短流程、明确终态、界面变化频繁的场景里确实比传统脚本省心维护成本能降下来。但在长链路、精确判断、资金相关的场景里它还不如老老实实写脚本或者人工操作。选型的时候我建议先问自己三个问题这个任务有没有明确的终态流程是不是足够短失败了能不能重来三个都是是那智能体大概率能帮上忙。只要有一个否就要慎重。另外别指望智能体完全替代人。它更像是把人的重复劳动压缩了把盯着屏幕点按钮这件事自动化了但判断、决策、异常处理这些还是需要人。把它当成一个不知疲倦但需要监督的实习生这个定位比较准确。最后分享一个我自己的用法把智能体当成探索工具。新 App 要测先用智能体跑一遍核心路径看它在哪里卡住、哪里走偏这些卡点往往就是传统脚本将来会出问题的地方。用智能体的失败来指导脚本的编写这个组合比单用任何一种都高效。