Контент по тегу

От REST к MCP: как LLM меняют принципы проектирования API и архитектуры систем.

Статьи machine learning
Привет, говорит AvitoTech! Меня зовут Дмитрий Бондарев, я backend-разработчик, я занимаюсь проектами на стыке разработки и машинного обучения.

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

Это первая статья из двух. В ней заглянем в историю эволюции API, его состояние на момент появления агентов и существующие ограничения методов интеграции. Во второй — поговорим уже о MCP и том, как появление агентов подталкивает нас к новой парадигме мышления, разработки и бизнеса.

В этой статье:

Контекст: эволюция API в эпоху LLM

История API берет начало в 1945-1951 году, когда появляются первые библиотеки подпрограмм и модульный подход к разработке. В это время растет количество программного кода и появляются первые проблемы с интеграцией. Развивается концепция модульности.
Впервые акроним API — Application Program Interface, — появляется в инженерных текстах в 1968 году, и его тут же начинают использовать в индустрии.
Эпоха веб-API начинается в 2000 году. Компании открывают HTTP-интерфейсы для внешних разработчиков, и мы начинает интеграцию между компаниями и сервисами с помощью SCP-интерфейсов.
На сегодняшний день в индустрии закрепилось три основных подхода к построению API.

Сравнительная таблица подходов REST, GraphQL, gRPC

REST — ресурсоориентированный stateless принцип. Его главная проблема — переизбыток данных, из-за которого перегружается сеть.
GraphQL появился как решение проблем REST. Это более редкая технология, которая предполагает, что мы можем регулировать глубину ответа, благодаря чему можно получить то, что нужно, за один запрос. Однако GraphQL сложнее в реализации, чем REST, и медленнее из-за более сложного процесса обработки запросов.
GRPC использует бинарный протокол сжатия, за счёт чего снижается нагрузка на сеть. Но при этом он довольно сложный в отладке, поэтому больше подходит внутренним highload-системам для общения между микросервисами. Лучший вариант использования — GRPC внутри с обвязкой REST снаружи.

Особенность этих подходов

Во всех трёх подходах программа должна заранее знать структуру API:
  • Какие эндпойнты доступны?
  • Какие параметры принимают?
  • Какой формат ответа ожидать?
  • Какие ошибки возможны?
Это создает очень жёсткую связанность между клиентом и сервером.
Предпринимались ли попытки решить эту проблему?

Принцип HATEOAS: почему он не решает проблемы полностью

Принцип Hypermedia as the Engine of Application State — HATEOAS — это принцип REST, где сервер включает в ответы ссылки на доступные действия. Но он не может полностью решить проблему жёсткой связи клиента с сервером.
{
    “user”: {

        “id”: 123,
        “name”: “Иван”,
        “_links”: {
            “self”: “/user/123”,
                “edit”: “/users/123/edit”,
                “delete”: “/users/123”
        }
    }
}
Недостатки:

  • клиент всё равно должен понимать семантику ссылок;
  • нужна стандартизация форматов;
  • сложная реализация на практике;
  • не решает проблему динамического обнаружения возможностей.

Значит, нужен какой-то код, который всё это обработает. Но прежде, чем мы перейдем к решению проблемы, нужно ввести ещё несколько понятий.

Появление LLM-агентов

30 ноября 2022 года. Релиз ChatGPT на базе GPT 3.5 в виде бесплатного research preview. Впрочем, это была не совсем новость — помнится, на GPT1 можно было играть в текстовые ролевые игры. Но именно 3.5 запускает рынок.
Август 2025 года. MAU ChatGPT собирает 812 миллионов пользователей. Так 2025 год, по какому-то общему согласию, был назван годом агентов: агенты будут писать код, агенты будут собирать, рисовать, бронировать за вас отели — и много чего ещё.
Но что такое агенты?
Концепция DAG (Direct Acyclic Graph) подразумевает, что запрос, пришедший в HTTP, разбивается на граф и собирается заново — и мы получаем ответ. Мы всегда знаем, как пойдет выполнение задачи в зависимости от параметров: выполняя один и тот же запрос с одними и теми же данными, получишь один и тот же ответ.

Жестко заданный DAG для workflow

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

Таким образом, главная отличительная черта агентов — неопределенность вычислительного графа. Решение об используемых сервисах происходит в процессе выполнения задачи.

Граф работы агента (определяется в runtime)

Ограничения классических API в эпоху LLM

Как интегрироваться с агентом, чтобы он эффективно выполнял свою работу?

Проблема MxN

