Jak działa agent AI: jedna pętla krok po kroku (obserwacja → plan → narzędzie → wynik) 

Agent AI działa na jednej prostej zasadzie: powtarza tę samą pętlę, dopóki nie ma powodu, żeby zakończyć. W jednej iteracji odbiera stan (zadanie, dane, wynik poprzedniego kroku), układa plan, wskazuje jedno narzędzie, dostaje odpowiedź i ocenia, czy wystarczy. Każda iteracja to jedno wywołanie modelu z powiększonym kontekstem, więc pętla jest zarazem mechanizmem i miejscem, w którym rodzi się koszt. Poniżej rozbijam ją na cztery ruchy, które widać w logach każdego wdrożenia, i pokazuję, gdzie wchodzi człowiek.

Pętla w trzech fazach, a wykonawczych kroków jest pięć

Najprostszy opis brzmi tak: percepcja, rozumowanie, akcja. Microsoft ujmuje to jednym zdaniem, w wersji czeskiej swojego materiału dla Copilota: „Většina agentů následuje smyčku vnímání, uvažování, akce, přičemž pokročilejší agenti se také učí a přizpůsobují na základě výsledków”, czyli: większość agentów stosuje pętlę percepcja, rozumowanie, akcja, a bardziej zaawansowani uczą się i dostosowują na podstawie wyników. Po polsku najbliższe wam będzie wersja TechTarget, która nazywa te same trzy fazy po angielsku: thought, action, observation, czyli myślenie, działanie, obserwacja.

Te trzy etapy to jednak skrót myślowy, a nie opis tego, co naprawdę się dzieje w kodzie. TechTarget w tym samym artykule rozbiera pętlę na pięć kroków operacyjnych: perceive, czyli odbierz stan; reason, czyli zbuduj plan i sprawdź, do czego masz prawo; execute, czyli wykonaj; observe, czyli oceń wynik; learn, czyli wykorzystaj doświadczenie w kolejnej iteracji.

NVIDIA w swoim glosariuszu pokazuje tę samą pętlę jako pięć nazwanych kroków, z przykładem polecenia „przeanalizuj dane sprzedażowe z ostatniego kwartału i przygotuj wykres”:

1. Żądanie użytkownika lub maszyny (User or Machine Request).
2. Model rozumujący, który interpretuje zadanie (The Reasoning Model: Interpreting the Task).
3. Moduł pamięci, który dostarcza kontekst (Memory Module: Providing Context).
4. Integracja z narzędziem, które wykonuje zadanie (Tool Integration: Performing the Task).
5. Rozumowanie i refleksja, poprawiające wynik (Reasoning and Reflection: Improving Outcomes).

Jeśli policzyć w różnych publikacjach liczbę faz pętli, wyjdą trzy, cztery, pięć, a czasem siedem. Nie jest to sprzeczność: każde źródło liczy co innego. Trzy fazy to opis przepływu informacji, pięć kroków to opis czynności, cztery moduły według Apify to opis komponentów architektury, a siedem pozycji Microsofta przy autonomicznych agentach to lista funkcji systemowych, nie etapów. Dwa artykuły o tej samej pętli mają więc różne nagłówki, a tę samą logikę.

Model tylko proponuje, wykonuje cała reszta systemu

Najczęstsze nieporozumienie przy tłumaczeniu agentów polega na utożsamieniu modelu językowego z całym agentem. NVIDIA rozdziela to wyraźnie na trzy elementy. Model językowy jest mózgiem agenta: rozumie zadanie, planuje, wybiera narzędzia i zarządza dostępem do danych. Harness jest rusztowaniem, które daje modelowi zdolność do działania: podłącza pamięć krótko- i długoterminową, wie, jakie narzędzia są dostępne, i potrafi tworzyć nowe umiejętności, jeśli mu na to pozwolono. Secure Runtime to osobne środowisko, w którym agent wykonuje swoją logikę, odpala wygenerowany kod i rozmawia z systemami zewnętrznymi.

