Typy agentów AI: klasyfikacja i zastosowania

Typy agentów AI

Typy agentów AI wywodzą się z jednej taksonomii: agenci odruchowi prości, agenci odruchowi oparci na modelu, agenci zorientowani na cel, agenci zorientowani na użyteczność oraz agenci uczący się. Każda nazwa opisuje jedną kwestię: zakres pamięci agenta oraz horyzont planowania przed podjęciem działania. Dwa dodatkowe terminy, multi-agent oraz hierarchiczny, opisują sposób połączenia wielu agentów, a nie mechanizm decyzyjny pojedynczej jednostki.

Powyższa lista jest starsza niż każdy model, którego używałeś. Pochodzi ze standardowego podręcznika do AI i przetrwała nadejście dużych modeli językowych, ponieważ stawia pytanie, które nadal determinuje projektowanie: co ten obiekt musi wiedzieć przed podjęciem działania? Jeśli nadal ustalasz, gdzie kończy się agent, a zaczyna asystent czatu, przeczytaj najpierw różnica między agentem AI a modelem LLM, na którym działa. Ta strona zaczyna się za tą linią.

Proste agenty reaktywne: jeden warunek, jedna akcja

Prosty agent reaktywny przypisuje bieżące dane wejściowe do konkretnej akcji i nie przechowuje żadnych informacji o wcześniejszych zdarzeniach. Jeśli temperatura przekracza 25, włącz wentylator. To cały mechanizm działania.

Z pewnością zdarzyło się już uruchomić taki system. Webhook wyzwalający workflow w n8n, który odczytuje przesłany formularz i zapisuje wiersz w bazie danych, jest prostym agentem reaktywnym. Pozostaje nim nawet wtedy, gdy w środku znajduje się model językowy przypisujący kategorię do tego wiersza. Jeśli zapytać go o to, co zrobił godzinę temu, nie udzieli odpowiedzi, ponieważ nic nie zapamiętało tego stanu.

Ten typ agenta sprawdza się częściej, niż można przypuszczać. Jest tani w utrzymaniu, a przyczyny jego awarii są czytelne: warunek został spełniony albo nie. Gdy zadanie sprowadza się do schematu „gdy pojawi się X, wykonaj Y”, dodawanie pamięci zwiększa jedynie ryzyko błędów, nie przynosząc żadnych korzyści. Agent n8n wyzwalany przez webhook to właśnie ten poziom taksonomii z dodanym interfejsem użytkownika.

System przestaje działać w momencie, gdy poprawna akcja zależy od historii. Bot odpowiadający na wiadomości bez znajomości stanu wątku zacznie sobie przeczyć przy trzeciej wiadomości, ponieważ dwie pierwsze nigdy nie stanowiły części jego danych wejściowych.

Agenty refleksyjne oparte na modelu: utrzymywanie stanu między zdarzeniami

Agent refleksyjny oparty na modelu przechowuje wewnętrzny obraz swojego środowiska i aktualizuje go wraz z napływem nowych danych wejściowych. Słowo "model" oznacza tutaj model świata, a nie sieć neuronową. Termin ten wyprzedza obecne znaczenie o około czterdzieści lat i wprowadza w błąd niemal każdego przy pierwszym zetknięciu.

Reguła automatyki domowej, która wyłącza światło po dwudziestu minutach braku ruchu, jest oparta na modelu. Musi taka być. "Brak ruchu w tej chwili" oraz "brak ruchu od 21:40" to dla prostego agenta refleksyjnego ten sam sygnał wejściowy, więc tylko zapisany stan pozwala je rozróżnić.

Wersja LLM to każdy agent posiadający zaplecze w postaci pamięci: podsumowanie bieżącej konwersacji lub zwykły plik markdown, który agent odczytuje na początku każdego uruchomienia. Lokalna usługa pamięci dla agenta to właśnie ta koncepcja w formie gotowego rozwiązania. Mechanizm pozostaje niezmienny. Obraz świata posiadany przez agenta trwa dłużej niż zdarzenie, które go wywołało.

Stan ma swoją cenę. Nieaktualny fakt jest gorszy niż brak jakiegokolwiek faktu, ponieważ agent działa w oparciu o niego z pełnym przekonaniem i bez żadnego ostrzeżenia. Każda przechowywana informacja musi mieć mechanizm wygasania lub weryfikacji, w przeciwnym razie agent będzie nadal podejmował decyzje dotyczące serwera, który został wycofany z eksploatacji w marcu.

Agenci celowi: planowanie w kierunku weryfikowalnego stanu

