在移动端自动化测试领域，让 AI 直接操作真机一直是一个颇具诱惑但门槛很高的方向。屏幕状态如何读取、控件如何点击、跨应用流程如何规划，这些问题都需要工程框架逐一解决。近期受到关注的开源项目 Mobilerun（原名 DroidRun）给出了一种更偏工程化的思路：它不是单纯把一个大模型接入手机，而是围绕设备控制构建了统一抽象层，并将不同能力拆给不同“角色”分别配置模型。
从“一个模型全包”到“按角色分配模型”
Mobilerun 的定位比较直接：它是一个用 LLM Agent 控制 Android 和 iOS 设备的开源框架，向 Agent 提供检查 UI 状态、理解截图、点击、滑动、输入文字以及规划多步流程等移动端原生工具，并支持通过 CLI 或 Python API 调用。
在项目设计上，Mobilerun 提供了两种运行模式。Direct 模式更偏轻量执行：由单一模型在一个循环中完成工具调用与结果回传，模型输出 XML 格式的工具调用块，框架解析执行后，再把结果作为用户消息返回，直到任务完成。Reasoning 模式则把流程拆成 ManagerAgent 与 ExecutorAgent 两个角色：前者负责分析当前状态、创建计划和子目标、跟踪进度并判断任务是否完成；后者只负责根据当前 UI 状态，围绕某个子目标选择并执行具体动作。
这种拆分的意义在于，它不再把“规划”和“执行”混在一个模型调用里完成，而是将任务分解为两个不同职责。文档给出的使用建议也比较明确：Reasoning 模式适合多步任务、需要规划和适应的任务，以及跨多个应用的复杂流程；Direct 模式则适合截图、发消息等简单动作，或者不需要规划开销、定义明确的单步任务。
角色级模型配置，让不同任务匹配不同模型
Mobilerun 更值得关注的一点，是它把模型配置从“任务级”推进到了“角色级”。在默认配置中，Manager、Executor、FastAgent、app_opener、structured_output 等角色均可独立设置模型和采样参数。默认情况下，这些角色都使用同一个 Gemini 模型，但温度参数按职责区分：Manager 为 0.2，保留一定规划探索空间；Executor 为 0.1，强调动作选择更确定；app_opener 和 structured_output 则为 0.0，对应纯确定性任务。
文档中的跨厂商配置示例进一步展示了这种灵活性：规划角色可以交给 Claude，执行角色可以交给 GPT-4o，而简单直接模式则可以使用更轻量的 Gemini Flash-Lite。也就是说，不同角色可以来自完全不同的模型厂商。
- 规划型角色可使用更擅长推理和长任务分解的模型
- 执行型角色可偏向动作选择更稳定的模型
- 轻量辅助角色可使用成本更低、响应更快的模型
这种设计的优势在于成本和能力可以按职责拆分。相比在任务开始前统一决定“用强模型还是弱模型”，角色级拆分允许开发者更细粒度地控制每个环节的模型投入。但相应地，配置项也会更多，问题排查时需要判断究竟该调整哪一环。
统一设备抽象：把 Android 与 iOS 差异压到驱动层
在设备连接层面，Mobilerun 通过 Portal 辅助应用与 Android 设备通信，iOS 端则使用类似机制的 iOS Portal flow。项目安装命令会完成 Portal 应用安装、无障碍服务启用以及本地控制准备等工作。代码中的 Portal 恢复逻辑显示，框架会通过 shell 命令重启无障碍服务，说明 Portal 本质上是一个运行在设备上的无障碍服务。
设备控制的抽象层则被放在外部依赖包 mobilerun_core_local 中。框架层依赖统一的 DeviceDriver 基类，Android 通过 AndroidDriver 实现，iOS 通过 IOSDriver 实现。上层 Agent 不直接面对 ADB shell 命令或 iOS 协议，而是调用一套统一动作接口。
目前暴露给上层 Agent 的动作包括 click、click_at、click_area、long_press、long_press_at、type、type_secret、swipe、system_button、wait、open_app、complete 等。值得注意的是，click(index) 依赖无障碍树给出的元素索引，属于结构化定位；click_at(x, y) 则是纯坐标点击，属于视觉或坐标定位。两者共存于同一工具集中。
Mobilerun 在默认策略上较为保守：坐标类工具通常会被遮蔽，只有在截图坐标系与设备输入坐标系对齐，且用户没有显式指定禁用列表时，才会自动解禁。这种设计减少了模型因坐标判断错误而导致误触的风险，也体现出框架在工具开放上的谨慎态度。
对 AI 测试工具链的启示
从行业视角看，Mobilerun 的价值不只是“让 AI 操作手机”，而是展示了一种更接近生产环境的 Agent 工程方法：模型不再是单一入口，而是被拆分成不同角色；设备控制不再是平台脚本堆叠，而是通过统一驱动接口封装；工具开放也不是无限制暴露，而是根据可靠性和风险进行默认约束。
对移动端自动化测试来说，这种路线的意义在于，它把大模型能力从“会看屏幕、会点按钮”的演示阶段，推进到更可控、更可配置的工具链阶段。未来如果更多测试框架采用类似的角色级模型拆分和统一设备抽象，AI 测试系统或许能更自然地进入真实业务流程，而不只是停留在单点功能验证。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-da-mo-xing-kai-shi-an-gang-wei-fen-gong-droidrun
