手机 Agent 的问题不在点按：从 3324 次 Android 操作看可靠性边界
让 AI 操作手机，第一反应往往是担心它看不懂界面、点错按钮。但 Opposable 团队发布的一份实测记录显示，真正的故障不只在视觉识别：2026 年 10 月 8 日至 11 月 3 日，Agent 在 45 台 Android 手机上执行了 3324 次操作，点按和滑动有 99% 按预期完成；与此同时，27 台手机至少一次从中继连接中掉线。自动化能否稳定工作，取决于手机是否持续在线、输入焦点是否就绪，以及用户是否仍能掌控屏幕。
这不是覆盖所有设备的行业基准，而是 Opposable 自身产品在四周内的运行日志。它的价值在于把“手机 Agent 不稳定”拆成了可以讨论和验证的工程问题。
成功率高，不代表整条链路可靠
报告统计了 3324 次操作，其中 91% 成功。失败的 305 次里，140 次被归为手机或 Android 侧问题：108 次手机不可达、21 次输入时没有文本框获得焦点，其余包括手势取消和锁屏。另有 165 次来自 Agent 或应用自身，例如找不到界面元素、模型尚未下载等。数字说明，单个动作看似简单，整条链路却跨越了设备、电源管理、辅助功能服务、Agent 判断和应用实现。
尤其值得注意的是，45 台手机中有 27 台在 Agent 会话期间至少掉线一次。按厂商拆分的样本也差异明显：记录中的三星设备为 20 台，其中 14 台至少掉线一次；小米设备 9 台，其中 7 台发生过掉线。作者也说明，日志无法区分系统省电管理、用户关机和信号丢失，因此不能仅凭这些数据断言某个厂商的系统必然导致断线。
手机不是一台随时在线的桌面电脑
手机操作系统的默认目标是省电和保护用户，而不是让第三方应用随叫随到。Android 的 Doze、应用待机以及厂商自带的后台管理，可能让长连接中的应用暂停或退出。对远程 Agent 来说，用户把手机放在桌上之后，恰恰是它最希望设备保持在线的时候。
Opposable 报告称，应用采用前台服务和常驻通知，并提示用户关闭电池优化；针对部分厂商，还展示需要用户手动启用的自启动或“不休眠应用”等设置。这些措施是产品侧的缓解方案，不是对所有设备都有效的保证。设计手机自动化时，应把“设备离线”作为一等故障处理：请求要有超时，调用方要能区分未执行、执行中断与执行结果未知，并提供可恢复或人工接管的路径。
辅助功能既是入口，也是权限边界
Android 的辅助功能服务可以读取界面并执行操作，因此成为 Agent 操控其他应用的通用入口。但它原本服务于无障碍场景，不等于专门为自主 Agent 设计的权限模型。启用过程需要用户进入系统设置；报告还指出，从浏览器安装的应用默认会把相关开关置灰，用户必须先在应用信息页允许受限制设置，才能启用相关服务。
更深层的问题是，系统无法区分“用户点按”和“辅助功能服务替用户点按”。因此，敏感动作不能只依赖 Agent 的提示词自律。Opposable 在自己的应用中为支付加入手机端确认，并阻止 Agent 操作其自身的审批设置；这是产品层的防护思路，而不是 Android 为所有应用提供的通用审批机制。需要自动化真实业务的团队，应把支付、删除、授权等动作设为显式确认点，并在服务端再次校验权限。
文本输入和应用启动也会制造脆弱点
报告中的文字输入成功率为 85%。Android 将文字发送给当前获得焦点的字段，而点按后焦点可能尚未就绪。Opposable 团队称，他们加入最多 600 毫秒的焦点等待；如果界面只有一个文本框则尝试聚焦，有多个候选时让 Agent 先选择。这体现了一条通用经验：界面操作应依据状态反馈推进，而不是盲目按固定延时连续发送动作。
启动应用同样会受厂商差异影响：同一款时钟应用在 Pixel 与三星设备上可能对应不同包名。若平台提供跨设备一致的系统 Intent 或应用 API，优先使用它们；只有缺少结构化接口时，再回退到屏幕识别和坐标点击。报告中点按和滑动总体成功率虽达 99%，但坐标点击“落在某处”并不等于目标语义正确；元素定位失败反而更容易被明确检测出来。
最核心的做法，是把手机自动化拆成“确认目标状态—执行单个动作—读取结果—判断是否继续”的闭环。若一次点击后界面没有变化，不要立刻重复点击：先重新读取屏幕或元素列表，判断是动作未送达、控件不可见，还是请求已执行但反馈延迟。对于可能产生副作用的动作，盲目重试可能导致重复提交；应为业务请求设计稳定标识，并在服务端检查其处理状态。Opposable 的报告没有声称所有界面操作都天然幂等，因此这一层需要由集成方根据业务语义实现。
边缘情况：一次会话可能被设备状态打断
屏幕锁定时，Agent 不应绕过设备的身份验证。报告指出，锁屏造成了 3 次失败操作；产品会唤醒屏幕并显示手机原有的解锁提示。对开发者而言，这类失败应被识别为“等待用户解锁”，而不是不断重试手势。类似地，设备掉线后，调用方未必知道最后一条操作是否已完成：应暂停后续有副作用的步骤，恢复连接后重新读取当前界面，再决定继续、撤销或请求人工确认。
会话本身也会占用整块手机屏幕。报告给出的中位数会话包含 14 次操作、约 4 分钟，最长一次达到 163 次操作；这意味着手机 Agent 更像暂时取得前台控制权的远程操作者，而不是在后台悄悄运行的脚本。产品体验应清楚告诉用户会话何时开始、当前执行到哪一步、如何中断，并在任务结束时把控制权交还给用户。
给开发团队的验证清单
在把手机 Agent 接入实际工作流前，可以先从低风险任务开始，并记录每个动作的请求、设备在线状态、界面快照或元素结果、执行反馈和人工接管原因。至少覆盖以下情况：设备后台休眠、锁屏、焦点未就绪、应用名称差异、重复请求、操作结果未知以及敏感动作确认。
Opposable 的样本只有 45 台设备，且报告说明 3324 次操作中大部分来自 Claude，因此结果不能直接外推到所有 Agent、手机型号或 Android 版本。不过它提醒我们：手机自动化的瓶颈未必是“模型看不懂按钮”。更可靠的设计需要把设备可达性、操作来源、权限审批和可恢复执行一起纳入系统边界。
相关链接