Курс · Как агенты работают с внешними сервисами

Две двери в любой сервис: через браузер или через API.

Чтобы агент что-то сделал в Gmail, CRM или Telegram, у него есть два способа: вести себя как живой пользователь в браузере — или дёргать сервис напрямую через API. Всё остальное — промежуточные варианты на этой шкале.

Что такое frontend, backend и API

Три термина, которые дальше будут мелькать постоянно. Один раз разобрались — и всё встанет на места.

🖼
Frontend
то, что видно на экране
Кнопки, формы, таблицы, графики — всё, что вы можете кликнуть и прочитать в браузере. Это «витрина» сервиса.
🖱 Через браузер цепляемся к видимому UI
↓ внутренние вызовы между frontend и backend ↓
⚙️
Backend
невидимая часть сервиса
Вся логика и данные: кому отправить письмо, где лежит клиент, как посчитать сумму сделки. На вашем экране этого нет — оно живёт на серверах сервиса.
🔌 Через API цепляемся к backend напрямую

API — это «дверь в backend». Сервис сам решает, какие действия через эту дверь пускать. Поэтому наборы функций в UI и в API часто не совпадают:

  • API уже, чем UI — сервис выставил наружу только часть операций. В интерфейсе кнопка есть, а через API этого не сделать.
  • API шире, чем UI — наоборот: массовые операции, служебные и админские функции бывают доступны только программно.

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

Два главных пути

Самое чистое противопоставление: «живой пользователь в браузере» против «прямой вызов API». Между ними — всё остальное.

Путь через frontend

🖱 Агент-пользователь

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

Гибко, работает где угодно. Но медленно и дорого.
Путь через backend

🔌 Официальный API / MCP

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

Быстро, надёжно, легально. Только если сервис его даёт.

Задача: отправить письмо клиенту через Gmail

🖱 Агент-пользователь 0.0с · 0
mail.google.com
✏️ Написать
Анна К.Встреча завтра?
Slack3 упоминания
NotionShared doc
StripeОплата
Новое сообщение
Кому:
Тема:
Отправить
🔌 Официальный API / MCP 0.0с · 0

Что мы только что увидели

Критерий 🖱 Агент-пользователь 🔌 Официальный API
Куда цепляется frontend — видимый UI backend — публичная дверь
Время на действие секунды — минуты миллисекунды
Стоимость вызова высокая — LLM на каждом шаге копейки
Если сервис обновился адаптируется в процессе продолжает работать — контракт стабилен
Набор доступных функций всё, что есть в UI только то, что опубликовали
Риск блокировки средний — CAPTCHA, анти-бот минимальный — легальный канал
Что нужно для подключения только логин API-ключ или MCP-сервер

А между ними — промежуточные варианты

У каждого из двух путей есть «сосед», который двигает компромисс в одну или другую сторону. Раскройте, чтобы посмотреть сравнение бок о бок.

🤖 Скрипт-робот — фиксированный путь через тот же браузер

Вместо того чтобы агент каждый раз решал куда кликать, программист один раз записывает последовательность шагов (Playwright, Selenium, n8n). Агент вызывает её как готовую команду. Сравним бок о бок с агентом-пользователем на той же задаче.

🖱 Агент-пользователь 0.0с · 0
mail.google.com
✏️ Написать
Анна К.Встреча завтра?
Slack3 упоминания
NotionShared doc
StripeОплата
Новое сообщение
Кому:
Тема:
Отправить
🤖 Скрипт-робот 0.0с · 0
mail.google.com
✏️ Написать
Анна К.Встреча завтра?
Slack3 упоминания
NotionShared doc
StripeОплата
Новое сообщение
Кому:
Тема:
Отправить

Коротко: что меняется по сравнению с агентом-пользователем

Критерий 🖱 Агент-пользователь 🤖 Скрипт-робот
Время на действиесекунды — минутысекунды
Стоимость вызовадорого — LLM на каждом шагедёшево — нет LLM-решений
Кто задал путьLLM, на каждом шаге зановопрограммист, один раз
Если сайт обновилиадаптируется в процессепадает с ошибкой
Поддержкане нужначинить после редизайнов
Риск блокировкисреднийвысокий — явная автоматизация

👤 Неофициальный API — «притворяемся официальным клиентом»

Сервис сам общается со своим backend через какие-то endpoints — из веб-клиента или мобильного приложения. Можно подсмотреть эти endpoints и вызывать их напрямую, представляясь официальным клиентом. Пример — Telethon для Telegram (MTProto), внутренние API Instagram, реверс XHR-запросов любого SaaS. Сравним с официальным API на той же задаче.

🔌 Официальный API / MCP 0.0с · 0
👤 Неофициальный API 0.0с · 0

Коротко: что меняется по сравнению с официальным API

Критерий 🔌 Официальный API 👤 Неофициальный API
Что этопубличная документированная дверьслужебные endpoints сервиса
Набор функцийтолько то, что опубликоваличасто шире — всё, что делает клиент
Стабильностьконтракт, сервис не ломаетвнутренности меняют без предупреждения
Легальностьчистоформально нарушение ToS
Риск блокировкиминимальныйвысокий — могут забанить аккаунт
Что нужноAPI-ключ или MCP-серверреверс протокола + сессия клиента

Как выбирать на практике

1

Есть официальный API или MCP — берите его. Самый быстрый, дешёвый, надёжный и легальный вариант. Сервис сам его поддерживает и не ломает.

2

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

3

Задача повторяется, сайт стабилен — пишите скрипт-робота. Playwright, Selenium, n8n. Быстро и дёшево за вызов. Готовьтесь, что раз в пару месяцев скрипт придётся чинить после обновления сайта.

4

Неофициальный API — только когда без него никак. Когда нужной функции нет в официальном API, а через UI автоматизировать долго и хрупко. Понимайте риски: блокировка аккаунта, ToS-нарушение, внезапная поломка после обновления сервиса. Классические случаи: Telegram-user-боты через MTProto, скрейпинг внутренних API крупных соцсетей.

5

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

Все четыре способа на одной картинке

Две оси: где агент стучится в сервис (через UI или через API) и как сервис к этому относится (поддерживает официально или нет).

🖥 Frontend · через UI
⚙️ Backend · через API
Официально
🖱 Агент-пользователь
LLM смотрит на экран и кликает как человек. Тот же UI, что у пользователя.
🔌 Официальный API / MCP
Документированная дверь. Стабильный контракт, легально, дёшево.
⚠️Неофициально
🤖 Скрипт-робот
Playwright/Selenium по DOM. Дёшево и быстро, но ломается на редизайнах.
👤 Неофициальный API
Реверс внутренних endpoints клиента. Мощно, но ToS и блокировки.