Agent celowy otrzymuje stan docelowy i wyszukuje sekwencję działań prowadzącą do jego osiągnięcia. Działa wstecz od punktu końcowego, więc ścieżka nie jest zapisywana z wyprzedzeniem.

Agent programistyczny jest najczytelniejszym przykładem, który można uruchomić samodzielnie. Polecenie „spraw, aby nieudany test przeszedł” nie wskazuje żadnych plików ani kroków. Agent odczytuje test, tworzy plan, wprowadza zmiany, uruchamia test, odczytuje błąd i próbuje ponownie. Pętla kończy się na weryfikacji, którą agent może faktycznie wykonać – dlatego ta instrukcja działa, a „ulepsz ten kod” nie. Cel, który agent potrafi ocenić, jest celem, który agent potrafi osiągnąć. Cel, którego nie potrafi ocenić, staje się nieskończoną pętlą generującą koszty. Uruchamianie agenta programistycznego na własnym VPS przenosi tę pętlę w miejsce, gdzie może ona pracować bez obciążania laptopa.

Koszty zależą od tego procesu. Każdy krok planowania to kolejne wywołanie modelu, które przesyła dotychczasową historię, więc zadanie dziesięciokrokowe nie kosztuje dziesięć razy więcej niż jeden krok – kosztuje więcej. Kluczową kwestią inżynieryjną jest kształt pętli oraz warunek jej zatrzymania, co stanowi temat inżynierii pętli.

Agenci oparci na użyteczności: wybór między kilkoma dobrymi odpowiedziami

Cel jest binarny. Użyteczność to wynik punktowy. Agent oparty na użyteczności staje przed kilkoma akceptowalnymi wynikami i wybiera ten, który uzyskuje najwyższą notę według zdefiniowanej funkcji.

Zadanie tworzenia kopii zapasowej, które musi zakończyć się przed rozpoczęciem dnia pracy bez wysycenia łącza, jest problemem użyteczności. Nie istnieje jedna poprawna odpowiedź, a jedynie kompromis. Router, który decyduje, który model obsłuży dane żądanie, ważąc cenę względem jakości odpowiedzi, ma taką samą strukturę.

Algorytm nie jest najtrudniejszym elementem. Jest nim napisanie rzetelnej funkcji użyteczności. Jeśli punktacja opiera się wyłącznie na koszcie, system wybierze najtańszy model dla każdego żądania, w tym dla tego, które wymagało modelu droższego. System optymalizuje dokładnie to, co zostało zmierzone, co stanowi problem, gdy mierzona wartość została wybrana tylko dlatego, że łatwo było ją zmierzyć.

Agenci uczący się: typ, który większość ludzi uważa za posiadany

Agent uczący się zmienia własne zachowanie na podstawie informacji zwrotnej o wcześniejszych wynikach. Wymaga to mechanizmu oceniającego rezultat oraz mechanizmu modyfikującego strategię w odpowiedzi na tę ocenę.

Bardzo niewiele systemów self-hosted spełnia te kryteria. Agent, który odczytuje notatki zapisane w poprzednim tygodniu, jest agentem opartym na modelu z plikiem pamięci. Jego wagi pozostają niezmienione. Jego strategia jest identyczna. Pobieranie danych nie jest uczeniem się, a rozróżnienie to ma znaczenie praktyczne: system oparty na pamięci powtarza błąd w nieskończoność, dopóki ktoś nie zmodyfikuje jego pamięci, podczas gdy system uczący się powinien przestać go popełniać.

Jeśli celem jest wdrożenie mechanizmu uczenia się, należy najpierw zbudować system oceny. Oceniany zestaw testowy, uruchomienie zmiany w odniesieniu do niego oraz decyzja o zachowaniu lub odrzuceniu zmiany tworzą zamkniętą pętlę, w której to użytkownik pełni rolę komponentu uczącego się. Jest to proces wolniejszy, niż mogłoby się wydawać, ale jest to jedyna wersja działająca obecnie w środowiskach self-hosted. Self-hosting an eval harness to punkt wyjścia dla tego procesu.

Systemy wieloagentowe i hierarchiczne: układy, nie typy

Nie są to szósty ani siódmy typ. Opisują one sposób rozmieszczenia agentów.

System wieloagentowy uruchamia kilku agentów jednocześnie wewnątrz współdzielonego środowiska, takiego jak kolejka lub repozytorium git. Ponieważ środowisko jest współdzielone, dochodzi w nim do kolizji. Dwóch agentów edytujących jeden plik to standardowy błąd, a rozwiązaniem jest blokada lub kolejka zadań. Żaden prompt tego nie rozwiąże.