Ta granica ma jedną praktyczną konsekwencję: model nigdy nie łączy się z Twoją bazą. On wysyła ustrukturyzowane żądanie, a wykonuje je kod poza modelem, według reguł, które napisał ktoś inny. Dlatego w logach wdrożenia zobaczysz nie jedno zapytanie, lecz serię: wywołanie modelu, wywołanie narzędzia, wynik narzędzia, kolejne wywołanie modelu z doklejonym wynikiem.

Jeśli budujesz to na n8n, ten sam podział widać w węzłach: węzeł z modelem to ten sam brain, a węzeł z zapytaniem HTTP do systemu firmowego to secure runtime. Praktyczne opisy tego, jak wygląda pamięć, narzędzia i human-in-the-loop agenta w n8n, są osobnym tematem, bo zasługuje na swoje podejście.

Skąd wziął się ten schemat: ReAct z 2023 roku

Współczesna pętla nie jest wymysłem marketingowym. Została opisana w 2023 roku w pracy Yao i innych „ReAct: Synergizing Reasoning and Acting in Language Models”, a IBM definiuje ją tak: agent ReAct to agent AI, który używa ramy rozumowania i działania, żeby połączyć rozumowanie w łańcuchu myśli z użyciem zewnętrznych narzędzi. Autorzy inspirowali się tym, jak człowiek rozwiązuje złożone zadania krok po kroku, często właśnie przez wewnętrzny monolog, czyli przez wypowiadanie na głos tego, co się planuje.

Stąd trzy elementy w jednej iteracji. Myśl (verbalized CoT reasoning steps) rozkłada duże zadanie na mniejsze podzadania. Akcja (predefined actions) pozwala użyć narzędzia, zrobić zapytanie do API i zebrać informacje z zewnętrznych źródeł. Obserwacja to ponowna ocena postępu po akcji, która albo daje odpowiedź końcową, albo staje się materiałem na następną myśl. IBM podkreśla, że właśnie tak powstaje pętla zwrotna: model rozwiązuje problem przez iteracyjne powtarzanie przeplatanego procesu myśl, akcja, obserwacja.

Ten schemat widać nawet w szablonie promptu. Prompt systemowy gotowego modułu ReAct w LangGraph wygląda tak: „Question: the input question you must answer”, „Thought: you should always think about what to do”, „Action: the action to take, should be one of [Wikipedia, duckduckgo_search, Calculator]”, „Action Input: the input to the action”, „Observation: the result of the action”, potem powtórzenie tych czterech linii tyle razy, ile potrzeba, i na końcu „Final Answer: the final answer to the original input question”. Zwykłe szablony w n8n czy w Make są dokładnie tym samym mechanizmem, tylko zapisanym w konfiguracji zamiast w tekście.

Po ReAct przyszła seria następców, między innymi Refleksja, która doprowadziła do modeli rozumujących. Sam ReAct ma też jedną zmierzoną zaletę: połączenie rozumowania w łańcuchu myśli z dostępem do zewnętrznych źródeł istotnie ogranicza halucynacje, bo model w miejscach, gdzie liczy się poprawność, sprawdza fakty zamiast je zmyślać. O granicach tego podejścia pisałem osobno przy technikach ograniczania halucynacji, od RAG po human-in-the-loop.

Narzędzia: jak model prosi o dane

Drugi paradygmat, obok ReAct, to function calling, czyli wywoływanie funkcji. Wprowadził go OpenAI w czerwcu 2023 roku. IBM opisuje to tak: paradygmat function calling polega na wytrenowaniu modeli tak, aby rozpoznawały sytuacje, w których należy wywołać narzędzie, i generowały ustrukturyzowany obiekt JSON z argumentami potrzebnymi do tego wywołania. Dziś tę zdolność ma wiele rodzin modeli, w tym Granite od IBM, seria Llama od Meta, Claude od Anthropic i Gemini od Google.

Technicznie wygląda to tak: przy budowie agenta dostajesz listę narzędzi, a każde narzędzie ma nazwę, opis w języku naturalnym i schemat argumentów. Model nie ma dostępu do funkcji, ma za to informację, że funkcja istnieje i jakie przyjmuje parametry. W odpowiedzi zwraca nazwę narzędzia i argumenty jako JSON, a warstwa wykonawcza sprawdza, czy nazwa jest dozwolona, wypełnia brakujące pola i dopiero wtedy wywołuje narzędzie. W logu wygląda to jak zwykły request wychodzący z serwera, tyle że z polem opisującym, po co ten request w ogóle powstał.

