Inżynieria promptów czy kontekstu, narzędzi, pętli? Naprawa agentów AI warstwa po warstwie

Gdy agent AI zachowuje się niewłaściwie w środowisku produkcyjnym, zespoły zwykle kłócą się o słownictwo zamiast o dowody: jeden inżynier chce lepszego promptu, inny obwinia kontekst, a trzeci wskazuje na mechanizm integracji. Inżynieria promptów, kontekstu, mechanizmów integracji oraz pętli nie są konkurencyjnymi szkołami myślenia; to cztery warstwy ułożone jedna na drugiej, przy czym każda z nich zawodzi w swoisty, rozpoznawalny sposób. Ten przewodnik definiuje każdą warstwę na przykładzie małego agenta programistycznego, a następnie przedstawia procedurę opartą na śledzeniu, która pomaga określić, która warstwa faktycznie zawiodła, zanim zmienimy jakikolwiek kod.

Cztery warstwy agenta AI w skrócie

• Inżynieria promptów kształtuje instrukcje przekazywane modelowi.
• Inżynieria kontekstu decyduje o tym, co model może zobaczyć przed udzieleniem odpowiedzi.
• Inżynieria harness tworzy środowisko, w którym działa model: narzędzia, pamięć, pliki, uprawnienia oraz mechanizmy odzyskiwania.
• Inżynieria pętli projektuje cykl, który utrzymuje system w działaniu, sprawdza jego postępy i decyduje, kiedy należy przestać.

Najdroższe incydenty związane z agentami wynikają z naprawiania błędów w jednej z tych warstw.

Gdy demo działa poprawnie, a produkcja nie

To schemat dobrze nam znany. Agent wydaje się doskonały w demonstracji. Kilka dni po uruchomieniu zaczyna się pętlić, zużywać tokeny, traci informacje, o których dowiedział się godzinę wcześniej, lub zawodzi, gdy narzędzie zwraca nieoczekiwany payload.

Zespół dzieli się na grupy. Ktoś proponuje przepisanie instrukcji, ktoś inny uważa to za problem z kontekstem, a jeszcze inna osoba podejrzewa sprzęt. Bez wspólnego sposobu na zlokalizowanie błędu naprawa trwająca dwa dni zamienia się w przerabianie tekstu przez dwa tygodnie, ponieważ każda poprawka wprowadzana jest na warstwę, która wcześniej funkcjonowała poprawnie.

To jest praktyczny powód, dla którego należy trzymać te cztery pojęcia oddzielnie. Każde z nich odnosi się do innego miejsca, gdzie mogą wystąpić problemy, a gdy potrafimy je rozróżnić, debugowanie agenta staje się procesem, a nie grą w zgadywanki.

PACT: mnemoniczna metoda do zapamiętywania czterech warstw

Kompaktowy sposób na zapamiętanie warstw podczas incydentu to PACT: Prompt, Awareness, Control, Trajectory. Każde słowo odpowiada jednemu pytaniu:

• Prompt: czy zadanie zostało jasno określone?
• Awareness: czy model otrzymał informacje potrzebne do tego kroku?
• Kontrola: czy środowisko wykonawcze może bezpiecznie i niezawodnie wykonać to, o co prosi model?
• Trajektoria: czy powtarzany proces zmierza w kierunku zakończenia, które można zweryfikować?

Celem nie jest dodanie kolejnej warstwy żargonu. Chodzi o to, aby granice pomiędzy typami awarii były na tyle łatwe do zapamiętania, by faktycznie je stosować, gdy coś idzie nie tak.

Jak pojawiły się te warstwy i dlaczego ważny jest ich porządek

Pojęcia te pojawiały się mniej więcej w kolejności, w miarę jak narzędzia zyskiwały nowe możliwości:

