Агенты через API или через браузер: что дешевле и надёжнее

Задача одна: агент должен зайти в CRM, вытащить сделки за месяц и сложить их в таблицу. Первый вариант — агент обращается к REST API системы, получает JSON и парсит его за долю секунды. Второй — агент открывает браузер, логинится, кликает по фильтрам, ждёт прогрузки, скроллит список и распознаёт данные со скриншота. Оба доводят дело до конца. Но один стоит центы за прогон и работает годами, а второй жжёт токены на каждом скриншоте и падает, как только дизайнеры подвинули кнопку. Выбор между этими двумя архитектурами — главная развилка, которую проходит каждый, кто строит агентов в 2024–2025 годах.

Две философии автоматизации

API-агент работает с системой на её родном языке: HTTP-запросы, структурированные ответы, документированные эндпоинты. Он не видит интерфейс и не должен его видеть. Ему всё равно, как выглядит кнопка «Создать заказ» — он вызывает POST /orders и получает предсказуемый ответ.

Браузерный агент имитирует человека. Он получает скриншот или дерево доступности (accessibility tree) страницы, решает, куда кликнуть, вводит текст, ждёт реакции интерфейса. Этот подход лёг в основу таких продуктов, как OpenAI Operator и Anthropic Computer Use — они управляют реальным браузером или экраном, а не дергают заранее известные ручки.

API-агент знает, что делать. Браузерный агент — смотрит, что происходит, и догадывается. Первый быстрее и дешевле, второй — работает там, где API просто нет.

Почему это не вопрос вкуса

Разница не косметическая. Она бьёт по трём вещам сразу: по счёту за токены, по проценту успешных прогонов и по тому, сколько инженерного времени вы потратите на поддержку. Браузерный агент на каждом шаге отправляет модели изображение страницы — а входные токены за картинку считаются десятками тысяч. API-агент отправляет компактный текст запроса и получает компактный ответ.

Где выигрывает API

Если у целевой системы есть документированный API, а у вас есть к нему доступ и ключ — почти всегда стоит идти через него. Причины прозаичны.

• Стоимость. Текстовый запрос и JSON-ответ на порядок дешевле цепочки скриншотов. Точные цифры зависят от модели и от того, сколько шагов делает агент, но разрыв в расходах на токены между двумя подходами на одной и той же задаче обычно измеряется разами, а не процентами.
• Надёжность. API-контракт меняется редко и с версионированием: /v1/, /v2/. Вёрстка страницы может поменяться в любой релиз без предупреждения.
• Скорость. Нет ожидания прогрузки DOM, нет распознавания картинки — ответ приходит за миллисекунды.
• Детерминированность. Одинаковый запрос даёт одинаковый ответ. Клик по «примерно той же кнопке» — нет.

Отдельный бонус — безопасность и аудит. Вызовы API можно ограничить правами ключа, залогировать и отозвать. Браузерный агент, залогиненный под живой учёткой сотрудника, имеет ровно те же права, что и человек, — включая те, которые вы ему давать не собирались.

Где выигрывает браузер

Браузерный агент нужен ровно тогда, когда API-путь закрыт:

1. API просто нет. Легаси-система, внутренний портал, госсервис без публичного интерфейса — работать можно только через экран.
2. API есть, но доступа к нему нет. Вендор не выдаёт ключи, тариф с API стоит дорого, или интеграция требует подписания договора на недели.
3. Задача размазана по нескольким несвязанным системам. Собрать данные из трёх сервисов, у каждого свой формат авторизации, — иногда браузер оказывается единственным общим знаменателем.
4. Нужен именно человеческий сценарий. Проверить, как выглядит форма для конечного пользователя, пройти капчу-подобный флоу, отработать шаг, который API умышленно не предоставляет.

Расплата за универсальность — хрупкость. Смена лейаута, всплывающий баннер cookie, A/B-тест интерфейса, медленная сеть — всё это ломает агента, который ориентируется по картинке. Поэтому браузерные агенты обвешивают ретраями, таймаутами и человеком в цикле (human-in-the-loop) для подтверждения рискованных действий вроде оплаты.

Сравнение по ключевым параметрам

Практичный ответ — гибрид

На реальных задачах развилка редко бывает бинарной. Разумная архитектура — API там, где он есть, браузер как запасной путь.

• Основной поток данных гоните через API: он несёт нагрузку и деньги.
• Браузер оставьте для «последней мили» — систем без интеграции и разовых операций.
• Рискованные действия (платежи, удаление, отправка внешним контрагентам) выносите на подтверждение человеку независимо от способа.
• Логируйте оба канала одинаково подробно, чтобы разбор инцидента не превращался в археологию.

Ещё один сдвиг стоит держать в голове: MCP* и подобные протоколы постепенно превращают часть браузерных сценариев в API-подобные. Если сервис отдаёт агенту структурированный инструмент вместо страницы для кликанья, то формально это уже не «браузер против API» — это тот же API, просто описанный для модели. Направление движения индустрии очевидно: чем больше систем публикуют инструменты для агентов, тем меньше причин гонять модель по скриншотам.

Если у вас есть API — берите API. Браузер оставьте на случай, когда выбора нет. И заранее считайте не только «работает ли демо», но и сколько будет стоить тысяча прогонов в месяц: именно на этой цифре красивый браузерный агент часто проигрывает скучному API-запросу.

* MCP (Model Context Protocol) — открытый протокол, через который приложение описывает модели доступные инструменты и данные в структурированном виде, вместо того чтобы модель разбирала интерфейс самостоятельно.