Wybór między tymi dwoma podejściami ma realną cenę i IBM opisuje ją wprost. Przy stosunkowo prostych albo przewidywalnych zadaniach function calling działa szybciej, oszczędza tokeny i jest prostszy w implementacji niż agent ReAct, bo liczba tokenów wydana na iteracyjną pętlę rozumowania byłaby po prostu marnowana. Kompromis jest taki, że ReAct daje większą kontrolę nad tym, kiedy i po co model sięga po narzędzie, a function calling tej kontroli nie daje. Jeśli zadanie zawsze wygląda tak samo, wybór jest prosty. Jeśli zależy od danych, których jeszcze nie ma, pętla się opłaca.

MCP: standard podłączania narzędzi i granica jego odpowiedzialności

Problem jest techniczny i bardziej przyziemny niż brzmi. Zanim pojawił się standard, każde narzędzie trzeba było osobno opisać i podpiąć. W 2024 roku Anthropic wprowadził Model Context Protocol, czyli otwarty standard interakcji AI z narzędziami. IBM opisuje go przez analogię sprzętową: MCP dla aplikacji AI pełni tę samą rolę co port USB-C dla sprzętu.

Architektura ma trzy elementy: host MCP, klient MCP i serwer MCP. Przy jednym hoście może istnieć wiele klientów, ale każdy klient ma relację jeden do jednego z serwerem, a klient odpowiada za zarządzanie sesją: przerwania, timeouty, ponowne połączenia i zamykanie. Serwer wystawia dane przez trzy typy prymitywów. Zasoby (Resources) to odczyt danych z baz wewnętrznych i zewnętrznych, bez wykonywania obliczeń. Narzędzia (Tools) to wywołania ze skutkiem ubocznym, czyli obliczenie albo zapytanie do API. Prompty (Prompts) to gotowe szablony i przepływy do komunikacji z serwerem.

Transport działa dwoma metodami, w obu przypadkach w formacie JSON-RPC 2.0: standardowe wejście i wyjście (stdio) sprawdza się przy zasobach lokalnych, a zdarzenia wysyłane z serwera (SSE) przy zasobach zdalnych. W protokole są trzy rodzaje komunikatów: żądania, odpowiedzi i powiadomienia, przy czym powiadomienie odpowiedzi nie oczekuje.

Najczęstsze nieporozumienie dotyczy odpowiedzialności. MCP nie jest frameworkiem agentów, tylko warstwą integracji narzędzi, i sam nie decyduje, kiedy narzędzie zostanie wywołane i po co. O tym decyduje model językowy, na podstawie kontekstu zadania użytkownika. W praktyce oznacza to, że podpięcie serwera MCP nie daje Ci automatyzacji, tylko dostęp do narzędzi, a zachowanie nadal trzeba zaprojektować. Red Hat opisuje to przez obraz warstw: możliwości MCP zbudowane są na API i bez API nie istniałyby, a komunikacja jest na API ustandaryzowana, nie zastąpiona.

Połączenie zaczyna się od handshake'u, czyli wzajemnego przedstawienia możliwości: klient mówi, jakie ma możliwości i jaką wersję protokołu rozumie, serwer odpowiada, co potrafi i jakie narzędzia oraz zasoby udostępni. Red Hat wskazuje pięć typów serwerów, które spotkasz w praktyce: lokalne źródła danych, usługi zdalne, oficjalne integracje, serwery społecznościowe i serwery referencyjne. Konfiguracja samego połączenia, krok po kroku, jest opisana w tekście o podpięciu Claude do własnych automatyzacji przez MCP.

Pamięć: co agent zabiera ze sobą z kroku na krok

Pamięć w pętlach opisuje się zwykle w dwóch typach. Pamięć krótkoterminowa trzyma kontekst bieżącego przepływu, na przykład podobne zadania z ostatniego kwartału, żeby usprawnić proces. Pamięć długoterminowa zachowuje wiedzę historyczną, na przykład lokalizację bazy danych czy preferowane metody analizy, i dzięki temu buduje głębsze rozumienie kontekstu. TechTarget dodaje, że agenci pamięci są odpowiedzialni za uczenie się, adaptację i wiedzę dziedzinową, bo systemy agentowe opierają się na pamięci, żeby utrzymać kontekst między krokami, zrozumieć preferencje i ograniczenia oraz dosięgnąć danych z przeszłości.