• Inżynieria promptów (mniej więcej od 2022 do 2024 roku) była pierwszą umiejętnością: sformułowanie zapytań, przykłady, ograniczenia oraz wzorce typu few-shot, skierowane na jedno wezwanie modelu.
• Inżynieria kontekstu (mniej więcej od 2024 do 2025 roku) stała się kluczowa, gdy agenci musieli jednocześnie obsługiwać pobraane dokumenty, historię rozmów oraz definicje narzędzi. Pytanie przesunęło się z tego, jak sformułować prośbę, na to, co faktycznie widzi model. Anthropic, LangChain i Chroma przyczyniły się do upowszechnienia tego podejścia wśród praktyków, a komentarze Andreja Karpathy’ego pomogły włączyć je do szerszych dyskusji inżynieryjnych.
• Inżynieria wykorzystania zasobów (początek 2026 roku) stała się głównym tematem, gdy agenci uzyskali dostęp do systemu plików, możliwość wykonywania poleceń w terminalu oraz operacje trwające godziny. Uwaga skupiła się na zasięgu działania agenta oraz na zachowaniu po nieudanej próbie wywołania narzędzia. Prace OpenAI nad Codexem uczyniły to istotnym problemem dla agentów programistycznych; ich opracowanie na temat inżynierii wykorzystania zasobów z Codexem stanowi przydatny podstawowy materiał referencyjny.
• Inżynieria pętli (połowa 2026 r.) to najnowsza kategoria. Nawet przy użyciu odpowiedniego zestawu narzędzi nadal trzeba zdecydować, co ma robić każda iteracja i kiedy przestać: obserwować, działać, weryfikować, powtarzać czy zatrzymać się. IBM udostępnia wyjaśnienie dotyczące inżynierii pętli, jeśli chcesz uzyskać inne ujęcie tematu.

Te daty opisują momenty, w których terminy te zaczęły być używane, a nie formalne kamienie milowe; pojęcia te są nadal w fazie kształtowania się w momencie pisania tego tekstu. Ważne jest to, że nic nie zostało zastąpione – każda warstwa została dodana na wierzch poprzedniej, ponieważ każdy wzrost autonomii wymagał własnego mechanizmu sterowania.

Inżynieria promptów: lokalna umowa

Inżynieria promptów to sztuka formułowania, strukturyzowania i ilustrowania instrukcji w taki sposób, aby odpowiedź była bardziej przewidywalna. Bez niej mamy do czynienia z niejasnymi poleceniami, niestabilnymi formatami wyników oraz modelem zmuszonym do zgadywania, co miałeśmy na myśli.

W przypadku agenta do programowania prompt do przeglądu kodu może wyglądać w ten sposób:

SYSTEM: You are a code reviewer.
Given a diff, output ONLY valid JSON:
{"issues": [{"line": int,
"severity": "low|medium|high", "note": str}]}
No prose. No markdown fences.
If there are no issues, return {"issues": []}.

To polecenie ustala lokalną umowę. Przypisuje rolę, opisuje transformację (różnice wejściowe, lista problemów wyjściowych), określa strukturę wyniku aż po nazwy pól i dozwolone wartości stopnia poważności, a nawet definiuje przypadek pustego wyniku, dzięki czemu późniejsze parsowanie nie musi radzić sobie z prozą ani brakującymi kluczami.

Powszechnie twierdzi się, że inżynieria poleceń jest przestarzała. Tak nie jest; stanowi ona najgłębszą warstwę. Każdy proces przetwarzania kontekstu ostatecznie przekazuje modelowi instrukcję, a słaba instrukcja w doskonałym „opakowaniu” nadal daje słabe wyniki, tylko teraz wzbogacone imponującą infrastrukturą.

Inżynieria kontekstu: selekcja w ramach budżetu

Inżynieria kontekstu polega na wyborze, dla każdego zapytania, jakich dokumentów, historii, definicji narzędzi oraz informacji pomocniczych ma znaleźć się w oknie interfejsu, a równie starannie decyduje się, które z nich nie powinny tam trafić. Gdy jest to zaniedbywane, model odpowiada na podstawie przestarzałych informacji, jest rozpraszany przez nieistotne fragmenty tekstowe lub traci koncentrację, ponieważ okno jest przepełnione materiałem dodanym tylko na wszelki wypadek.

Budowniczy kontekstu dla agenta programistycznego może wyszukiwać odpowiednie opcje, przekształcać ich ranking oraz kompresować historię działań:

def build_context(query, full_history, kb):
    relevant = retrieve(query, kb, top_k=8)
    reranked = rerank(relevant, query)[:3]
    summary = summarize_if_long(
        full_history, max_tokens=800
    )
    return {
        "docs": reranked,
        "history": summary,
        "query": query,
    }

Traktuj to jak lejek. Proces pozyskiwania danych rozsiewa szeroką sieć ośmiu kandydatów, a ponowna klasyfikacja zachowuje trzy najbardziej istotne. Historia rozmów jest podsumowywana do około 800 tokenów tylko wtedy, gdy staje się zbyt długa. Funkcja zwraca mały, ustrukturyzowany pakiet danych, a nie surowy materiał. Kluczowymi umiejętnościami są selekcja, ranking i kompresja, a nie ilość danych.

