Wnętrze pętli agenta: wzorzec stojący za niezawodnymi agentami AI

W naszym poprzednim wpisie postawiliśmy tezę, że kodowanie staje się pętlą, a nie naciśnięciem klawisza: wywołaj model, uruchom narzędzie, zwróć wynik, powtórz. To nagłówek. Ten wpis to inżynieria, która kryje się pod spodem.

Bo jest coś, co każdy zespół budujący agenty w końcu odkrywa: podmiana modelu na mądrzejszy rzadko naprawia chwiejnego agenta. Przesiadasz się z jednego frontierowego modelu na kolejny, patrzysz, jak Twój benchmark podskakuje o dwa punkty, a Twój agent wciąż kręci się w nieskończoność na tym samym zadaniu, wciąż zapomina, czego nauczył się dziesięć kroków temu, wciąż ogłasza zwycięstwo nad kodem, który się nie uruchamia. Inteligencja się poprawiła. Agent nie.

Powód jest taki, że agent to nie model. Agent to pętla ze strukturą — a to struktura decyduje, czy niezawodność zostanie wygrana, czy przegrana. To ta część, która nie mieści się w demowym tweecie, więc bywa ignorowana. Nie ignorujmy jej. Oto wzorzec pętli agenta, rozłożony na czynniki pierwsze.

Pętla w jednym oddechu

Zacznij od nieredukowalnego rdzenia. Jak ujmuje to Simon Willison, agent to „coś, co uruchamia narzędzia w pętli, aby osiągnąć cel”. Wersja minimalna to naprawdę pętla while: daj modelowi cel i jakieś narzędzia, pozwól mu zażądać wywołania narzędzia, uruchom je, zwróć wynik i powtarzaj, aż powie, że skończył.

To da się zbudować w jedno popołudnie. Czego nie da się zbudować w jedno popołudnie, to pętla, która pozostaje spójna przez pięćdziesiąt kroków, nie przekracza swojego budżetu kontekstu i nie wysyła z przekonaniem zepsutej pracy. Naiwna pętla i niezawodna pętla mają ten sam szkielet i zupełnie różne wskaźniki przeżywalności. Różnicą jest wszystko to, co zaraz opiszemy — zbiorczo harness: pozamodelowy runtime, który owija pętlę rozumowania dyspozytorem narzędzi, zarządzaniem kontekstem, bezpieczeństwem i weryfikacją. Jak ujmuje to elementarz Firecrawl o harnessach agentów, model to tylko połowa systemu; harness to druga połowa — i to ta połowa, o której istnieniu większość kupujących nie wie.

Fazy prawdziwej pętli

Produkcyjna pętla agenta nie jest jednym niezróżnicowanym krokiem „pomyśl i działaj”. To potok faz, z których każda wykonuje odrębne zadanie w każdej iteracji:

Pre-check / kompaktowanie. Zanim model pomyśli, harness decyduje, co w ogóle wolno mu zobaczyć. Jeśli rozmowa się wydłuża, harness kompaktuje ją — streszczając lub odrzucając przestarzały kontekst, tak aby ważny stan przetrwał.
Myślenie. Model rozumuje o celu i bieżącym stanie oraz proponuje kolejne działanie (często w formie „myśl → akcja” w stylu ReAct).
Działanie / wykonanie. Harness wysyła żądane wywołanie narzędzia — odczyt pliku, uruchomienie polecenia, zapytanie do API — i przechwytuje wynik. To tutaj żyją też guardrails: które narzędzia są dozwolone, co wymaga potwierdzenia, co jest wprost zakazane.
Obserwacja. Wynik narzędzia trafia z powrotem do kontekstu jako nowy dowód modelu o rzeczywistości.
Weryfikacja / post-processing. Przed kolejnym obiegiem harness (lub drugi model) sprawdza, czy krok rzeczywiście przybliżył do celu — i czy agent sam siebie nie oszukuje.

