Agenci AI: wprowadzenie

„Agent AI” to dziś najbardziej nadużywane słowo w branży. Sprzedaje się je jako magię, a w środku siedzi prosta pętla. Jeśli rozumiesz tę pętlę, przestajesz dać się nabierać na demo i zaczynasz trzeźwo oceniać, kiedy agent ma sens, a kiedy lepiej napisać zwykły skrypt. Ten tekst jest dla programistów, którzy słyszeli słowo „agent” pięćset razy i nadal nie wiedzą, czym on różni się od chatbota. Różni się jedną rzeczą: agent działa, a nie tylko odpowiada.

Czym agent jest, a czym nie jest

Chatbot dostaje tekst i zwraca tekst. Koniec. Nie ma dostępu do świata, nie wykonuje akcji, nie pamięta niczego poza oknem kontekstu bieżącej rozmowy. Agent to coś więcej. Praktyczna definicja, której warto się trzymać: agent to LLM — plus narzędzia, plus pętla, plus pamięć.

• LLM — mózg, który decyduje, co zrobić w następnym kroku;
• narzędzia — ręce: wyszukiwarka, baza danych, terminal, API;
• pętla — mechanizm, który pozwala wykonać więcej niż jeden krok;
• pamięć — to, co agent wie poza bieżącym promptem.

Wyjmij którykolwiek z tych elementów i przestaje to być agent. Sam LLM bez narzędzi to chatbot. LLM z narzędziami, ale bez pętli, to pojedyncze wywołanie funkcji — przydatne, ale to nie agent. Dopiero pętla, w której model obserwuje wynik własnej akcji i decyduje o kolejnej, zamienia model językowy w coś, co realizuje cel.

Pętla, czyli serce agenta

Najprostszy model myślowy to cykl postrzegaj – planuj – działaj – obserwuj. Agent dostaje cel, patrzy na bieżący stan, wybiera akcję, wykonuje ją, odczytuje wynik i wraca na początek. Powtarza, aż uzna cel za osiągnięty albo wyczerpie budżet kroków.

1. Postrzegaj — zbierz kontekst: cel, dotychczasowe wyniki, stan świata;
2. Planuj — zdecyduj, które narzędzie i z jakimi argumentami wywołać;
3. Działaj — wykonaj wywołanie narzędzia (to robi kod, nie model);
4. Obserwuj — wynik narzędzia wraca do kontekstu jako nowa obserwacja.

Ta pętla jest zwodniczo prosta i tu kryje się większość problemów produkcyjnych. Bez twardego limitu iteracji agent potrafi kręcić się w kółko, wywoływać to samo narzędzie dziesięć razy albo „poprawiać” działające rozwiązanie, aż je zepsuje. Limit kroków i jasne kryterium „skończone” to nie opcja — to wymóg.

Tool use i function calling

Mechanizm, który daje LLM ręce, nazywa się function calling albo tool use. Działa to tak: opisujesz modelowi dostępne narzędzia — nazwę, opis i schemat argumentów (zwykle JSON Schema). Model, zamiast odpowiedzieć tekstem, zwraca ustrukturyzowane żądanie: „wywołaj search z argumentem query: agenci AI”.

Kluczowy szczegół, który myli początkujących: model nie wykonuje narzędzia. Model tylko prosi o jego wykonanie. To twój kod odbiera żądanie, uruchamia faktyczną funkcję, łapie wynik i wkłada go z powrotem do kontekstu. Granica zaufania przebiega tutaj — i to po tej stronie, w kodzie, wdrażasz walidację argumentów oraz limity. Nigdy nie pozwalaj, by tekst wygenerowany przez model trafiał wprost do eval, shella czy zapytania SQL bez warstwy kontroli.

ReAct kontra plan-and-execute

Są dwie dominujące architektury pętli, warto znać różnicę.

