Większość zespołów AI, które chcą poprawić skuteczność agentów, sięga po te same środki: większe okna kontekstu, więcej dokumentów i lepsze polecenia. W tym artykule dowodzę, że to całkowicie błędny odruch. Brakującym elementem nie jest większa ilość informacji. Jest nim kontrola. To dobrze zaprojektowana warstwa kontroli odróżnia agenta działającego podczas demonstracji od agenta sprawdzającego się na produkcji.
Większa pamięć, więcej dokumentów czy dłuższe okno kontekstu nie uczynią agenta AI inteligentniejszym — jedynie spowolnią jego działanie i zwiększą koszty. Prawdziwe korzyści daje nauczenie agenta, by wybierał, czego i kiedy potrzebuje, zamiast przetwarzać wszystko naraz.
Niezawodność wynika z pętli, a nie z modelu. Różnica między agentem robiącym wrażenie podczas demonstracji a takim, który sprawdza się na produkcji, nie polega na jakości AI, lecz na tym, czy system kontroluje własną pracę. Agenci, którzy na każdym etapie planują, działają, obserwują i weryfikują, wykrywają własne błędy, zamiast popełniać je z pełnym przekonaniem.
Większość dzisiejszych agentów AI to w istocie chatboty z dodatkowymi krokami — nie mają mechanizmu pozwalającego stwierdzić, czy zmierzają we właściwym kierunku, kiedy się zatrzymać ani kiedy spróbować innego podejścia. Dopiero odpowiednia warstwa kontroli — jasne kryteria sukcesu, ustrukturyzowany stan i kontrole walidacyjne — zmienia obiekt przypominający agenta w coś, czemu rzeczywiście można zaufać.
Co jadłeś wczoraj na lunch?
Prawdopodobnie nie odtwarzałeś wszystkich swoich wspomnień, aż trafiłeś na „wczoraj + lunch”. Od razu przeszedłeś do obszaru doświadczeń, w którym znajdują się te pojęcia. To przydatny model mentalny podczas tworzenia agentów:
Ogromne okno kontekstu nie jest pamięcią.
Zbiór pobranych dokumentów nie jest zrozumieniem.
Długi łańcuch rozumowania nie oznacza niezawodności.
To tylko składniki. Jednak tym, co sprawia, że agent rzeczywiście nim jest, pozostaje ten sam mechanizm, dzięki któremu mózg nie przeszukuje siłowo całej historii życia: kontrola.
Niedawny przegląd — Agentic Reasoning for Large Language Models — znakomicie podsumował (i nazwał) zmianę, którą wielu z nas zauważa podczas tworzenia systemów: przejście od rozumowania wewnątrz modelu do rozumowania poprzez interakcję. Ten wpis nie jest streszczeniem tamtej publikacji. To próba przełożenia tej zmiany na praktyczny projekt systemu:
Jeśli tworzysz agentów jak chatboty z narzędziami, nadal będą zawodzić jak chatboty — tyle że ich błędy okażą się droższe.
Przez pewien czas nasz standardowy przepis na „uczynienie modelu inteligentniejszym” obejmował przede wszystkim lepsze polecenia, łańcuch rozumowania, samospójność lub ulepszenia oparte na próbkowaniu, a czasem także wyszukiwanie.
ReAct okazał się punktem zwrotnym, bo sprawił, że sekwencja „myśl → działanie → obserwacja” zaczęła wydawać się naturalna. Zwróć jednak uwagę na ukryte ograniczenie: wiele z tych rozwiązań nadal sprowadza się do „wnioskowania z jednym przykładem, ale przy użyciu większej liczby tokenów”. Przegląd ujmuje to precyzyjniej: rozumowanie agentowe kładzie nacisk na skalowanie interakcji podczas testowania — przekształca wnioskowanie w proces iteracyjny, w którego pętli pozostają model, pamięć i środowisko.
Jeśli tworzysz (lub używasz) agentów, którzy imponują podczas demonstracji, ale są zawodni w rzeczywistych przepływach pracy, ten tekst jest dla Ciebie.
Opiszę wzorzec, który widuję bardzo często (i którego warianty sam z pewnością tworzyłem):
Weź dobry model czatu
Dodaj kilka narzędzi (wyszukiwanie, zapytania do bazy danych, ewentualnie wykonywanie kodu)
Dodaj RAG
Dodaj polecenie systemowe “you are an autonomous agent”
Umieść wszystko w pętli while działającej do zatrzymania lub przekroczenia limitu czasu
Gratulacje, masz obiekt przypominający agenta. Zwykle jednak zawodzi w przewidywalny sposób:
Nadmierny rozrost kontekstu: każda obserwacja jest dopisywana, a polecenia zamieniają się w warstwy archeologiczne.
Chaotyczne używanie narzędzi: domyślnym trybem awarii staje się „niewłaściwe narzędzie użyte z pełnym przekonaniem”.
Brak warunków zatrzymania: agent kontynuuje pracę, bo może, a nie dlatego, że powinien.
Brak rygoru ugrutowania: agent nie zauważa, że się myli, dopóki go do tego nie zmusisz.
Pamięć = historia czatu: czyli w praktyce zapisywanie dzienników i nazywanie tego uczeniem.
Właśnie dlatego „agenci” często wydają się magiczni podczas demonstracji, a na produkcji panuje chaos. Potwierdzają to również nasze doświadczenia z wdrażaniem systemów agentowych na produkcji: gdy oceniasz już nie model, lecz system, tryby awarii obejmują nawigację, prawidłowe używanie narzędzi, przycinanie kontekstu i projektowanie ewaluacji — a nie tylko pytanie, czy model odpowiedział poprawnie.
Pytanie brzmi więc: jak powinien wyglądać docelowy agent?
Aby przedstawić to mniej abstrakcyjnie, rozważmy prosty przepływ pracy, który łatwo sobie wyobrazić: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Typowa implementacja „przypominająca agenta” wygląda tak:
Natychmiast pobiera wiele dokumentów linii lotniczych i zasad podróży (nawet jeśli nie są jeszcze potrzebne).
Wywołuje narzędzie wyszukiwania, wkleja długą listę wyników do polecenia i „wybiera jeden”.
Dokonuje rezerwacji przedwcześnie, bez sprawdzenia ograniczeń dotyczących czasu przylotu, bagażu, miejsca i zasad.
Jeśli próba się nie powiedzie, ponawia ją w nieco inny sposób, ale bez jasnego określenia, co się zmieniło ani czego się nauczył.
Problem nie polega na tym, że model nie potrafi rozumować, lecz na tym, że system nie kontroluje przepływu pracy.
Bardziej agentowe podejście traktuje zadanie jako interaktywny proces z jawnym stanem i kontrolami:
PLAN: powtórz ograniczenia i wymień brakujące informacje (np. “which airport preference?” / “is 1 stop ok?”).
DZIAŁANIE: wywołaj wyszukiwanie lotów za pomocą ustrukturyzowanego zapytania (zakres dat, ograniczenie czasu przylotu, budżet).
OBSERWACJA: zapisz wyniki w zwartym obiekcie stanu (5 najlepszych propozycji z ceną, czasem przylotu i przesiadkami), zamiast wklejać ogromny blok danych.
AKTUALIZACJA: doprecyzuj zapytanie, jeśli ograniczenia nie są spełnione (np. “arrival before 6pm is too strict—widen time window or raise budget?”).
WERYFIKACJA: uruchom walidatory („przylot < 18:00”, „cena ≤ 900 GBP”, „zgodność z zasadami”, „dostępny wybór miejsca”).
STOP: dopiero gdy interfejs API rezerwacji zwróci potwierdzenie, a wszystkie walidatory zakończą się pomyślnie.
Zmiana jest subtelna, ale decydująca. Pobieranie jest warunkowe (a nie odruchowe), kontekst jest zarządzany (stan ma strukturę, zamiast narastać), a weryfikacja stanowi część pętli (zamiast spadać na użytkownika). Zastąp „rezerwację lotu” „tworzeniem zamówienia”, „realizacją zwrotu”, „zmianą konfiguracji produkcyjnej” lub „wdrożeniem PR”, a sytuacja pozostanie taka sama: gdy agent może działać, pętla ma większe znaczenie niż polecenie.
Wspomniany przegląd dzieli rozumowanie agentowe na trzy warstwy: podstawową (planowanie, używanie narzędzi i wyszukiwanie), samodoskonalącą się (informacja zwrotna i pamięć) oraz zbiorową (koordynacja wielu agentów).
Głębsza idea polega jednak na tym, że rozumowanie staje się zasadą organizującą planowanie, podejmowanie decyzji i weryfikację, a nie tylko generowanie wiarygodnie brzmiącego łańcucha rozumowania. Brzmi to abstrakcyjnie, dopóki nie przełożysz tego na zmiany w swojej architekturze. Warto zapamiętać trzy najważniejsze kwestie:
Dobry agent nie powinien traktować pobierania jako czynności obowiązkowej. Pobieranie to decyzja, a nie odruch.
Oto praktyczna reguła:
Jeśli system pobiera dane w każdej turze, nie masz mechanizmu pobierania — masz podatek od kontekstu.
W praktyce zdarza się to bardzo często. Podczas debugowania incydentu produkcyjnego nie wrzucasz wszystkich dzienników do kontekstu; na podstawie aktualnej hipotezy decydujesz, które metryki i dzienniki pobrać w następnej kolejności. To właśnie „pobieranie agentowe”. Oto bardziej konkretny wzorzec:
Zdecyduj, czy potrzebujesz pobierania
Jeśli tak: przygotuj zapytanie, pobierz dane, przejrzyj je i wyodrębnij istotne informacje
Jeśli dowody są sprzeczne: pobierz dane ponownie
Dopiero wtedy dokonaj syntezy
W tym miejscu „agentowy RAG” zaczyna różnić się od tradycyjnego RAG: pobieranie staje się świadomym etapem rozumowania, a nie domyślną częścią potoku.
Gdy przestajesz oceniać „model”, a zaczynasz oceniać „system”, śledzenie stanu i przebiegu działań nabiera znaczenia.
Branża zaczęła już wyraźniej podkreślać potrzebę obserwowalności przepływów pracy agentów. Na przykład pakiet Agents SDK firmy OpenAI ma wbudowane śledzenie oraz panel Traces, który rejestruje przebiegi agentów (generowanie, wywołania narzędzi, przekazania, zabezpieczenia i zdarzenia niestandardowe), aby umożliwić debugowanie i kontrolę każdego kroku.
To nie jest tylko „miły dodatek”. To różnica między systemem, który można debugować, a takim, który da się ocenić jedynie na wyczucie.
Moim zdaniem najbardziej praktycznym elementem tego przeglądu jest bezpośrednie podejście do informacji zwrotnej. Dzieli on informację zwrotną na trzy tryby: refleksyjny (generowanie → krytyka → poprawa), adaptację parametryczną (uczenie przez dostrajanie / RL) oraz informację zwrotną opartą na walidatorach (ponawianie prób do czasu zaliczenia walidacji).
Większość zespołów powinna zacząć od informacji zwrotnej opartej na walidatorach, bo jest mało efektowna, ale skuteczna. Jeśli potrafisz napisać jakikolwiek walidator, który wykonuje testy jednostkowe, sprawdza schemat, egzekwuje reguły biznesowe lub ograniczenia („bez eskalacji nie zwracaj kwot powyżej X”) albo weryfikuje fakty („wymagane źródła”), możesz przekształcić niedeterministyczne wyniki modelu w coś, czemu rzeczywiście można zaufać.
Jedna z mniej oczywistych zmian jest prosta: w świecie agentów niezawodność często zależy bardziej od pętli niż od modelu.
Oto najprostsza metodyka pracy w pętli, która według moich doświadczeń niezawodnie poprawia działanie bez trenowania:
Pracuj etapami: Zaplanuj → Działaj → Obserwuj → Aktualizuj,
Po każdym działaniu podsumuj obserwację w 1–3 punktach,
Zatrzymaj się po spełnieniu kryteriów sukcesu lub wyczerpaniu budżetu; zwróć najlepszy znany wynik i pozostałe niewiadome.
Nie chodzi o to, by model był rozwlekły. Chodzi o czytelność systemu i wymuszanie „kontaktu z rzeczywistością” na każdym etapie. Dobrym przykładem, bliskim inżynierom, jest ugrutowanie w zamkniętej pętli w stylu CI:
Plan: zaproponuj listę zmian
Działanie: uruchom testy / lintowanie
Obserwacja: przeanalizuj błędy
Aktualizacja: wprowadź poprawki i spróbuj ponownie
Oto kilka pytań, które zwykle ujawniają przypadkowo powstałe konstrukcje agentowe:
„Czy mój agent wybiera, co pobrać, czy zawsze pobieram wszystko?”
Bezwarunkowe pobieranie oznacza większe opóźnienia i koszty, rozmycie kontekstu oraz wyższe ryzyko, że bezwartościowe dane wejściowe dadzą bezwartościowy wynik.
„Czy mój agent potrafi zauważyć, że się myli?”
Jeśli jedynym sygnałem zwrotnym dla agenta jest irytacja użytkownika, prowadzisz RL kosztem ludzkich nerwów. Pętla ponawiania prób sterowana walidatorem to najprostszy sposób na skonfrontowanie go z rzeczywistością.
„Czy pamięć można zapisywać i czy z czasem staje się lepsza?”
Jeśli Twoja „pamięć” polega tylko na dopisywaniu historii czatu, w praktyce tworzysz dzienniki. Ważne jest ujęcie pamięci w przeglądzie: staje się ona dynamicznie rozbudowywanym kontekstem, który agenci z czasem udoskonalają — a nie tylko zapisem rozmowy.
Dzienniki mówią, co się wydarzyło, a pamięć — co zrobić następnym razem. Historia czatu jest zapisem rozmowy. Pamięć to ewoluująca polityka określająca, co warto zachować na przyszłość.
Na początek sprawdzi się niewielka tabela „wyciągniętych wniosków”, w której kluczem są typ zadania, narzędzie i tryb awarii, a wartością — informacje o tym, co zadziałało i czego unikać. Nie chodzi o zbudowanie idealnego grafu wiedzy. Chodzi o stworzenie efektu kumulacji: pamięć i informacja zwrotna przekształcają agentów z „bezstanowych pomocników” w systemy, które z czasem stają się lepsze.
Kusi, by zaangażować w problem większą liczbę agentów, ale często zwielokrotnia to koszty koordynacji. Dobry wzorzec „minimalnego użytecznego zespołu”:
Koordynator: dzieli zadania i je przydziela
Wykonawca: wywołuje narzędzia i wprowadza zmiany
Krytyk/ewaluator: sprawdza poprawność i ryzyko
Opiekun pamięci: zapisuje i porządkuje wnioski
Jeśli nie potrafisz wyjaśnić, za co odpowiada każdy agent, prawdopodobnie nie potrzebujesz jeszcze wielu agentów.
Jeśli naprawdę przyjmujemy tę zmianę paradygmatu, powinniśmy przestać umieszczać wszystko w poleceniach, traktować niepowodzenia jako wyniki końcowe i oceniać agentów jak chatboty. Powinniśmy zacząć traktować agentów zgodnie z ich naturą: jako systemy oprogramowania, w których język jest płaszczyzną sterowania, a niezawodność wynika z pętli.
Zanim dodasz kolejny model, dodaj kolejną pętlę ewaluacji. Zanim zaczniesz pobierać wszystko, uzależnij pobieranie od warunków. Wdróż jeden walidator, zanim wdrożysz dziesięć. Traktuj pamięć jak decyzje dotyczące polityki, a nie jak bazę danych. A gdy przechodzisz na system wieloagentowy, zacznij od dwóch agentów, nie od dwudziestu. To nie reguły, lecz wzorce, które sprawdziły się na produkcji.