Открытые фреймворки мобильных агентов: Open-AutoGLM, Mobilerun и mobile-use
Как выбрать Open-AutoGLM, Mobilerun или Minitap mobile-use: подключение устройств, модели, лицензии, журналы, миграция карточек приложений и проверка сбоев.
- Open-AutoGLM стоит рассматривать для исследовательского стека телефонного агента с ADB, отдельным API-эндпоинтом модели и явными точками человеческого вмешательства.
- Mobilerun Framework подходит для CLI/Python, деревьев доступности и анализа траекторий; Cloud — отдельный управляемый путь. Перед запуском важны явный выбор устройства, платформенные карточки приложений и проверка состояния после ошибки.
- Minitap mobile-use полезен для структурированных мобильных задач с настраиваемыми LLM-провайдерами. Android работает через ADB, а iOS в README ограничен симуляторами на macOS без физических iOS-устройств.
- Открытый код не отменяет расходы на модели, устройства, облако и обслуживание. FoneClaw — отдельный готовый Android-агент, где модель планирует, а включенные инструменты выполняют поддерживаемые действия с учетом разрешений и политики одобрения.
Короткий выбор по задаче
Выбирая фреймворки мобильных агентов с открытым кодом, не начинайте с абстрактного рейтинга. Сначала решите, что именно вы готовы обслуживать: устройство, сервер модели, журналы выполнения, доступы, сбои и стоимость вызовов. Открытый репозиторий не означает бесплатную модель, бесплатное облачное устройство или готовый потребительский агент. Перед первым запуском важнее подтвердить целевой телефон и границы действий, чем оценивать красивую демонстрацию.
| Выберите | Когда это подходящий вариант | Что проверить сразу |
|---|---|---|
| Open-AutoGLM | Исследование визуального подхода к телефонному агенту, Android через ADB, отдельная модель или собственное обслуживание модели | ADB, ADB Keyboard, API-эндпоинт модели, подтверждения чувствительных действий |
| Mobilerun Framework | Автоматизация через CLI или Python, дерево доступности, скриншоты, журналы и структурированные результаты | Выбор устройства, служба доступности Portal, провайдер модели, платформенные карточки приложений и траектории |
| Minitap mobile-use | Структурированные мобильные задачи и извлечение данных через настраиваемых LLM-провайдеров | ADB для Android, ограничения iOS, качество дерева доступности в нужном приложении |
FoneClaw в этот список не входит как открытый фреймворк. Это готовое Android-приложение с настраиваемым модельным маршрутом и управляемыми поддерживаемыми инструментами. Если вам нужно пользоваться агентом на телефоне, а не разворачивать стек, смотрите отдельный маршрут в конце статьи.
Настройка, выполнение, модели и лицензии
Телефонный агент состоит как минимум из четырех слоев: фреймворк, вывод модели, исполнитель действий на телефоне и устройство. Фреймворк решает, как видеть экран, выбирать действие и записывать ход задачи. Модель отвечает за рассуждение и следующий шаг. Исполнитель нажимает, вводит, читает дерево интерфейса или скриншот. Устройство задает ограничения: Android, iOS-симулятор, физический телефон, облачный телефон или эмулятор.
| Критерий | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| Основной путь | Визуальный фреймворк через ADB для Android; также описан HDC для HarmonyOS | Framework для CLI/Python, деревьев доступности, скриншотов и структурированных результатов | Автоматизация мобильного интерфейса по естественному языку и структурированное извлечение данных |
| Развертывание и модель | Агент с размещенным API или самостоятельно обслуживаемой моделью | Локальный Framework либо отдельный Cloud; провайдер модели выбирается отдельно | Настраиваемые LLM-провайдеры; быстрый запуск через Docker относится только к Android |
| Подключение и доступы | Android через ADB, режим разработчика, отладка по USB и ADB Keyboard | Android через ADB и службу доступности Portal; отдельно проверить целевое устройство, службу и клавиатуру | Физические Android-устройства и эмуляторы через ADB; проверить доступность нужных элементов интерфейса |
| iOS | Отдельная настройка WebDriverAgent | Отдельный поток настройки Portal, не равнозначный Android | Симуляторы iOS на macOS; физические iOS-устройства в README не поддерживаются |
| Карточки приложений и идентификаторы | Проверить конфигурацию целевого приложения в выбранном маршруте | Карточки разделены по Android и iOS; старый плоский файл игнорируется | Проверить выбранное приложение и данные его интерфейса; не переносить формат карточек Mobilerun автоматически |
| Журналы и сбои | Проверять собственные журналы и точки передачи управления человеку | Arize Phoenix, Langfuse и сохраненные траектории; после ошибки вызова проверить уже выполненные действия | Проверять извлечение, дерево доступности и фактический результат задачи |
| Лицензия репозитория | Apache-2.0 | MIT | Apache-2.0 |
Перед внедрением сверьте файл лицензии выбранной ревизии. Лицензия репозитория не переносится автоматически на модель, данные, облачный телефон или внешние зависимости. Локальный запуск фреймворка также не доказывает локальный вывод модели. Для ее выбора отдельно полезно руководство Лучшие модели ИИ для агентов в 2026 году: что выбрать для задач на Android: оно помогает не смешивать модель, протокол API и исполнитель действий.
Когда подходит Open-AutoGLM
Open-AutoGLM стоит выбирать, если вам нужен исследовательский стек вокруг визуального поведения телефонного агента и вы готовы управлять устройством через ADB. В официальном репозитории описаны Android-настройки с режимом разработчика, USB debugging и ADB Keyboard, а также отдельный HDC-маршрут для HarmonyOS. Это не потребительская кнопка «включить агента», а инженерная среда, где устройство, модель и исполнитель нужно собрать в рабочую связку.
Сильная сторона Open-AutoGLM — явное разделение агента и модели. Python-агент может работать с размещенным API или с самостоятельно обслуживаемой моделью; локальный GPU не требуется, если используется размещенный API. Но это также означает, что открытый исходный код не отменяет счетов за модельные вызовы и не доказывает полностью локальную обработку.
Отдельно важны границы безопасности. В репозитории описаны подтверждение чувствительных операций и передача управления человеку для входа, captcha и подобных шагов. Для реального телефона это правильно: успешная демонстрация в одном приложении не равна разрешению автоматически управлять всеми приложениями пользователя.
Когда выбрать Mobilerun Framework или Cloud
Mobilerun, ранее известный как DroidRun, логичен для команд, которым нужен программный контроль через CLI или Python. Открытый Mobilerun Framework работает на вашей машине, использует ADB, службу доступности Portal, скриншоты, деревья доступности, выбор модельного провайдера и структурированные результаты. Это удобно для повторяемых экспериментов, где нужно смотреть не только итог, но и путь агента.
Главное — не смешивать Framework и Cloud. Framework — локальная открытая среда выполнения, которую вы обслуживаете сами. Mobilerun Cloud — управляемый маршрут с подключенными локальными телефонами, размещенными виртуальными и физическими телефонами, API-сценариями и другими операционными зависимостями. Облако может уменьшить нагрузку на инфраструктуру команды, но оно не является тем же самым, что запуск Framework на своем компьютере.
README документирует запись выполнения через Arize Phoenix или Langfuse и сохраненные траектории. Это основание рассмотреть Mobilerun, когда важны разбор сбоев и наблюдаемость, но не доказательство превосходства по успешности над другими фреймворками.
В выпуске от 14 октября 2026 года по UTC изменен выбор устройства: mobilerun run использует сначала -d, затем ANDROID_SERIAL, затем единственное подключенное устройство в рабочем состоянии. Если устройств несколько и выбор не задан, запуск завершается ошибкой, а не берет первое. Перед запуском просмотрите список подключений и явно выберите свой тестовый телефон.
FastAgent обрабатывает только первый блок function_calls, игнорирует последующие и после неудачного вызова пропускает остаток блока. Поэтому остановитесь, проверьте фактический экран и устраните причину перед повтором. Уже выполненные шаги не считаются автоматически отмененными; это не транзакция с гарантированным откатом.
При миграции учтите изменение карточек приложений от 5 октября: используются app_cards_dir/android/app_cards.json и app_cards_dir/ios/app_cards.json. Файл app_cards.json непосредственно в app_cards_dir больше не читается. Разнесите карточки по платформам и проверьте Android-идентификаторы приложений отдельно от iOS bundle ID. Настройка использует закрепленную для фреймворка версию Portal и сохраняет уже установленную более новую.
Portal может восстановить службу доступности и свою клавиатуру во время запуска. Если вы намерены отозвать доступ, сначала остановите агент и затем проверьте фактическое состояние службы и клавиатуры на устройстве. Не отключайте защиту телефона ради продолжения опыта. Для Cloud SDK отдельно учитывайте совместимость дерева интерфейса и изменения вызовов нажатия и ввода без повторных попыток: это вопросы сопровождения, а не гарантия успеха на любом устройстве.
Когда подходит Minitap mobile-use
Minitap mobile-use лучше рассматривать для структурированных мобильных задач: открыть приложение, пройти понятный интерфейс, извлечь данные, вернуть результат в предсказуемом формате. В репозитории описаны автоматизация мобильного интерфейса по естественному языку, настраиваемые LLM-провайдеры и структурированное извлечение данных. Это делает проект полезным не как рейтинг моделей, а как инструмент для задач с понятным входом и проверяемым выходом.
По устройствам важно читать README буквально. Физические Android-устройства и эмуляторы работают через ADB, а быстрый запуск через Docker указан только для Android. В разделе ручной настройки устройств для iOS перечислены симуляторы iOS на macOS и прямо сказано, что физические iOS-устройства пока не поддерживаются. Поэтому широкие заявления об iOS нельзя превращать в обещание полной паритетности с Android.
Еще один практический предел — приложения с бедным деревом доступности. README отмечает сложности с играми, где нет достаточной информации в дереве доступности. Если ваша задача зависит от визуально сложного приложения, заранее заложите проверку: видит ли фреймворк нужные элементы, может ли объяснить сбой и можно ли восстановиться без ручного пересоздания состояния.
Как проверить на обратимой задаче
Не оценивайте фреймворки по одному красивому демо. Для одинаковой первой проверки выберите установленное безобидное приложение, например калькулятор, на принадлежащем вам тестовом телефоне. Задача: открыть его и остановиться, ничего не отправляя, не покупая и не меняя важные данные. Это предлагаемый пример по документированным маршрутам настройки, а не результат проведенного нами тестирования.
- Зафиксируйте тип устройства, его идентификатор и исходный экран. Просмотрите список подключенных устройств, например через
adb devicesдля Android. - Для Mobilerun явно задайте нужное устройство через
-dлибо проверьтеANDROID_SERIAL. Несовпадение целевого телефона — причина остановить запуск. - Разделите среду выполнения, модель и исполнение: где работает фреймворк, какой API модели используется и какой компонент действует на устройстве.
- Проверьте доступы, службу и клавиатуру, а при использовании карточек — платформенный путь и идентификатор приложения.
- Дайте одну команду открыть выбранное приложение. Сверьте журнал с фактическим экраном именно выбранного телефона.
- При ошибке остановитесь и установите, что успело произойти. Не повторяйте весь блок вслепую, особенно если часть действий уже выполнена.
- После устранения причины повторите ограниченную проверку и зафиксируйте изменение одного параметра: модели, устройства, приложения или запроса.
Признак завершения — нужное приложение действительно открыто на выбранном устройстве и журнал согласуется с видимым состоянием. Ответ модели «готово» недостаточен. Для проверки прерывания используйте такую же безопасную задачу; остановка процесса не должна трактоваться как автоматический возврат телефона в исходное состояние.
Для более строгой методики используйте Бенчмарк телефонных агентов Android: как оценивать ИИ-агента в 2026 году. Там удобнее отделить надежность выполнения от впечатления от модели. А для задач с последствиями держите под рукой принципы из статьи Управление Android ИИ-агентом: намерение, подтверждение и проверка результата.
Когда выбрать готовый Android-маршрут
Открытый фреймворк хорош, когда у вас есть инженерная цель: исследовать агентное поведение, встроить мобильное управление в рабочий процесс, записывать сбои или обслуживать собственную инфраструктуру. Если задача проще — пользоваться поддерживаемыми действиями агента на совместимом телефоне, — развертывание отдельного стека может быть лишней нагрузкой.
FoneClaw — не открытый фреймворк и не замена исследовательским репозиториям. В нашем готовом Android-приложении настроенная модель понимает запрос и планирует, а включенные инструменты выполняют поддерживаемые действия с учетом реальных разрешений Android и политики одобрения. Это не универсальное управление любым приложением и не подтвержденная интеграция с перечисленными фреймворками.
Можно использовать модель по умолчанию или совместимый настраиваемый модельный маршрут. Выполнение инструмента на телефоне не означает, что вся модельная обработка остается на устройстве. Равным образом политика одобрения не означает одинаковое окно подтверждения перед каждым действием: проверяйте настройки конкретного инструмента и фактический результат.
Если вы не хотите обслуживать ADB, Portal, WebDriverAgent, журналы выполнения и облачные телефоны, начните со страницы возможностей FoneClaw и выберите один безопасный поддерживаемый сценарий. Варианты установки представлены на странице загрузки FoneClaw. Такой выбор меняет объем самостоятельного обслуживания, но не отменяет проверку доступов, совместимости и результата.