Большинство бенчмарков, на которых сегодня оценивают LLM-агентов для Android, запускается на эмуляторах. Отсюда главный пробел: метрики реального устройства в таких тестах почти не измеряются. Расход батареи, тепловыделение и температура смартфона в отчёты обычно не попадают, а сами задачи разбросаны по разным наборам, языкам и приложениям. Понять по таким результатам, отработает ли агент надёжно на телефоне обычного пользователя, практически невозможно.
На это указал автор библиотеки научных работ по бенчмаркингу мобильных и Android-агентов. Он собрал публикации по теме и сформулировал три системные претензии к устройству оценки: эмуляторы вместо физических устройств, отсутствие метрик развёртывания и отсутствие единого глобально релевантного набора задач (My Reading Library: Evaluating LLMs on Android Tasks).
Дальше разберём каждую проблему отдельно: что именно теряется при тестировании на эмуляторе, какие показатели критичны для мобильного агента и как эти пробелы влияют на выводы о готовности технологии к ежедневному использованию.
Что не так с текущими бенчмарками для Android-агентов
Короткий ответ: оценка Android-агентов оторвана от реальной эксплуатации. Причин три, и все они методологические.
- Среда запуска. Большинство бенчмарков работает на эмуляторах, поэтому метрики реальных устройств сложно получить в принципе.
- Набор метрик. Расход батареи, тепловыделение и температура, то есть показатели развёртывания, в тестах часто отсутствуют.
- Состав задач. Повседневные сценарии распределены по разным бенчмаркам, языкам и приложениям и не складываются в согласованный набор, релевантный для пользователей по всему миру.
Итог: по опубликованным результатам трудно судить, сможет ли агент надёжно работать на реальном смартфоне для реальных пользователей. Дело в том, как устроены тесты, а не в возможностях конкретных моделей: агент может проходить сценарии в лаборатории и при этом разряжать устройство за час или уходить в троттлинг на пятнадцатой минуте работы.
Почему эмулятор не заменяет реальное устройство
Эмулятор воспроизводит программную среду Android: версию системы, разрешение экрана, часть API. Аппаратную часть смартфона он не воспроизводит. Агент, который в лаборатории уверенно проходит цепочку шагов, на физическом устройстве сталкивается с ограничением питания, нагревом, фоновыми процессами, нестабильной сетью и живым пользователем, готовым в любой момент прервать выполнение задачи.
Формулировка важна: речь именно о большинстве бенчмарков. Часть тестов уже работает на физических устройствах, но общая картина в области строится вокруг эмуляторов.
Что именно теряется при тестировании на эмуляторе
- Расход батареи. Эмулятор питается от хоста, поэтому энергопотребление агента измерить нечем.
- Тепловыделение и температура. На хосте нет корпуса, который греется, и нет пассивного охлаждения, которое упирается в предел.
- Фоновые процессы. На реальном телефоне параллельно работают синхронизация, мессенджеры, обновления и службы производителя. Они отнимают CPU, память и сеть.
- Реальная задержка сети. Мобильный интернет меняет скорость и стабильность, а эмулятор обычно работает в предсказуемых условиях хост-машины.
- Сенсоры и прерывания. Звонки, уведомления, смена ориентации, блокировка экрана вмешиваются в работу агента и ломают последовательность шагов.
Каждый пункт бьёт по пользовательскому опыту и надёжности. Агент, формально выполнивший задачу, но превративший телефон в грелку или съевший половину заряда, в повседневной работе не задержится. Простой пример: бенчмарк на эмуляторе фиксирует успешное завершение сценария, но в отчёте нет ни одного числа о том, сколько энергии потратил агент и насколько нагрелось устройство.
Когда эмулятор всё-таки уместен
Отказываться от эмуляторов не нужно. Они дают воспроизводимость: один и тот же сценарий прогоняется одинаково, результаты сравнимы между версиями агента, а массовый прогон сотен задач не требует парка телефонов. Для отладки логики, проверки сценариев и быстрых итераций это рабочий инструмент.
Граница проходит там, где начинается вопрос эксплуатации. Эмулятор отвечает на вопрос, справляется ли агент с задачей в управляемой среде. Финальную оценку готовности дают тесты на физических устройствах. Эти подходы дополняют друг друга: сначала дешёвый массовый прогон, потом проверка на железе, с которым пользователь работает каждый день.
Какие метрики важны для мобильных AI-агентов
Мобильный агент работает в жёстких рамках: небольшой аккумулятор, пассивное охлаждение, ограниченная память, конкуренция за CPU с другими приложениями. Поэтому точность выполнения задач описывает только часть картины. Вторая часть - цена, которую агент платит за свою работу, и её как раз фиксируют метрики развёртывания (deployment metrics): расход батареи, тепловыделение и температура. В существующих тестах они часто отсутствуют.
| Метрика | Что показывает | Типичный бенчмарк на эмуляторе |
|---|---|---|
| Успешность задачи | Справился ли агент со сценарием | Обычно есть |
| Расход батареи | Сколько энергии ушло на выполнение | Часто нет |
| Тепловыделение и температура | Нагрелось ли устройство и снизились ли частоты | Часто нет |
| Задержка сети | Сколько ждёт пользователь при мобильном соединении | Как правило нет, условия хост-машины |
| Поведение при прерываниях | Как агент реагирует на уведомления, звонки, блокировку экрана | Как правило нет |
Расход батареи: почему это не второстепенная деталь
Автономность - ресурс, которого у пользователя всегда меньше, чем задач. Агент, выполняющий сценарий корректно, но за час работы сажающий аккумулятор, теряет практическую ценность: его либо отключат, либо ограничат фоновую активность, либо удалят после первой недели. На эмуляторе этот показатель не измеряется, поэтому в результатах бенчмарка он просто не появляется.
Практический смысл: двух агентов с одинаковой точностью имеет смысл сравнивать и по тому, сколько энергии каждый тратит на одну и ту же задачу. Без этих данных выбор сводится к точности в вакууме. Конкретных порогов здесь нет, и придумывать их не стоит: важна не абстрактная цифра, а сравнение агентов и версий между собой на одном устройстве.
Тепловыделение и температура: скрытый риск
Смартфон рассеивает тепло пассивно. Длительная работа агента с моделью, камерой, сетью и распознаванием интерфейса нагревает корпус, а система защиты снижает частоты. Дальше включается обратная связь: производительность падает, шаги выполняются медленнее, агент чаще промахивается и делает лишние вызовы, что добавляет нагрузку и нагрев.
Троттлинг меняет саму механику оценки. Задача, которую агент закрывает за двадцать секунд на холодном устройстве, на прогретом может тянуться минутами, и выводы бенчмарка окажутся оптимистичнее реальности. На эмуляторе такого поведения нет. Утверждать, что любой мобильный агент перегревает телефон, нельзя: нагрев нужно измерять, а не предполагать.
Разрозненность задач: почему нет единого набора для оценки
Повседневные задачи пользователя распределены по разным бенчмаркам, языкам и приложениям. Один тест проверяет работу с календарём на английском, другой - с мессенджером на другом языке, третий - с системными настройками. Каждый набор валиден сам по себе, но вместе они не образуют единого глобально релевантного набора, который отражал бы типичный день обычного владельца смартфона.
Отсюда две проблемы. Сравнивать агентов между собой становится трудно: победа в одном наборе не переносится на другой. И нельзя ответить на простой вопрос, справится ли конкретный агент с задачами конкретного человека.
Языковой и культурный разрыв
Агент, уверенно работающий с интерфейсом на одном языке, может проваливаться на другом. Причины бытовые: различаются формулировки элементов, порядок экранов, названия кнопок, а вместе с языком меняются и привычные сценарии. Культурный контекст добавляет своё: структура календаря, форматы адресов, популярные приложения и сервисы отличаются от региона к региону. Результаты, полученные на одном языке, плохо переносятся на остальные.
Все существующие бенчмарки одноязычными не назвать. Проблема в другом: языки и приложения внутри них разбросаны и почти не пересекаются, поэтому цельной картины по глобальной аудитории не получается.
Почему единый набор задач так сложно собрать
Android фрагментирован по определению. Разные версии ОС, производители с собственными оболочками, лаунчеры, наборы предустановленных приложений, правила выдачи разрешений и поведение фоновых служб. Пользовательские привычки различаются не меньше: кто-то живёт в мессенджерах, кто-то в почте и календаре, кто-то в банковских приложениях и картах.
Собрать один набор, релевантный для всех сразу, методологически тяжело. Это не оправдание текущего состояния, а контекст, который нужно учитывать: любой универсальный бенчмарк неизбежно что-то упростит, и важно понимать, что именно он выбросил за скобки.
Что это значит для оценки агента на реальном смартфоне
Практические следствия простые, но требуют дисциплины.
- Не полагайтесь только на результаты эмуляторных бенчмарков. Они говорят о логике агента, а не о его поведении на вашем железе.
- Проверяйте агента на своём устройстве и в своих сценариях. Набор задач, близкий к вашей повседневности, информативнее абстрактного лидерборда.
- Следите за нагревом и расходом батареи. Смотрите, сколько заряда уходит за типовую сессию и как меняется скорость после десяти-пятнадцати минут работы.
- Учитывайте, что успех в одном приложении не гарантирует успеха в другом. Интерфейсы, разрешения и нестандартные элементы ломают перенос.
Бенчмарки при этом не стоит отвергать: они дают быстрый и дешёвый способ отсеять заведомо слабые варианты. Реальные тесты нужны на следующем шаге, чтобы понять, выдержит ли агент вашу повседневную нагрузку. Как устроены компактные наборы задач и рабочие метрики для агентов, подробно разобрано в материале про Terminal Bench 4.0: там речь о harness, автоматических проверках, latency и стоимости успешного решения, и эту логику можно перенести на мобильные сценарии.
Куда двигаться исследователям и разработчикам
Ситуация поправима, и направления довольно конкретные.
- Метрики развёртывания в стандартных бенчмарках. Расход батареи, тепловыделение и температура должны измеряться наравне с точностью выполнения задач.
- Методики тестирования на физических устройствах. Нужны воспроизводимые протоколы: одинаковые модели устройств, одинаковая температура старта, одинаковая фоновая нагрузка, повторные прогоны.
- Более универсальные наборы задач. Многоязычные сценарии, разные категории приложений, покрытие разных регионов и привычек.
Автор библиотеки научных работ предлагает свой сборник публикаций по бенчмаркингу мобильных и Android-агентов как отправную точку для тех, кто хочет копнуть глубже (My Reading Library: Evaluating LLMs on Android Tasks).
Полезно смотреть и на смежные области, где на оценке агентов уже набили шишки. История с Real-SWE показывает одну крайность: громкое имя бенчмарка и отсутствие деталей о методологии, наборе задач и результатах. Пример The Struggle Bench напоминает о другом: название теста не говорит, какие навыки он реально проверяет. Мобильная оценка рискует повторить обе ошибки, если ограничится эмуляторами и красивыми процентами успеха.
Проверять стоит и сами обзоры: корпоративный шиллинг в AI-обзорах прячет рекламу под независимый тест, и мобильные агенты тут не исключение.
Ограничения этого разбора
Все утверждения выше опираются на личные наблюдения автора библиотеки научных работ, а не на формальный мета-анализ (My Reading Library: Evaluating LLMs on Android Tasks). Перед нами систематизированный взгляд практика, прочитавшего много публикаций, а не исследование с контрольными группами и статистикой.
В исходных материалах нет конкретных названий бенчмарков, метрик и примеров приложений. Неизвестно и то, какие именно работы вошли в библиотеку, как автор отбирал публикации и по каким критериям. Поэтому судить о полноте охвата темы по этому источнику нельзя, и обобщать его выводы на всю область оценки Android-агентов стоит осторожно.
Что это меняет на практике? Немного. Проблемы, о которых идёт речь, проверяемы на вашем собственном устройстве: поставьте агент, дайте ему десяток своих повседневных задач, посмотрите на нагрев корпуса и остаток заряда через час работы. Такая проверка займёт вечер и скажет о пригодности агента больше, чем любое рассуждение о метриках и методологии.