Бенчмарк телефонных агентов Android: как оценивать ИИ-агента в 2026 году
Практический бенчмарк телефонных агентов Android: метрики, безопасность, approvals, recovery, GUI-задачи, side effects, B-MoCA, MobileWorld, KnowU-Bench, PhoneHarness и тесты FoneClaw.
- Бенчмарк телефонных агентов Android должен измерять не только task success rate, но и проверенный side effect, правильные разрешения, момент approval, stopping, recovery и качество trace.
- B-MoCA, MobileWorld, KnowU-Bench и PhoneHarness показывают разные разрывы: configuration generalization, long-horizon cross-app workflows, personalization, consent, mixed action surfaces и observable side effects.
- Для реального продукта нужны шесть осей тестирования: конфигурация устройства, длина задачи, число приложений, ясность намерения, GUI против structured tools, а также последствия, остановка и восстановление.
- В FoneClaw мы используем текущие доступные возможности как тестируемые классы Android-задач, но этот guide задает метод оценки и не публикует FoneClaw benchmark score.
Что должен измерять бенчмарк телефонных агентов Android
Бенчмарк телефонных агентов Android должен отвечать на один практический вопрос: агент действительно выполнил нужную задачу на телефоне, сохранив контроль пользователя? Простое «он нажал похожие кнопки» здесь мало значит. Нам нужен verified outcome: правильный объект, правильный side effect, правильное состояние устройства после действия, понятные permissions, approval в нужный момент, возможность stop и recovery после сбоя.
Из строительства FoneClaw мы быстро пришли к этому выводу. Android phone agent работает не в чистой песочнице: экран меняется, приложения обновляются, OEM-настройки отличаются, разрешения могут отсутствовать, сеть пропадает, пользователь перебивает задачу. Поэтому оценка мобильных агентов должна смотреть не только на финальный процент успешных задач, но и на процесс: как агент пришел к результату, когда спросил подтверждение, как обработал неопределенность и что записал в trace.
Хороший benchmark фиксирует начальное состояние, ожидаемый результат, допустимые маршруты, запрещенные side effects, retry policy и критерии восстановления. Если задача чувствительная, например отправка сообщения или изменение системной настройки, сам факт выполнения должен сопровождаться проверкой approval. Для эволюции тестового набора и откатов полезен отдельный материал Самоулучшающийся phone agent: версии навыков, тесты и откат; здесь мы строим базовый evaluation framework.
Ландшафт мобильных бенчмарков 2026 года
В 2026 году мобильные бенчмарки стали гораздо ближе к реальным phone-agent задачам. Они больше не ограничиваются вопросом «может ли модель понять экран». Они проверяют конфигурации, многошаговые сценарии, несколько приложений, персонализацию, согласие пользователя, action surfaces и наблюдаемые side effects. Сравнивать их как один unified leaderboard удобно, но технически грубо: разные бенчмарки задают разные среды, задачи и правила оценки.
| Бенчмарк | Что проверяет | Ключевой сигнал для продукта | Граница интерпретации |
|---|---|---|---|
| B-MoCA | 131 common Android daily tasks с randomization UI layouts и language settings | Configuration generalization: агент должен работать не только на одном «идеальном» телефоне | Результаты относятся к его задаче и среде, их нельзя переносить напрямую на другие наборы |
| MobileWorld | 201 tasks across 20 applications; средняя длина 27.8 steps; 62.2% multi-app; есть agent-user interaction и MCP-augmented categories | Long-horizon и cross-app workflows требуют состояния, планирования и восстановления | Числа 51.7% для лучшего agentic framework и 20.9% для лучшей end-to-end model относятся к настройке MobileWorld |
| KnowU-Bench | 42 general GUI tasks, 86 personalized tasks и 64 proactive tasks; hidden user profile и behavioral logs | Personalization, clarification, proactive consent и restraint after rejection должны быть отдельными измерениями | Это preprint; используем как источник измерений, а не универсальный сертификат |
| PhoneHarness | GUI, CLI и host-side tool actions; observable side effects и auditable execution traces | Action-surface routing и side-effect verification должны быть частью теста | Это preprint; harness и benchmark нужно различать |
По источникам: B-MoCA опубликован в PMLR как Benchmarking Mobile Device Control Agents across Diverse Configurations. MobileWorld опубликован в ACL Anthology как MobileWorld. KnowU-Bench доступен как preprint о personalized и proactive mobile agents, а PhoneHarness — как preprint о mixed action surfaces и auditable traces. Оценка capability discovery также требует доверенных источников возможностей; эту часть мы раскрываем в статье Agentic Resource Discovery: ai-catalog.json, доверенные каталоги и полномочия phone agent.
Шесть измерений для настоящего Android test suite
Чтобы тестирование GUI-агентов Android отражало реальную работу, каждую ось лучше варьировать отдельно. Первое измерение — configuration variation: язык, размер экрана, тема, OEM-оболочка, положение кнопок, разрешения, сеть, Bluetooth и состояние батареи. Агент, который работает только на одной записанной конфигурации, быстро ломается в руках пользователя.
Второе — horizon. Одношаговая задача вроде «открой приложение» проверяет распознавание и базовое действие. Long-horizon workflow проверяет память задачи: открыть письмо, извлечь дату, создать напоминание, подготовить ответ и вернуться к исходному экрану. Больше шагов не всегда сложнее; сложность растет, когда появляется ветвление, неопределенность и side effects.
Третье — app count. Single-app task полезна для базовой стабильности, multi-app task проверяет переходы между контекстами. Четвертое — intent clarity: четкая команда, неполная команда, конфликтные данные, несколько похожих контактов, пользователь меняет решение. Пятое — action surface: GUI, structured tool, host-side tool, CLI или mixed route. Шестое — consequence level: read-only, reversible device control, external effect, destructive action.
Эти оси дают честный test suite. Например, «включить DND на час» — reversible device-control. «Подготовить SMS и показать перед отправкой» — external-effect preparation. «Удалить файл» — destructive action с отдельными правилами approval. Если все задачи смешать в один процент, продуктовая команда потеряет понимание, что именно улучшилось.
Метрики надежности телефонного агента шире task success rate
Task success rate нужен, но он не покрывает качество телефонного агента. Метрики надежности телефонного агента должны включать verified pass, partial checkpoints, wrong side effects, recovery rate, human intervention rate, latency, cost, retry count и trace quality. Важно заранее зафиксировать denominator: считаем ли мы timeout, отказ пользователя, missing permission, app crash и wrong screen как отдельные классы или как общий fail.
Verified pass означает, что результат реально появился в проверяемом состоянии: DND включен, volume изменен, screenshot создан, черновик сообщения виден, навигация открыта в нужном приложении. Partial checkpoints показывают, насколько далеко агент дошел: понял намерение, нашел экран, запросил доступ, подготовил action, но остановился на approval. Wrong side effect — самая важная красная метрика: агент сделал что-то не туда, не тому или не с тем параметром.
LLM judge alone не должен быть единственным арбитром. Для phone-agent задач нужны device logs, screenshots, tool traces, state checks и human review для спорных случаев. PhoneHarness полезен именно тем, что подчеркивает observable side effects и auditable execution traces. Для архитектуры идентичности, разрешений и журналов глубже подходит статья Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов.
Также фиксируйте retry policy. Один агент может повторять действие пять раз и случайно добиться результата; другой остановится и попросит доступ. Без общего правила сравнение нечестно. Для внешних эффектов повтор должен проходить через idempotency, approval и verification.
Как тестировать approvals, permissions, restraint и stopping
Бенчмарк ИИ-агентов 2026 должен оценивать safety как часть выполнения, а не как отдельный опросник. Сначала смотрим least required authority: агент просит только нужный доступ или пытается расширить полномочия. Затем approval timing: подтверждение появляется до действия с последствиями, а не после. Третья точка — clarification: агент уточняет получателя, дату, файл или канал, когда намерение неоднозначно.
KnowU-Bench важен для этой темы, потому что проверяет proactive consent и restraint after rejection. Если пользователь сказал «нет», агент должен остановить или изменить план, а не продолжать обходным путем. Refusal rate сам по себе не измеряет безопасность: полезный агент должен не только отказываться, но и предлагать правильный безопасный путь, например открыть экран настройки, сохранить черновик или запросить недостающий параметр.
В тестах нужно включать stop command и audit. Пользователь говорит «останови», отключает разрешение, меняет экран, закрывает приложение, отклоняет approval. Агент должен сохранить состояние, показать, что уже сделано, и дать recovery path. Подробную сторону approval UX мы разбираем в статье Интерфейс подтверждения действий ИИ-агента на телефоне: уверенность, причины и восстановление, а security state — в материале Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов.
Как мы бы оценивали текущие задачи FoneClaw
По актуальной информации о продукте на момент обновления статьи, FoneClaw дает текущие пользовательские поведения для test matrix: floating assistant, current-screen attachment, task continuity, approvals and stopping, permission recovery, DND, volume, meeting-mode, screenshot reliability и quick actions. Актуальную сборку можно получить на странице загрузки FoneClaw. Этот guide описывает метод оценки и не публикует FoneClaw score.
Первый класс тестов — read-only state. Агент должен прочитать текущий видимый экран, описать состояние, отличить системную подсказку от контента приложения и не выполнять side effect. Второй класс — reversible device control: DND, volume, Bluetooth state, screenshot. Здесь проверяем expected state до и после действия, approval по риску, latency и rollback или recovery.
Третий класс — external-effect preparation: messaging, calendar, tasks, memo, navigation. Например, «подготовь SMS-черновик и покажи перед отправкой» должен проверять получателя, текст, default app и stable control. Четвертый класс — permission loss: отключаем доступ и смотрим, сохраняет ли агент task state, запускает ли permission recovery и возвращается ли к задаче. Пятый — current-screen change: пользователь меняет экран во время выполнения, а агент должен перечитать состояние, а не действовать по старому snapshot.
На странице возможностей FoneClaw мы описываем 100+ built-in tools и governed Android workflows. Для benchmark это не список обещаний, а источник классов задач: visible-screen workflows, app opening, DND, volume, Bluetooth, screenshots, calendar, memo, messaging, tasks, workflows и shortcuts under risk-appropriate contracts. Конкретный user-facing audit scenario можно взять из статьи Проверка состояния Android с ИИ: разрешения, особый доступ и скрытые приложения.
Как собрать воспроизводимый протокол phone-agent benchmark
Воспроизводимый бенчмарк телефонных агентов Android начинается с протокола. Зафиксируйте device model, Android version, OEM build, locale, app versions, account state, permissions, network, battery mode, retry policy и allowed intervention. Затем опишите initial state и expected state: какой экран открыт, какие данные существуют, какой side effect допустим, где агент должен остановиться.
- Заморозьте среду: устройство, язык, приложения, разрешения, сеть.
- Опишите задачу как intent, initial state, expected result и forbidden side effects.
- Рандомизируйте одну ось за раз: layout, язык, permission, app state, ambiguity.
- Записывайте actions, approvals, stops, retries, screenshots и tool traces.
- Проверяйте side effects устройством или внешним состоянием, а не только текстовым ответом.
- Классифицируйте recovery: successful, user takeover, permission recovery, safe stop, wrong retry.
- Публикуйте ограничения: среда, версии, число задач, denominator и policy.
Начните с обратимого starter test: прочитать текущий экран, включить DND на короткое время, проверить состояние, остановить задачу и восстановить исходное состояние. Когда протокол стабилен, добавляйте messaging draft, navigation, calendar и permission loss. Для governance loop используйте Самоулучшающийся phone agent: версии навыков, тесты и откат. Хороший benchmark не ищет один красивый процент; он показывает, где агент надежен, где нужен approval, а где пользователь должен взять управление.