Изменение архитектуры бэкенда: от фиксированных API к системам ИИ-агентов
Узнайте, как меняется проектирование бэкенда, когда ИИ-агенты заменяют фиксированные API-маршруты, с реальными примерами кода, случаями использования и практическими факторами, которые необходимо учитывать.
В течение долгого времени разработка бэкендов следовала одной простой схеме: вы настраиваете маршруты, клиент обращается к ним, а сервер возвращает ответ.
POST /create-order
GET /user/123
Это упорядочено, легко понимается и хорошо масштабируется в производственных условиях.
Но есть недостаток:
Каждый возможный путь в приложении должен быть заранее определён.
Когда пользователь пытается выполнить действие вне этого списка, решение всегда одно и то же: писать больше кода, добавлять новые маршруты и условия.
Теперь представьте другой тип запроса. Пользователь просто пишет:
«Найдите для меня самый дешёвый билет на завтра и забронируйте его».
Не существует единого конечного пункта, который мог бы выполнить эту задачу. Именно здесь традиционная модель начинает давать сбои.
Как мы создаём бэкенды сегодня (API)
Рассмотрим конкретную ситуацию.
Поток электронной коммерции (на основе API)
// Step 1: Get product
GET /products/:id
// Step 2: Add to cart
POST /cart// Step 3: Create order
POST /order// Step 4: Payment
POST /payment
Каждый из этих шагов является:
- заранее определенным
- явно контролируемым
- закодированным непосредственно в потоке
Даже логика, стоящая за этими маршрутами, обычно выглядит так:
if (user.isLoggedIn) {
createOrder()
} else {
throw new Error("Unauthorized")
}
Этот подход хорошо работает, но он основан на предположении: вы уже должны знать все пути, которыми может пройти пользователь в системе.
Создание той же функциональности с помощью агента
Вместо описания каждого шага вы описываете желаемый результат.
«Заказать самый дешевый iPhone стоимостью до 70 000 рупий»
Благодаря такому подходу структура бэкенда меняется.
Шаг 1: Определение инструментов (ваши API)
const tools = [
{
name: "search_products",
description: "Search products by name and filters",
},
{
name: "create_order",
description: "Create order for a product",
},
{
name: "make_payment",
description: "Process payment",
}
]
Внимательно посмотрите, что изменилось.
Те же самые основные API по-прежнему существуют — они просто представлены в виде инструментов, которые можно вызывать.
Шаг 2: Позвольте агенту принимать решение
Используя конфигурацию вроде Ollama в сочетании с Gemma 4:
const userGoal = "Buy the cheapest iPhone under 70000"
const response = await agent.run({
goal: userGoal,
tools
})
По сути, агент самостоятельно решает проблему:
- Вызывает функцию
search_products - Фильтрует результаты по цене
- Выбирает лучший вариант
- Вызывает функцию
create_order - Инициирует процедуру
make_payment
Нет заранее заданной последовательности действий, написанной вручную.
Основное отличие, сформулированное просто
Вот краткое описание различий:
API:
Вы пишете:
Step 1 → Step 2 → Step 3
Агенты:
Вы пишете:
Goal → System figures out steps
В этом и заключается суть изменений.
Где это действительно приносит пользу
Давайте рассмотрим практические сценарии, а не абстракции.
1. Автоматизация обслуживания клиентов
Вместо отдельных конечных точек вроде:
/get-order/cancel-order/refund
вы позволяете системе обрабатывать единый запрос, например:
User: "My order is late, cancel it and refund"
Затем агент выполняет следующие действия:
- проверяет статус заказа
- аннулирует его
- инициирует возврат средств
2. Внутренние инструменты разработчика
Например:
"Проверьте, почему задержка API увеличилась за последний час"
Агент способен:
- анализировать логи
- проверять показатели
- предлагать вероятные причины проблемы
3. Платформа поиска пропавших людей
Этот случай заслуживает особого внимания.
Пользователь загружает фото и запрашивает:
">Выясните, был ли этот человек объявлен пропавшим"
Алгоритм действий агента будет следующим:
- запрос к сервису поиска по изображениям
- поиск в базе данных
- возврат найденных совпадений
Для всего этого не требуется строгая, заранее определенная последовательность API-запросов.
Как выглядит архитектура
На высоком уровне все просто:
User → Agent → Tools → Your Existing Backend
Ваши существующие API не исчезают — их просто оборачивают, чтобы агент мог вызывать их по мере необходимости.
Пример реализации (стиль Node.js)
app.post("/tools/create_order", async (req, res) => {
const { productId } = req.body
const order = await createOrder(productId)
res.json(order)
})
Агент просто вызывает этот эндпоинт как один из своих доступных инструментов.
Реальные проблемы, с которыми вы столкнетесь
Этот подход не лишен трудностей.
1. Отладка становится сложнее
При использовании традиционных API вы отлаживаете собственный код.
При работе с агентами вам часто приходится разбираться, почему модель выбрала определенное действие.
2. Поведение не всегда последовательно
Один и тот же входной данный может приводить к разному результату каждый раз.
3. Расходы могут быстро расти
Агент может выполнять 5 вызовов API плюс 10 шагов обработки, чтобы сделать то, что можно было бы сделать одним запросом.
4. Безопасности требуется больше внимания
Необходимо строго контролировать, к каким инструментам может обращаться агент и с какими данными он имеет доступ.
Что это означает для вас как для разработчика бэкенда
Не усложняйте ситуацию больше, чем это необходимо.
Продолжайте создавать API
Они по-прежнему являются основой для всего остального.
Проектируйте свои API как инструменты для вызова
Думайте в терминах определения инструмента:
{
"name": "get_user_orders",
"description": "Fetch all orders for a user"
}
Создайте один небольшой проект агента
Выберите что-то управляемое, например помощника с оформлением заказов, анализатора логов или внутреннего чат-бота. Инструменты вроде Ollama или Gemma 4 могут служить разумной отправной точкой.
Сместите фокус мышления на цели, а не на фиксированные процессы
Такая смена подхода важнее любого выбора конкретного инструмента.
API придают системам бэкенд структуру. Агенты — гибкость. Будущее не в противостоянии API и агентов, а в их совместном использовании. Если вы уже умеете создавать надежные API, значит, вы уже на полпути. Начните задавать себе вопрос: а что, если ваш бэкенд сможет самостоятельно определять шаги выполнения задач?