Jak działają agenci sztucznej inteligencji: architektura, ReAct i praktyczna implementacja w Pythonie
Agenci sztucznej inteligencji to nie tylko „inteligentne boty do czatów”, ale autonomiczne systemy zdolne planować, wybierać narzędzia, wykonywać zewnętrzne wywołania oraz korygować swoje działania w czasie rzeczywistym. W przeciwieństwie do RAG, który jedynie dostarcza kontekst przed generacją, agent zarządza pełnym cyklem rozwiązywania zadania – od analizy celu po finalny wynik z samokontrolą. To zupełnie nowy poziom automatyzacji dla programistów, szczególnie w scenariuszach wymagających wieloetapowej interakcji z API, kodem, bazami danych czy zewnętrznymi usługami.
Dlaczego RAG nie wystarcza do skomplikowanych zadań
RAG rozwiązuje jedną konkretną problematykę – aktualizację wiedzy za pomocą zewnętrznych źródeł. Jednak jest statyczny: model otrzymuje zestaw fragmentów i generuje odpowiedź raz. Nie ma mechanizmu powtórnego zapytania przy nierelwantnych wynikach, brakuje oceny wiarygodności pośrednich wniosków ani możliwości ponownego planowania. W realnych procesach roboczych to krytyka:
- Przy analizie dokumentacji technicznej może być konieczny sekwencyjny przejście po linkach, wyodrębnienie kodu z różnych plików i jego walidacja;
- Podczas generowania raportu na podstawie danych Excel trzeba najpierw przeczytać tabelę, następnie określić metryki, obliczyć je i dopiero później sformułować wynik;
- W przypadku automatyzacji CI/CD wymagane jest interpretowanie logów błędów, uruchomienie diagnostyki, zastosowanie poprawki i potwierdzenie rezultatu.
Wszystkie te scenariusze wykraczają poza ramy jednorazowej generacji. Tutaj niezbędna jest dynamiczna architektura – czyli sam agent.
Kluczowe komponenty współczesnego agenta SI
Agent to nie monolit, a koordynowany system współpracujących modułów. Każdy komponent spełnia ściśle określoną funkcję i może zostać zastąpiony lub rozwinięty bez konieczności przepisywania całej logiki.
LLM jako jądro podejmowania decyzji
Model nie generuje bezpośrednio finalnej odpowiedzi, lecz pełni rolę „mózgu": formułuje plan, wybiera narzędzia, interpretuje wyniki wywołań i decyduje o kolejnym kroku. Jego role to strategiczne zarządzanie, a nie produkcja tekstu.
Narzędzia jako interfejs do środowiska
To wszelkie zewnętrzne możliwości: zapytania HTTP do API REST, wykonanie kodu Pythona w sandboxie, czytanie/zapisywanie plików, zapytania SQL, wywoływanie narzędzi CLI. Narzędzie musi mieć jasny opis (docstring), typowane argumenty i obsługę błędów – właśnie tak LLM może bezpiecznie go używać.
Pamięć: krótkoterminowa i długoterminowa
Krótkoterminowa to bieżący kontekst dialogu i pośrednie wyniki (np. ID utworzonego zasobu). Długoterminowa to wektorowe bazy wiedzy, zwyczajowo zapamiętane odpowiedzi, historię sesji użytkownika. Pozwala ona agentowi „zapamiętywać” kontekst między wywołaniami i uczyć się na doświadczeniu.
Planer i kontroler błędów
Planer dzieli cel na etapy, śledzi postęp i zapobiega pętlom. Kontroler błędów sprawdza, czy wyniki narzędzi są prawidłowe, porównuje fakty z źródłami i inicjuje ponowne próby w razie niepowodzenia. Bez tych komponentów agent jest niestabilny i nieprzewidywalny.
ReAct: przejrzysty wzorzec zachowania dla LLM
ReAct (Reason + Act + Observe) to nie framework, a szablon zachowania, który definiuje jasny cykl pracy agenta. Sprawia, że wewnętrzne rozumowanie modelu staje się widoczne i kontrolowane:
- Reason – model analizuje aktualny stan, formułuje hipotezę co do następnego kroku i wyjaśnia, dlaczego jest on niezbędny;
- Act – model wywołuje narzędzie z konkretnymi argumentami;
- Observe – model otrzymuje wynik wywołania i ocenia jego stosowność do zadania.
Ten cykl powtarza się aż do osiągnięcia celu. Przykład z praktyki: przy wyszukiwaniu informacji o zgodności biblioteki z Pythonem 3.12 model najpierw „rozmyśla”, że należy sprawdzić PyPI i GitHub; następnie „działając”, wywołuje get_pypi_info('requests'); po tym „obserwuje” odpowiedź i decyduje, czy warto analizować kod źródłowy repozytorium.
Zaletą ReAct jest jego reprodukcyjność i możliwość debugowania. Każdy krok jest rejestrowany: plan → wywołanie → wynik → nowa decyzja. To krytyczne dla systemów produkcyjnych, gdzie wymagana jest audyt i śledzenie.
Systemy multiagentowe: skalowanie przez specjalizację
Jeden uniwersalny agent szybko osiąga granicę swojej skomplikowania. Systemy multiagentowe (MAS) rozwiązują ten problem poprzez podział ról. Zamiast monolitu – zespół wyspecjalizowanych agentów, koordynowanych przez orkiestratora.
Typowe role w MAS:
- Planer – dekomponuje cel, określa kolejność podzadań i przypisuje je wykonawcom;
- Badacz – pracuje z zewnętrznymi źródłami: API, dokumentacją, bazami danych;
- Wykonawca – uruchamia kod, zmienia pliki, stosuje konfiguracje;
- Walidator – sprawdza wyniki pod kątem poprawności, spełniania wymagań i bezpieczeństwa.
Koordynator zbiera wyniki, rozwiązuje sprzeczności i formuluje finalną odpowiedź. Taki podejście daje trzy kluczowe korzyści:
- Paralelizm: kilka agentów może jednocześnie pracować nad niezależnymi podzadaniami;
- Zwiększenie niezawodności: walidator wyłapuje błędy, które mógłby przegapić wykonawca;
- Uproszczenie debugowania: awaria jednej roli nie paraliżuje całego systemu.
Jednak MAS wymagają przemyślanego protokołu współpracy i ochrony przed zależnościami cyklicznymi – np. gdy badacz żąda danych od walidatora, a ten czeka na potwierdzenie od badacza.
Praktyka: minimalny asystent-agent na LangChain
Realizujemy prosty, ale w pełni funkcjonalny agent, zdolny do pobrania pogody, znalezienia wydarzeń i wysłania e-maila. Celem jest pokazanie, jak poszczególne komponenty łączą się w jeden system, a nie stworzenie rozwiązania produkcyjnego.
Inicjalizacja modelu i środowiska
Używamy Qwen 3.5 (9B) przez Ollama – model jest wystarczająco mocny do zadań agentowych i mieści się w Google Colab. Połączenie jest standardowe:
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
model="qwen3.5:9b",
base_url="http://localhost:11434/v1",
api_key="ollama",
temperature=0.3,
)Definicja narzędzi
Każde narzędzie to funkcja Pythona z dekoratorem @tool, jasnym docstringiem i typowanymi argumentami. Na przykład get_weather:
@tool
def get_weather(city: str) -> str:
"""Zwraca aktualną pogodę w podanym mieście.
Przyjmuje nazwę miasta po rosyjsku lub angielsku."""
# ... realizacja przez Open-Meteo API
return f"{name}: {weather['temperature_2m']}°C, {desc}, wiatr {weather['wind_speed_10m']} km/h"Ważne: funkcja musi obsługiwać błędy sieciowe, nieistniejące miasta i nieprawidłowe kody pogody – inaczej agent otrzyma nieuporządkowany tekst zamiast oczekiwanej odpowiedzi.
Prompt i kontekst użytkownika
Prompt określa rolę, ograniczenia i styl odpowiedzi. Dla technicznego agenta istotne jest jasne sprecyzowanie:
- Które narzędzia są dostępne i w jakich sytuacjach należy ich używać;
- Co zrobić w razie błędu (powtórzyć, uściślić u użytkownika, odmówić);
- Jak formatować finalną odpowiedź (np. tylko JSON, bez dodatkowych wyjaśnień).
USER_CONTEXT zawiera personalizowane dane – imię, preferencje, historię interakcji. Dzięki temu agent może dostosować ton i głębokość szczegółów.
Co jest ważne
- Agent SI to nie LLM z rozszerzonym prompem, ale architektonicznie złożony system z jasnym podziałem odpowiedzialności między komponentami.
- ReAct to nie „fajna bajka”, ale niezbędny wzorzec zapewniający przejrzystość, debugowanie i bezpieczeństwo w środowisku produkcyjnym.
- Narzędzia muszą być typowane, dobrze dokumentowane i odporne na błędy – inaczej agent traci kontrolę nad wykonywaniem zadań.
- Systemy multiagentowe są uzasadnione nie dla mody, ale dla skalowania skomplikowania: jeden agent nie jest w stanie niezawodnie zarządzać dziesiątkami narzędzi i źródeł.
- Agenci w produkcji wymagają mechanizmów śledzenia, logowania każdego kroku cyklu i rygorystycznej walidacji danych wejściowych i wyjściowych.
— Editorial Team
Brak komentarzy.