Пользователь открывает форму доставки и видит поле города, список пунктов выдачи, карту и кнопку «Продолжить». Браузерный агент получает ту же задачу, но сообщает, что не может найти пункт выдачи. Или находит кнопку, нажимает ее, а форма не отправляется.

Обычно после такого начинают менять промпт, модель или локаторы. Но фраза «агент не видит элемент» еще не описывает проблему. Сначала нужно выяснить, что именно инструмент показал модели, как обозначил доступные цели и какое состояние вернул после действия.

Модель не видит веб‑страницу напрямую. Между браузером и моделью существует интерфейс, который можно назвать контрактом наблюдения. Он определяет, какое представление страницы получит модель, какую часть страницы оно охватит, как элемент будет связан с последующим действием, когда наблюдение обновится и по каким данным агент поймет результат.

Если этот контракт не соответствует задаче, сильная модель будет уверенно рассуждать о неполной или устаревшей картине.

Страница, наблюдение и действие

Браузер хранит сразу несколько представлений интерфейса. DOM описывает узлы документа. Дерево доступности, или accessibility tree, содержит роли элементов, доступные имена, состояния и отношения. Отрисованный кадр хранит расположение, цвет, перекрытия и графику.

Это не три формата одного и того же файла. Между ними нет полного взаимно однозначного соответствия.

Chrome называет дерево доступности производным от DOM и объясняет, что оформительские узлы без семантического содержания могут быть из него исключены. У оставшихся узлов есть роли вроде button и heading, а имена могут вычисляться из содержимого или ARIA‑атрибутов.

В спецификации W3C среди данных accessibility API перечислены роль, имя, значение, временные состояния, отношения, события и доступные действия. Как Chrome строит accessibility tree, Core Accessibility API Mappings W3C.

Простейший цикл агента выглядит так:

  1. Управляющий код считывает состояние браузера и собирает наблюдение.

  2. Модель выбирает следующее действие.

  3. Управляющий код исполняет его в браузере.

  4. Новое состояние снова преобразуется в наблюдение.

На практике ошибки возникают не только на втором шаге. Инструмент может не включить нужный элемент в наблюдение, связать команду не с той целью, исполнить ее в уже изменившемся интерфейсе или вернуть недостаточно данных для проверки результата.

Поэтому полезно описывать контракт наблюдения пятью параметрами.

Параметр

Вопрос к реализации

Что ломается при неудачном выборе

Представление

Модель получает снимок дерева, скриншот, DOM или их сочетание?

Значимая информация отсутствует в выбранном канале

Область

В наблюдение попадает весь документ, видимая область или отдельное поддерево?

Нужный элемент остается за границей либо контекст забивается лишними данными

Привязка цели

Действие адресуется через ref, локатор, текст или координаты?

Намерение модели связывается не с тем элементом

Актуальность

Когда снимок считается устаревшим и запрашивается новый?

Действие применяется к состоянию, которого уже нет

Обратная связь

Что агент получает после клика или ввода?

Выполненная команда ошибочно принимается за успешный результат

Этот набор не является стандартом какого‑либо фреймворка. Это инженерная модель, с помощью которой удобно сравнивать реализации и разбирать сбои.

Понимание того, как ИИ-агент получает данные и принимает решения, — один из ключевых навыков при создании современных приложений с ИИ.

В отдельном разборе мы посмотрели, как устроена архитектура ИИ-агентов и какие компоненты нужны для их разработки. Читать разбор.

Два реальных контракта

Разницу хорошо видно на стандартных контурах Playwright MCP и OpenAI Computer Use. Это не сравнение качества моделей и не результат эксперимента. Ниже сопоставлены интерфейсы, описанные в официальной документации.

Структурированный контур Playwright MCP

Playwright MCP по умолчанию использует снимок дерева доступности, а не пиксельный ввод. Инструмент browser_snapshot возвращает текущее accessibility‑представление страницы. Снимок можно ограничить выбранным элементом и глубиной, а также добавить координатные рамки узлов.

Действия получают точную ссылку на элемент из снимка либо уникальный селектор. Скриншоты поддерживаются отдельно, а координатные команды включаются опциональной возможностью vision. README Playwright MCP.

В актуальном API Playwright ARIA snapshot представлен в YAML. В нем видны роли, доступные имена, текст и часть состояний.

Режим ai добавляет ссылки вида [ref=e2], а параметры depth и boxes управляют глубиной дерева и координатами элементов. Документация locator.ariaSnapshot(), руководство по ARIA snapshots.

Упрощенное наблюдение может выглядеть так:

- heading "Выберите пункт выдачи" [level=1]
- textbox "Город": Ростов-на-Дону
- region "Карта пунктов выдачи"
- button "Закрыть карту" [ref=e7]
- button "Продолжить" [ref=e9]

Это иллюстрация документированного формата, а не результат запуска на конкретном сайте.

Для обычной формы такое представление удобно. Название кнопки aria-label="Закрыть карту" понятнее модели, чем нарисованный крестик. Роль textbox сразу сообщает, как взаимодействовать с полем. Ссылка ref связывает рассуждение модели с последующей командой.

Цена этой определенности заключается в зависимости от семантики страницы. Если разработчик сделал выпадающий список из кликабельного div, но не задал ему роль, имя и состояние, структура интерфейса для агента будет беднее видимой страницы.

Содержимое canvas тоже не превращается автоматически в набор осмысленных маркеров. Кроме того, полный снимок большого приложения может занять заметную часть контекста, поэтому область и глубину наблюдения приходится ограничивать.

Визуальный контур OpenAI Computer Use

Во встроенном цикле OpenAI Computer Use модель получает скриншот текущего интерфейса и возвращает структурированные действия, включая клик, прокрутку, ввод, нажатие клавиш и перетаскивание. Управляющий код исполняет действия, делает новый снимок экрана и передает его модели.

В документации этот путь прямо описан как визуальное взаимодействие. Там же предусмотрены два других варианта: собственный harness на Playwright, Selenium, VNC или MCP и среда выполнения кода, в которой можно сочетать изображения с DOM‑операциями. Руководство OpenAI Computer Use.

Скриншот сохраняет то, что теряет дерево доступности: геометрию, взаимное расположение, графику, состояние карты, перекрывающий кнопку индикатор загрузки. Он ближе к тому, что видит человек.

Но пиксели не содержат явного объекта «кнопка Продолжить». Модели нужно распознать элемент, оценить его координаты и предположить способ взаимодействия. Иконка без подписи может быть неоднозначной, а маленькая ошибка координат приводит к клику по соседнему элементу. После прокрутки, анимации или изменения масштаба старые координаты перестают описывать текущий кадр.

Параметр

Playwright MCP по умолчанию

Встроенный OpenAI Computer Use

Представление

Структурированный accessibility snapshot

Скриншот текущего UI

Область

Страница или выбранное поддерево, глубину можно ограничить

Текущий экран; охват меняется прокруткой и размером среды

Привязка цели

Ссылка из снимка или селектор

Координаты и тип действия

Сильная сторона

Роли, имена, состояния, адресуемые элементы

Геометрия, перекрытия, canvas и прочая графика

Типичный пробел

Визуально понятный, но семантически пустой виджет

Семантика, не выраженная заметным текстом или формой

Эта таблица не делит инструменты на «умный» и «слепой». У Playwright MCP есть скриншоты и опциональные координатные действия. OpenAI допускает собственные инструменты и DOM‑сценарии. Сравниваются именно базовые способы наблюдения, а не все возможности продуктов.

Как контракт ломается на одной форме

Вернемся к форме доставки. Запускать двух агентов необязательно, чтобы найти потенциальные разрывы. Достаточно последовательно проверить, в каком представлении существует каждый значимый факт.

  1. Самодельный список пунктов выдачи. На экране это поле со стрелкой. В DOM это может быть div с обработчиком onclick, а в accessibility tree он останется без роли combobox, доступного имени и состояния expanded. Визуальный агент распознает сходство с контролом. Структурированный агент увидит текст, но не обязательно поймет, что с ним можно взаимодействовать. Здесь нарушен параметр представления.

  2. Кнопка закрытия карты. На экране виден только крестик, но в разметке есть aria-label="Закрыть карту". Структурированный снимок дает модели точное назначение. Визуальному агенту приходится интерпретировать условный знак. Здесь семантический канал информативнее изображения.

  3. Маркеры внутри canvas. Для браузера это растровая область, если приложение не предоставило отдельные доступные элементы или альтернативное описание. Структурированный снимок может показать саму карту, но не координаты и подписи нарисованных точек. Скриншот сохранит маркеры и их взаимное расположение. Здесь нужен визуальный канал либо специальный программный интерфейс приложения.

  4. Кнопка под индикатором загрузки. Дерево может по‑прежнему содержать кнопку «Продолжить», хотя поверх нее расположен непрозрачный слой. Скриншот покажет перекрытие. Однако правильное решение состоит не просто в подключении зрения. Исполнитель действия должен проверить, что элемент действительно доступен для клика, а агент после попытки должен получить обновленное состояние.

  5. Перерисовка списка после выбора города. Снимок, ссылка на узел и координаты корректны только для некоторого состояния страницы. После обновления DOM, прокрутки или анимации прежнее описание цели может больше не соответствовать интерфейсу. Здесь ломается уже не представление, а актуальность.