Naiwna pętla zwija kroki 1 i 5 do niczego: po prostu myśli, działa i dokleja wszystko do wciąż rosnącego zapisu. To działa przez dziesięć kroków i rozpada się przy pięćdziesięciu. Niezawodna pętla traktuje pre-check i weryfikację jako fazy pierwszej klasy. I to jest cała gra.

Context engineering: karmienie pętli

Pojedynczym największym czynnikiem decydującym o tym, czy długo działająca pętla przetrwa, jest to, co stawiasz przed modelem na każdym kroku — to, co Anthropic nazywa context engineering. Okno kontekstu modelu to budżet, a nie plecak. Nie możesz po prostu wpychać do niego coraz więcej.

Każda iteracja pętli dodaje tokeny: odczytane pliki, wynik polecenia, wcześniejsze rozumowanie, wyniki narzędzi. Na prawdziwym repozytorium istotne informacje w końcu przekraczają okno, a model zaczyna zapominać, czego nauczył się wcześniej w trakcie przebiegu. Context engineering to dyscyplina decydowania, na każdym kroku, które instrukcje, dowody i stan naprawdę muszą być obecne — i bezwzględnego wykluczania reszty.

Dla przebiegów, które realnie przekraczają pojedyncze okno kontekstu, wzorzec staje się bardziej przemyślany. Harness dla długo działających agentów firmy Anthropic, udokumentowany w bazie ZenML LLMOps, wykorzystuje dwuczęściowy projekt: inicjalizator, który przygotowuje pracę, oraz agenta kodującego, który ją wykonuje, z resetami kontekstu i artefaktami przekazania między oknami. Zamiast jednego agenta próbującego utrzymać w głowie wielogodzinne zadanie, praca jest zapisywana w punktach kontrolnych jako trwałe artefakty, które świeży kontekst może podjąć. Agent zapomina — celowo — a harness dba o to, by nic ważnego nie przepadło, gdy to się dzieje.

To nieefektowna rzeczywistość agentów długiego horyzontu: większość inżynierii dotyczy zarządzania zapominaniem, a nie dodawania inteligencji.

Pętla weryfikacji: generator kontra ewaluator

Oto tryb porażki, który upokarza każdy zespół: agenty kiepsko oceniają własną pracę. Zapytaj model „czy zrobiłeś to poprawnie?” tuż po tym, jak coś zrobił, a przeważnie odpowie „tak” — także wtedy, gdy odpowiedź brzmi „nie”. Samokrytyka jednym tchem z generowaniem jest słaba, bo model jest zakotwiczony w pracy, którą właśnie wytworzył.

Naprawa jest strukturalna, a nie lepszym promptem. Dzielisz pętlę na dwie role. Jeden model generuje; osobny, sceptyczny model ewaluuje — adwersarialnie, z innym ujęciem i najlepiej innymi dowodami. Epsilla opisuje to jako pętlę agenta w stylu GAN: Generator proponuje, Ewaluator próbuje to rozbić, a dalej idzie tylko praca, która przeżyje Ewaluatora. Nazwa to ukłon w stronę generatywnych sieci adwersarialnych, a intuicja jest ta sama — adwersarialna presja daje lepszy wynik niż pojedynczy model sprawdzający własną pracę domową.

W praktyce to dlatego agent kodujący z mocnymi testami przewyższa tego bez nich z dużym zapasem: zestaw testów jest Ewaluatorem. Gdy brakuje Ci tego sygnału — cienkie pokrycie testami, brak jasnego kryterium sukcesu — faza weryfikacji w pętli jest ślepa, a agent z przekonaniem przepłynie obok błędów. Śmieci na wejściu sprzężenia zwrotnego, śmieciowa pewność na wyjściu. Jeśli masz wynieść z tego wpisu jedno: jakość Twojej fazy weryfikacji wyznacza górny limit jakości Twojego agenta.

Ograniczenia to funkcja, a nie ograniczenie

