让 AI Agent 操作真机：mobile-agent 如何把手机变成可观测的测试目标
让编码 Agent 写出一个移动应用只是第一步。要验证它是否真的能启动、点按钮、填写表单并观察结果，传统流程往往需要人手操作模拟器，或额外拼接截图、坐标点击和等待逻辑。开源项目 mobile-agent 尝试把 Android 与 iOS 设备控制封装成面向 Agent 的接口：后台 daemon 维护设备屏幕、无障碍树和最新帧的镜像，CLI 与 MCP server 则提供统一的操作面。
它目前仍是实验性预发布项目，尚未发布到 crates.io 或提供二进制包，需要从源码构建。仓库采用 MIT 许可证，但驱动依赖 Apple 私有接口和 Android 隐藏接口，项目明确定位为开发工具，不适合嵌入正式应用。这个边界很重要：它适合开发与测试实验，不应被误读成稳定的跨平台自动化 SDK。
核心思路：把“观察”变成可复用状态
许多自动化脚本在每次动作后重新读取设备，再固定 sleep 几秒。这不仅慢，也容易因动画、网络或设备负载变化而失效。mobile-agent 的 daemon 持续维护设备的屏幕窗口、可访问性树和帧信息；请求快照、等待变化或检查界面稳定状态时，可以从这份镜像读取，而不是每次从设备端重新取数。
对 Agent 来说，这种设计让动作与反馈更紧密：先读取当前界面，再基于可见控件执行交互，之后等待状态变化并重新观察。相比只传屏幕坐标，结构化的可访问性信息能为决策提供更多上下文。不过，项目并不意味着任意应用都能被可靠操控；设备状态、系统版本、权限提示和控件暴露情况仍会影响结果。
它也没有把所有平台强行伪装成相同底层实现。Android 端通过 adb 部署一个 dex agent；iOS 模拟器由主机侧驱动；实体 iPhone 的可访问性树需要 XCTest runner，并涉及开发者签名、设备信任和 UI Automation 授权。统一的是上层 CLI/MCP 交互，不是平台内部的权限模型。
从源码构建并连接 Android 模拟器
README 当前给出的构建方式如下。构建环境还需具备 Rust、Android SDK 工具和项目要求的相关依赖；构建 iOS 相关目标则需要 macOS 与兼容的 Xcode。
cargo build --release export PATH="$PWD/target/release:$PATH"
仓库说明 release 构建会生成 mobile-agent、mobile-agent-daemon 和 mobile-agent-mcp。Android 模拟器可通过 adb 与 gRPC 控制端点连接，示例启动方式是：
export ANDROID_HOME="${ANDROID_HOME:-$HOME/Library/Android/sdk}"
export PATH="$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
adb start-server
emulator -avd <name> -grpc 8554 -grpc-use-token
这里的模拟器命令应在独立终端运行。若设备已经启动，daemon 会连接现有目标，并不会替你启动模拟器。项目还提到可关闭模拟器控制器快路径，让操作改走 agent 路径；具体诊断和设备状态应以仓库 Quick start 中 doctor、status 的输出为准，不要将示例环境变量当作所有设备都必需的配置。
适合什么工作流
一个务实的试用场景，是让编码 Agent 对自己生成的 Android 应用做基本冒烟验证：人先启动模拟器并准备好测试账号，Agent 通过 MCP 工具观察页面、执行有限交互，再检查页面是否进入预期状态。这样能把“代码已生成”推进到“界面至少经过一次真实运行验证”。如果测试关注的是跨平台细节，则可分别在 Android 模拟器和 iOS 模拟器上运行，而不是假定一份脚本会自动覆盖两者差异。
需要实体 iPhone 时，准备成本更高：设备需通过 USB 连接并信任主机，开发者模式与 UI Automation 需要启用，runner 还需由开发团队签名。官方文档指出，某些授权可能再次弹出；因此，把它放进无人值守 CI 前，应先验证设备可用性、签名有效期和授权恢复流程。
mobile-agent 的价值不只是“让模型点手机”，而是把设备观察、交互和平台差异纳入一个可供 Agent 调用的运行时。它仍处于实验阶段，且底层接口有兼容性风险；如果团队愿意接受构建和设备配置成本，可以用它探索 Agent 驱动的移动端冒烟测试。若需求是稳定的产品级测试基础设施，则应先评估平台支持边界与维护成本，再决定是否采用。