Artykuł 3 z serii Anatomia Agenta AI ← Jak agent myśli — ReAct, Chain-of-Thought i pętla działania
Wyobraź sobie że zatrudniasz asystenta. Pierwszego dnia tłumaczysz mu wszystko: jak działasz, jakie są Twoje preferencje, na czym Ci zależy. Pracuje świetnie.
Następnego dnia przychodzi i nie pamięta nic. Zero. Musisz tłumaczyć od nowa.
Dokładnie tak działa model językowy bez mechanizmów pamięci. Każde wywołanie zaczyna od czystej kartki. Poprzednia rozmowa, decyzje z zeszłego tygodnia, kontekst który nabudowałeś przez miesiąc — znikają po zamknięciu sesji.
Dla chatbota to jest akceptowalne. Dla agenta który ma być użytecznym współpracownikiem przez miesiące — to jest fundamentalne ograniczenie. I jest to ograniczenie które można obejść.
Cztery typy pamięci agenta
Pamięć agenta to nie jedna rzecz. To cztery różne mechanizmy, każdy z innymi właściwościami i zastosowaniami. Rozróżnienie między nimi jest kluczowe — bo błędy przy projektowaniu pamięci agenta niemal zawsze wynikają z użycia złego typu do złego zadania.
1. Pamięć robocza — okno kontekstu
To wszystko co agent „widzi” teraz — aktualna sesja, historia kroków, wyniki narzędzi, instrukcja systemowa. Tak jak RAM w komputerze: błyskawiczny dostęp, ale znika gdy skończy się sesja.
Okno kontekstu ma konkretny rozmiar mierzony w tokenach. GPT-4o — 128 tysięcy tokenów. Claude Sonnet 4 — 200 tysięcy. Gemini 1.5 Pro — milion.
To brzmi jak dużo, ale przy długim zadaniu z wieloma krokami, wywołaniami narzędzi i pobranymi dokumentami — okno kontekstu wypełnia się szybciej niż myślisz. A gdy jest zapełnione, najstarsze informacje wypadają albo model gorzej korzysta z tego co leży „pośrodku” (zjawisko znane jako „lost in the middle” — model lepiej pamięta co jest na początku i końcu kontekstu niż w środku).
Pamięć robocza jest dobra do: aktualnego zadania, bieżącej sesji, danych które potrzebne są teraz.
Nie nadaje się do: przechowywania informacji między sesjami, skalowalnej historii, wiedzy firmowej.
2. Pamięć epizodyczna — wspomnienia zdarzeń
Agent skończył rozmowę z klientem. Omawialiście specyficzne wymagania, zapadły decyzje, pojawiły się niestandardowe warunki. Następnym razem gdy ten klient wróci — agent powinien to wiedzieć.
Pamięć epizodyczna to zewnętrzna baza (najczęściej wektorowa) gdzie zapisywane są konkretne zdarzenia i interakcje. Agent może przeszukiwać ją semantycznie: „co ustaliliśmy z klientem X w marcu?”, „jakie były problemy przy projekcie Y?”, „co ten użytkownik powiedział o swoich preferencjach?”
Kluczowa właściwość: nie musisz pamiętać słów kluczowych. Szukasz semantycznie — „cokolwiek dotyczyło harmonogramu projektu Y” — i baza wektorowa zwraca relevantne fragmenty.
To jest najpopularniejszy typ „długoterminowej pamięci” który deweloperzy implementują dla agentów. Narzędzia: Mem0, Zep, MemGPT — każde z nich zapewnia warstwę pamięci epizodycznej nad modelem.
3. Pamięć semantyczna — wiedza
Inne pytanie: agent obsługuje klientów firmy. Musi znać produkty, politykę cenową, warunki gwarancji, procedury reklamacji.
To nie są „wspomnienia” konkretnych zdarzeń. To jest wiedza deklaratywna — fakty, dokumenty, instrukcje. Przechowywana jako baza dokumentów, odpytywana przez RAG gdy agent potrzebuje konkretnej informacji.
Różnica między epizodyczną a semantyczną jest subtelna ale ważna: epizodyczna przechowuje „co się stało”, semantyczna przechowuje „jak jest”. Rozmowa z klientem — epizodyczna. Polityka zwrotów — semantyczna.
4. Pamięć proceduralna — umiejętności
Najtrudniejszy typ do zrozumienia, a często najcenniejszy w praktyce.
Agent wielokrotnie wykonuje ten sam typ zadania — powiedzmy analizuje umowy prawne i szuka klauzul ryzyka. Z czasem „uczy się” co szukać, jak to opisać, jakie wzorce pojawiają się najczęściej.
Ta wiedza proceduralna może być przechowywana jako:
- Zaktualizowany system prompt z lepszymi instrukcjami
- Przykłady few-shot w prompcie (przykład dobrej analizy + przykład złej)
- Fine-tuning modelu na zadanych przykładach (zaawansowane)
Pamięć proceduralna sprawia że agent poprawia się z czasem — nie tylko „pamięta” co się działo, ale uczy się jak działać lepiej.
Przykład który pokazuje różnicę
Asystent bez pamięci długoterminowej — wersja „chatbot”:
Klient: „Pamiętasz że prosiłem żebyś zawsze formatował raporty jako bullet-pointy?” Asystent: „Niestety, nie mam dostępu do poprzednich rozmów…”
Ten sam asystent z pamięcią epizodyczną:
Klient: „Przygotuj mi podsumowanie spotkania.” Asystent: [pobiera z pamięci: „użytkownik preferuje bullet-pointy, unika długich akapitów, raporty ma dostawać rano”] „Oto podsumowanie:” → [bullet-pointy, zwięźle]
Różnica między tymi dwoma wersjami to nie model, nie prompt. To architektura pamięci.
Agent który „pamiętasz że…” jest fundamentalnie innym produktem niż chatbot który zaczyna od zera. I jest to przewaga której nie można uzyskać samym lepszym modelem.
Trzy błędy przy projektowaniu pamięci
Błąd 1: Wrzucanie wszystkiego do kontekstu.
Kusząca droga na skróty: zbierasz historię wszystkich rozmów i wklejasz do system promptu. Działa dla pierwszych kilku sesji. Potem kontekst jest pełen, koszty rosną, a model gorzej radzi sobie z informacjami zakopanymi w środku długiego kontekstu.
Właściwa architektura: przechowuj historię zewnętrznie, pobieraj relevantne fragmenty przy każdym zapytaniu — nie całość.
Błąd 2: Brak selektywności — zapamiętuj wszystko.
Agent zapamiętuje każdą wymienioną informację. Po miesiącu pamięć jest pełna szumu — nieważnych szczegółów, przestarzałych danych, sprzecznych informacji.
Właściwa architektura: agents z pamięcią powinny decydować co warte jest zapamiętania. Mem0 i podobne systemy mają wbudowaną logikę „co zapisać” zamiast zapisywać surowo każde zdanie.
Błąd 3: Ignorowanie bezpieczeństwa i GDPR.
Pamięć przechowuje dane użytkowników. Długoterminowo. To rodzi dwa problemy:
Context poisoning — atakujący może wstrzyknąć fałszywe „wspomnienie” do bazy wektorowej agenta. Przy kolejnym relevantnym zapytaniu agent pobierze zatrute dane i będzie działał na ich podstawie. Zewnętrzna pamięć to nowy wektor ataku który nie istniał przy chatbocie.
GDPR i prawo do bycia zapomnianym — użytkownik może zażądać usunięcia swoich danych. Czy potrafisz usunąć wszystkie dane konkretnego użytkownika z bazy wektorowej agenta? Nie jest to tak proste jak DELETE FROM users WHERE id=X. Wymaga przemyślanej architektury od początku.
Narzędzia które warto znać
Mem0 — dedykowana warstwa pamięci dla agentów. Inteligentna ekstrakcja „co zapamiętać” z rozmów, semantyczne przeszukiwanie historii, integracja z popularnymi frameworkami.
Zep — pamięć dla aplikacji konwersacyjnych. Automatyczna ekstrakcja faktów, preferencji i relacji z rozmów.
Claude Projects — wbudowana pamięć między sesjami w ramach jednego projektu. Najprościej do uruchomienia dla niedewelopera.
OpenAI Memory — pamięć w ChatGPT między sesjami. Prosta, transparentna (użytkownik widzi co model „zapamiętał”), ale zamknięta w ekosystemie OpenAI.
Microsoft Copilot — najszersza pamięć enterprise: łączy Outlook, Teams, SharePoint i Azure AI Search jako kontekst. Agent „wie” co było w mailach, na spotkaniach, w dokumentach. Dla firm w ekosystemie Microsoft — to naturalna droga.
Co to znaczy dla kogoś kto buduje agenta
Zanim napiszesz pierwszą linię kodu agenta — zdecyduj jakiej pamięci potrzebuje.
Jednorazowe zadanie bez kontynuacji? Pamięć robocza wystarczy. Asystent który wraca do tych samych tematów? Potrzebujesz pamięci epizodycznej. Agent obsługi klienta z bazą wiedzy firmowej? Semantyczna przez RAG. Agent który ma się poprawiać przez powtarzanie zadań? Pomyśl o pamięci proceduralnej.
I jeden wniosek którego się nie spodziewasz zanim przez to przejdziesz: pamięć to nie tylko techniczny problem. To problem produktowy. Agent który pamięta to inny UX, inne oczekiwania użytkownika i inne ryzyko gdy coś pójdzie nie tak. Zanim wdrożysz — zastanów się co agent powinien pamiętać, co powinien zapomnieć, i jak użytkownik może to kontrolować.
W następnym artykule: dość teorii. Budujemy pierwszego agenta bez linii kodu — n8n, praktyczny workflow od zera i przykład który możesz uruchomić jeszcze dziś.
Pojęcia ze słownika: Agent memory · Context window · RAG · Context poisoning · Enterprise RAG · Agent loop
![Artykuł 2 z serii "Agenci AI — od konceptu do produkcji" ← RAG, Agent AI, Agentic RAG — czym się różnią Poprzedni artykuł tej serii skończył się na rozróżnieniu: RAG odpowiada na pytanie, agent realizuje cel. Ale to rodzi pytanie które każdy kto buduje agenta zadaje sobie prędzej czy później: jak właściwie agent decyduje co zrobić dalej? Między "dostałem zadanie" a "zadanie wykonane" jest czarna skrzynka. Dla chatbota ta czarna skrzynka jest prosta — jeden prompt, jedna odpowiedź. Dla agenta to sekwencja decyzji, wywołań narzędzi i ocen wyniku która może trwać sekundy albo godziny. Żeby budować agentów świadomie — a nie przez próby i błędy — trzeba zrozumieć co jest w środku tej czarnej skrzynki. Pętla która napędza każdego agenta Zacznijmy od analogii. Wyobraź sobie że dostajesz zadanie: "Zarezerwuj mi hotel w Krakowie na weekend 14-15 czerwca, do 400 zł za noc, blisko centrum." Jak to robisz? Nie jednym ruchem. Najpierw szukasz opcji. Sprawdzasz ceny. Czytasz opinie. Może jedno miejsce ma dobry rating ale jest za drogie — odrzucasz. Drugie pasuje, ale patrzysz jeszcze na lokalizację. Potwierdzasz. Rezerwujesz. To jest pętla: obserwujesz → planujesz → działasz → oceniasz wynik → wracasz do początku. Agent AI działa identycznie. Każde wieloetapowe zadanie jest realizowane przez powtarzający się cykl czterech kroków — i ten cykl ma swoją nazwę: agent loop. Cztery kroki pętli Percepcja — agent patrzy na stan: co jest w oknie kontekstu, jakie były wyniki poprzednich akcji, co zwróciło ostatnie narzędzie, jaki jest cel. Planowanie — na podstawie tego co widzi, agent decyduje co zrobić dalej. To jest moment decyzji: czy cel jest osiągnięty? Jeśli nie — jaka akcja przybliży mnie do celu? Jakie narzędzie wywołać? Akcja — agent wykonuje to co zaplanował. Wywołuje narzędzie MCP, odpytuje bazę danych, robi request HTTP, pisze plik. Ocena — agent patrzy na wynik akcji. Czy to działało? Co teraz wiem więcej? Co jest następnym krokiem? Czy napotkałem błąd który wymaga innej strategii? I z powrotem do percepcji. Pętla kręci się dopóki agent nie osiągnie celu, nie napotka przeszkody której nie może pokonać, albo — i to jest ważne — nie przekroczy limitu iteracji. Limit iteracji jest krytyczny Agent bez limitu może kręcić się w pętli nieskończenie. Narzędzie zwraca błąd, agent próbuje jeszcze raz, i jeszcze raz, i jeszcze raz. Minuty zamieniają się w godziny. Tokeny i koszty rosną. Każdy agent produkcyjny musi mieć limit kroków po którym zatrzymuje się i raportuje do człowieka: "doszedłem do limitu X iteracji, oto co udało mi się ustalić, oto gdzie utknąłem." To jest pierwsza zasada którą ignoruje większość ludzi budujących swojego pierwszego agenta. ReAct — jak agent myśli zanim działa Teraz wiemy że agent kręci się w pętli. Ale co dokładnie dzieje się w kroku "planowanie"? Jak agent decyduje co zrobić? W 2022 roku badacze z Princeton i Google zaproponowali wzorzec który zmienił sposób budowania agentów: ReAct (Reasoning + Acting). Pomysł jest prosty do bólu: zanim agent wykona akcję, niech najpierw "powie na głos" co myśli. Generuje explicite reasoning — widoczny łańcuch myślenia — a potem na jego podstawie podejmuje decyzję o akcji. Wygląda to tak: Thought: Użytkownik chce hotelu w Krakowie na 14-15 czerwca do 400 zł. Powinienem najpierw sprawdzić dostępność. Action: search_hotels(city="Kraków", checkin="2026-06-14", checkout="2026-06-15", max_price=400) Observation: [3 wyniki: Hotel A — 380 zł, Hotel B — 350 zł, Hotel C — 420 zł] Thought: Hotel C jest za drogi. Hotel A i B mieszczą się w budżecie. Sprawdzam odległość od centrum. Action: get_location(hotel_id="hotel_A") Observation: 800m od Rynku Głównego Thought: 800m to blisko centrum. Hotel A kosztuje 380 zł i jest blisko. Rezerwuję. Action: book_hotel(hotel_id="hotel_A", dates=["2026-06-14"]) Trzy zalety ReAct które robią różnicę w praktyce: Debugging jest możliwy. Widzisz dokładnie skąd pochodzi każda decyzja agenta. Jeśli coś poszło nie tak — możesz śledzić rozumowanie krok po kroku i znaleźć moment gdzie agent zboczył z kursu. Narzędzia są wywoływane trafniej. Agent który "przemyśli" co wywołać zanim to zrobi, robi mniej błędnych wywołań niż agent który po prostu reaguje na ostatni wynik. Agent może się korygować. Reasoning jest widoczny — i agent może sam zauważyć że jego poprzedni krok był błędny, zanim podejmie kolejny. Chain-of-Thought — "myślmy krok po kroku" ReAct to wzorzec na poziomie architektury agenta. Chain-of-thought (CoT) to technika na poziomie promptowania modelu. Idea: zamiast prosić model o bezpośrednią odpowiedź, zachęć go żeby najpierw pokazał swoje obliczenia. Jak matematyk który nie podaje samego wyniku, ale zapisuje wszystkie kroki. Najprostszy możliwy CoT to dosłownie jedno zdanie dodane do promptu: "Myślmy krok po kroku." Brzmi banalnie. Ale działa — szczególnie przy zadaniach wieloetapowych, matematycznych i logicznych. Bardziej zaawansowany CoT to few-shot: dostarczasz modelowi przykłady pytanie + rozumowanie + odpowiedź, i model uczy się wzorca. Dla agentów operujących w specyficznej domenie — powiedzmy agent analizujący umowy prawne — few-shot CoT z przykładami z tej domeny jest jednym z najskuteczniejszych sposobów poprawy jakości. Extended thinking — CoT wbudowany w model Claude 3.7+ i kilka innych modeli poszło dalej: extended thinking jest wbudowane bezpośrednio w model, bez potrzeby specjalnego promptowania. Model generuje wewnętrzny długi łańcuch myślenia przed odpowiedzią — niewidoczny dla użytkownika (lub opcjonalnie widoczny). Efekt: znacząco lepsza jakość przy złożonych, wieloetapowych zadaniach — za cenę wyższej latencji i więcej tokenów. Dla agentów wykonujących skomplikowane analizy gdzie czas odpowiedzi jest mniej ważny niż poprawność — extended thinking jest naturalnym wyborem. Przykład który łączy wszystko: agent rezerwujący hotel Wróćmy do zadania: "Zarezerwuj hotel w Krakowie na 14-15 czerwca." Chatbot dostałby to pytanie i wygenerował listę hoteli z opisem. Odpowiedź tekstowa. Nic nie zarezerwował. Agent z agent loop, ReAct i dostępem do narzędzi wykonuje to zadanie od początku do końca: Iteracja 1: Percepcja → cel jasny, narzędzia dostępne. Planowanie → wywołaj search_hotels. Akcja → [wywołanie]. Ocena → 3 wyniki, Hotel C za drogi. Iteracja 2: Percepcja → mam 2 kandydatów. Planowanie → sprawdź lokalizację. Akcja → [wywołanie]. Ocena → Hotel A blisko centrum, Hotel B dalej. Iteracja 3: Percepcja → Hotel A: 380 zł, 800m od centrum. Spełnia wszystkie kryteria. Planowanie → rezerwuj. Akcja → [wywołanie book_hotel]. Ocena → rezerwacja potwierdzona, numer #KRK2026-0891. Wynik: "Zarezerwowałem Hotel A na 14-15 czerwca, 380 zł, 800m od Rynku Głównego. Numer rezerwacji: #KRK2026-0891." Trzy iteracje pętli. Trzy wywołania narzędzi. Jedno wykonane zadanie. Co to zmienia dla kogoś kto buduje agenta Zrozumienie agent loop, ReAct i CoT nie jest teorią akademicką — bezpośrednio wpływa na to jak projektujesz agenta. Agent loop mówi ci: musisz zdefiniować kryterium sukcesu (jak agent wie że skończył?), ustawić limit iteracji (co gdy agent utknął?), i zdecydować gdzie wstawić human-in-the-loop (które akcje wymagają potwierdzenia człowieka przed wykonaniem?). ReAct mówi ci: daj modelowi miejsce na reasoning zanim podejmie akcję. Nie optymalizuj prompta do minimum — reasoning kosztuje tokeny, ale zmniejsza błędy narzędziowe i ułatwia debugging gdy coś pójdzie nie tak. CoT mówi ci: przy złożonych zadaniach "myślmy krok po kroku" to nie magia — to zmiana trybu pracy modelu. Dla zadań domenowych few-shot CoT z przykładami z Twojej domeny jest wart inwestycji. W następnym artykule: agent myśli i działa — ale co pamięta? Jak działa pamięć agenta między krokami, między sesjami i między zadaniami — i dlaczego zły design pamięci jest jednym z najczęstszych błędów przy budowaniu agentów produkcyjnych. Pojęcia ze słownika: Agent loop · Chain-of-thought · Reasoning model · Tool use · Human-in-the-loop · Agent AI](https://webflux.pl/wp-content/uploads/2026/06/agent_mysli.webp)