Dlatego najczęstsze nieporozumienie, że inżynieria kontekstu oznacza dostarczanie modelowi więcej informacji, jest zazwyczaj błędne. Większy kontekst ma tendencję do zawierania większej ilości szumów: przestarzałych instrukcji, powtarzających się faktów i sprzecznych dowodów. Duża część pracy polega na decydowaniu, co pominąć.

Inżynieria kontekstu jest szersza niż RAG

Generowanie wzbogacone pozyskiwaniem danych to jedna z technik w ramach inżynierii kontekstu, obejmująca etap pozyskiwania informacji. Proces RAG może pobrać osiem fragmentów i przeklasfikować je do trzech, jak opisano powyżej. Inżynieria kontekstu obejmuje również kompresję historii, formatowanie definicji narzędzi, utrzymywanie aktywnego stanu kluczowych zadań, przekazywanie wyników weryfikacji z powrotem do modelu oraz decydowanie o tym, co pominąć.

Agenctwo programistyczne bez żadnego magazynu wektorowego nadal ma poważny problem z kontekstem do rozwiązania. Stan pliku Git, otwarte pliki, błędy kompilatora, wyniki testów, obecny plan oraz log poprzednich działań muszą dotrzeć do modelu w formie użytecznej.

Inżynieria wykorzystania zasobów: granica między intencją a efektem

Pasek jest niewiążącą się z modelem częścią systemu: narzędzia i dostęp do plików, pamięć trwała, zasady uprawnień, środowiska testowe, śledzenie działań oraz wszystko to, co dzieje się w przypadku błędu. Bez dobrego rozwiązania otrzymujemy agenta, który dobrze rozumie sytuację, ale nie może na niej działać, albo takiego, który działa, ale nie ma niezawodnego sposobu na odzyskanie stanu w przypadku błędu przy wywołaniu narzędzia.

Przykład obwoluty do wywoływania narzędzi ilustruje tę koncepcję:

def call_tool(tool_name, args, retries=2):
    for attempt in range(retries + 1):
        try:
            result = TOOLS[tool_name](**args)
            log_trace(tool_name, args, result, status="ok")
            return result
        except ToolError as e:
            log_trace(tool_name, args, str(e), status="failed")
            if attempt == retries:
                return {"error": str(e), "recoverable": False}
            args = repair_args(args, e)

Wrapper nie podejmuje żadnych prób rozwiązania zadania. Określa on granicę pomiędzy tym, o co prosi model, a tym, co robi rzeczywisty system. Każda próba jest rejestrowana wraz ze swoimi argumentami, wynikiem i stanem. Niepowodzenie powoduje ograniczoną próbę ponowną z poprawionymi argumentami, a po wyczerpaniu wszystkich prób zwraca ustrukturyzowany błąd oznaczony jako nieodwracalny, dzięki czemu wywołujący otrzymuje dane, na których może się oprzeć, zamiast wyjątku, który zatrzymuje działanie.

Kuszące jest utożsamianie tego narzędzia z dowolną implementacją agenta, którą zainstalowałeś. Framework dostarcza szkieletu; narzędzie to stanowi zbiór konkretnych decyzji, które podejmujesz na jego podstawie: co jest logowane, co robi nieudana próba wywołania, jaki stan przetrwa awarię, jakie polecenia są dozwolone oraz w jaki sposób wyniki wykonywania są przekazywane z powrotem do modelu.

Inżynieria pętli: umowa zakończenia

Inżynieria pętli określa pracę przy każdej iteracji, sposób, w jaki agent ocenia, czy robi postępy, oraz, co najważniejsze, warunki zatrzymania się. Jej charakterystycznym błędem jest nieskończona pętla: agent, który ciągle wywołuje narzędzia i wydaje tokeny, ponieważ nic mu nigdy nie podaje sygnału, że skończył lub utknął.

Minimalny kontroler wygląda tak:

def run_loop(task, harness, max_iters=15, stall_limit=3):
    state = init_state(task)
    stalls = 0
    for i in range(max_iters):
        action = plan_next_step(state)
        result = harness.call_tool(action.tool, action.args)
        state = update_state(state, result)
        if is_goal_met(state):
            return state, "success"
        if made_no_progress(state):
            stalls += 1
            if stalls >= stall_limit:
                return state, "stalled — escalate"
        else:
            stalls = 0
    return state, "max iterations reached"