Последние два случая особенно важны. Обсуждение браузерных агентов часто сводят к выбору между деревом и картинкой, хотя способ обновления и проверки наблюдения влияет на надежность не меньше.

Четыре места, где стоит искать ошибку

Когда агент промахивается, формулировка модель не справилась слишком груба. Полезнее разделить траекторию на четыре этапа.

Этап

Диагностический вопрос

Признак проблемы

Наблюдение

Нужный элемент или состояние вообще попали во вход модели?

В снимке нет контрола, на кадре не видна нужная область

Интерпретация

Правильно ли модель поняла роль и намерение?

Элемент присутствует, но выбран неверный способ действия

Исполнение

Команда дошла до нужной цели в актуальном состоянии?

Клик перехвачен, координаты сместились, цель изменилась

Проверка

Есть ли свидетельство достижения результата?

Команда выполнилась без ошибки, но страница осталась прежней

Для диагностики стоит сохранять не только финальный ответ модели. Нужны наблюдение перед действием, выбранная цель, параметры команды и наблюдение после нее. Тогда становится видно, где именно исчезла информация. Иначе ошибку исполнителя легко принять за слабое рассуждение, а отсутствие элемента во входе пытаться лечить новым промптом.

Как проектировать наблюдение для своего агента

Универсального формата нет, но есть несколько практических правил.

Для форм, таблиц, навигации и операций над текстом выгодно начинать со структурированного представления. Оно явно сообщает роли и имена, позволяет адресовать элемент и обычно содержит меньше визуального шума. Для карт, графических редакторов, canvas, drag‑and‑drop и задач, где важны положение или перекрытие, нужен скриншот.

Гибридный контракт не означает «передавать и полное дерево, и полноразмерный скриншот после каждого шага». Это быстро раздувает контекст и оставляет модели задачу самой разрешать противоречия между каналами.

Полезнее маршрутизировать наблюдение: сначала получить компактную структуру, затем запросить изображение при наличии визуального виджета, неоднозначной цели или неудачного действия. На большой странице лучше отдавать выбранное поддерево или результат поиска, а не весь интерфейс.

После любого действия, способного изменить расположение или состав страницы, следует обновить наблюдение. Для важного шага нужно заранее определить наблюдаемый критерий успеха: появился адрес в итоговом блоке, закрылось модальное окно, изменился URL, исчез индикатор, стала доступна следующая кнопка. Сам факт отправки команды click таким критерием не является.

Перед реализацией полезно письменно ответить на пять вопросов:

  1. Какое представление получает модель в этом типе задачи?

  2. Как определяется область наблюдения и как агент расширяет ее?

  3. Чем адресуется цель действия?

  4. Какие события делают предыдущее наблюдение устаревшим?

  5. Какие данные подтверждают успех или требуют восстановления?

Если ответы существуют только внутри кода нескольких инструментов, контракт уже есть, просто он неявный. Именно такие контракты труднее всего отлаживать.

Где заканчивается эта модель

Контракт наблюдения не объясняет все ошибки браузерного агента. Даже при полном и свежем входе модель может построить неверный план, забыть ограничение, неправильно обработать неоднозначность или нарушить политику подтверждений. Отдельно остаются авторизация, защита от инструкций со страницы, чувствительные действия и восстановление после сетевых сбоев.

Кроме того, возможности инструментов меняются. Структурированные решения получают координатные и визуальные функции, а визуальные контуры дополняются DOM и программным исполнением. Поэтому полезно оценивать не название продукта, а конкретную конфигурацию интерфейса между браузером и моделью.

Главный вывод прост. AI‑агент видит не страницу, а наблюдение, собранное для него инструментом.

До настройки промпта стоит проверить пять частей контракта:

  1. Представление.

  2. Область

  3. Привязку цели.

  4. Актуальность.

  5. Обратную связь.

Если вы работаете с ИИ‑агентами, важно понимать не только возможности модели, но и то, как она получает данные, вызывает инструменты и проверяет результат. На бесплатных уроках Otus будут разбираться практические подходы к созданию и применению ИИ‑агентов в разработке, присоединяйтесь:

  • 1 октября, 20:00. «Навыки ИИ‑агентов: как повысить продуктивность разработчика». Записаться

  • 19 октября, 20:00. «ИИ‑агенты в реальной разработке: что они уже умеют делать». Записаться

  • 20 октября, 20:00. «Tool Calling и MCP: интеграция ИИ‑агентов с корпоративными системами». Записаться

Полный список уроков сентября можно посмотреть в дайджесте.

Комментарии (0)