Как Android ИИ-агент понимает экран: дерево UI, скриншот или гибрид
Решение для Android ИИ-агента: когда достаточно дерева доступности, когда нужен скриншот и как FoneClaw сочетает структуру, пиксели, подтверждение и проверку.
- Android ИИ-агенту стоит начинать с дерева UI, когда задача опирается на текст, роли, состояния и доступные действия элементов.
- Скриншот нужен, когда важны пиксели: изображения, графики, карты, кастомная отрисовка, визуальная близость элементов или состояние, которого нет в семантическом дереве.
- Гибридный маршрут работает надежнее для сложных экранов: сначала структурная проверка, затем минимальный снимок только для недостающего визуального факта, сверка и подтверждение.
- В FoneClaw мы применяем этот выбор к текущему экрану через поддерживаемые инструменты, видимый прогресс, пользовательское подтверждение и повторную проверку результата.
Что выбрать: дерево UI, скриншот или оба сигнала
Короткое решение такое: Android ИИ-агенту стоит начинать с дерева UI, если задача зависит от текста, роли элемента, состояния переключателя, доступного действия или иерархии экрана. Скриншот нужен, когда важен внешний вид: изображение, график, карта, кастомная кнопка, цветовая подсказка, визуальное расположение или контент, который приложение не выразило в семантических узлах. Гибрид нужен там, где один сигнал отвечает на часть вопроса, а второй закрывает оставшийся риск.
Понимание экрана ИИ-агентом Android не сводится к одному источнику. Дерево доступности дает структурные данные: какие элементы объявлены приложением, где они находятся, какие у них подписи, состояния и действия. Скриншот дает пиксельное доказательство: что действительно видно пользователю в момент захвата. Один сигнал обычно компактнее и ближе к действию, другой богаче визуально и полезен для проверки того, что структура упустила.
Больше входных данных не всегда лучше. Полный скриншот может добавить приватные детали, увеличить стоимость обработки и запутать модель декоративными элементами. Дерево UI может быть экономным и точным, но приложение может отрисовать важный контент в canvas, WebView, карте или изображении без полезной семантики. Поэтому правильный вопрос не «дерево доступности или скриншот», а «какой сигнал доказывает именно этот следующий шаг».
Если читателю нужен полный путь от намерения до выполнения действия, мы разбираем его отдельно в статье Управление Android ИИ-агентом: намерение, подтверждение и проверка результата. Здесь фокус уже: как выбрать доказательство для текущего экрана до того, как агент предложит действие.
Что показывает дерево доступности Android
В Android дерево доступности строится вокруг объектов AccessibilityNodeInfo. В официальном справочнике Android по AccessibilityNodeInfo этот объект описывает узел содержимого окна: текст, описание, состояние, границы, фокус, доступные действия и связи с родителем или дочерними элементами там, где приложение предоставляет такие данные.
Для агента это ценно, потому что структура часто отвечает на практические вопросы без изображения. Есть ли на экране кнопка «Сохранить»? Какой переключатель включен? Какой элемент сейчас выбран? Где находится поле ввода? Можно ли нажать, прокрутить или изменить значение? Когда приложение правильно заполняет текст, content description, checked-состояние, clickable-состояние, focus и bounds, дерево UI становится быстрым и проверяемым способом выбрать цель.
Android требует явной настройки службы для получения содержимого окна и возможностей жестов. Документация Android по службам доступности описывает их как специализированную технологию, которую пользователь включает для ассистивных сценариев. Для телефонного агента это важная граница продукта: доступ к структуре экрана появляется через пользовательское разрешение и поддерживаемый путь, а не как скрытый общий канал автоматизации.
У дерева UI есть типовые слабые места. Во-первых, некоторые видимые элементы отсутствуют, если приложение рисует их как изображение, canvas или сложный WebView без доступной разметки. Во-вторых, узлы могут дублироваться, особенно в списках, где похожие карточки имеют одинаковые подписи. В-третьих, состояние может устареть между событием доступности и действием, потому что экран изменился или список прокрутился. В-четвертых, текст или описание могут быть слишком общими: «кнопка», «изображение», «далее», без контекста. Добавим еще одну частую проблему: bounds могут указывать на область элемента, но не объяснять, какая часть визуальной карточки реально является нужной целью.
Из этого следует практическое правило. Дерево UI хорошо подходит для форм, настроек, списков, переключателей и кнопок с ясной семантикой. Оно слабее для визуальных сравнений, графиков, дизайнерских карточек и экранов, где смысл живет в пикселях.
Когда нужны пиксели экрана
Скриншот фиксирует то, что пользователь видит на экране в конкретный момент. Это не семантическая карта приложения, а пиксельное доказательство: цвета, изображения, расстояния, наложения, диаграммы, карты, состояния загрузки, визуальные акценты и фактическая компоновка. Когда дерево UI и компьютерное зрение работают вместе, агент может не только прочитать объявленные элементы, но и проверить, как они выглядят в реальном интерфейсе.
Скриншот нужен, когда задача спрашивает о визуальном факте. Например: «какая из карточек выделена зеленым», «на графике есть резкий скачок», «какой маршрут короче на карте», «эта кнопка находится под предупреждением или над ним», «на экране появился QR-код», «форма выглядит заполненной или остались пустые поля». Дерево UI может показать текст и координаты, но не всегда передает цвет, плотность данных, изображения, графические отношения и нестандартную отрисовку.
У пиксельного подхода свои режимы отказа. Во-первых, OCR может прочитать текст, но не доказать, что это нужный управляющий элемент. Во-вторых, координаты зависят от размера экрана, ориентации, системных панелей, масштабирования шрифта и наложений. В-третьих, анимация, прокрутка или обновление данных могут сделать снимок устаревшим до действия. В-четвертых, изображение раскрывает больше приватного контекста, чем нужно для узкой задачи: соседние уведомления, имена, фотографии, сообщения или фрагменты приложений. Еще один риск состоит в том, что модель может придать декоративному элементу смысл, которого у него нет в приложении.
Поэтому скриншот лучше использовать как точечное доказательство. Если вопрос решается через семантический узел, снимок не обязателен. Если же важный факт существует только визуально, изображение стоит захватывать минимально, с понятной целью и с последующей проверкой свежего состояния.
Сравнение сигналов по качеству доказательств
Ни дерево UI, ни скриншот не являются универсальным источником истины. Один маршрут ближе к семантике и действию, второй ближе к видимому экрану. Для мультимодального Android-агента важнее не выбрать любимый сигнал, а понять, какой из них снижает неопределенность в конкретной задаче.
| Критерий | Дерево UI | Скриншот | Практическое решение |
|---|---|---|---|
| Текст и подписи | Часто компактно показывает текст, content description и роль | Может прочитать видимый текст через OCR, но без роли элемента | Начинайте со структуры, добавляйте снимок при сомнительной разметке |
| Состояния и действия | Может показывать checked, selected, focused, clickable и доступные действия | Показывает внешний признак состояния, если он заметен | Для переключателей и форм сильнее дерево UI, для визуальных индикаторов нужен снимок |
| Изображения, графики, карты | Часто дает слабое описание или общий контейнер | Показывает пиксельную форму, цвет и расположение | Используйте визуальную привязку, затем проверяйте действие свежим состоянием |
| Стоимость и задержка | Обычно компактнее для модели и быстрее для анализа | Больше данных, выше стоимость обработки и риск лишнего контекста | Не отправляйте изображение, если структурного сигнала достаточно |
| Приватность | Раскрывает объявленные узлы текущего окна | Раскрывает весь видимый экран в области захвата | Собирайте только тот сигнал, который нужен для решения |
| Проверка результата | Хорошо подтверждает появление элемента, состояние или текст | Хорошо подтверждает визуальное изменение и layout | После действия перечитайте свежий экран, а не полагайтесь на старую догадку |
Для задач заполнения форм это различие особенно заметно. Подробный разбор того, какие поля и подтверждения реально стоит доверять AI, вынесен в статью Заполнение форм Gemini на Android: что реально можно доверить AI. В общем случае форма начинается со структуры, а скриншот помогает там, где внешний вид или ошибка валидации не выражены узлами.
Гибридный маршрут: структура плюс визуальная проверка
Гибридный маршрут начинается не со снимка, а с вопроса: что агенту нужно доказать перед следующим шагом? Мы в FoneClaw строим такой процесс как последовательность inspect, capture, reconcile, approve, act, verify. В переводе на повседневный Android это означает: прочитать текущий экран, заметить пробелы, захватить минимальное изображение при необходимости, сверить сигналы, показать предложение, получить подтверждение для значимого действия, выполнить поддерживаемый шаг и проверить новое состояние.
Первый этап - структурный осмотр. Агент получает текущие элементы, их подписи, состояния, bounds и доступные действия. Если пользователь просит «нажми кнопку сохранения», а дерево показывает одну видимую кнопку с понятным текстом и состояние экрана стабильно, снимок может только добавить шум. Если же на экране две одинаковые кнопки «Далее», карточка с изображением товара или график без семантики, появляется вопрос к пикселям.
Второй этап - обнаружение неопределенности. Сигнал слабый, если целевой узел отсутствует, повторяется, имеет слишком общий текст, конфликтует с визуальным положением, находится под оверлеем или зависит от цвета и layout. В этот момент агент должен остановить уверенное действие и собрать ровно тот дополнительный контекст, который нужен. Полный скриншот оправдан, когда визуальный факт нельзя получить из структуры; частичный или пользовательски выбранный контекст лучше, когда задача узкая.
Третий этап - сверка. Узел и пиксель должны указывать на одну и ту же область. Если дерево говорит «кнопка отправки», но скриншот показывает, что поверх нее открыто предупреждение, действие переносится на уточнение. Если OCR видит слово «Удалить», но узел не сообщает доступное действие или экран относится к другому приложению, агент не должен угадывать. Конфликтующие доказательства требуют вопроса пользователю или ручного продолжения.
Четвертый этап - предложение и подтверждение. Для низкорискового чтения достаточно показать найденный факт. Для действия с последствиями нужны параметры: какое приложение, какой элемент, что изменится, как будет проверен результат. Это относится к нажатию кнопки, отправке черновика, изменению настройки, сохранению записи и любому шагу, который меняет состояние телефона. Углубленную архитектуру разрешений и границ мы рассматриваем в статье Песочница AI-агента и разрешения телефона: почему безопасным агентам нужны границы.
Последний этап - свежая проверка. Экран мог измениться между анализом и касанием: появился диалог, список прокрутился, сеть обновила данные, приложение перерисовало карточку. Поэтому результат стоит проверять новым структурным чтением, новым снимком или обоими сигналами, если именно визуальное состояние было целью.
Как мы применяем это в FoneClaw
FoneClaw - Android phone-agent runtime: настроенная модель рассуждает и планирует, а FoneClaw предоставляет управляемые поддерживаемые инструменты для действий на телефоне. Пользователь может начать с бесплатной модели FoneClaw по умолчанию, а затем, при необходимости, настроить совместимую модель. В разделе возможностей FoneClaw мы показываем текущий продуктовый контур, включая 100+ встроенных инструментов и сценарии, где экранный контекст помогает перейти к следующему шагу.
Для текущего экрана мы не начинаем с идеи «всегда снимай изображение». В практической задаче FoneClaw сначала может использовать structured screen information через get_screen_info или cross_app_read_screen, когда пользователь просит понять открытый экран, найти элемент или подготовить следующий шаг. Такой путь хорошо подходит для текстовых экранов, настроек, списков, форм и состояний, которые приложение выражает в доступных узлах.
Когда вопрос становится визуальным, FoneClaw может подключить screenshot_take или screenshot_open. Это помогает в сценариях, где пользователь сам выбрал контекст, приложил снимок или просит проверить то, что видно глазами: график, изображение, layout, предупреждение, карточку, карту или нестандартный интерфейс. В текущем продукте мы усилили работу с пользовательски выбранными изображениями и снимками: размеры, ссылки на файл, повторный анализ и подготовка мультимодального запроса помогают сохранять связь между визуальным фактом и последующим планом.
Главное для нас - не собрать максимум данных, а сделать путь проверяемым. FoneClaw показывает прогресс, работает через разрешения Android, может остановиться при недостающем доступе и оставляет значимые действия видимыми для пользователя. Если запрос касается плавающего помощника и текущего экрана поверх другого приложения, практический интерфейсный слой разобран отдельно в статье Плавающий ИИ-ассистент Android и текущий экран: контекст, действия и контроль.
После выполнения мы проверяем результат свежим состоянием, а не считаем сам вызов инструмента успехом. Если экран сменился не так, как ожидалось, если нужный элемент исчез или если приложение требует ручного выбора, корректный маршрут показывает это пользователю. Для установки и проверки актуального выпуска используйте страницу загрузки FoneClaw, а для формального сравнения телефонных агентов по надежности подойдет Бенчмарк телефонных агентов Android: как оценивать ИИ-агента в 2026 году.
Как проверить понимание экрана на безопасной задаче
Проверять понимание экрана лучше на обратимой задаче в том приложении, устройстве и версии Android, где вы реально собираетесь работать. Хороший первый тест: открыть настройки с безвредным переключателем, список заметок без личных данных или экран приложения, где можно отменить изменение. Высокорисковые действия, платежи, публикации, удаление данных и отправка сообщений не подходят для первого испытания.
- Выберите экран и заранее запишите ожидаемую цель: какой элемент должен быть найден и какое состояние считается правильным.
- Попросите агента объяснить экран только по дереву UI: какие узлы он видит, какой элемент считает целью и почему.
- Добавьте скриншот только для факта, который структура не доказала: цвет, график, изображение, визуальное положение или оверлей.
- Измените состояние один раз: прокрутите список, поверните экран или откройте небольшой диалог, чтобы проверить, замечает ли агент свежий контекст.
- Прервите процесс до действия и посмотрите, показывает ли агент, что уже понял и где остановился.
- Разрешите только обратимый шаг, затем проверьте итог новым чтением экрана или снимком.
Один успешный экран показывает, что выбранный маршрут подходит для этого сценария. Широкую совместимость нужно доказывать набором экранов: семантические формы, визуальные карточки, изменяющиеся списки, неоднозначные элементы и ручной fallback. Именно так дерево UI и компьютерное зрение становятся инженерным решением, а не эффектной догадкой.