Mobilerun 是 droidrun 开源的移动设备自动化框架，目标是让 LLM agent 可以用自然语言控制 Android 和 iOS 设备。它提供移动端原生工具，让智能体能够检查 UI 状态、理解截图、点击、滑动、输入、规划多步任务，并通过 CLI 或 Python API 返回结果。
这个项目的定位很清楚：它不绑定某一家模型，而是做移动设备与智能体之间的执行层。README 中列出的模型来源包括 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 以及 OpenAI-compatible providers。对开发者来说，这比“只支持一个模型的演示项目”更实用。
它解决什么问题
移动端自动化最麻烦的地方，是自然语言任务和真实设备操作之间隔着很多层。模型需要知道当前打开了什么 App、页面有哪些控件、是否需要截图补充视觉信息、下一步该点哪里，以及执行失败后如何继续。
Mobilerun 把这些能力整理成一套框架：
- 通过 CLI 和 TUI 运行一次性自然语言任务、检查设备、回放宏和调试流程。
- 通过 Python API 构建自定义移动自动化工作流。
- 支持 Android 和 iOS，Android 通过 Portal app 和无障碍能力控制设备，iOS 走单独的 Portal 流程。
- 同时使用 accessibility tree 和截图，让模型既能读结构化 UI，也能看视觉画面。
- 支持
--vision、--vision-only和--reasoning等模式，应对不同复杂度的任务。 - 支持结构化输出、app cards、自定义工具、凭据和执行轨迹追踪。
这让 Mobilerun 更像一个“移动端 agent runtime”，而不是单纯把截图发给大模型再模拟点击。
本地框架和云端服务
Mobilerun 把本地框架和 Mobilerun Cloud 分得比较清楚。本地框架适合开发者在自己的机器和设备上运行 agent，拿到更强的代码级控制；Cloud 则面向托管设备、REST API、SDK 和规模化工作流。
这个分层很重要。很多移动自动化场景开始时只是“帮我在手机上跑一个任务”，但一旦进入团队使用，就会遇到设备管理、并发、日志、失败重试、权限和 API 调用的问题。Cloud 不是替代本地框架，而是把设备运维和工作流接入往后端服务方向推进。
README 中还区分了几类云端设备：用户自己的硬件、托管云手机、托管实体手机。这里的差别不只是成本，也涉及应用风控、身份可信度和任务稳定性。对电商、社交、金融或本地生活类 App 来说，真实设备和虚拟设备的表现可能完全不同。
为什么 LLM 无关很关键
移动 GUI agent 还处在快速变化阶段，很难说哪一家模型长期最好。不同任务对模型的要求也不一样：有的更依赖视觉理解，有的更依赖长链路规划，有的更看重工具调用，有的则需要低成本批量执行。
Mobilerun 选择模型无关的框架路线，价值在于把设备控制、任务执行、日志追踪和模型选择拆开。开发者可以先稳定设备侧流程，再根据任务成本、准确率和延迟切换模型。
这对实际落地很有帮助。企业不会只因为一个模型演示效果好就重写设备控制层；更合理的方式是保留统一执行框架，把模型当成可替换组件。
适合哪些场景
Mobilerun 当前适合几类需求：
- 移动 App QA 和回归测试。
- 从原生 App 中抽取数据并返回结构化结果。
- 自动执行重复性的手机任务。
- 为非技术用户封装自然语言移动操作流程。
- 在多台设备上运行自动化任务。
- 把日程、通知或自定义触发器接入移动端工作流。
不过，它也不是“安装后立刻替你管手机”的消费级助手。Android 侧需要 ADB、开发者选项、USB 调试和 Portal app；iOS 侧也有自己的接入流程。真正跑稳定，还要处理模型配置、设备状态、权限弹窗和任务失败恢复。
我的判断
Mobilerun 的价值在于把移动设备控制做成了可编程、可观测、可替换模型的 agent 框架。它承认移动自动化不是一个模型问题，而是模型、设备、执行器、日志、工具和云端基础设施共同组成的系统问题。
短期看，它适合开发者搭建移动端自动化原型和内部工具；长期看，这类框架可能会成为“手机上的 AI 工作流引擎”。如果 GUI agent 要进入真实业务，像 Mobilerun 这样把本地运行、云端设备、结构化输出和追踪能力放在一起的项目会越来越重要。
项目链接：droidrun/mobilerun