Instynkt, gdy agent się źle zachowuje, każe dać mu więcej swobody i mądrzejszy model. Przeciwna intuicji lekcja od zespołów wysyłających prawdziwe systemy jest odwrotna: to ograniczenia w harness czynią agenty niezawodnymi. Opracowanie Augment Code o harness engineering dla agentów kodujących argumentuje dokładnie to — że to ograniczenia, a nie większe modele, wysyłają na produkcję godny zaufania kod.

Konkretnie, ograniczenia, które się opłacają:

Wąskie, dobrze opisane narzędzia. Kilka ostrych narzędzi, które model rozumie, bije rozłożystą powierzchnię API. Projektowanie narzędzi to prompt engineering pod inną nazwą.
Bramki uprawnień. Zdecyduj, co agent może robić autonomicznie, a co wymaga człowieka w pętli. „Tryb YOLO” ma swoje miejsce — ale to świadomy wybór, nie domyślne ustawienie.
Ograniczone kroki i budżety. Pętla, która może działać w nieskończoność, będzie działać w nieskończoność. Limity iteracji, tokenów i czasu rzeczywistego zamieniają rozbiegankę w eleganckie poddanie się.
Observability. Nie naprawisz pętli, której nie widzisz. Logowanie każdej fazy — co model zobaczył, co wybrał, co zwróciło narzędzie — to różnica między debugowaniem a zgadywaniem.

Nic z tego nie pochodzi od modelu. Wszystko to pochodzi z harness. To sedno tego, dlaczego aktualizacje modelu nie naprawiają chwiejnych agentów: porażka nigdy nie tkwiła w wagach.

Gdzie włożyć wysiłek

Załóżmy więc, że budujesz agenta i masz ograniczoną liczbę godzin inżynierskich. Dokąd je skierować?

Nie w pogoń za najnowszym modelem — to ustawienie, które zmieniasz w jedno popołudnie, gdy warto. Trwała dźwignia tkwi w pętli: faza weryfikacji z prawdziwym sygnałem sukcesu, dyscyplina kontekstu przetrwająca długie przebiegi, wąskie narzędzia i observability, dzięki któremu naprawdę widzisz, co się dzieje. To są części, które się kumulują — i, co znamienne, części, które przeżywają aktualizacje modelu. Lepszy model czyni dobrze zbudowaną pętlę lepszą. Niemal nic nie robi dla pętli bez weryfikacji i bez strategii kontekstu.

Jest też strategiczna wersja tej tezy. W miarę jak modele bazowe wchłaniają więcej zdolności planowania i doboru narzędzi, część rusztowania zostaje „połknięta” przez model — ale troski na poziomie systemu (pamięć, orkiestracja, weryfikacja, governance) nie pochodzą od samego modelu i, można argumentować, muszą rosnąć w miarę jak model staje się zdolniejszy i powierza mu się pracę o dłuższym horyzoncie. Stawiaj na warstwy, które przeżyją następne wydanie.

Podsumowanie

Agent to pętla ze strukturą, a struktura to produkt. Model dostarcza inteligencji; pętla decyduje, czy ta inteligencja kiedykolwiek wyląduje. Fazy — pre-check, myślenie, działanie, obserwacja, weryfikacja — to miejsce, gdzie inżynieruje się niezawodność. Context engineering utrzymuje długie przebiegi spójnymi. Osobny ewaluator utrzymuje agenta w uczciwości. Ograniczenia powstrzymują go przed spadnięciem z urwiska. Podmień model na mądrzejszy, a nic z tego nie przyjdzie za darmo; zbuduj pętlę dobrze, a mądrzejszy model uczyni to wszystko lepszym.

To warstwa, w której pracujemy. Jeśli Twój zespół ma agenta, który pięknie demonstruje się i psuje na produkcji — albo projektujesz takiego i chcesz dobrze ustawić pętlę za pierwszym razem — to dokładnie ta praca, którą wykonujemy.

Projektujemy i audytujemy pętle oraz harnessy agentów. Umów się z nami na przegląd.