Tutaj zastosowano kilka ograniczeń. max_iters określa maksymalną liczbę iteracji, is_goal_met umożliwia wyjście w przypadku osiągnięcia celu, a licznik zatrzymań śledzi kolejne iteracje bez postępów, resetując się po wznowieniu postępów. Po stall_limit krokach bez postępów pętla zwraca specjalny stan wskazujący na konieczność interwencji, zamiast kontynuować pracę w tle. Każda ścieżka wyjścia zwraca wyraźny powód, co ułatwia późniejszą klasyfikację wykonań.

Główną ideą jest umowa zakończenia: jasny cel, mierzalne sygnały postępów, ograniczona liczba prób, budżety czasowe i tokenowe, krok weryfikacyjny oraz określona polityka postępowania w przypadku zatrzymania postępów. Aby zapoznać się z implementacjami tych samych koncepcji w TypeScript, zobacz ograniczone pętle agentowe do wykorzystania w narzędziach LLM.

Inżynieria pętli i systemów zarządzających narzędziami są często mylone. System zarządzający określa, czego agent może dotknąć oraz jak radzić sobie z awariami na poziomie poszczególnych narzędzi. Pętla znajduje się na wyższym poziomie i decyduje o zachowaniu w poszczególnych krokach, w tym o momencie zakończenia całego procesu.

Cztery warstwy obok siebie

• Prompt (P): odpowiada za instrukcję. Typowa awaria: model błędnie interpretuje intencję lub zwraca dane w niewłaściwym formacie. Pierwsze miejsce do sprawdzenia: sam wynik.
• Context (A): odpowiada za stan gotowy do użycia przez model. Typowa awaria: model działa na podstawie przestarzałych, brakujących lub rozpraszających informacji. Pierwsze miejsce do sprawdzenia: zrzuty stanu kontekstu po każdym kroku.
• Harness (C): odpowiada za wykonywanie zadań i przywracanie normalnego funkcjonowania. Typowa awaria: wywołania narzędzi zawodzą, próby ponownego uruchomienia są bezskuteczne lub nie da się przywrócić normalnego stanu. Pierwsze miejsce do sprawdzenia: nieudane operacje w śledzeniu działań narzędzi.

Pętla (T): odpowiada za postęp i zatrzymanie działania. Typowe problemy: agent nigdy nie osiąga celu ani nie przestaje działać. Pierwsze, na co należy zwrócić uwagę: powtarzające się udane wywołania z niemal identycznymi argumentami.

Rozróżnienie błędu w narzędziu od błędu w pętli

Najskuteczniejszym sposobem oszczędzenia czasu jest zauważenie, że dwa różne błędy wyglądają identycznie z zewnątrz. Agent uwięziony w pętli z powodu nieprawidłowego kontrolera oraz agent uwięziony z powodu awarii narzędzia wykazują ten sam objaw: nadal działają, koszty rosną, a nikt nie wie dlaczego. Krótka lista kontrolna pomaga je odróżnić od innych problemów.

1. Sprawdź ślad wywołań narzędzi

Wywołania, które wszystkie kończą się sukcesem z rozsądnymi wynikami, podczas gdy agent ciągle używa tego samego narzędzia z niemal niezmienionymi argumentami, wskazują na pętlę.

2. Szukaj powtarzających się awarii narzędzi

Jeśli jakiś narzędzie ciągle zawodzi, a agent próbuje ponownie bez zmiany swojego podejścia, sprawdź harness.

3. Sprawdź, co model mógł zobaczyć

Jeśli model wydaje się zapominać jakąś informację w trakcie wykonywania zadania, przyjrzyj się budowie kontekstu: jego skracaniu, zastępowaniu, kompresji lub sposobowi przenoszenia stanu pomiędzy kolejnymi krokami.

4. Sprawdź wynik na końcu

Jeśli narzędzia działały poprawnie, kontekst był dokładny, a pętla zakończyła się bez problemów, ale odpowiedź nadal jest błędna, sprawdź prompt.

Zasada ogólna

Błędy w pętlach wynikają z decyzji o tym, co ma nastąpić dalej. Błędy w harness wynikają z tego, co dzieje się, gdy coś się psuje. Błędy w kontekście wynikają z tego, co model może zobaczyć. Błędy w prompt wynikają z tego, o co poprosiłeś.

Odpowiedz najpierw, które z czterech pytań jest aktualne, zanim cokolwiek edytujesz.

Przypadek studialny: recenzent pull requestów, który nie chce przestać

Wyobraźmy sobie zespół, który wdraża agenta do kodowania, który recenzuje pull requesty. Testy przebiegają pomyślnie. W środowisku produkcyjnym niektóre recenzje trwają ponad 40 minut na jeden pull request i powodują nieoczekiwane rachunki.