System hierarchiczny umieszcza przełożonego nad pracownikami. Przełożony dzieli zadanie, rozdziela części i scala to, co do niego wraca. Jest to popularne rozwiązanie, ponieważ odpowiada sposobowi, w jaki ludzie dzielą pracę, ale jest kosztowne, ponieważ kontekst przełożonego rośnie wraz z każdym przeczytanym raportem. A multi-agent harness pokazuje to połączenie w praktyce.

Jeden agent, który działa, jest lepszy niż czterech, którzy działają tylko częściowo.

Każde przekazanie zadania to miejsce, w którym może dojść do utraty informacji. Zacznij od jednej pętli. Podziel ją tylko wtedy, gdy potrafisz wskazać krok, który stanowi wąskie gardło.

Dlaczego niemal każdy rzeczywisty system jest hybrydowy

Należy rozważyć agenta wdrożeniowego, którego można uruchomić samodzielnie. Webhook inicjuje jego działanie, co stanowi reakcję (reflex). Agent odczytuje bieżący stan wydania (release), co opiera się na modelu (model-based). Planuje kroki przejścia z wersji uruchomionej do wersji docelowej, co jest podejściem zorientowanym na cel (goal-based). Wybiera okno wdrożeniowe na podstawie bieżącego obciążenia, co jest podejściem zorientowanym na użyteczność (utility-based). System nigdy nie modyfikuje własnych zasad, więc nie posiada zdolności uczenia się.

Jeden system, cztery wiersze taksonomii jednocześnie. Taksonomia sprawdza się jako lista kontrolna projektowania, a nie jako etykieta dla gotowego produktu. Gdy system działa nieprawidłowo, użytecznym pytaniem jest to, która warstwa zawiodła. Wyzwalacz, który zadziałał przy niewłaściwym zdarzeniu, stan, który stał się nieaktualny, weryfikacja celu, której nie da się osiągnąć, oraz wynik nagradzający niewłaściwy rezultat to cztery różne błędy wymagające czterech różnych napraw.

Dopasowanie typu do zadania

• Stały wyzwalacz, stała odpowiedź, brak potrzeby historii: prosty odruch.
• Właściwa odpowiedź zależy od wcześniejszych zdarzeń: odruch oparty na modelu.
• Stan końcowy jest weryfikowalny, ale ścieżka nie jest znana z góry: podejście celowe.
• Kilka akceptowalnych wyników z koniecznością wyboru kompromisu: podejście oparte na użyteczności.
• Potrzeba poprawy wyników w czasie: należy zbudować pętlę ewaluacyjną i przyjąć do wiadomości, że to użytkownik jest elementem uczącym się.

Czy można samodzielnie hostować te agenty i jakie są tego koszty?

Tak, a koszty dzielą się na dwie części. Orkiestracja jest tania. Instancja n8n lub pętla agenta w Python przez większość czasu oczekuje na wywołania sieciowe, więc 2 vCPU i 4 GB RAM w zupełności wystarczą. Koszty generuje natomiast model.

Jeśli agent korzysta z zewnętrznego API, serwer nie wymaga niemal żadnych zasobów, a rachunek skaluje się wraz z liczbą tokenów. W przypadku agenta opartego na celach oznacza to skalowanie w zależności od liczby dozwolonych kroków planowania, dlatego należy ograniczyć liczbę iteracji pętli.

W przypadku uruchamiania modelu na własnym sprzęcie, ilość pamięci RAM decyduje o tym, co w ogóle można uruchomić. Poniższe wartości to typowe rozmiary plików dla wag skwantyzowanych do 4 bitów według stanu na sierpień 2026, zestawione z szacunkowym zapotrzebowaniem na całkowitą pamięć RAM, ponieważ okno kontekstowe i środowisko uruchomieniowe wymagają dodatkowej przestrzeni poza samymi wagami.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Model 8B przy kwantyzacji 4-bitowej zajmuje około 4.9 GB wag, a serwer z 10 GB pamięci RAM uruchomi go bez korzystania ze swapu. Model 70B przy tej samej kwantyzacji to 43 GB wag, co wymaga około 64 GB pamięci RAM. Należy zwrócić uwagę na to, czego te liczby nie uwzględniają: szybkości. Na serwerze VPS bez GPU model 8B przy kwantyzacji 4-bitowej generuje pojedyncze tokeny na sekundę. Jest to akceptowalne dla agenta przetwarzającego kolejkę zadań w nocy, ale uciążliwe w przypadku interakcji z użytkownikiem. Lokalne wnioskowanie (inference) należy stosować do zadań wsadowych, natomiast do zadań interaktywnych warto użyć GPU lub API. Krótka lista agentów AI do samodzielnego hostowania zawiera zestawienie projektów wartych uwagi, a ścieżka nauki o agentach w 2026 opisuje, czego i w jakiej kolejności warto się uczyć.