ReAct (reason + act) przeplata myślenie z działaniem. Model na bieżąco rozumuje na głos, wykonuje jedną akcję, czyta wynik, znów rozumuje. Jest reaktywny i dobrze radzi sobie w środowiskach nieprzewidywalnych — gdy nie da się zaplanować wszystkiego z góry, bo każdy krok zmienia obraz sytuacji. Wada: bywa krótkowzroczny i potrafi się zgubić w długim łańcuchu.

Plan-and-execute rozdziela fazy. Najpierw model układa cały plan (lista kroków), potem wykonuje je po kolei, ewentualnie replanując, gdy coś pójdzie nie tak. Daje większą przewidywalność i jest tańszy — planowanie raz, nie przy każdej iteracji. Wada: sztywny plan źle znosi środowiska, które zmieniają się szybciej, niż agent zdąży go wykonać.

Mój domyślny wybór: zacznij od ReAct, bo jest prostszy do uruchomienia i debugowania. Przejdź na plan-and-execute, gdy zadania robią się długie, a koszt „myślenia” przy każdym kroku zaczyna boleć.

Jeden agent czy wielu

Pokusa, by rozbić problem na zespół wyspecjalizowanych agentów — badacz, koder, recenzent, orkiestrator — jest silna i zwykle przedwczesna. Wieloagentowość brzmi elegancko, ale dokłada dwa realne koszty: komunikacja między agentami pożera tokeny, a błędy jednego agenta propagują się do reszty, często niezauważone.

• Jeden agent — domyślny start. Łatwiejszy do śledzenia, tańszy, wystarcza dla zdecydowanej większości zadań;
• Wielu agentów — sięgaj po nich, gdy zadanie naturalnie dzieli się na równoległe poddomeny albo gdy potrzebujesz różnych zestawów narzędzi i uprawnień dla różnych ról.

Zasada kciuka: nie wprowadzaj drugiego agenta, dopóki jeden naprawdę nie wystarcza. Większość „potrzebujemy multi-agenta” to w istocie „nasz jeden agent ma za dużo narzędzi i zbyt mglisty prompt”.

Pamięć: krótka, długa, wektorowa

Pamięć dzieli się na dwa rodzaje i mylenie ich to częsty błąd projektowy.

• Pamięć krótkotrwała to okno kontekstu — bieżąca rozmowa, ostatnie obserwacje. Jest szybka, ale ograniczona i znika po zakończeniu sesji;
• Pamięć długotrwała to wiedza, która przeżywa sesję: dokumenty, historia, fakty o użytkowniku. Zwykle trzymana poza modelem i dociągana na żądanie.

Najczęstszy mechanizm długiej pamięci to baza wektorowa. Tekst zamieniasz na embedding (wektor liczb), a przy zapytaniu szukasz fragmentów najbliższych semantycznie i wstrzykujesz je do kontekstu. To fundament RAG. Uwaga na pułapkę: baza wektorowa to nie magia — jeśli wrzucisz do niej śmieci, agent dostanie semantycznie podobne śmieci. Jakość chunków i metadanych decyduje o wszystkim.

MCP: wspólny standard na narzędzia

Do niedawna każdy framework agentowy definiował narzędzia po swojemu. MCP(Model Context Protocol) to próba ujednolicenia tego — otwarty protokół, w którym serwer wystawia narzędzia, zasoby i prompty, a dowolny klient (agent) może z nich korzystać bez pisania integracji od zera.

Dlaczego to ważne dla ciebie: piszesz serwer MCP raz, a podpina się on do wielu agentów i hostów. Zamiast n integracji dla n narzędzi i m agentów, masz wspólny interfejs. To dla narzędzi agentowych mniej więcej to, czym LSP stał się dla edytorów kodu — jeden protokół zamiast kwadratowej liczby wtyczek. W 2026 warto pisać nowe integracje narzędziowe właśnie pod MCP, jeśli tylko masz wybór.

Gdzie agenci błyszczą, a gdzie się wykładają