Pierwsza teoria zakłada, że instrukcja jest zbyt niejasna i agent zbyt dużo myśli. Instrukcja zostaje przepisana – nic się nie zmienia. Druga teoria dotyczy kontekstu: być może agent na każdym kroku ponownie czyta całe repozytorium. Dane z śledzenia mówią coś innego – pobieranie danych jest właściwie skonfigurowane i ładują się tylko te pliki, które są istotne.

Następnie ktoś uważnie analizuje ślad wywołań narzędzi. Agent wielokrotnie uruchamia narzędzie test-runner, a każde z tych wywołań kończy się bez błędów. Pakiet testów rzeczywiście zawodzi z powodu niestabilnego testu integracyjnego, który nie ma związku z prośbą o połączenie zmian. Agent nadal próbuje naprawić ten błąd poprzez zmiany w kodzie, które nie są z nim powiązane, oraz ponowne uruchamianie testów, ponieważ nic nie wskazuje mu, że wykonał już wystarczającą liczbę prób w ramach tego podcelu i powinien przestać oraz zgłosić problem wyżej.

To nie jest problem z promptem, nie jest problemem kontekstu ani problemem narzędzi do zarządzania; narzędzia zachowywały się dokładnie tak, jak zostały zaprojektowane. To czysto błąd pętli. Krok po kroku można przeanalizować sytuację, aby dojść do takiego wniosku.

Krok 1: potwierdzenie poprawnego działania narzędzi

Uspieszne wykonywania w śladzie wykluczają najprostsze błędy narzędzi do zarządzania, takie jak polecenie, które nigdy się nie uruchamia, lub adapter, który ciągle wywołuje błędy.

Krok 2: porównanie stanu pomiędzy iteracjami

Wynik testu znajduje się w kontekście agenta, a proces wyodrębniania informacji jest prawidłowo skonfigurowany, więc model nie pomija żadnych dowodów.

Krok 3: sprawdzenie zbieżności

W repozytorium zachodzą zmiany przy każdej iteracji, ale sygnał weryfikacyjny, który ma znaczenie, nigdy się nie poprawia. Brak jest detektora zatrzymania oraz ograniczenia liczby prób realizacji tego samego podcelu.

Krok 4: nauczenie kontrolera wykrywania stagnacji

Rozwiązaniem jest niewielki fragment logiki kontrolera, który porównuje „podpis postępu” pomiędzy poszczególnymi krokami:

if progress_signature == previous_signature:
    stagnant_steps += 1
else:
    stagnant_steps = 0

if stagnant_steps >= 3:
    escalate("no measurable progress")
    stop()

progress_signature może być czymkolwiek, co odzwierciedla istotny postęp, na przykład zbiorem nieudanych testów wraz z ich komunikatami o błędach. Jeśli nie ulega zmianie, zwiększa się licznik stagnacji; po trzech takich krokach kontroler eskaluje sytuację z uzasadnieniem i zatrzymuje proces. Każda rzeczywista zmiana sformatuje ten licznik na zero.

Można posunąć się dalej i ograniczyć liczbę prób dla każdej konkretnej sygnatury błędu, a nie tylko całkowitą liczbę iteracji. Ta różnica jest ważna: piętnaście produktywnych iteracji może być w pełni wystarczających, podczas gdy piętnaście prób naprawy jednego nie do usunięcia błędu testu to czysta strata czasu. Prawdziwym rozwiązaniem nie jest uczynienie modelu mniej upartym, lecz dostarczenie kontrolerowi jasnej definicji stanu stagnacji.

Przypadek studialny: ograniczenie, które znika z kontekstu

Załóżmy teraz agenta, który na początku migracji ustala, że nic nie może uszkodzić istniejących klientów. Po czterdziestu turach rozmowa zostaje skompresowana, a to ograniczenie ginie w streszczeniu. Wtedy agent proponuje zmianę schematu, która może spowodować problemy.

Wygląda to jak błędne rozumowanie, ale przyczyna leży gdzie indziej. Porównaj kontekst, który model faktycznie otrzymał w różnych turach. Jeśli ograniczenie było obecne w piątej turze, a brakowało go w czterdziestej, rozwiązanie leży w inżynierii kontekstu: przechowuj kluczowe niezmienniki oddzielnie od rozmowy, spraw, by streszczenia przenosiły wyraźne ograniczenia, i przestań traktować surową historię jako jedyny źródło prawdy.