Implementacja bywa banalna. Apify pokazuje konfigurację LangChain, która trzyma trzy ostatnie rozmowy: ConversationBufferWindowMemory z parametrem k równym 3, model ustawiony na temperature 0.3. Kontekst często dokłada się przed rozumowaniem, a nośnikiem jest zwykle baza wektorowa, bo szybciej szuka dzięki embeddingom.

Tu muszę zaznaczyć lukę w źródłach, bo często to obiecywane w artykułach. Żadne z przejrzanych źródeł nie opisuje mechanizmu, którym historia pętli jest przycinana albo streszczana po przekroczeniu limitu okna. Nie znalazłem też żadnego źródła podającego realny limit okna konkretnego modelu w tokenach ani typową liczbę iteracji z telemetrii. Jeśli ktoś podaje Ci konkretną liczbę, traktuj ją jako wartość wybraną przez konkretnego dostawcę, nie jako właściwość agentów.

Kiedy pętla się zatrzymuje i dlaczego to kosztuje

Każda iteracja to wywołanie modelu, czyli wydatek i opóźnienie. IBM podaje dwa warianty zakończenia i w żadnym nie ma liczby. Wariant pierwszy: ustalenie maksymalnej liczby iteracji pętli to prosty sposób na ograniczenie opóźnień, kosztów i zużycia tokenów oraz uniknięcie pętli bez końca. Wariant drugi: pętlę można zakończyć po spełnieniu konkretnego warunku, na przykład gdy model rozpozna potencjalną odpowiedź końcową przekraczającą próg pewności.

Żadne z tych podejść nie daje wiarygodnej liczby do wklejenia w dokumentację projektu, bo zależy od tego, czym się zajmuje agent. Dla zadania, które wymaga trzech odczytów, limit dziesięciu kroków to zabezpieczenie. Dla zadania, które musi przejrzeć kilkanaście faktur i porównać je z dokumentami, dziesięć kroków to za mało, a model zacznie się kręcić i zgłaszać gotowość, zanim skończy pracę. Dlatego limit ustawia się po testach na prawdziwych danych, a nie na podstawie artykułu.

Jest też ograniczenie, o którym rzadko się pisze: czas życia samego przebiegu. Materiał inżynierski Runtype opisuje to wprost: większość pętli agenta działa w obrębie jednego żądania, czyli funkcji serverless, handlera HTTP albo workera z limitem czasu ściany, a decyzja, która trwa dwadzieścia minut, przeżywa wszystkie z nich. To ustawienia tego konkretnego produktu, nie standard branżowy, ale kierunek jest właściwy: oczekujący na odpowiedź klient i robot, która trwa dwadzieścia minut, to dwie różne usługi. Ten sam materiał podaje domyślny timeout bramki zatwierdzenia na poziomie pięciu minut i radzi dobierać go do miejsca, z którego zatwierdza człowiek: kilka minut, gdy ktoś czeka w panelu, godzina, gdy ktoś odbiera telefonem.

Człowiek w pętli: które akcje muszą czekać na zgodę

Tu dochodzimy do granicy, o którą pytają wszyscy właściciele firm. Definicja human-in-the-loop z materiału Runtype brzmi: projekt, w którym agent AI musi uzyskać decyzję człowieka przed wykonaniem określonych akcji, a pauza, decyzja i wynik są wszystkie zapisywane.

Które akcje? Autorzy rozwiązują to klasyfikacją według promienia rażenia (blast radius), czyli trzema pytaniami o każde narzędzie: czy zmienia stan, czy ten stan należy do kogoś spoza systemu i czy zmianę da się cofnąć. Z tego wychodzą cztery klasy narzędzi:

Klasa narzędzia	Przykłady	Zasada
Odczyt	przeszukanie, pobranie rekordu, lista zamówień	bez bramki, limit wywołań na turę
Odwracalny zapis wewnętrzny	worska szkic, notatka, założenie zgłoszenia	bez bramki, zapis w logu, limit wywołań na turę
Nieodwracalne lub zewnętrzne	wysłanie maila, publikacja na kanale klienta, usunięcie	wymagane zatwierdzenie
Pieniądze lub operacja masowa	refund, zmiana planu, aktualizacja wielu rekordów	wymagane zatwierdzenie, jedno wywołanie na turę

Z tej tabeli wynika praktyczny wniosek, którego nie ma w definicji: jeśli jedno narzędzie obsługuje zarówno zwrot pięciu dolarów, jak pięciu tysięcy, rozdziel je na dwa narzędzia, żeby bramka potrafiła je rozróżnić. Dopóki to nie zrobisz, agent będzie prosił o zgodę na każdą transakcję bez względu na kwotę albo ominie bramkę przy małych kwotach, żeby nie zasypywać człowieka pytaniami.

I tu jest pułapka, którą warto znać. Bramkowanie wszystkiego daje zmęczenie zatwierdzaniem, a bramka, którą zatwierdzający klikają bez czytania, nie jest bramką. W praktyce w ciągu tygodnia zatwierdzający zaczyna klikać automatycznie i niebezpieczne wywołanie na sto kliknięć dostaje taki sam odruch jak dziewięćdziesiąt dziewięć odczytów. Dlatego polityka łączy bramkę z limitem wywołań na turę i pozwala zatwierdzającemu wybrać opcję „zawsze odmawiam” dla narzędzia, którego nie chce już widzieć. Akcje tylko do odczytu bramki zwykle w ogóle nie potrzebują. Praktyczny efekt: przy dobrze zaprojektowanym procesie jedna na sto akcji wymaga Twojej decyzji, a nie co trzecia.

Ten model sprawdza się w praktyce przy realnych zadaniach, nie tylko przy zadaniach z podręcznika. Opisuję to osobno w tekście o dziesięciu zadaniach biznesowych, które agenci AI naprawdę ogarniają, z wynikami testu i opisem, gdzie się wysypali.

Bramka musi być w systemie, a nie w instrukcji dla modelu

To jest punkt, który odróżnia działające wdrożenie od takiego, które działa, dopóki ktoś nie zmieni modelu. Instrukcja w prompcie jest doradcza: model decyduje w każdej turze, czy jej posłucha, a ta decyzja zmienia się wraz z wersją modelu, długością kontekstu i każdą instrukcją wstrzykniętą przez wynik narzędzia albo dokument. Prompt mówiący „nie usuwaj nic bez pytania” jest dokładnie taką instrukcją.

Bramka egzekwowana przez runtime stoi między wywołaniem narzędzia przez model a samym wykonaniem, więc wywołanie nie może się wykonać bez zapisanej decyzji, niezależnie od tego, co modelowi powiedziano albo w co został wmówiony. Praktyczne są dwie własności. Po pierwsze, gdy model zgłasza bramkowane wywołanie, runtime zatrzymuje się przed wykonaniem, zapisuje stan, w tym wiadomości i oczekujące wywołanie z jego identyfikatorem i parametrami, i zwraca uchwyt. Decyzja wysłana pod tym identyfikatorem wznawia przebieg dokładnie w tym samym wywołaniu, z tymi samymi parametrami, które widział człowiek, i nic nie jest generowane od nowa. Po drugie, model wciąż tylko proponuje akcję i jej parametry, a człowiek zatwierdza albo odrzuca dokładne wywołanie, i przebieg rusza dalej od decyzji.

Człowiek widzi nazwę narzędzia, parametry z usuniętymi wartościami wrażliwymi, to, kto lub co uruchomiło przebieg, oraz uzasadnienie agenta, ale oznaczone wyraźnie jako jego własna deklaracja. Uzasadnienie poprawia tekst, który czyta człowiek, i nigdy nie wchodzi do logiki decyzji. Kod, który podejmuje decyzję na podstawie uzasadnienia, czyli automatyczne zatwierdzanie, ocena ryzyka albo klasyfikator, zamienia tekst zapisywalny przez atakującego na wejście autoryzacji. To jest dokładnie ten przypadek, o którym pisałem przy atakach prompt injection na agentów w n8n.