Agenci są świetni tam, gdzie zadanie wymaga wielu kroków, dostępu do narzędzi i tolerancji na iterację:

• Research — przeszukiwanie wielu źródeł, synteza, weryfikacja krzyżowa;
• Kodowanie — czytanie repo, pisanie zmian, uruchamianie testów, poprawki;
• Operacje — triage zgłoszeń, rutynowe zadania na danych, automatyzacja przepływów.

I tak samo przewidywalnie się wykładają:

• Długi horyzont — im więcej kroków, tym większa szansa, że agent zgubi cel albo utknie;
• Kumulacja błędów — jeśli pojedynczy krok ma 95% szans powodzenia, to po dwudziestu krokach łączna szansa sukcesu spada poniżej połowy. Błędy się mnożą, nie dodają;
• Koszt — każda iteracja to wywołanie LLM. Agent, który „myśli” trzydzieści razy, kosztuje trzydzieści razy więcej niż pojedyncze zapytanie, a bywa, że i tak nie kończy zadania.

Te liczby traktuj jako szacunek ilustrujący mechanizm, nie jako twardy benchmark — realne wskaźniki zależą od zadania i modelu. Ale kierunek jest pewny: zawodność rośnie z długością łańcucha.

Guardrails i człowiek w pętli

Agent z dostępem do narzędzi może realnie coś zepsuć — usunąć plik, wysłać maila, wydać pieniądze. Dlatego bariery ochronne nie są dodatkiem, lecz częścią architektury.

• Limity — maksymalna liczba kroków, budżet tokenów, timeout;
• Walidacja narzędzi — każde wywołanie sprawdzane po stronie kodu (np. schematem), zanim cokolwiek się wykona;
• Najmniejsze uprawnienia — agent dostaje dostęp tylko do tego, czego naprawdę potrzebuje, nigdy do produkcyjnej bazy „na wszelki wypadek”;
• Człowiek w pętli — akcje nieodwracalne lub kosztowne wymagają zatwierdzenia przez człowieka, zanim się wykonają.

Człowiek w pętli to nie brak zaufania do AI — to ta sama zasada, którą stosujesz przy deployu na produkcję czy migracji bazy. Im wyższa stawka i im trudniej cofnąć skutek, tym bliżej decyzji powinien stać człowiek.

Agent czy zwykły skrypt

Najważniejsza decyzja zapada, zanim napiszesz pierwszą linijkę. Model myślowy jest prosty: jeśli kroki są znane z góry i się nie zmieniają — napisz skrypt. Skrypt jest tańszy, szybszy, deterministyczny i łatwy do przetestowania.

Po agenta sięgaj dopiero wtedy, gdy droga do celu nie jest znana z góry, gdy każdy krok zależy od wyniku poprzedniego, a liczba rozgałęzień jest zbyt duża, by zakodować ją na sztywno. Innymi słowy: agent to narzędzie na niepewność, nie na powtarzalność. Jeśli potrafisz narysować schemat blokowy zadania, prawie zawsze lepszy będzie skrypt. Jeśli schemat ma sto ścieżek i połowa zależy od treści danych — to grunt dla agenta.

TL;DR

Agent to LLM plus narzędzia plus pętla plus pamięć — coś, co działa, a nie tylko odpowiada. Serce to pętla postrzegaj–planuj–działaj–obserwuj; ręce daje function calling, przy czym wykonanie narzędzia robi twój kod, nie model. Zaczynaj od ReAct i jednego agenta, wektorowa pamięć obsługuje wiedzę spoza kontekstu, a MCP standaryzuje narzędzia. Agenci błyszczą w researchu, kodowaniu i operacjach, ale wykładają się na długim horyzoncie przez kumulację błędów i koszt. Otaczaj je limitami i człowiekiem w pętli dla akcji nieodwracalnych. A jeśli kroki są znane z góry — napisz skrypt, nie agenta.