При росте числа инструментов (M) и LLM-агентов (N), связанность «каждый с каждым» требует, чтобы каждый агент учился уникальным схемам инструментов и способам их вызова. Так возникают MxN-адаптеры промптов и форматов function-calling, дублируются примеры использования, а поведение инструментов между моделями становится неоднородным.
Без единой, понятной для языковой модели абстракции растут издержки на промпт-инженерию и поддержку. Разнятся описания, JSON-форматы, меняются протоколы ошибок, требуется создание отдельной логики выбора инструмента и восстановления неудачных вызовов. Контекст используется для повторяющихся описаний и few-shot примеров для каждой пары — смена модели или обновление инструмента ломает ранее стабильные цепочки.
Из-за постоянно растущего числа моделей (сейчас популярных, наверное, штук двадцать) и их кастомизаций, возникают сложности в интеграции. Для лёгкой интеграции каждая модель должна знать о каждом инструменте.

Проблема self-discovery: агент не знает доступные API

Программный клиент с классическим API заранее знает все доступные эндпойнты — разработчики заранее прописали, куда программа может обращаться, и создают детальные инструкции по работе с каждым сервисом.
LLM-агенты работают иначе. Они должны динамически обнаруживать доступные инструменты и понимать, как ими пользоваться. При этом нужен программный способ узнать все доступные операции, а описания нужно писать максимально понятными для LLM.

Проблема контекста

LLM ориентированы на работу с контекстом и последовательными рассуждениями. Но традиционные REST API не могут предоставить необходимые для этого механизмы.
REST API работает по принципу stateless — каждый запрос должен содержать полную информацию для обработки. 
GET/api/tasks?user_id=123&status=active&page=1
GET/api/tasks?user_id=123&status=active&page=2
Поэтому при работе с REST агенты сталкиваются с несколькими проблемами:
  • Избыточность данных — одни и те же параметры нужно передавать в каждом запросе;
  • Потеря контекста — отсутствует встроенное сохранение состояния диалога;
  • Увеличение нагрузки — дополнительная когнитивная нагрузка на модель возникает из-за необходимости постоянно отслеживать контекст;
  • Снижение эффективности — растёт время обработки запросов и вероятность ошибок.
LLM-агенты работают в режиме длительных диалогов, где важно сохранять контекст предыдущих действий. Например:
Покажи мне мои задачи → Отметь первую как выполненную → Создай похожую
По сути LLM имитирует человеческое мышление через обработку текстовых данных. Это и делает их такими чувствительными к контексту и последовательности действий.
Традиционный подход к интеграции с API требовал от разработчиков тщательного планирования последовательность вызовов. Агент работает похожим образом, но его эффективность напрямую зависит от контекста.

Проблема гранулярности: мелкие операции vs человеческие задачи

В классических системах API строится на множестве мелких операций, каждый запрос выполняет конкретную узконаправленную задачу:
GET /user/123 — получение информации о пользователе
GET /user/123/orders — получение списка заказов
POST /reports — создание отчёта
PUT /reports/456 — обновление отчёта
Разработчику нужно сделать несколько последовательных вызовов для выполнения одной комплексной задачи, а это усложняет логику и увеличивает нагрузку на систему.
При работе с LLM нужно нужно перейти к более крупным, семантически значимым операциям, похожим на то, как человек формулирует и понимает (хотелось бы) задачи.
  • Подготовь отчет по клиенту — вместо последовательности запросов на сбор данных.
  • Обнови статус заказа и уведоми клиента — вместо раздельных операций.
Крупнозернистые операции позволяют упростить взаимодействие с системой, снизить когнитивную нагрузку на агента, повысить эффективность выполнения задач.

Проблема выбора инструментов среди большого числа опций

Когнитивная нагрузка — критический фактор в работе с большим количеством инструментов. Качество работы агента напрямую зависит от числа доступных ему методов и функций.
Можно выделить два ключевых показателя:
  • Точность выбора (accuracy) — способность агента корректно выбрать подходящий инструмент для выполнения задачи;
  • Частота ошибок (error rate) — количество некорректных решений в выборе инструментов.
На графике хорошо видно, как растёт частота ошибок в зависимости от числа инструментов.

Заключение

Все API-подходы объединяет одно — жесткая связанность клиента и сервера. Структура, эндпойнты, параметры и форматы ответов должны быть известны. Но LLM-агенты работают иначе — динамически выбирают инструменты, постоянно обновляют контекст и принимают решения в процессе выполнения задачи. Это противоречит классическому API-подходу, из-за чего возникают проблемы MxN-связей, повышается когнитивная нагрузка на модель, снижается точность выбора инструментов.
Во второй части материала обратимся к MCP (Model Context Protocol), который, на первый взгляд, кажется логичным шагом вперед и решает все проблемы интеграции клиентов с агентами. Рассмотрим возможные риски работы с агентами и необходимые шаги для адаптации.