„Model zapomniał” to nigdy nie jest kompletna diagnoza. Ważne pytanie brzmi, co faktycznie dano modelowi.

Warstwy, a nie zamienniki

Każda nowsza dziedzina opiera się na starszych, zamiast je zastępować. Agent produkcyjny otacza jasny prompt starannie wybranym kontekstem, uruchamia go w niezawodnym środowisku i kieruje całym procesem za pomocą celowego pętli. Sekwencja tych elementów odzwierciedla to, co zespoły musiały stopniowo dodawać: coraz jaśniejsze instrukcje, następnie lepiej dobrane informacje, potem środowisko wykonawcze dla modelu, a na końcu kontroler, który utrzymuje to środowisko w działaniu bez nadzoru. Jeśli zastanawiasz się, czy Twój własny silnik wykonawczy, czy framework powinien zarządzać tą zewnętrzną pętlą, porównanie silników wykonawczych i frameworków złożonych przedstawia wszystkie możliwe kompromisy.

Przekazane za pomocą PACT:

• Prompt: określenie instrukcji.
• Świadomość: stworzenie stanu, nad którym będzie rozumować model.
• Kontrola: zapewnienie, by wykonywanie zadań było widoczne, ograniczone i możliwe do przywrócenia.
• Trajektoria: przekształcenie powtarzania w postęp, który można zmierzyć, zakończony weryfikowalnym rezultatem.

Następnie trzeba dopasować rozwiązanie do problemu. Model, który błędnie interpretuje jasno określone zadanie, wymaga natychmiastowych działań korygujących. Model, który nie posiada niezbędnych faktów, wymaga uzupełnienia kontekstu. Rozsądne decyzje, które nie przeradzają się w niezawodne działania, wymagają opracowania odpowiednich narzędzi. Działania, które odnoszą sukces, podczas gdy cały proces nigdy się nie zakończa, wymagają modyfikacji pętli.

Częste pytania dotyczące warstw agentów

Czy inżynieria narzędzi to po prostu inna nazwa dla frameworku agentów?

Nie. Framework dostarcza elementów budulcowych. „Szykownica” składa się z decyzji, które podejmujesz podczas ich łączenia: zachowanie w przypadku awarii narzędzia, utrzymywanie stanu, logowanie, uprawnienia oraz sposób, w jaki wyniki wracają do modelu.

Czy asystent zadający jedno pytanie potrzebuje inżynierii pętli?

Właściwie nie. Inżynieria pętli staje się istotna, gdy agent podejmuje kilka działań w ramach jednego zadania i musi samodzielnie lub za pośrednictwem kodu kontrolera zdecydować, że praca jest zakończona. Bot do pytań i odpowiedzi działający w jednej rundzie ma niewiele lub wcale nie musi projektować pętli.

Którą warstwę powinieneś najpierw poznać?

Zacznij od inżynierii promptów i kontekstu, a następnie przejdź do „szykownicy” i pętli. Musisz odróżnić złą instrukcję od braku stanu, zanim będziesz mógł naprawiać błędy w czasie wykonywania oraz w kodzie kontrolera.

Czy jeden błąd może dotyczyć kilku warstw?

Tak, i to często są najtrudniejsze przypadki. Błąd w kontekście może ukryć sygnał postępu przed pętlą, przez co wygląda to jak błąd pętli. Należy prześledzić przyczynę awarii na wszystkich poziomach, zamiast naprawiać tylko pierwszy widoczny objaw.

Lista kontrolna przy kolejnym incydencie związku z agentem

• Cztery te terminy opisują elementy sterujące, a nie sprzeczne tendencje: instrukcję, stan gotowości modelu, wykonywanie i przywracanie, oraz powtarzający się postęp z regułą zatrzymania.
• Każde śledztwo należy rozpoczynać od zapisu działań, a nie od promptu: należy zapytać, co zobaczył model, co zrobił system, co zmieniło się pomiędzy iteracjami oraz dlaczego sterownik zdecydował się kontynuować.
• Sukcesywne wywołania narzędzi z niemal identycznymi argumentami wskazują na pętlę; powtarzające się awarie przy próbach bez żadnych modyfikacji wskazują na problemy z systemem sterowania.
• Proszę nadać pętlom wyraźną definicję stanu zatrzymania, najlepiej w zależności od specyfiki błędu, oraz ścieżkę eskalacji.
• Niech trwałe ograniczenia znajdują się poza kompresowalną historią, aby kompresja nie mogła ich usunąć.