Gdzie taksonomia przestaje być pomocna

Nie zawiera ona informacji o narzędziach ani uprawnieniach. Podręcznikowe agenty postrzegają i działają. Autorzy tego rozdziału nie martwili się agentem posiadającym produkcyjny token API. Agent oparty na celach z dostępem do powłoki oraz agent oparty na celach z jednym połączeniem do bazy danych w trybie tylko do odczytu znajdują się w tym samym wierszu tabeli, a niosą ze sobą zupełnie inne ryzyko. Należy określić, do czego agent może mieć dostęp, zanim podejmie się decyzję o poziomie jego zaawansowania. Przed przekazaniem agentowi jakichkolwiek poświadczeń, należy zapoznać się z sposobami ochrony sekretów przed agentem AI.

Taksonomia nie wspomina również o tym, co dzieje się w przypadku niepowodzenia kroku. Rzeczywiste agenty spędzają większość czasu pracy na obsłudze błędów: limitów szybkości (rate limit) lub narzędzi, które zwróciły dane niezgodne z oczekiwaniami modelu. To właśnie ten kod decyduje o użyteczności systemu, a żaden wiersz taksonomii go nie opisuje.

FAQ

Jakie jest pięć typów agentów AI?

Agenty oparte na prostym odruchu, agenty oparte na modelu, agenty zorientowane na cel, agenty zorientowane na użyteczność oraz agenty uczące się. Są one uszeregowane według zakresu wiedzy posiadanej przez agenta przed podjęciem działania. Agent o prostym odruchu reaguje wyłącznie na bieżące dane wejściowe. Agent oparty na modelu przechowuje stan swojego środowiska. Agent zorientowany na cel planuje działania w kierunku stanu docelowego. Agent zorientowany na użyteczność ocenia kilka dopuszczalnych wyników i wybiera ten o najwyższej punktacji. Agent uczący się modyfikuje własną politykę na podstawie informacji zwrotnych, co w praktyce nie występuje w niemal żadnym samodzielnie hostowanym rozwiązaniu.

Którego typu agenta AI użyć do prostej automatyzacji?

Agenta opartego na prostym odruchu, co w praktyce oznacza webhook lub harmonogram wyzwalający stałą sekwencję działań. Jeśli poprawna odpowiedź zależy wyłącznie od danych, które właśnie dotarły, pamięć wprowadza jedynie ryzyko awarii, nie oferując żadnych dodatkowych możliwości. Przejdź do projektu opartego na modelu w momencie, gdy potrafisz wskazać choć jedną decyzję wymagającą wiedzy o zdarzeniach z przeszłości.

Czy mogę uruchamiać własne agenty AI na VPS?

Tak. Warstwa orkiestracji jest lekka, więc 2 vCPU i 4 GB RAM wystarczą do komfortowego działania silnika przepływów pracy lub pętli agenta. Kluczową decyzją jest miejsce uruchomienia modelu. Zewnętrzne API pozwala zachować niewielki rozmiar serwera i przenosi koszty na opłaty za tokeny. Model lokalny wymaga pamięci RAM proporcjonalnej do liczby parametrów, a bez GPU generuje pojedyncze tokeny na sekundę, co sprawdza się w zadaniach wsadowych, a nie w oknach czatu.

Czy duży model językowy sam w sobie jest agentem AI?

Nie. Model mapuje tekst wejściowy na wyjściowy i kończy pracę. Staje się agentem, gdy zostaje zamknięty w pętli, która może oddziaływać na otoczenie i zwracać wynik z powrotem do modelu. Wymaga to narzędzi, które model może wywoływać, oraz warunku kończącego pętlę. Agentem jest otoczka, a model stanowi jedynie jeden z jej komponentów.

Czy potrzebuję systemu wieloagentowego?

Zazwyczaj nie. Pojedyncza pętla z kilkoma narzędziami obsługuje większość zadań i jest znacznie łatwiejsza w debugowaniu. Wiele agentów przydaje się, gdy części zadania są od siebie niezależne i mogą być wykonywane równolegle lub gdy jedna z części wymaga innego modelu. Kosztem jest koordynacja: współdzielony stan oraz nadzorca, którego kontekst rośnie wraz z każdym raportem odczytanym od pracownika. Dodaj drugiego agenta dopiero wtedy, gdy potrafisz wskazać konkretny etap, który działa zbyt wolno.