Когда ИИ-агент работает с веб-интерфейсом, у него есть два стандартных инструмента восприятия. Первый — читать исходный код: HTML, CSS, JavaScript. Второй — анализировать скриншоты страницы, а в теории и видеозаписи. Оба подхода существуют давно, оба активно используются в инструментах автоматизации и тестирования — и оба имеют принципиальные ограничения, которые становятся особенно заметны при масштабировании.
Код описывает структуру, но не состояние. По разметке невозможно определить, что кнопка оказалась за пределами экрана после рендера, что два блока наложились друг на друга, что выпадающее меню перекрыто другим элементом. Элемент может формально присутствовать в DOM, но быть полностью недоступен пользователю — и код об этом не скажет. Контекстное окно можно растянуть до миллиона токенов, применить сжатие или разряженное внимание, но это не решает проблему: модель всё равно работает с описанием интерфейса, а не с самим интерфейсом после рендера.
Скриншоты закрывают часть этих пробелов, но создают новые. Чтобы адекватно понять страницу, одного кадра недостаточно: нужны снимки при разных viewport, в разных состояниях — hover, focus, открытые модальные окна, процесс загрузки, динамические изменения. Браузер внутренне уже хранит всю эту информацию как структуру элементов с геометрией и состояниями — но модель вынуждена заново извлекать её из пикселей. Это дорого и по вычислительным ресурсам, и по деньгам: мультимодальные вызовы со скриншотами стоят существенно больше текстовых.
Скриншот не фиксирует состояния: hover, focus, модальные окна, динамические изменения.
Человек решает ту же задачу иначе. Глядя на страницу, он почти мгновенно различает кнопки, поля ввода, меню, границы блоков и сломанные элементы — не восстанавливая DOM из кода и не анализируя каждый пиксель фона. Это восприятие работает на уровне семантических объектов: «овал с надписью — кнопка», «изменение цвета при наведении — интерактивный элемент». Именно этого уровня абстракции моделям сейчас не хватает.
Автор материала на Habr формулирует идею третьего слоя восприятия — промежуточного представления интерфейса, которое не является ни сырым кодом, ни растровым изображением. Такой слой должен передавать модели структуру элементов, их геометрию, состояния и визуальную доступность — примерно так, как браузер хранит это внутри себя через accessibility tree или аналогичные механизмы. Это не требует новой архитектуры трансформеров и не предполагает отказа от существующих подходов — речь о специализированном модуле восприятия, встроенном постоянно, а не генерируемом агентом заново под каждую задачу.
Подобные идеи не возникают в вакууме. Инструменты вроде Playwright и Puppeteer уже экспортируют accessibility tree — машиночитаемое дерево доступности, которое описывает элементы страницы с их ролями и состояниями. Некоторые исследовательские проекты используют его как входные данные для ИИ-агентов вместо скриншотов. Однако до стандартного, универсально подключаемого «глаза» для моделей этот подход пока не дорос. Опрос, проведённый на Habr параллельно с публикацией, показал: 72% из 18 проголосовавших считают высокую стоимость использования и инфраструктуры одной из ключевых проблем современных ИИ-систем — что косвенно подтверждает запрос на более экономичные способы восприятия.
