1. 当智能体第一次摸到真机，它到底在摸什么
很多人对"AI 智能体操作真机"这件事的第一反应是：不就是自动化脚本换了个壳吗？以前用 Appium、用 Playwright、用影刀，现在换成大模型来驱动，本质不还是点按钮、填输入框、滑屏幕？这个判断对了一半。传统自动化脚本的核心是"我预先知道每一步该点哪里"，坐标写死、控件 ID 写死、流程写死，一旦界面改版、弹窗顺序变化、网络加载慢半拍，脚本立刻崩。而智能体操作真机的核心变化在于：它不再依赖预先写死的路径，而是靠"看当前屏幕 + 理解任务目标 + 决定下一步动作"这个循环来推进。
这个差别听起来只是实现方式不同，实际影响是数量级的。我拿一个真实场景举例：给一个购物 App 做"搜索商品、加入购物车、走到结算页但不付款"的流程验证。传统脚本要处理登录态、首页弹窗、搜索框定位、结果列表滚动加载、商品详情页的规格选择、加购成功提示、购物车角标更新……每一步都要单独写定位和等待逻辑，维护成本极高。而智能体模式下，你只需要告诉它目标，它自己截图、识别当前处于哪个页面、判断下一步该做什么。界面小改版对它来说往往不构成致命打击，因为它本来就不是靠固定坐标活的。
但这里必须先把预期拉正：智能体操作真机，目前能稳定做的是"有明确终态的短流程任务"，做不到的是"长链路、强状态依赖、需要精确数值判断的复杂业务"。这个边界如果不清楚，上手就会踩大坑。我见过太多团队一上来就想让智能体跑完整的下单支付链路，结果卡在验证码、卡在风控、卡在支付密码，最后得出"这东西不能用"的结论。问题不在智能体，在于任务选错了。
这篇文章我想把这件事讲透：智能体操作真机的技术底座是什么、它和传统自动化框架的本质区别在哪、哪些任务现在就能落地、哪些任务现阶段别碰、以及真上手时那些文档里不会写的坑。适合正在评估这类方案的测试工程师、自动化从业者，以及想用智能体做重复性手机操作的产品和运营同学。
2. 智能体操作真机的技术底座拆解
2.1 从"坐标驱动"到"感知-决策-执行"闭环
传统自动化的执行模型是线性的：脚本第 1 行找元素 A，第 2 行点击 A，第 3 行等待元素 B 出现，第 4 行输入文本……它假设世界是按剧本走的。智能体的执行模型是循环的，通常叫Perceive-Act 循环或者更完整的ReAct（Reasoning + Acting）模式：观察当前屏幕状态，结合任务目标做一次推理，输出一个动作，执行动作后再观察新状态，如此往复直到任务完成或判定失败。
这个循环里最关键的三个能力是：屏幕理解、动作空间定义、终止条件判断。屏幕理解决定了它"看得懂"多少——是把界面当成一张图去理解，还是能拿到控件树的结构化信息。动作空间决定了它"能做什么"——是只能点击和输入，还是能滑动、长按、返回、多指操作。终止条件决定了它"什么时候停"——是靠模型自己判断任务完成，还是靠外部规则校验。
我实测下来，屏幕理解这一环是决定成败的分水岭。纯视觉方案（只给模型截图）在界面元素密集、文字小而多的情况下识别率会明显下降，尤其是列表项里那些长得几乎一样的条目。而如果能同时拿到系统的控件树（类似 Appium 的 page source），把结构化信息和截图一起喂给模型，定位准确率会有肉眼可见的提升。这也是为什么现在主流的真机智能体方案，底层往往还是复用了 Appium、Maestro 这类成熟的设备控制层，只是在"决策"这一层换成了大模型。
2.2 设备控制层：为什么绕不开 Appium 和 Maestro
很多人以为智能体操作真机是全新的一套东西，其实设备控制这一层几乎没有革命性变化。你要在真机上点击、滑动、输入，底层无非是几条路：Android 走 ADB 和 UiAutomator，iOS 走 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 要测，先用智能体跑一遍核心路径，看它在哪里卡住、哪里走偏，这些卡点往往就是传统脚本将来会出问题的地方。用智能体的失败来指导脚本的编写，这个组合比单用任何一种都高效。
