Appium 你用了多少年？

从 2013 年算起，整整 12 年了。

这 12 年里，移动端自动化测试的江湖格局，几乎没变过——Appium 就是那个绕不过去的存在。

但说实话，Appium 真的不好用。

写一个测试脚本，得找元素 ID、写 XPath、处理各种弹窗、适配不同屏幕尺寸。脚本写下来，比业务代码还长，UI 一动，全部重来。12 年了，一直如此。

直到最近，一个开源项目进入了视野——它让我觉得，移动端自动化测试的范式，可能真的要变了。

它叫 agent-device

这是 Callstack 团队的作品，MIT 开源协议。目前，JPMorgan Chase、Expensify、Shopify 这些公司的团队已经在用了。

一句话概括：它是一款专为 AI Agent 设计的设备自动化 CLI，覆盖 iOS、Android、TV 以及桌面端。目前，这个项目在 GitHub 上的 Star 数已经接近 4k。

安装很简单（Node.js 版本需大于 22.12）：

npm install -g agent-device@latest
agent-device doctor
agent-device --version
agent-device help workflow

注意，它不是另一个 Appium。

Appium 的逻辑是：你写脚本，一步步教它怎么点、怎么填。

agent-device 的思路完全不同：你把它交给 AI Agent（比如 Codex 或 Claude Code），Agent 自己看屏幕、找按钮、执行操作。

agent-device 只做一件事——充当 Agent 的“眼睛”和“手”。

为什么它可能改变格局？

先说结论：不是技术一定比 Appium 更牛，而是思路的根本不同。

Appium 时代，测试的核心能力是“写脚本”——你得精通 XPath、懂元素定位策略、会处理各种等待逻辑。

agent-device 时代，测试的核心能力变成了“描述意图”——你只需要说“验证登录功能正常”，Agent 自己看屏幕、找元素、点按钮、判断结果。

这不是优化，是真正的范式转移。

就像从“手写汇编”到“用高级语言”——不是汇编不好，是整个抽象层变了。

三个值得注意的设计

第一，语义化引用。

agent-device 在截取屏幕快照后，会给每个可交互元素分配一个引用——像 @e1、@e2、@e3 这样。

Agent 不需要写 XPath，只需要说“点击 @e3”。

agent-device snapshot -i
# @e1 [heading] "Settings"
# @e2 [button] "Sign In"
# @e3 [text-field] "Email"

agent-device fill @e3 "test@example.com"

XPath 会因为 UI 改版而失效，但基于无障碍树的引用，稳定性高出不止一个量级。

第二，证据收集不只是截图。

日志、网络流量、性能采样、崩溃上下文、React 渲染 profile——这些数据都会自动收集。

这意味着 Agent 不只是“操作完了”，还能自证清白。出了 Bug 要复盘？证据链一条不少。

第三，探索变回放。

Agent 探索完一遍操作流程，会自动录制成 .ad 脚本，之后可以在 CI 里反复跑。

探索时靠 AI，回归时靠脚本——两个阶段各取所长。

但别急着吹，它也有短板

第一，需要 AI Agent 驱动。

你得有 Codex 或 Claude Code。没有 Agent，它就是一个普通的 CLI，价值直接砍半。

第二，吃 App 的无障碍标签。

它依赖 accessibility tree。如果 App 没做无障碍适配，所有元素都可能被标成“button”，Agent 也束手无策。

第三，生态还处于早期。

虽然已经有大型团队在用，但文档、教程、社区最佳实践还在积累中。碰到一些问题，可能得自己摸索。

判断

它可能不会立刻替代 Appium——但很可能是 Appium 之后的下一个方向。

Appium 解决的问题是“怎么让机器按步骤操作手机”。

agent-device 解决的问题是“怎么让 AI 像人一样看屏幕、理解界面、自主操作”。

这两件事，根本不在一个层面上。

未来两三年，移动端测试的核心能力，大概率会从“写自动化脚本”转向“编排 AI Agent 做验证”。agent-device 不一定是终局，但它可能是推倒多米诺骨&牌的那只手。

如果你在做移动端测试，建议现在就去 GitHub 看看，跑一遍 Demo。

别等到所有人都在用的时候，才反应过来。

GitHub 项目地址：github.com/callstack/agent-device