夜雨聆风
APP 冒烟最容易制造一种假象：登录、下单、支付按钮都点通了，于是大家默认“这版没问题”。真正到了提审前，QA 才发现 Agent 没记录系统弹窗、没保存崩溃上下文，也没说明它点的是哪个元素。流程跑完了，证据却不足以支持发版判断。
这篇文章不讨论“AI 能不能代替移动测试”。结论更具体：让 Agent 负责探索和收集证据，让 QA 负责判断覆盖是否充分、异常是否可接受。
为什么普通 UI Agent 不够用
移动端不是缩小版网页。一次看似简单的登录，可能同时涉及：
iOS 或 Android 系统权限弹窗； 键盘遮挡、焦点丢失和输入法差异； WebView、原生页面和第三方 SDK 之间切换； 弱网、接口超时、冷启动和后台恢复； 日志、崩溃、网络请求和性能采样。
如果 Agent 只能“看截图并点击坐标”，它可以完成演示，却很难形成可重复的测试资产。QA 最终仍要手工复现一遍，确认点击对象、页面状态和失败原因。
agent-device 的价值不在于多一个自动点击工具，而在于它把移动设备能力封装成适合 Agent 调用的 CLI。官方 README 描述的能力包括：读取 accessibility snapshot、使用 @e3 这类语义引用操作元素、截图、录像、日志、Trace、网络数据、性能采样和崩溃上下文，并把有效探索保存为 .ad 回放脚本。
项目地址：https://github.com/callstack/agent-device
截至 2026 年 7 月 23 日，仓库最新 Release 为 v0.20.0。官方同时明确说明，各平台支持的命令和证据类型并不完全一致，GitHub Actions 模板仍在建设中，不能把“支持 CI”理解成所有项目可以零配置接入。
它介入移动测试的哪一步
原来的手工链路通常是：QA 打开模拟器，点一遍流程，发现异常后再打开日志工具、补截图、回忆操作步骤，最后把零散材料贴进 Bug 单。
更合理的 Agent 链路是：
QA 指定目标包、设备和冒烟任务。 Agent 打开会话并获取当前页面快照。 Agent 根据语义元素引用执行点击、输入和滚动。 每次页面切换后重新获取快照，避免继续使用失效引用。 命中异常时收集截图、日志、网络和崩溃上下文。 跑通的路径保存为 .ad，由 QA 复核后再进入重复执行。
这里最重要的变化不是“少点几次”，而是把探索过程变成可审查记录。QA 不必相信 Agent 的一句“测试通过”，而是可以检查它看到的元素、执行的动作和留下的证据。
15 分钟最小验证路径
官方要求 Node.js 22 以上；iOS 需要 Xcode，Android 需要 Android SDK 与 ADB。先在已有模拟器或测试机上验证，不要一开始就接 CI。
npm install -g agent-device@latest
agent-device --version
agent-device doctor
agent-device help workflow
以 iOS 模拟器为例，先找应用、打开会话、读取交互元素：
agent-device apps --platform ios
agent-device open SampleApp --platform ios
agent-device snapshot -i
快照会返回类似 @e2 [button] "Sign In"、@e3 [text-field] "Email" 的引用。引用只对当前页面状态有效，滚动或切页后必须重新获取快照。
agent-device fill @e3 "qa@example.com" --settle
agent-device screenshot ./artifacts/login.png
agent-device close
这只是能力验证，不代表已经形成自动化。最小验证应该回答四个问题：能否稳定识别当前页面、弹窗后引用是否刷新、异常时能否留下所需证据、同一段步骤能否重复执行。
用一个真实发版任务来评估
建议选择“登录后修改个人资料”这种 5 分钟内能手工跑完的流程，不要直接拿支付全链路试水。
不要只断言按钮存在。移动测试真正有价值的断言通常跨越 UI、接口和本地状态：保存返回成功后，重启应用仍应展示相同值；拒绝相册权限后，应用不应卡死；切到后台再恢复，当前编辑内容是否符合产品设计。
具体能少做什么
少手工抄写“点击哪里、输入什么、在哪一步失败”。 少在截图、logcat、网络面板和崩溃日志之间来回切换。 少把一次探索结果遗忘在聊天记录里，可以沉淀为回放脚本。 少让研发重新询问“哪个包、哪个页面、失败前做了什么”。
但以下工作不能交给 Agent 自动拍板：
冒烟路径是否覆盖本次需求风险； 系统权限、弱网、升级和后台恢复是否符合产品预期； 视觉问题是否影响可用性； 日志和网络证据中是否包含敏感信息； 某次偶现失败是否足以阻断发布。
什么时候值得接入
适合个人快速验证的场景是：已有可运行的模拟器、主流程相对稳定、每次发版都要重复点同一段路径，而且缺陷经常因为证据不足被来回追问。
不适合直接替换现有 Appium、Detox 或 Maestro 测试套件。官方定位也更接近“让 Agent 观察、操作、调试并沉淀证据”，而传统框架仍负责长期、确定性的回归。更稳妥的组合是：Agent 先探索和生成候选脚本，QA 复核后将稳定路径转成严格回放或现有框架用例。
最终判断很简单：如果它只是替你点完页面，价值有限；如果它能把页面状态、动作、日志和回放脚本一起交给 QA 审核，才真正进入了质量流程。
官方资料
GitHub：https://github.com/callstack/agent-device 官方文档：https://oss.callstack.com/agent-device/
