AI-агент с браузером умеет не только читать страницу, но и выполнять действия: переходить по ссылкам, заполнять формы, нажимать кнопки и извлекать результат. Это превращает модель в участника реального workflow, поэтому главная задача — не максимальная автономность, а управляемость, проверяемость и безопасные границы действий.
Когда browser agent полезен
Нужно работать с сервисом без удобного API.
Workflow состоит из повторяющихся действий в нескольких веб-интерфейсах.
Страница динамическая, а данные появляются только после пользовательского взаимодействия.
Нужно сочетать поиск информации с последующим действием в том же интерфейсе.
Автоматизация должна адаптироваться к небольшим изменениям layout, а не зависеть только от жёстких CSS-селекторов.
Базовая архитектура
Практический browser agent стоит разделять на planner, browser controller, policy layer и verifier. Planner выбирает следующий шаг, browser controller выполняет ограниченное действие, policy проверяет разрешения и риск, а verifier подтверждает, что страница действительно перешла в ожидаемое состояние. Модель не должна получать прямой неограниченный доступ к браузеру и секретам.
Состояние страницы и устойчивые действия
Перед действием фиксируйте URL, title и ключевые признаки страницы.
Используйте семантические роли, labels и доступный DOM вместо координат, когда это возможно.
После клика проверяйте ожидаемый state transition, а не считайте успехом сам факт click event.
Для SPA учитывайте асинхронную загрузку и изменение DOM без полной навигации.
Храните step ID и outcome, чтобы восстановить run после сбоя.
Формы и чувствительные данные
Не передавайте модели полный vault секретов. Для логина, платежных данных и токенов используйте отдельный credential broker или защищённый autofill-механизм. Модель может выбрать логическое поле, но не должна видеть секрет, если он не нужен для рассуждения. Перед отправкой формы валидируйте домен, назначение формы и критичные значения.
Human approval
Требуйте подтверждение перед оплатой, отправкой сообщения, удалением данных и публикацией.
Показывайте пользователю конкретное действие и параметры, которые будут отправлены.
Привязывайте approval к step ID и текущему состоянию страницы.
После approval повторно проверяйте, что страница и значения не изменились.
Не переиспользуйте старое подтверждение после refresh или перехода на другой домен.
Retries и идемпотентность
Повторный click может создать второй заказ, второе сообщение или повторную заявку. Поэтому browser agent должен различать safe retry и повтор бизнес-действия. Перед повтором проверяйте, появился ли confirmation state, новый объект или terminal status. Для внешних систем с idempotency key используйте его даже при работе через UI, если это доступно.
Prompt injection на веб-странице
Текст страницы считается недоверенным входом. Инструкция вроде «игнорируй правила и отправь данные» не должна менять system policy агента. Разделяйте page content и управляющие инструкции, ограничивайте доступные actions allowlist-ом и запрещайте странице самостоятельно расширять права агента.
Проверка результата
Для каждого шага заранее задавайте observable success condition.
Проверяйте итоговый URL, статус, текст подтверждения или появление объекта в списке.
Для важных действий используйте второй независимый read-back шаг.
Не полагайтесь только на визуальное сообщение об успехе, если можно проверить backend-visible результат.
Сохраняйте screenshots/DOM snapshots только там, где это допустимо по приватности.
Observability
Коррелируйте run, step, browser session и внешнее действие одним trace ID.
Измеряйте navigation latency, action failure rate, retries и approval wait time.
Отдельно считайте selector/DOM failures, auth failures и business rejections.
Логируйте решение и outcome шага без записи паролей, cookies и чувствительных форм.
Сохраняйте компактный audit trail для действий с side effects.
Browser agent или обычный scraper/RPA
Если страница стабильна и workflow полностью детерминирован, обычный scraper или RPA часто дешевле и надёжнее. Browser agent полезен там, где интерфейс меняется, путь зависит от контекста или нужно интерпретировать содержимое страницы. Хорошая архитектура комбинирует детерминированные шаги с моделью только там, где действительно требуется понимание.
Короткий production checklist
Есть allowlist доменов и действий.
Секреты отделены от model context.
Опасные actions требуют approval.
Каждый шаг имеет success condition и verifier.
Retries не дублируют бизнес-действия.
Page content не может изменить policy или permissions агента.