Jeśli nikt nie zatwierdzi na czas, żądanie wygasa i narzędzie się nie wykonuje. Wygaśnięcie nigdy nie może oznaczać zgody. Zapis odpowiadający na pytanie kto co zatwierdził musi zawierać co najmniej identyfikator zatwierdzenia i wywołania, nazwę narzędzia i parametry dokładnie tak, jak zostały pokazane, tożsamość zatwierdzającego, decyzję z znacznikiem czasu, informację, czy żądanie wygasło, oraz wynik wykonanego wywołania.

Warto odróżnić dwie rzeczy, które często się mieszają. Guardrails sprawdzają treść: klasyfikują dane wejściowe i wyjściowe, maskują dane osobowe, blokują tematy. Bramki human-in-the-loop sprawdzają działanie: konkretne wywołanie narzędzia z konkretnymi parametrami czeka na człowieka. Jedno bez drugiego daje system pozornie bezpieczny.

Bezpieczeństwo pętli: sandbox, uprawnienia i atak przez treść od klienta

Pełna pętla, która może wywoływać narzędzia, potrafi zrobić szkodę. NVIDIA opisuje to bez owijania w bawełnę: każdy agent ma własny sandbox, żeby nawet wtedy, gdy agent „wymknie się spod kontroli” albo zostanie zmanipulowany, nie mógł skompromitować systemu bazodanowego, wyciągnąć wrażliwych danych ani nabić kosztów. Chodzi o warstwę infrastruktury, a nie o zabezpieczenia wewnątrz kodu agenta: sandboxy, silniki polityk i routery prywatności dla dostępu do sieci i danych, egzekwowanie reguł na poziomie infrastruktury.

Skala zagrożeń ma już pomiary. ESET, w materiale opartym na skanowaniu ponad 60 tys. umiejętności dla agentów AI, z 20 marca 2026 roku, podaje, że spośród przeanalizowanych przeskanowanych 33% komunikuje się z internetem bez żadnych sprawdzeń i ograniczeń, 23% wykonuje polecenia w imieniu użytkownika, 18% modyfikuje pliki na dysku, a 2,4% zmienia polityki bezpieczeństwa skryptów. Metodologia nie jest w tekście opisana: brak próby, brak definicji umiejętności i brak linku do raportu, więc traktuj te liczby jako wiarygodne, ale niemożliwe do niezależnego sprawdzenia. Warto jednak zobaczyć sam kierunek: 23% umiejętności wykonujących polecenia to nie jest egzotyka, to najczęstsza klasa uprawnień, o którą będziesz prosił.

ESET opisuje też sposób, w jaki atak na agenta wygląda w praktyce: nadużycia umiejętności agentowych obserwowano przy kradzieży danych, pobieraniu i uruchamianiu złośliwego oprogramowania, nadpisywaniu instrukcji przez prompt injection oraz stopniowym przesuwaniu zachowania agenta w kolejnych interakcjach, zanim ujawni ukryty cel. Skutec złośliwy, zdaniem autorów, może ujawnić się dwa, trzy lub więcej etapy dalej w łańcuchu, czyli tam, gdzie człowiek już nie patrzy. Jedna umiejętność może zmienić się z pomocnej w złośliwą z dnia na dzień, więc traktuj je jak oprogramowanie, a nie jak prompty: przypinaj wersje i monitoruj zmiany.

Po stronie uprawnień zasada jest prosta i Red Hat nazywa ją dosłownie: nadaj serwerom MCP tylko minimalny dostęp, którego potrzebują do działania, czyli zasadę najmniejszych uprawnień (PoLP), i okresowo sprawdzaj, do czego każdy serwer ma dostęp, żeby żaden nie miał nadmiarowych uprawnień. Praktycznie: token API klienta sprzedażowego wpięty do agenta przetwarzającego maile to zaproszenie do kłopotu.

