Лучшие открытые фреймворки телефонных ИИ-агентов: Open-AutoGLM, Mobilerun и mobile-use
Как выбрать открытый фреймворк телефонного ИИ-агента: Open-AutoGLM, Mobilerun и Minitap mobile-use по устройствам, моделям, лицензии, журналам выполнения и затратам.
- Open-AutoGLM лучше рассматривать для исследовательского стека телефонного агента с ADB, отдельным API-эндпоинтом модели и явными точками человеческого вмешательства.
- Mobilerun Framework подходит командам, которым нужен контроль через Python или CLI, дерево доступности, скриншоты, журналы выполнения и выбор провайдера модели; Mobilerun 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 accessibility service, ADB, провайдер модели, хранение траекторий |
| 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 или собственное обслуживание модели; локальный GPU не обязателен при размещенном API | Выбор провайдера модели; локальный запуск фреймворка не доказывает локальный вывод модели | Настраиваемые LLM-провайдеры; стоимость зависит от выбранного провайдера |
| Телефонное выполнение | Android через ADB, режим разработчика, USB debugging и ADB Keyboard | Android через ADB и Portal accessibility service; для iOS есть отдельная настройка Portal | Физические Android-устройства и эмуляторы через ADB; быстрый запуск через Docker относится только к Android |
| iOS | Отдельная настройка WebDriverAgent | Отдельный поток настройки, не универсальная равнозначность Android | README указывает iOS-симуляторы на macOS и отдельно говорит, что физические iOS-устройства пока не поддерживаются |
| Журналы выполнения | Проверяйте собственные журналы и точки передачи управления человеку | Документированы 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 accessibility service, скриншоты, деревья доступности, выбор модельного провайдера и структурированные результаты. Это удобно для повторяемых экспериментов, где нужно смотреть не только итог, но и путь агента.
Главное — не смешивать Framework и Cloud. Framework — локальная открытая среда выполнения, которую вы обслуживаете сами. Mobilerun Cloud — управляемый маршрут с подключенными локальными телефонами, размещенными виртуальными и физическими телефонами, API-сценариями и другими операционными зависимостями. Облако может уменьшить нагрузку на инфраструктуру команды, но оно не является тем же самым, что запуск Framework на своем компьютере.
У Mobilerun сильная сторона в наблюдаемости: README документирует запись выполнения через Arize Phoenix или Langfuse и сохраненные траектории. Если вы сравниваете Open-AutoGLM или Mobilerun, Mobilerun чаще выглядит практичнее там, где важна инспекция сбоев, повторяемые запуски и анализ траектории.
Когда подходит Minitap mobile-use
Minitap mobile-use лучше рассматривать для структурированных мобильных задач: открыть приложение, пройти понятный интерфейс, извлечь данные, вернуть результат в предсказуемом формате. В репозитории описаны автоматизация мобильного интерфейса по естественному языку, настраиваемые LLM-провайдеры и структурированное извлечение данных. Это делает проект полезным не как рейтинг моделей, а как инструмент для задач с понятным входом и проверяемым выходом.
По устройствам важно читать README буквально. Физические Android-устройства и эмуляторы работают через ADB, а быстрый запуск через Docker указан только для Android. В разделе ручной настройки устройств для iOS перечислены симуляторы iOS на macOS и прямо сказано, что физические iOS-устройства пока не поддерживаются. Поэтому широкие заявления об iOS нельзя превращать в обещание полной паритетности с Android.
Еще один практический предел — приложения с бедным деревом доступности. README отмечает сложности с играми, где нет достаточной информации в дереве доступности. Если ваша задача зависит от визуально сложного приложения, заранее заложите проверку: видит ли фреймворк нужные элементы, может ли объяснить сбой и можно ли восстановиться без ручного пересоздания состояния.
Как проверить на обратимой задаче
Не оценивайте фреймворки по одному красивому демо. Возьмите одну обратимую задачу, которая не отправляет сообщения, не покупает, не удаляет и не меняет важные данные. Например: открыть настройки приложения, найти статус уведомлений, вернуться назад и сохранить наблюдение. Такой тест не доказывает общую успешность, но показывает, как фреймворк видит экран, выбирает действие и объясняет ошибку.
- Зафиксируйте устройство: физический Android, эмулятор, iOS-симулятор или облачный телефон.
- Разделите среду выполнения, модель и исполнение: где запускается фреймворк, какой API-эндпоинт модели используется, кто нажимает на телефоне.
- Проверьте ввод и наблюдение: дерево доступности, скриншот, OCR или визуальный контекст.
- Остановите задачу в середине и проверьте восстановление.
- Сравните журнал: есть ли траектория, запись выполнения, скриншот, аргументы действия и причина сбоя.
- Повторите только после изменения одного параметра: модель, устройство, приложение или запрос.
Для более строгой методики используйте Бенчмарк телефонных агентов Android: как оценивать ИИ-агента в 2026 году. Там удобнее отделить надежность выполнения от впечатления от модели. А для задач с последствиями держите под рукой принципы из статьи Управление Android ИИ-агентом: намерение, подтверждение и проверка результата.
Когда выбрать готовый Android-маршрут
Открытый фреймворк хорош, когда у вас есть инженерная цель: исследовать агентное поведение, встроить мобильное управление в рабочий процесс, записывать сбои или обслуживать собственную инфраструктуру. Если ваша задача проще — пользоваться Android-агентом на телефоне, проверять SMS, открывать приложения, сохранять задачи, работать с входящими и видеть подтверждения — отдельный фреймворк может быть лишней нагрузкой.
FoneClaw — не открытый фреймворк и не замена исследовательским репозиториям. Это готовое Android-приложение с моделью по умолчанию, совместимыми настраиваемыми модельными маршрутами и управляемыми поддерживаемыми инструментами. Модель помогает понять запрос, а FoneClaw ведет действие через разрешения, видимый результат и точки подтверждения. При этом выполнение задачи на телефоне не означает, что вся модельная обработка всегда остается на устройстве: выбранный маршрут модели и разрешения имеют значение.
Если вы не хотите обслуживать ADB, Portal, WebDriverAgent, журналы выполнения, облачные телефоны и API-эндпоинты модели, начните со страницы возможностей FoneClaw и проверьте один безопасный сценарий. Также доступна страница загрузки FoneClaw. Такой путь не дает вам открытый фреймворк, зато снимает часть эксплуатационной работы, которая обычно скрыта за словом «открытый».