Zmiana architektury backendu: od stałych API do systemów agentów AI
Dowiedz się, jak zmienia się projekt backendu, gdy agenci AI zastępują stałe trasy API, przy użyciu rzeczywistych przykładów kodu, przypadków zastosowania oraz praktycznych kompromisów, które należy wziąć pod uwagę.
Przez długi czas inżynieria backendu opierała się na jednym prostym wzorcu: ustawiasz trasy, klient do nich wysyła żądania, a serwer zwraca odpowiedź.
POST /create-order
GET /user/123
Jest to uporządkowane, łatwe do zrozumienia i dobrze skaluje się w środowisku produkcyjnym.
Jednak istnieje problem:
Każda możliwa ścieżka w aplikacji musi zostać z góry zaplanowana.
Gdy użytkownik próbuje coś poza tym planem, rozwiązanie jest zawsze takie samo: trzeba napisać więcej kodu, dodać więcej tras oraz większą liczbę warunków.
A teraz wyobraźmy sobie inny rodzaj żądania. Użytkownik po prostu wpisuje:
">Znajdź dla mnie najtańszy lot na jutro i go zarezerwuj."
Nie ma żadnego pojedynczego punktu końcowego, który mógłby to zrobić. W tym momencie tradycyjny model zaczyna sprawiać problemy.
Jak budujemy backendy dzisiaj (API)
Rozważmy konkretny scenariusz.
Przepływ e-commerce (oparty na 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
Każdy z tych kroków jest:
- ustalony z góry
- wprost kontrolowany
- uwzględniony w przepływie jako kod stały
Nawet logika znajdująca się za tymi ścieżkami zazwyczaj wygląda w ten sposób:
if (user.isLoggedIn) {
createOrder()
} else {
throw new Error("Unauthorized")
}
Ten podejście dobrze działa, ale zakłada coś oczywistego: musisz już znać wszystkie ścieżki, którymi użytkownik może przemieścić się w systemie.
Budowanie tej samej funkcji za pomocą agenta
Zamiast opisywać każdy krok, opisujesz pożądany wynik.
">Zamów najtańszy iPhone w cenie poniżej 70 000 rupii"
Dzięki tej zmianie backend przybiera inny kształt.
Krok 1: Określenie narzędzi (twoje 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",
}
]
Przyjrzyj się uważnie temu, co się zmieniło.
To same podstawowe API nadal istnieją — są po prostu dostępne jako narzędzia, które można wywołać.
Krok 2: Pozwól agencie podjąć decyzję
Używając konfiguracji typu Ollama w połączeniu z Gemma 4:
const userGoal = "Buy the cheapest iPhone under 70000"
const response = await agent.run({
goal: userGoal,
tools
})
W rzeczywistości agencja sama rozwiązuje problem:
- Wywołuje funkcję
search_products - Filtruje według ceny
- Bierze najlepszą opcję
- Wywołuje funkcję
create_order - Uruchamia procedurę
make_payment
Nie ma żadnej ustalonej sekwencji napisanej ręcznie.
Główna różnica, wyrażona prosto
Oto streszczenie różnicy:
API:
Napisujesz:
Step 1 → Step 2 → Step 3
Agence:
Napisujesz:
Goal → System figures out steps
To jest istota tej zmiany.
Gdzie to naprawdę przynosi korzyści
Rozważmy praktyczne scenariusze zamiast abstrakcji.
1. Automatyzacja obsługi klienta
Zamiast oddzielnych punktów końcowych takich jak:
/get-order/cancel-order/refund
pozwala się systemowi obsłużyć pojedynczą prośbę w tym rodzaju:
User: "My order is late, cancel it and refund"
Następnie agent:
- weryfikuje stan zamówienia
- anuluje je
- uruchamia zwrot pieniędzy
2. Wewnętrzne narzędzia deweloperskie
Naprzykład:
"Sprawdź, dlaczego opóźnienie API wzrosło w ciągu ostatniej godziny"
Agent jest w stanie:
- przeglądać logi
- weryfikować metryki
- sugerować możliwy problem
3. Platforma do wyszukiwania osób zaginionych
Ten przypadek zasługuje na uwagę.
Użytkownik przesyła zdjęcie i pyta:
">Czy ta osoba jest zgłoszona jako zaginiona?
Proces działania agenta wyglądałby następująco:
- wywoływanie usługi do porównywania obrazów
- weryfikacja bazy danych
- zwracanie znalezionych dopasowań
Żadna z tych czynności nie wymaga sztywnej, z góry określonej sekwencji API.
Jak wygląda architektura
User → Agent → Tools → Your Existing Backend
Twoje istniejące API nie znikają — po prostu je otaczasz, aby agent mógł je wywoływać w razie potrzeby.
Przykład implementacji (w stylu Node.js)
app.post("/tools/create_order", async (req, res) => {
const { productId } = req.body
const order = await createOrder(productId)
res.json(order)
})
Agent po prostu wywołuje ten endpoint jako jeden z dostępnych narzędzi.
Prawdziwe wyzwania, z którymi się spotkasz
To podejście nie jest pozbawione trudności.
1. Debugowanie staje się trudniejsze
Z tradycyjnymi API debugujesz swój własny kod.
Z agentami często musisz sprawdzać, dlaczego model wybrał określoną akcję.
2> Zachowanie nie zawsze jest spójne
To samo dane wejściowe mogą za każdym razem dawać różne wyniki.
3. Koszty mogą szybko rosnąć
Agent może wykonać 5 żądań API plus 10 kroków rozumowania, aby osiągnąć to, co załatwiłoby jedno żądanie.
4. Bezpieczeństwo wymaga większej uwagi
Należy ściśle kontrolować, do jakich narzędzi może mieć dostęp agent oraz z jakimi danymi ma kontakt.
Co to oznacza dla Ciebie jako programisty backendu
Nie komplikuj tego bardziej, niż to konieczne.
Kontynuuj tworzenie API
Pożycia one pozostają fundamentem, na którym opiera się wszystko inne.
Projektuj swoje API jako narzędzia możliwe do wywołania
Myśl w kategoriach definicji narzędzia:
{
"name": "get_user_orders",
"description": "Fetch all orders for a user"
}
Stwórz jeden mały projekt agenta
Wybierz coś przystępnego, takiego jak asystent do obsługi zamówień, analizator logów lub wewnętrzny chatbot. Narzędzia takie jak Ollama czy Gemma 4 stanowią rozsądny punkt wyjścia.
Zmień sposób myślenia na kierunek celów, a nie stałe procesy
To zmiany w sposobie myślenia są ważniejsze niż wybór jakiegoś konkretnego narzędzia.
Podsumowanie
API zapewniają strukturę systemom backendowym, natomiast agenci dają im elastyczność. Przyszłość nie polega na konfrontacji API z agentami — to połączenie obu tych elementów. Jeśli już wiesz, jak budować solidne API, jesteś w połowie drogi. Zacznij się zastanawiać: a co, gdyby twój backend mógł samodzielnie określić kolejne kroki?
Powiązane materiały
- Zrozumienie agentów AI: cele, narzędzia, pamięć i pętla agenta — przystępne dla początkujących wyjaśnienie różnic między agentami AI a chatbotami, obejmujące podstawowe komponenty, pętlę decyzyjną, poziomy autonomii oraz praktyczne zastosowania.