Зміна архітектури бекенду: від фіксованих API до систем AI-агентів
Дізнайтеся, як змінюється проектування бекенду, коли штучні інтелектуальні агенти замінюють фіксовані маршрути 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"
Потім агент:
- перевіряє статус замовлення
- sкасовує його
- ініціює повернення грошей
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 разом із ейєнтами. Якщо ви вже знаєте, як створювати надійні API, ви вже на півдорозі. Почніть ставити собі запитання: а що, якщо ваш бекенд зможе самостійно визначати кроки?
Пов’язана література
- Розуміння AI-ейєнтів: цілі, інструменти, пам’ять та цикл ейєнта — просте для початківців пояснення того, чим AI-ейєнти відрізняються від чат-ботів, з описом основних компонентів, циклу прийняття рішень, рівнів автономії та прикладів використання у реальному світі.