agent-device：AI Agent 终于能验收手机 App 了
移动开发被 AI 改掉的第一层，是代码生成。第二层已经到了验收。
一个 coding agent 可以读 diff、跑单测、修改页面，却很难知道代码落到手机上之后究竟发生了什么。键盘有没有挡住验证码按钮，系统权限弹窗是否打断流程，列表在弱网下会不会白屏——这些问题都藏在真实运行环境里。代码看起来正确，只能说明工作完成了一半。
agent-device 是 Callstack 开源的工具，定位很直接：Mobile app verification for AI agents。它沿用了移动自动化的基础能力，却把使用者从预先编写脚本的人，换成了正在实现功能的 coding agent。对 Agent 来说，这套 CLI 相当于一双手、一双眼睛，再加一个证据收集器。
仓库：https://github.com/callstack/agent-device
真正的变化：Agent 有了验收层
传统自动化通常由人先定义路径，机器随后稳定执行。agent-device 支持另一种工作方式：Agent 在实现功能时进入真实 App，观察当前界面，选择下一步动作，再把截图、日志、性能样本和可回放脚本交给人检查。
想象一个很普通的移动端任务：Agent 修改了注册页，单测全部通过。模拟器启动后，它发现键盘挡住了验证码按钮。第一次 snapshot 给出了输入框和按钮的语义 ref；填写手机号后页面发生变化，旧 ref 随之失效，于是它重新读取界面。提交时接口响应变慢，它转去检查网络日志和性能数据。流程跑通后，Agent 留下一张截图和一份 replay 脚本，等待工程师在 PR 中确认。
这个过程已经越过"帮我写代码"的范围，进入了真实环境验收。
核心工作流
agent-device 把验收拆成一组简单动作：
npm install -g agent-device@latest
agent-device doctor
# 打开 App
agent-device open SampleApp --platform ios
# 读取当前屏幕的 accessibility tree
agent-device snapshot -i
# 操作界面
agent-device fill @e3 "test@example.com"
agent-device screenshot ./artifacts/settings.png
# 关闭
agent-device close
系统会给可交互元素分配类似 @e3 的语义 ref，Agent 可以据此执行 tap、fill、scroll、wait 和 assert；遇到异常时，再调用截图、录屏、日志、网络、崩溃上下文和性能采样。
为什么移动端更难
Web 端已经有相对成熟的 Agent 自动化路径：浏览器 DOM、Playwright、可访问性树和截图都能接入。移动端同时牵涉 iOS Simulator、Android Emulator、真机、系统权限、原生日志、键盘、手势、深链和平台差异。很多代价最高的 bug，恰好发生在这些边界上。
agent-device 目前覆盖原生 iOS 和 Android，也支持 Expo、Flutter、React Native、tvOS、Android TV、macOS、Linux 与桌面 App。底层会根据平台调用不同后端：
- iOS 和 tvOS：依赖 XCTest
- Android：通过 ADB 与 snapshot helper
- Linux 桌面：使用 AT-SPI
它并非简单地对截图做坐标点击，而是在不同平台上提供相对统一的观察、操作和证据接口。
Agent Skills：无缝接入主流 Coding Agent
通过 npx skills add callstackincubator/agent-device，Codex、Claude Code 等工具可以直接获得最新命令说明和高效工作流，减少临场猜测与无效调用。
一条真实任务能跑多远
Callstack 在优化复盘中给出过一条完整任务链：打开 Expensify → 进入 Inbox → 打开聊天 → 调用相机提交报销 → 定位慢 API → 分析渲染性能 → 最后发送消息。
这次执行一共触发 55 次工具调用，工具与 Skills 消耗约 25,000 tokens，推理消耗约 44,000 tokens。整个复杂流程只使用了一次截图兜底，其余步骤主要依赖结构化 UI 信息。
更重要的是，探索还能沉淀为确定性的 replay。一次临时验证因此有机会继续进入 PR 检查和 CI，变成可以重复执行的回归路径。
成本问题比看起来更硬
Callstack 对同一个复杂调试流程做过前后对比：优化前耗时 9 分钟、消耗约 150,000 tokens；优化后降到 6 分钟和 69,200 tokens。另一组数据更能说明方向：12 次 UI snapshot 总共约 5,000 tokens，只相当于 3 张原始截图的成本。
Accessibility snapshot 同时解决了成本和操作问题。它给 Agent 的是一组带 label、role、testID 和语义 ref 的可操作对象。截图依然适合充当视觉证据和兜底输入，但不需要出现在每一步里。
移动 UI 层级经常包含数百个屏幕外元素、隐藏视图和嵌套容器。agent-device 会裁掉当前不可操作的部分，只保留 visible-first snapshot。Callstack 的测试显示，这种裁剪在长列表场景中最多可以减少 80% 的 token。
另一个容易被低估的细节：ref 会过期。点击、滚动或跳页之后，上一轮 snapshot 里的 @e3 未必还指向同一个对象。成熟的 Agent 需要识别界面变化，在合适的时机重新 snapshot。
能操作真实手机，也意味着真实风险
复旦 JADE 团队在 2026 年 6 月发表了一项 phone-use agents 研究。他们围绕 27 个真实商业 App 测试了 9 个商业和开源模型，发现这些 Agent 执行高风险请求的平均任务完成率达到 68.8%。在真机测试中，Gemini 3.1 Pro 完成了 43/50 个滥用任务，成功率为 86%。
论文将其中的关键问题称为 Safety Awareness–Execution Gap：模型在回答安全判断题时可能识别出风险，进入代理执行模式后却继续完成任务。风险不再停留于生成一段有害文字，而是会形成真实外部结果。
这类工具不适合直接连接个人主力账号和生产权限。更稳妥的起点包括测试账号、沙盒数据、设备白名单、App 白名单、命令审计和人工批准点。
使用建议
agent-device 的意义已经超出几条移动自动化命令。它把 coding agent 的反馈闭环从代码仓库延伸到了真实设备，也会倒逼移动团队重新设计 UI 可访问性、测试账号、日志采样、性能证据和验收脚本。
短期内，更实际的做法是挑一条高频、低风险、可复现的路径，比如登录、创建内容、上传图片、弱网重试或设置页保存，让 Agent 在每次改动后走一遍，留下 snapshot、截图、日志和 replay。等这条证据链稳定后，再逐步增加任务长度和自主程度。
AI 写代码会继续变便宜，真实世界的验收却会越来越贵。谁能把验收做成结构化接口，谁就更接近真正可交付的 Agent。
GitHub：https://github.com/callstack/agent-device