Po co ci agent AI: od czatu do realnej automatyzacji
Różnica między „czatem z modelem” a agentem
Klasyczny „czat z modelem” to sytuacja, w której człowiek wpisuje pytanie, model językowy generuje odpowiedź i na tym koniec. Zero pamięci o szerszym procesie, brak konkretnych akcji w systemach zewnętrznych, wszystko kontroluje człowiek. To nadal bywa bardzo użyteczne, ale nie jest jeszcze agentem.
Agent AI to element większego systemu, który ma pewien cel, potrafi wykonywać kroki prowadzące do tego celu, podejmuje decyzje na podstawie obserwacji i – co kluczowe – korzysta z narzędzi oraz integracji. Nie ogranicza się do generowania tekstu, ale np.:
wywołuje API (CRM, Jira, Slack, system fakturowy),
czyta i zapisuje pliki,
przeszukuje dokumenty w bazie wiedzy,
planuje sekwencję kroków, a nie tylko odpowiada na jedno pytanie.
Myślenie w kategoriach agenta AI przesuwa nacisk z „ładnej odpowiedzi tekstowej” na realny wynik biznesowy: wysłany raport, zaktualizowaną sprawę w systemie, zarejestrowaną szansę sprzedaży, uzupełnione dane.
Typowe zastosowania agentów AI w firmie
Najbardziej naturalne pierwsze zastosowania agentów AI dotyczą powtarzalnych zadań opartych na tekście i prostych decyzjach. W praktyce często zaczyna się od:
asystenta wiedzy – agent podpięty do bazy dokumentów, procedur, polityk. Odpowiada na pytania, wkleja referencje, streszcza długie PDF-y; przydaje się w HR, supportach, działach prawnych, marketingu.
wsparcia zespołu – agent w Slacku lub MS Teams, który zakłada taski, zakłada zgłoszenia w helpdesku, pilnuje statusów, generuje podsumowania spotkań.
automatyzacji procesów – agent, który zbiera dane z kilku systemów, robi analizę i zwraca gotowy wynik, np. propozycję odpowiedzi do klienta, projekt oferty, wstępny plan kampanii.
Prosty czat może odpowiedzieć „jak skonfigurować VPN”, ale agent AI może dodatkowo sprawdzić w twoim systemie, czy dany pracownik ma już nadane uprawnienia, wygenerować instrukcję kroki-po-kroku z waszej konkretnej bazy wiedzy i wysłać ją użytkownikowi w preferowanym kanale.
Jak ocenić, czy agent AI ma sens: prosta matryca
Zanim zaczniesz budować agenta AI, przejdź przez krótką matrycę decyzyjną. Dla każdego kandydata na użycie agenta odpowiedz tak/nie na pytania:
Czy zadanie jest powtarzalne i tekstowe (e‑maile, raporty, analizy, odpowiedzi)?
Czy człowiek zwykle realizuje je według mniej więcej stałego schematu kroków?
Czy decyzje w tym procesie są głównie oparte na informacjach tekstowych/liczbowych, bez bardzo skomplikowanej logiki domenowej?
Czy dane potrzebne do decyzji są dostępne przez API, w plikach lub bazach, do których możesz dodać dostęp?
Czy akceptowalny jest nadzór człowieka (human‑in‑the‑loop), przynajmniej na początku?
Jeśli masz 4–5 odpowiedzi „tak” – agent AI to dobry kandydat. Jeśli dominują „nie”, prawdopodobnie lepszy będzie klasyczny system regułowy lub automatyzacja bez LLM.
Przykład: prosty agent do researchu rynkowego
Wyobraź sobie osobę, która przygotowuje krótkie analizy konkurencji. Standardowo robi to tak: wchodzi na strony konkurentów, przegląda oferty, czyta cenniki, potem ręcznie wkleja wnioski do Excela czy prezentacji. Dużo skakania po kartach, powtarzalny schemat, mało kreatywności.
Agent AI może przejąć większość tej pracy:
przyjmuje od użytkownika nazwę branży i kilkunastu konkurentów,
przez narzędzie „browser” zbiera treści ze stron,
tworzy znormalizowany opis ofert i wyróżników,
generuje tabelaryczne porównanie, a na końcu krótki komentarz.
Użytkownik nie rezygnuje z kontroli, ale przestaje robić nudne kopiuj‑wklej. Taka transformacja z czatu („opisz mi firmę X”) w agenta („zbierz dane o tych 10 firmach i stwórz porównanie”) pokazuje, gdzie zaczyna się realna automatyzacja.
Co to jest agent AI w praktyce (bez marketingowego żargonu)
Agent jako pętla: obserwacja → decyzja → akcja → ewaluacja
Od strony technicznej agent AI to nic innego jak pętla sterowana modelem językowym. Można ją rozbić na cztery powtarzalne kroki:
Obserwacja – agent zbiera dane wejściowe: wiadomość użytkownika, aktualny stan systemu, wyniki poprzednich działań, logi błędów.
Decyzja – LLM, na podstawie promptu i obserwacji, decyduje, jaki następny krok wykonać (np. „wywołaj narzędzie X z parametrami Y” albo „zakończ zadanie i wygeneruj raport”).
Akcja – system wykonuje technicznie akcję, np. zapytanie SQL, wywołanie API, odczyt z pliku, wysłanie maila.
Ewaluacja – agent analizuje wynik akcji (udało się? błąd? częściowy sukces?) i wraca do punktu 1, aż uzna, że cel jest osiągnięty.
W prostym bocie pętla wykonuje się raz: wejście → odpowiedź. W agencie ta sama pętla powtarza się wielokrotnie, aż do zakończenia zadania lub osiągnięcia limitu kroków.
Kluczowe elementy: LLM, narzędzia, pamięć, reguły
Praktyczny agent AI składa się zwykle z czterech komponentów:
LLM (Large Language Model) – „mózg” agenta. Odpowiada za rozumienie poleceń, generowanie planów, wybór narzędzi, pisanie podsumowań. Może to być API zewnętrzne (OpenAI, Anthropic, Google, Azure) albo własny model.
Narzędzia (tools / functions) – funkcje, które agent może wywołać: zapytanie do bazy, wyszukanie w wektorowym indeksie dokumentów, integracja z CRM, czytanie/ zapis do plików.
Pamięć – mechanizm przechowywania kontekstu. Obejmuje pamięć krótkoterminową (aktualna rozmowa, obecny task) oraz długoterminową (historia użytkownika, stare dokumenty, logi poprzednich sesji).
Reguły i cele – opis roli agenta, ograniczeń i definicja zakończenia zadania. Tu mieści się prompt systemowy, polityki bezpieczeństwa, zasady reakcji na błędy.
Dopiero połączenie tych elementów daje zachowanie, które zaczyna przypominać „autonomię”, a nie tylko gadatliwy interfejs tekstowy.
Granica między prompt engineeringiem a prawdziwym agentem
Rozbudowane prompty potrafią bardzo wiele: narzucają strukturę odpowiedzi, ograniczają długość, zmieniają personę. To nadal mieści się w świecie „czatu”, dopóki model nie steruje żadnymi realnymi akcjami ani przepływem pracy.
Agent AI zaczyna się tam, gdzie model:
może wybrać i wywołać jedno z wielu narzędzi,
decyduje, czy wykonać jeszcze jeden krok, czy zakończyć zadanie,
ma dostęp do pamięci poza bieżącą konwersacją,
wpływa na stan systemu (tworzy rekordy, zmienia statusy, wysyła komunikaty).
Możesz mieć „agenta” bez ani jednej linijki UI, działającego w tle jako proces batchowy, jeśli spełniasz powyższe warunki. Z drugiej strony piękny interfejs czatowy, bez narzędzi i pamięci, pozostaje tylko UI do LLM.
Kiedy wystarczy prosty prompt, a kiedy architektura agentowa
Prosty, dobrze napisany prompt jest wystarczający, gdy:
zadanie dotyczy pojedynczego wejścia i jednej odpowiedzi (np. przeredaguj tekst, streść dokument),
nie musisz odpytywać dodatkowych systemów,
nie ma potrzeby zapisywania wyników w infrastrukturze,
użytkownik sam decyduje o kolejnych krokach (człowiek jest orchestratorzem).
Architektura agentowa pojawia się, gdy:
proces składa się z wielu kroków, które można zautomatyzować,
trzeba sięgać do API, baz i plików,
chcesz mieć powtarzalny workflow i logi do audytu,
planowany jest nadzór, a docelowo częściowa autonomia (bez każdorazowego klikania człowieka).
dzięki temu łatwiej określić, kiedy jeszcze wyciskasz maksimum z „czatu”, a kiedy już sensownie jest inwestować w pełnoprawnego agenta AI.
Źródło: Pexels | Autor: Mikhail Nilov
Pierwszy krok: prosty bot oparty na LLM bez narzędzi
Minimalny stack techniczny
Zanim zaczniesz podpinać bazy danych, API i kolejki, zbuduj najprostszy możliwy bot oparty na LLM. Minimalny stack wygląda zwykle tak:
Model – np. GPT‑4o, Claude, Gemini albo lokalny LLM, dostępny przez API lub bibliotekę.
Interfejs – prosta aplikacja CLI (Python, Node) albo mały frontend webowy (np. React/Vue + backend z jednym endpointem).
Prompty systemowe – definicja roli bota, podstawowe reguły, oczekiwany format odpowiedzi.
Na tym poziomie nie ma jeszcze toolsów. Inwestujesz w zrozumienie: jak LLM reaguje na role, jak kontrolować długość i formę odpowiedzi, jak logować całą rozmowę. To fundament, bez którego debugging agentów jest potem męką.
Projektowanie roli: persona i zakres odpowiedzialności
Bot bez jasno zdefiniowanej roli będzie próbował być wszystkim naraz. W praktyce dobrze działa podejście „asystenta z wąską specjalizacją”. Kilka zasad:
Dla osób śledzących rozwiązania typu Informatyka, Nowe technologie, AI naturalnym kolejnym krokiem jest połączenie takich agentów z pipeline’ami CI/CD lub istniejącą infrastrukturą chmurową, ale zanim do tego dojdziesz, warto dobrze zrozumieć samą koncepcję agenta.
Opisz konkretną rolę: „Jesteś asystentem działu sprzedaży B2B w firmie SaaS, który pomaga przygotowywać maile follow‑up.”
Dodaj cele: „Twoim celem jest zwiększenie liczby odpowiedzi na maile oraz skrócenie czasu przygotowania draftu.”
Ogranicz zakres: „Nie odpowiadasz na pytania spoza kontekstu sprzedaży. W takim przypadku prosisz użytkownika o doprecyzowanie lub odsyłasz do działu supportu.”
Zaznacz ton i styl: „Pisz po polsku, zwięźle, bez żargonu, w tonie partnerskim, bez przesadnych grzeczności.”
Takie definicje wrzucasz do promptu systemowego. Dzięki temu nawet prosty bot bez narzędzi staje się przewidywalny i użyteczny dla zespołu.
Kontrola przewidywalności: styl, język, ograniczenia
Aby bot był praktyczny na co dzień, musi być „nudny” w dobrym sensie – zachowywać się przewidywalnie, nie wymyślać formatów na nowo przy każdym zapytaniu. Możesz to osiągnąć poprzez:
Szablony odpowiedzi – np. zawsze generuj mail w formacie: „Temat: …, Wstęp: …, Główna treść: …, Call‑to‑action: …”.
Opis ograniczeń – „Jeśli nie masz wystarczających informacji, zadaj maksymalnie 3 pytania uzupełniające zamiast zgadywać.”
Zakotwiczony język – „Zawsze odpowiadaj po polsku, chyba że użytkownik wyraźnie poprosi o angielski.”
Limity długości – „Twoja odpowiedź nie powinna przekraczać 200 słów, chyba że użytkownik poprosi inaczej.”
Im lepiej to opiszesz na starcie, tym mniej później frustracji przy przechodzeniu w stronę pełnego agenta AI.
Mikro‑checklista do pierwszego bota
Przed pierwszym uruchomieniem bota przejdź krótką listę kontrolną:
Czy rola bota jest opisana jednym, jasnym zdaniem?
Czy zdefiniowałeś, czego bot NIE robi?
Czy masz prosty log: data, użytkownik, wejście, wyjście?
Czy odpowiedzi mają ustalony format (nawet minimalny)?
Czy wiesz, kiedy bot ma powiedzieć „nie wiem” zamiast zgadywać?
Jeśli te punkty są spełnione, masz solidny fundament do dalszego rozbudowania bota w kierunku agenta używającego narzędzi.
Od bota do agenta: narzędzia, funkcje, integracje
Tools / function calling z perspektywy programisty
W API większości nowoczesnych LLM pojawił się mechanizm „tools” lub „function calling”. Technicznie to prosty koncept:
Programista rejestruje funkcje dostępne dla modelu (nazwa, opis, parametry w JSON‑schema).
Jak model wybiera narzędzie i parametry
Z punktu widzenia agenta kluczowy jest nie sam mechanizm wywołania funkcji, ale logika wyboru: kiedy i z jakimi parametrami. Model dostaje trzy rzeczy: kontekst rozmowy, listę narzędzi i instrukcję, jak ma z nich korzystać. Na tej podstawie generuje strukturę JSON z nazwą funkcji i argumentami.
Żeby to działało przewidywalnie, zadbaj o kilka elementów:
Dobry opis narzędzia – w polu description napisz, kiedy używać funkcji („używaj tylko, gdy użytkownik chce wysłać mail, a nie tylko go zredagować”).
Jasne typy parametrów – zdefiniuj JSON‑schema tak, by model nie musiał zgadywać, co można podać (enum, minimalne/maksymalne wartości, wymagane pola).
Przykładowe wywołania w promptach – pokaż 1–2 krótkie przykłady rozmów, w których agent decyduje się na użycie konkretnego narzędzia.
Jeśli tego zabraknie, model będzie albo nadużywał narzędzi, albo ich unikał. Efekt: agent, który teoretycznie „ma integrację z CRM”, praktycznie nic z niej nie korzysta.
Bezpieczeństwo i granice narzędzi
Narzędzia to miejsce, gdzie agent dotyka prawdziwego świata: danych klientów, maili, systemów finansowych. Trzeba z góry zbudować bezpieczne ograniczenia, a nie liczyć, że „model sam będzie ostrożny”.
Kilka prostych zasad na start:
Tryb tylko‑do‑odczytu na początku – pierwsza wersja agenta powinna raczej czytać niż pisać (logi, statusy, listy, podglądy danych).
Whitelisting akcji – zamiast ogólnego narzędzia „wykonaj dowolne zapytanie SQL”, zrób dedykowane funkcje: „pobierz raport X”, „wylistuj zamówienia użytkownika”.
Limitowanie zakresu danych – np. funkcja zwraca tylko 20 rekordów i ich skróty, zamiast całej bazy.
Ręczna akceptacja wrażliwych operacji – wysyłka maila, usuwanie rekordów, zmiana statusu płatności: agent generuje propozycję, człowiek klika „OK”.
Na tym etapie budujesz mentalny nawyk: agent jest silnikiem decyzyjnym, ale techniczny „bezpiecznik” leży po stronie twojej infrastruktury.
Od jednego narzędzia do zestawu integracji
W praktyce rzadko kończy się na jednej funkcji. Zwykle dochodzą kolejne integracje: wyszukiwarka dokumentów, CRM, task manager, baza danych, system ticketowy. Jeśli dodajesz je chaotycznie, prompt agenta puchnie, a zachowanie staje się losowe.
Dobrze działa strategia „warstw” narzędzi:
Warstwa danych – narzędzia do czytania: wektorowe wyszukiwanie, SQL, API typu „GET”.
Warstwa meta – narzędzia pomocnicze, np. walidacja danych, parsowanie PDF, konwersja dat i walut.
W promptach opisujesz ogólną zasadę: najpierw czytaj, potem planuj, na końcu pisz. Dzięki temu agent rzadziej próbuje coś „zmienić”, zanim zrozumie kontekst.
Źródło: Pexels | Autor: Yan Krukau
Architektura prostego agenta: jeden agent, jasne zadanie
Minimalny szkic architektury
Gdy prosty bot z jednym LLM przestaje wystarczać, naturalny kolejny krok to jeden agent z narzędziami. Architektura nadal może być bardzo lekka. Zwykle obejmuje:
Moduł interfejsu – HTTP API, CLI albo worker batchowy, który odbiera zadania.
Silnik agenta – kod, który utrzymuje pętlę „obserwacja → decyzja → akcja → ewaluacja”.
Adapter LLM – pojedyncza abstrakcja do wywołań modelu (ułatwia zmianę dostawcy).
Rejestr narzędzi – definicje funkcji dostępnych dla agenta.
Logi i metryki – zapis kroków, czasu odpowiedzi, błędów narzędzi.
Na tym poziomie nie potrzebujesz jeszcze rozbudowanego orkiestratora. Wystarczy jedna pętla w Pythonie czy Node z prostą obsługą stanu.
Stan zadania: co agent musi „wiedzieć” w trakcie pracy
Agent pracujący nad jednym zadaniem potrzebuje spójnego stanu. Bez niego zaczyna powtarzać pytania i powielać kroki. Minimalny stan obejmuje:
Id zadania – techniczny identyfikator, którym powiążesz logi, błędy, status w systemie.
Cel – skondensowany opis tego, co ma być wynikiem (np. „przygotuj draft odpowiedzi na reklamację #1234”).
Historia kroków – jakie narzędzia były już wywołane, z jakimi parametrami i efektami.
Aktualny plan – w prostszych przypadkach może to być po prostu ostatnia „myśl” modelu zapisana w logu.
Ten stan możesz trzymać w pamięci procesu (krótkie zadania) albo w bazie (zadania długotrwałe, batchowe). Klucz, żeby agent miał dostęp do tej informacji przy każdym kolejnym wywołaniu LLM.
Makro‑checklista prostego agenta
Przed wypuszczeniem pierwszego agenta produkcyjnie, przejdź przez podstawową checklistę:
Czy agent ma jeden główny cel biznesowy, opisany w jednym zdaniu?
Czy wszystkie narzędzia są jasno opisane i mają ograniczony zakres działania?
Czy w logach zapisujesz: wejście użytkownika, wszystkie wywołania narzędzi i finalną odpowiedź?
Czy masz mechanizm twardego limitu kroków (np. max 10 iteracji pętli)?
Czy użytkownik rozumie, co agent robi „w tle” (komunikaty typu „sprawdzam status w systemie X”)?
To pozwala uniknąć typowego chaosu: agent robi 30 kroków w kółko, a ty nie wiesz, gdzie to się rozjechało.
Pamięć, kontekst i wiedza domenowa agenta
Trzy poziomy pamięci agenta
W praktyce można myśleć o pamięci agenta jak o trzech warstwach:
Kontekst bieżącej rozmowy – to, co przekazujesz do LLM w każdym wywołaniu: ostatnie wypowiedzi, obecne polecenie, ostatnie wyniki narzędzi.
Pamięć sesyjna – informacje specyficzne dla aktualnej sesji/zadania: ID klienta, parametry kampanii, ustalenia z początku rozmowy.
Pamięć długoterminowa – historia interakcji z użytkownikiem, wcześniejsze projekty, preferencje, dokumenty domenowe.
Bez tego rozróżnienia wszystko ląduje w jednym „worku”, aż nagle prompt przestaje się mieścić w limicie tokenów, a koszt rośnie lawinowo.
Jak przechowywać pamięć w praktyce
Nie potrzebujesz od razu pełnej platformy vector DB. Na start wystarczy prosty podział:
Pamięć sesyjna – zwykły JSON w bazie (Redis, Postgres, Mongo), kluczowany ID sesji lub zadania.
Historia rozmów – „append‑only log” w bazie lub systemie logującym (np. Elasticsearch, ClickHouse), do analizy zachowania agenta.
Wiedza domenowa – dokumenty trzymane w storage (S3, dysk, GCS) plus prosty indeks wektorowy (np. SQLite+pgvector, Qdrant, Weaviate).
Dopiero gdy zobaczysz, że agent realnie korzysta z pamięci i rosną wolumeny, ma sens inwestycja w bardziej wyrafinowane rozwiązania.
Wiedza domenowa: jak „nauczyć” agenta firmy
Standardowy LLM wie dużo, ale prawie nic o twojej firmie: produktach, SLA, procesach. Trzeba mu to podać w uporządkowanej formie. Dobrze sprawdzają się trzy kategorie materiałów:
Procedury – checklisty, instrukcje, polityki działania (np. jak obsłużyć reklamację, jak zakwalifikować lead).
Szablony – gotowe wzory maili, odpowiedzi, raportów, które agent może adaptować zamiast wymyślać od zera.
FAQ i fragmenty wiedzy – krótkie, samodzielne odpowiedzi, które nadają się do wektorowego wyszukiwania.
Te materiały dzielisz na nieduże fragmenty (np. akapity), indeksujesz wektorowo, a agent dostaje narzędzie typu search_knowledge_base(query). W promptach jasno piszesz: najpierw wyszukaj, potem odpowiadaj, cytując źródło.
Strategie podawania kontekstu do LLM
Gdy pamięci przybywa, pojawia się pytanie: co dokładnie wysłać w kontekście do modelu. Kilka użytecznych wzorców:
Top‑k retrieval – podajesz 3–5 najlepiej pasujących fragmentów z indeksu wektorowego, z krótkimi nagłówkami.
Streszczenia zamiast pełnych logów – zamiast całej historii 20 kroków, agent generuje krótkie „podsumowanie sesji”, które wstrzykujesz do kolejnych wywołań.
Filtry po typie danych – osobno podajesz: „Profil użytkownika”, „Reguły firmy”, „Ostatnie działania agenta”. Model łatwiej rozróżnia, skąd ma czerpać.
Taki porządek ma prostą konsekwencję: agent staje się tańszy w utrzymaniu (mniej tokenów) i bardziej przewidywalny (konkretny kontekst, a nie „wszystko naraz”).
Źródło: Pexels | Autor: MART PRODUCTION
Wieloagentowe systemy: kiedy jeden agent to za mało
Sygnal, że pojedynczy agent nie wyrabia
W pewnym momencie pojawia się ściana: jeden agent z rozbudowanym promptem robi wszystko, ale byle zmiana rozwala całość. Typowe symptomy:
Prompt systemowy ma kilka stron i jest trudny do utrzymania.
Agent miesza style: raz odpowiada jak support, raz jak analityk, raz jak marketer.
Narzędzi jest tyle, że model często wybiera złe lub nie używa właściwych.
Debugowanie zachowania w konkretnym scenariuszu wymaga czytania kilometrowych logów.
To dobry moment, by rozdzielić odpowiedzialności na kilka wyspecjalizowanych agentów.
Proste wzorce wieloagentowe
Nie trzeba od razu budować skomplikowanego społeczeństwa agentów. W praktyce dobrze działają dwa proste wzorce:
Orkiestrator + eksperci – jeden „router” przyjmuje zadanie, decyduje, który wyspecjalizowany agent ma je obsłużyć (np. support, billing, onboarding), przekazuje im kontekst i zbiera wynik.
Pipeline etapów – agent A zbiera dane, agent B analizuje, agent C generuje output dla użytkownika. Każdy ma prostą rolę i swoje narzędzia.
Takie podejście ułatwia też zarządzanie ryzykiem: np. agent odpowiedzialny za „działanie na systemie” jest bardzo restrykcyjny, a agent „copywriterski” może być bardziej kreatywny.
Wymiana informacji między agentami
Kluczowe pytanie: jak przekazywać wiedzę między agentami, żeby nie robić spaghetti. Kilka praktycznych zasad:
Standardowy format zadania – każde zadanie to obiekt zawierający: cel, kontekst, ograniczenia, preferowany format wyniku.
Jawne „kontrakty” – np. agent analityczny zawsze zwraca JSON z polami facts, insights, risks, a nie „co mu wyjdzie”.
Centralny log – wszystkie agentowe wątki zapisujesz w jednym miejscu, z oznaczeniem, który agent wykonał dany krok.
Przykładowo: w procesie przygotowania oferty B2B orkiestrator tworzy zadanie „analityka klienta”, potem zadanie „kreatora oferty”, na końcu zleca „kontrolę ryzyka”. Każdy agent dostaje konkretny input i zwraca standardowy output.
Kiedy nie rozbijać systemu na wiele agentów
Rozdzielanie agentów bywa kuszące, ale łatwo przesadzić. Jeden dobrze zaprojektowany agent często wygrywa z pięcioma kiepsko skoordynowanymi. Odpuść multi‑agent, jeśli:
problem mieści się w jednej dziedzinie (np. tylko obsługa zgłoszeń, bez analiz, marketingu, billingów),
liczba narzędzi jest mała (2–3 integracje),
nie potrzebujesz równoległego przetwarzania zadań przez różne „role”.
W takich scenariuszach lepiej dopracować jednego agenta i jego prompt, niż dokładać kolejne byty do utrzymania.
Wybór narzędzi i frameworków do budowy agentów
Trzy podejścia: od „gołego” API do pełnych frameworków
Przy tworzeniu agentów masz kilka poziomów abstrakcji. W uproszczeniu:
Gołe API LLM + własny kod – pełna kontrola, najwięcej pracy, dobre na start i do nauki.
Biblioteki narzędziowe i lekkie SDK
Między gołym API a ciężkim frameworkiem są lekkie biblioteki, które rozwiązują konkretne problemy: wywołania narzędzi, pamięć, retry, logowanie. Dają kilka gotowych klocków, ale nie narzucają całej architektury.
Biblioteki do wektorów (pgvector, Qdrant client, chroma) – proste API do indeksowania i wyszukiwania kontekstu.
Middlewary HTTP / kolejki (Celery, Sidekiq, BullMQ) – do obsługi długich zadań i retrajów agenta.
To dobre rozwiązanie, gdy chcesz mieć własny „mini‑framework”, ale nie wynajdować na nowo klienta do API czy obsługi wektorów.
Pełne frameworki agentowe
Trzeci poziom to frameworki, które dają gotowe komponenty: agentów, narzędzia, pamięć, orkiestrację. Popularne przykłady:
LangChain / LangGraph – bogaty ekosystem, dużo integracji, możliwość rysowania grafów workflow.
Semantic Kernel – bliżej świata .NET/enterprise, integracje z Azure i M365.
AutoGen, CrewAI, inne „multi‑agentowe” – skupione na rozmowie między agentami i orkiestracji zadań.
Plus: szybko zbudujesz PoC i prototypy. Minus: spinasz się z ich sposobem myślenia o agentach, co czasem utrudnia debugowanie i migracje. Dobrze mieć świadomość, że frameworki się zmieniają szybko, a logika biznesowa powinna żyć raczej po twojej stronie niż w „magicznych dekoratorach”.
Jak dobrać poziom abstrakcji do etapu projektu
Prosty schemat decyzyjny pomaga uniknąć nadinwestowania w narzędzia:
Eksperyment / 1–2 agenci, małe wolumeny – gołe API + własna pętla, ewentualnie lekkie SDK. Celem jest zrozumienie problemu, nie idealna architektura.
Pierwsza wersja produkcyjna – własny kod + kilka bibliotek (wektory, kolejki, logowanie). Tu zaczynasz porządkować schematy promptów i standardy narzędzi.
Złożony system, wiele agentów i integracji – dopiero tutaj rozważ pełny framework agentowy lub własny mini‑framework, bo zyskujesz na standaryzacji i reużywalności.
Dobrze działa zasada: najpierw zrozum dokładnie przepływ i potrzeby, potem dobieraj framework, a nie odwrotnie.
Kryteria wyboru frameworku agentowego
Przy realnym projekcie ogranicz wybór do 2–3 opcji, a potem oceń je praktycznie. Kilka kryteriów, które od razu odsiewają słabe dopasowania:
Obsługa twojego stosu – język (Python, JS, .NET), typ bazy, queue, chmura. Jeśli integracja jest „na siłę”, zaczną się problemy przy wdrożeniu.
Jak wygląda debugowanie – czy łatwo podejrzeć, jaki prompt poszedł, jakie narzędzia zostały wywołane, jak wyglądał stan po każdym kroku.
Stopień magii – im więcej ukrytej automatyki („sam wykryje narzędzia, sam routuje zadania”), tym trudniejsze późniejsze strojenie.
Stabilność API – duże zmiany co miesiąc to koszmar w systemach produkcyjnych.
Dobry test: spróbuj zaimplementować w wybranym narzędziu prosty, ale „pełny” przypadek – agent z jednym narzędziem, pamięcią sesyjną, limitem kroków i logowaniem. Jeśli walczysz z frameworkiem, a nie z problemem, to sygnał ostrzegawczy.
Vendor lock‑in i neutralna warstwa pośrednia
LLM i frameworki zmieniają się szybko. Żeby nie zostać zakładnikiem jednej technologii, wprowadź cienką warstwę abstrakcji:
własny interfejs typu LLMClient z metodami chat(), embed(), ukrywający konkretnego dostawcę,
prosty format opisu narzędzia (nazwa, opis, schema) niezależny od konkretnego SDK,
własne ID sesji i struktura logów, które możesz zmapować na dowolny framework.
W praktyce pozwala to wymienić dostawcę modelu lub framework agentowy bez przepisywania całego systemu, tylko „adapterów”.
Projektowanie workflow agenta: od zadania użytkownika do wyniku
Rozbicie problemu na etapy
Zanim zaczniesz pisać kod, opisz na kartce, co ma się zadziać krok po kroku. Najprostszy szkic to sekwencja:
Wejście użytkownika (polecenie, formularz, zdarzenie z systemu).
Interpretacja zadania przez agenta (co jest celem, brakującymi danymi, ograniczeniami).
Decyzja: potrzebne narzędzia czy wystarczy „czysta” odpowiedź LLM.
Wywołania narzędzi (czasem kilka iteracji: pobierz → przelicz → sprawdź).
Scalenie wyników w odpowiedź dla użytkownika lub kolejny system.
Ten „manualny” opis to później podstawa promptu systemowego i implementacji pętli agenta.
Wzorzec: plan → działanie → refleksja
Przy bardziej złożonych zadaniach przydaje się prosty wzorzec myślenia agenta:
Plan – agent w pierwszym kroku opisuje, co zrobi w 2–4 krokach, np. „1) sprawdzę dane klienta, 2) wyciągnę historyczne zamówienia, 3) wyliczę rekomendację”.
Działanie – wywołuje narzędzia zgodnie z planem, bez freelancowania po drodze.
Refleksja – po zebraniu danych sprawdza, czy wystarczą do odpowiedzi, i dopiero wtedy generuje finalny output.
To nie jest „agencja generalna”. To jedna prosta pętla, którą jasno opisujesz w promptach. W logach od razu widać, gdzie agent podjął złą decyzję: w planie, w działaniu czy w interpretacji wyników.
Projektowanie wejścia do workflow
Wejście do workflow to nie tylko tekst użytkownika. Zazwyczaj masz więcej sygnałów:
kontekst biznesowy (ID sprawy, typ zgłoszenia, SLA).
Dobrym nawykiem jest budowanie z tego jednego obiektu, np. TaskInput, który przekazujesz agentowi. Dzięki temu możesz rozszerzać kontekst bez przeróbek wszystkich promptów – agent dostaje zawsze podobną strukturę, a ty dodajesz nowe pola po swojej stronie.
Jawne stany workflow
Zamiast „magii w kodzie” można wprowadzić jawne etapy workflow. Przykładowo, dla agenta ofertowego:
QUALIFY – agent sprawdza, czy ma wystarczająco danych o kliencie.
RESEARCH – pobiera dane z CRM, analityki, poprzednich kampanii.
DRAFT – generuje pierwszą wersję oferty.
REVIEW – sprawdza zgodność z regułami (cennik, rabaty, polityki).
FINAL – tworzy wynik dla człowieka lub systemu.
Każdy stan ma swoje reguły: jakie narzędzia są dostępne, co musi być spełnione, by przejść dalej, kiedy workflow trzeba przerwać i poprosić człowieka o decyzję. To znacząco upraszcza testy i obsługę wyjątków.
Przejścia między krokami: kto decyduje?
Są dwa modele: „LLM decyduje” i „silnik workflow decyduje”. W praktyce dobrze się sprawdza miks:
LLM pomoże w miękkich decyzjach: czy dane są kompletne, który wariant odpowiedzi będzie lepszy dla użytkownika.
Przykład: po etapie RESEARCH silnik zawsze przechodzi do DRAFT, ale to LLM decyduje, czy trzeba poprosić użytkownika o doprecyzowanie wymagań, czy już może tworzyć ofertę.
Obsługa błędów i ślepych uliczek
Agent będzie popełniał błędy. Zamiast zakładać, że „jakoś zadziała”, zaprojektuj z góry reakcje na typowe problemy:
Brak danych z narzędzia – narzędzie zwraca błąd, timeout lub pustą odpowiedź. Agent powinien dostać jasny komunikat i opcje: ponów, użyj fallbacku, poproś użytkownika o inną ścieżkę.
Niespójne dane – np. duplikaty klientów, sprzeczne daty. W promptach dajesz reguły: „w razie konfliktu wykorzystaj ostatnią aktualizację” albo „zatrzymaj proces i zgłoś problem”.
Zapętlanie się planu – dlatego potrzebny jest licznik iteracji oraz warunek typu: „jeśli po 3 cyklach wynik nadal jest pusty, przerwij i pokaż użytkownikowi, co próbowałeś zrobić”.
Logi z tych sytuacji są złotem. Na ich podstawie poprawiasz instrukcje, schematy danych i walidacje.
Projektowanie wyjścia: format, który da się wykorzystać
Wyjście agenta nie powinno być „ładnym tekstem” na ślepo. Zazwyczaj masz dwa poziomy:
Strukturalny – JSON/obiekt z polami typu summary, actions, risks, data_points. Tym karmisz kolejne systemy lub agentów.
Prezentacyjny – tekst/HTML/Markdown dla człowieka, oparty na warstwie strukturalnej.
W promptach warto jawnie wymagać tego podziału: najpierw poproś model o strukturalny wynik (z walidacją po twojej stronie), a dopiero potem, na bazie tej struktury, generuj „ludzką” wersję.
Workflow hybrydowy: agent + człowiek w pętli
W wielu przypadkach agent nie powinien domykać procesu sam. Dwa praktyczne miejsca na wpięcie człowieka:
Gate przed działaniem nieodwracalnym – zmiana w systemie produkcyjnym, wysyłka kampanii, zatwierdzenie oferty. Agent przygotowuje, człowiek akceptuje jednym kliknięciem.
Gate jakościowy – np. content marketing. Agent generuje drafty, człowiek wybiera wariant i poprawia ton.
W workflow oznaczasz to jako osobny stan, np. HUMAN_REVIEW. Agent zatrzymuje się, czeka na input człowieka, a potem kontynuuje od kolejnego kroku.
Testowanie workflow agenta na scenariuszach
Zamiast odpalać agenta „na żywym organizmie”, przygotuj kilka scenariuszy testowych:
scenariusz z brakującymi danymi (agent musi dopytać lub użyć fallbacku),
scenariusz z konfliktem danych (sprzeczne informacje).
Do każdego scenariusza definiujesz oczekiwany przebieg: które stany workflow agent ma przejść, jakie narzędzia wywołać, jaka powinna być struktura wyniku. Później automatyzujesz te testy i odpalasz przy każdej zmianie promptu lub kodu agenta.
Monitorowanie i iteracja workflow
Po wdrożeniu agent żyje własnym życiem. Żeby nad nim panować, przydaje się kilka prostych metryk:
średnia liczba kroków na zadanie,
procent zadań, które kończą się błędem lub wejściem w HUMAN_REVIEW,
najczęściej używane (i nieużywane) narzędzia,
czas od zadania do wyniku.
Na bazie tych danych poprawiasz workflow: skracasz ścieżki, dodajesz brakujące narzędzia, usuwasz martwe gałęzie. W praktyce co kilka tygodni warto przejrzeć logi 10–20 losowych zadań i ręcznie ocenić, czy agent faktycznie zrobił to, czego oczekiwałby człowiek na tym stanowisku.
Najczęściej zadawane pytania (FAQ)
Czym różni się zwykły czat z AI od agenta AI?
Zwykły czat z AI działa w trybie: pytanie → odpowiedź. Model generuje tekst, ale nie ma pamięci procesu, nie wykonuje akcji w innych systemach i każdą kolejną decyzję podejmuje człowiek.
Agent AI ma cel, potrafi zaplanować kilka kroków, korzysta z narzędzi (API, bazy danych, pliki) i sam podejmuje decyzje, czy zrobić kolejny krok czy zakończyć zadanie. Zamiast tylko „ładnej odpowiedzi tekstowej” dostarcza konkretny wynik: założony task w Jira, wysłany e‑mail, uzupełnione pola w CRM.
Kiedy w firmie ma sens budowa agenta AI zamiast prostego bota?
Agent ma sens, gdy proces jest powtarzalny, oparty na tekście/liczbach i da się go opisać w kilku krokach. Dodatkowo dane do decyzji muszą być dostępne przez API, pliki lub bazy, do których możesz podpiąć narzędzia.
Jeśli do tego możesz zaakceptować nadzór człowieka na początku (np. zatwierdzanie odpowiedzi do klienta) i masz 4–5 „tak” w takiej matrycy, to znak, że warto myśleć o agencie. Gdy proces wymaga skomplikowanej logiki domenowej lub danych bez dostępu maszynowego, lepszy będzie klasyczny workflow lub reguły bez LLM.
Jakie są najprostsze zastosowania agentów AI w biznesie?
Najczęściej startuje się od trzech typów rozwiązań. Po pierwsze: asystent wiedzy, który siedzi na dokumentach, procedurach i politykach i odpowiada na pytania pracowników, wkleja źródła, streszcza PDF‑y. Mocno pomaga w HR, obsłudze klienta czy działach prawnych.
Po drugie: wsparcie zespołu w Slacku lub Teamsach – agent zakłada zgłoszenia w helpdesku, pilnuje statusów, generuje podsumowania spotkań. Po trzecie: automatyzacja prostych procesów, np. zbieranie danych z kilku systemów i generowanie gotowej propozycji odpowiedzi dla klienta albo szkicu oferty.
Jak sprawdzić, czy mój proces nadaje się do automatyzacji agentem AI?
Użyj krótkiej checklisty. Zadaj sobie pytania: czy zadanie jest powtarzalne i tekstowe, czy człowiek zwykle działa według podobnego schematu kroków, czy decyzje opierają się głównie na informacjach tekstowych/liczbowych, czy dane są dostępne technicznie (API, pliki, bazy) i czy dopuszczasz nadzór człowieka.
Jeśli większość odpowiedzi to „tak”, proces jest dobrym kandydatem. Dla kontrastu: procesy jednorazowe, mocno kreatywne lub takie, gdzie kluczowa jest skomplikowana logika biznesowa, zwykle nie są optymalne na pierwszy agentowy eksperyment.
Jak w praktyce wygląda działanie agenta AI „pod maską”?
Agent działa w pętli: obserwacja → decyzja → akcja → ewaluacja. Najpierw zbiera dane wejściowe (wiadomość użytkownika, stan systemu, wyniki poprzednich kroków), potem model językowy decyduje, co dalej – np. które narzędzie wywołać i z jakimi parametrami.
Następnie system technicznie wykonuje akcję (zapytanie SQL, wywołanie API, zapis pliku), a agent analizuje rezultat i decyduje, czy kontynuować, czy kończyć. W prostym bocie ta pętla wykonuje się raz, w agencie – wielokrotnie, aż do osiągnięcia celu lub limitu kroków.
Kiedy wystarczy dobry prompt, a kiedy potrzebuję pełnego agenta AI?
Dobry prompt wystarczy, gdy masz pojedyncze wejście i jedną odpowiedź (przeredagowanie tekstu, streszczenie dokumentu), nie musisz sięgać do innych systemów i użytkownik sam decyduje o dalszych krokach. Wtedy czat z LLM jest tańszy i prostszy w utrzymaniu.
Architektura agentowa jest potrzebna, gdy proces składa się z wielu kroków, trzeba wywoływać API, pracować na bazach i plikach, prowadzić logi i audyt oraz stopniowo zdejmować z człowieka rolę „orchestratora”. Przykład: zamiast proszenia bota „opisz firmę X”, zlecasz agentowi zebranie danych o 10 konkurentach, przygotowanie tabeli porównawczej i komentarza.
Jakie są podstawowe komponenty techniczne prostego agenta AI?
Nawet prosty agent składa się z kilku elementów. Pierwszy to LLM – mózg, który rozumie polecenia, planuje i wybiera narzędzia. Drugi to same narzędzia: funkcje do zapytań do bazy, szukania w dokumentach, integracji z CRM czy operacji na plikach.
Do tego dochodzi pamięć (kontekst bieżącej rozmowy i ewentualnie dłuższa historia) oraz reguły i cele: opis roli agenta, ograniczenia, warunki zakończenia zadania, zasady bezpieczeństwa i obsługi błędów. Dopiero zestaw tych klocków daje coś więcej niż „gadatliwy interfejs tekstowy”.