Osobny wektor jest mniej oczywisty, bo nie wymaga złośliwego narzędzia. Agent, który czyta treści od klientów, czyta pliki wgrane przez klientów, wklejone maile i rekordy z integracji. Zarówno wywołanie narzędzia, jak i uzasadnienie agenta mogą ukształtować się pod wpływem tej treści. Dlatego bramka musi być egzekwowana w runtime, a uzasadnienie agenta nie może być sygnałem sterującym. I druga strona tej samej prawdy: bramka zatwierdzenia nie zobaczy prompt injection, który nigdy nie zamieni się w wywołanie narzędzia, więc sama bramka nie wystarczy jako ochrona.

Kiedy pętla jest za dużo: agent czy zwykły przepływ

Najczęstszy błąd w projektach, które widzę, to budowanie autonomii tam, gdzie wystarczy wywołanie funkcji. IBM formułuje to jako prosty kompromis: przy prostych lub przewidywalnych zadaniach function calling działa szybciej, oszczędza tokeny i jest prostszy, a iteracyjna pętla rozumowania byłaby marnowaniem. Pętla ReAct ma sens tam, gdzie wynik poprzedniego kroku zmienia plan i model musi zdecydować, czytać dalej, czy kończyć.

Microsoft w swoim materiale (w wersji czeskiej) podaje skalę nakładu od strony czasu: proste agenty da się zbudować w kilka dni, a zaprojektowanie, wytrenowanie, przetestowanie i zintegrowanie agentów bardziej złożonych lub dopasowanych do firmy może trwać kilka tygodni albo dłużej. Koszt zależy od zakresu, wymaganych narzędzi i infrastruktury, przy czym autorzy nie podają żadnych kwot, więc nie będę zmyślał widełek. Ich miejsce jest w wycenie projektu, po ustaleniu listy narzędzi.

Spojrzenie z bezpieczeństwa prowadzi do tej samej konkluzji. Runtype opisuje, dlaczego instrukcja w prompcie przestaje działać, gdy zmienia się model, gdy lista narzędzi rośnie powyżej dwudziestu pozycji albo gdy klient wklei dokument, który mówi agentowi, żeby pominął sprawdzenie. Przy kilku narzędziach i jednym zadaniu, które zawsze wygląda tak samo, zwykły przepływ z kilkoma węzłami jest tańszy i bardziej przewidywalny niż agent. Wybór techniczny - przepływ, kod czy agent - ma swoje konsekwencje kosztowe i utrzymaniowe, opisałem je w tekście o n8n kontra Dify kontra LangChain i kiedy który wariant pasuje.

Pytania, które sprawdzam, zanim włączę pętlę w firmie

Zanim cokolwiek wdrożymy, mam gotową listę pytań, które zadaję na pierwszym spotkaniu. Nie jest ona wykazem funkcji, tylko testem, czy pętla ma w ogóle sens w tym procesie.

1. Co dokładnie zmienia się w świecie po wywołaniu narzędzia i komu należy ten zmieniony stan: nam czy komuś z zewnątrz?
2. Czy da się to cofnąć, czy wynik jest nieodwracalny? Jeśli nie, to na której klasie z tabeli wyżej stoi narzędzie?
3. Jaki jest limit iteracji i skąd ta liczba, a nie skąd inna? Po czym poznam, że agent krąży zamiast działać.
4. Kto zatwierdza bramkowane akcje, w jakim czasie od zgłoszenia i co się dzieje, gdy nie odpowie w ciągu tego czasu?
5. Jakie uprawnienia mają tokeny i klucze użyte przez narzędzia, kto je wystawił i kiedy ostatnio ktoś je przeglądał?
6. Jakie dane klientów wchodzą do pętli, gdzie są przechowywane i co zostaje w logu po zakończeniu przebiegu.

To pytania, które padają, gdy wdrożenie się zatrzymuje, a nie gdy idzie gładko. Większość porażek, które widzę w praktyce, wynika nie z modelu, tylko z braku odpowiedzi na któryś z tych sześciu punktów. Opisałem je szerzej przy pięciu automatyzacjach, które się nie udały - warto tam zajrzeć, jeśli zastanawiasz się, czy Twój proces nadaje się na pętlę, czy na zwykły przepływ.

Jeśli chcesz sprawdzić, które z tych pytań dotyczy Twojej firmy, napisz do mnie. Odpowiadam zwykle tego samego dnia, a zakres i wycenę dostajesz na piśmie, zanim cokolwiek zaczniemy pisać.