Schemat: pętle sprzężenia zwrotnego agentów, narzędzia i podejścia
Mapa odniesienia dla pętli sprzężenia zwrotnego agentów: siedmiostopniowy cykl życia tarcia, pętle nazwane w tej dziedzinie według poziomów oraz stosowane schematy klasyfikacji.
TeamRetro interesuje się każdym cyklem ciągłego doskonalenia realizowanym przez zespoły; praca wspomagana sztuczną inteligencją to nowy obszar, nad którym zastanawiamy się w kontekście retrospektyw. Niniejsza strona stanowi uzupełnienie niniejszego przewodnika: całość została tu przedstawiona w sposób systematyczny. Jeśli wolałby Pan/Pani zacząć od opisu, proszę przejść do wstępu do przewodnika i następnie powrócić do tej strony.
Czym jest ta strona
Trzy kwestie, w kolejności: cykl życia, jaki przechodzi pojedynczy problem od momentu jego wystąpienia do momentu rozwiązania; nazwane pętle, które branża stworzyła w celu realizacji tego cyklu życia, posortowane według poziomu, na którym każda z nich funkcjonuje; oraz schematy klasyfikacji stosowane do nazywania tego, co poszło nie tak. Proszę zapoznać się z tym tekstem od góry do dołu, aby zorientować się, na jakim etapie znajduje się Państwa zespół: które etapy są już obsługiwane przez Państwa narzędzia, którą pętlę stosują Państwo już pod inną nazwą oraz jakiego słownictwa używaliby Państwo do opisania ustaleń. Wszystkie przedstawione tutaj elementy są niezależne: żadna z nich nie wymaga przyjęcia naszych praktyk, naszych oznaczeń ani naszego produktu.
Cykl życia: siedem etapów od pojawienia się problemu do jego rozwiązania
Gdy pracownik wykonujący rzeczywiste zadania napotyka przeszkodę (brakujący dokument, niejasna instrukcja, zawodne narzędzie), sygnał ten ma charakter ulotny: pracownik radzi sobie z nią, sesja się kończy, a podczas kolejnej sesji napotyka tę samą przeszkodę. Wzorce przeszkód Rahula Garga opisują koszt pierwszego rzędu (pętlę frustracji: generowanie → weryfikacja → brak dopasowania → ponowne generowanie); poniższy cykl życia przedstawia problem drugiego rzędu: co musi się wydarzyć, aby przeszkoda została usunięta na odpowiednim poziomie. Lukę tę można zmierzyć: około 90% zespołów rejestruje ślady działania agentów, ale tylko około 37–52% systematycznie je ocenia (LangChain, czerwiec 2026) — większość zespołów potrafi obserwować tarcia; znacznie mniej z nich przekształca je w rozwiązania.
| Scena | Pytanie, na które udziela odpowiedzi | Opcje | Termin dotyczący praktykujących |
|---|---|---|---|
| 0 · Hosting | Gdzie działa ten agent? | lokalny interfejs CLI · aplikacja internetowa · środowisko IDE · CI/tryb bezinterfejsowy · zadania zaplanowane | — |
| 1 · Wykrywanie | W jaki sposób dostrzega się tarcie? | autokontrola · weryfikacja przez podmiot drugorzędny · korekta przez człowieka · telemetria | przegląd śladów, analiza błędów |
| 2 · Oprzyrządowanie | Skąd agent wie, że ma to śledzić? | umiejętność · haczyk · konwencja · polecenie | — |
| 3 · Nagrywanie | W jaki sposób i gdzie jest to rejestrowane? | pamięć · magazyn MCP · logi/ślady · zgłoszenia · zatagowane zatwierdzenia | kodowanie otwarte, pamięć epizodyczna |
| 4 · Zbiór | W jaki sposób organizują Państwo spotkania wykraczające poza jedną sesję? | analiza śladów a agregacja artefaktów · skanowanie a zdarzenie · deduplikacja | — |
| 5 · Synteza i ukierunkowanie | Dane surowe → wzorce → jaki poziom korekty? | grupa + wynik, a następnie sortowanie według wysokości | kodowanie osiowe, taksonomia awarii |
| 6 · Zamknąć pętlę | Czy wprowadzone poprawki ograniczyły przyszłe tarcia? | ocenić tendencję | Koło zamachowe sprzężenia zwrotnego, inżynieria efektu kumulacji |
Etap 0: Hosting
Wszystko, co dzieje się dalej, zależy od tego, gdzie działa agent. Lokalny agent CLI zapisuje transkrypcję na dysku i może tworzyć pliki pamięciowe; agent działający w środowisku CI lub bezinterfejsowy może mieć charakter efemeryczny, a jedynym śladem jego działania są dane zalogowane przed zakończeniem działania kontenera; agent internetowy lub działający w środowisku IDE przechowuje historię po stronie serwera, którą można przeszukiwać, ale nie da się jej filtrować za pomocą grep; agent zaplanowany działa bez nadzoru człowieka. Środowisko hostingu określa możliwości na każdym kolejnym etapie: co można obserwować, gdzie stan może być utrzymywany oraz kto (lub co) może go przeglądać. Kompromis polega na wyborze między bogatszą lokalną obserwowalnością a odtwarzalnością i scentralizowanym przechowywaniem wyników uruchomień w środowisku hostowanym.
Etap 1: Wykrywanie
Cztery kanały, rzadko wyłączne. Samokontrola (agent rozpoznaje własne ponowne próby i cofanie się) jest najtańsza, ale najbardziej stronnicza: agent nie wie, czego nie wie. Weryfikacja przez drugiego agenta, polegająca na tym, że nowy agent zapoznaje się z zapisem rozmowy po jej zakończeniu, jest bardziej obiektywna, ale wymaga przeprowadzenia drugiego przejścia. Korekta ludzka stanowi sygnał najwyższej jakości i nadal dominuje: w trwającym osiem tygodni badaniu produkcyjnym stwierdzono, że około 70% cichych błędów zostało po raz pierwszy wykrytych przez człowieka, który zauważył, że coś jest nie tak (arXiv 2606.14589). Telemetria (wskaźniki błędów narzędzi, odmowy zezwoleń, liczba pętli) jest automatyczna, ale powierzchowna — wie co, a nie dlaczego. Najskuteczniejsze rozwiązania opierają się na triangulacji: telemetria wskazuje, gdzie należy szukać, a weryfikacja wyjaśnia przyczynę.
Etap 2: Oprzyrządowanie
Agent nie zarejestruje tarcia, chyba że coś je wywoła. Dostępne opcje, w zależności od tego, w jakim stopniu opierają się na pamięci modelu: umiejętność (jawna, przenośna procedura wywoływana w punkcie zatrzymania: przejrzysta, ale musi faktycznie zostać uruchomiona), haczyk (uruchamia się automatycznie przy rozpoczęciu lub zakończeniu sesji: niezawodny, ale mało precyzyjny), konwencja (instrukcja zawarta w pliku kontekstowym: bez infrastruktury, oparta na zaufaniu) lub polecenie (uruchamiane przez człowieka: celowe, ale uzależnione od ludzkiej interwencji). Jest to etap najczęściej pomijany i właśnie dlatego tak wiele problemów pozostaje niezarejestrowanych: nikt nie polecił agentowi, aby to sprawdził.
Etap 3: Rejestracja
Dwa pytania: co zawiera dobry zapis i gdzie się znajduje. Przydatny zapis zawiera odniesienia do dowodów (co się wydarzyło, ile to kosztowało), opatrzony jest jedną etykietą z ustalonego słownika, dzięki czemu zapisy można później porównać, a na końcu zawiera propozycję kolejnego kroku. Jeśli chodzi o miejsce przechowywania, każda opcja wiąże się z konkretnym kompromisem: pliki pamięci (trwałe i łatwe w obsłudze, ale prywatne i o luźnej strukturze), magazyn MCP (współdzielony i umożliwiający wyszukiwanie, ale wymagający serwera), logi/ślady (automatyczne i kompletne, ale sygnał jest zagubiony w szumie), zgłoszenia (umożliwiające podjęcie działań i widoczne dla zespołu, ale obciążające system w przeliczeniu na pojedynczy element) lub oznaczone commit’y i PR’y, np. etykietawork-material-friction powiązująca opór z konkretną zmianą, choć ma to zastosowanie wyłącznie w przypadku, gdy praca trafia do systemu kontroli wersji. Żadne z tych rozwiązań nie jest specyficzne dla kodu: dziennik konta zespołu ds. mediów lub opatrzona adnotacjami historia kolejki wsparcia technicznego również stanowią podłoża rejestrujące. Należy pamiętać o jednym zastrzeżeniu, które dotyczy wszystkich podłoży, na których później opierają się agenci: pamięć zapisana przez agenta stanowi nazwany punkt podatny na ataki i odchylenia (OWASP Agentic Top 10, ASI06), co stanowi argument przemawiający za zapisami popartymi dowodami i poddanymi weryfikacji.
Etap 4: Zbiór
Pojedyncze zdarzenie związane z tarciem to zwykły szum; to samo tarcie występujące w ośmiu sesjach stanowi problem procesowy. Strategicznym wyborem jest eksploracja śladów (ponowne przeglądanie surowych transkrypcji: kompletne, ale kosztowne i wiążące się z dużymi wymaganiami dotyczącymi prywatności) w przeciwieństwie do agregacji artefaktów (przeglądanie celowo sporządzonych zapisów: tanie, ale skuteczne tylko w zakresie dyscypliny etapu 3); rzeczywiste procesy łączą oba podejścia. Następnie należy uwzględnić częstotliwość (zaplanowane przeszukiwanie a zbieranie danych na koniec sesji) oraz mało efektowną pracę związaną z deduplikacją: to samo utrudnienie sformułowane na pięć różnych sposobów przez pięć osób musi zostać sprowadzone do jednego wzorca z rzetelnym zliczeniem. Właśnie na etapie zbierania danych ujawnia się wartość, ponieważ to agregacja powoduje zmianę priorytetów: pięciominutowa niedogodność, której nikt nie naprawiłby indywidualnie, w ujęciu zbiorczym stanowi jeden z największych kosztów dla zespołu.
Etap 5: Synteza i ukierunkowanie
Dwa etapy. Grupowanie i ocena: należy pogrupować wyniki w wzorce, uszeregowane według częstotliwości pomnożonej przez koszt; właśnie do tego służą przedstawione poniżej schematy klasyfikacji. Określ odpowiedni poziom: przypisz każdy wzorzec do właściwego poziomu rozwiązania, od tymczasowego do strukturalnego (pamięć → umiejętność/podpowiedź → środowisko i konfiguracja → dokumentacja → sam materiał roboczy → proces → narzędzie lub dostawca wyższego szczebla). Jeśli cel zostanie niedoszacowany (prywatna notatka w pamięci dotycząca dokumentu zespołowego, którego w rzeczywistości brakuje), utrudnienia powracają dla wszystkich pozostałych osób; jeśli cel zostanie przeszacowany (nowa umiejętność wymagana tylko jednorazowo), powoduje to nadmierne rozbudowanie artefaktu, aż przestanie on być czytany. Społeczność niezależnie doszła do tego samego wniosku: ogranicz pamięć efemeryczną, promuj trwałe uczenie się w ramach kontroli wersji — dokumentacja Windsurf/Devin zaleca przenoszenie powtarzających się wniosków do reguł lub pliku AGENTS.md (stałego pliku instrukcji odczytywanego przez agentów) zamiast polegania na automatycznej pamięci, wytyczne OpenAI Codex wskazują, że powtórzenie tego samego błędu wymaga aktualizacji pliku AGENTS.md, a pamięć Copilota wygasa po 28 dniach zgodnie z założeniami: pamięć, która nie została przekształcona, powinna ulec usunięciu. Łatwo przeoczyć jedną syntetyczną konkluzję: nie każde opóźnienie jest stratą. Część z nich stanowi powierzchnię sterową – „opór jest tym, co jest niezbędne… do sterowania” (podsumowanie wystąpienia Ronachera podczas konferencji AIE Europe), dlatego proces selekcji obejmuje decyzję o zachowaniu lub usunięciu, a nie tylko o naprawie.
Etap 6: Zamknięcie cyklu
Rzetelny test całego cyklu życia: czy tego rodzaju tarcie wykazuje tendencję spadkową w kolejnych sesjach? Poprawka, która została zgłoszona, ale nigdy nie została wdrożona, lub została wdrożona, ale niczego nie zmieniła, to tylko pozory. Jest to zjawisko opisane przez Garga jako Feedback Flywheel oraz założenie inżynierii kumulacyjnej: każda poprawka ułatwia wykonanie kolejnego etapu pracy, o ile pętla faktycznie się zamyka.
Pętle z nazwami, według poziomu operacyjnego
W tej dziedzinie przyjęto co najmniej pół tuzina nazw określających ten cykl życia. Wszystkie są trafne; żadna z informacji zawartych na tej stronie nie zastępuje żadnej z nich. Jedynym kryterium sortowania zastosowanym w tej tabeli jest poziom, na którym działa każda pętla — a po posortowaniu należy zwrócić uwagę na następującą kwestię:
| Pętla | Odbywa się w | Zamknięcie pętli poprzez |
|---|---|---|
| Inżynieria pętli / Inżynieria złożona | jeden specjalista | osobiste zasady, wskazówki, scenariusze postępowania |
| agent-retro | jedna sesja | zmiany dotyczące umiejętności i konfiguracji wprowadzane na bieżąco podczas sesji na podstawie transkrypcji |
| Czujniki stosowane w inżynierii wiązek przewodów (Thoughtworks) | struktura testowa jednego kodu źródłowego (szkielet otaczający model) | włączenie natywnych narzędzi zapewniających informacje zwrotne (testy, narzędzia do sprawdzania poprawności kodu, CI) do pętli agenta |
| Marzenia (Anthropic, OpenAI) | pamięć jednej platformy | eksploracja historii sesji w czasie bezczynności w celu uzyskania różnic w pamięci bramkowanej, w całej flocie |
| Silnik LangSmith / Tematy Braintrust | jeden stos rozwiązań w zakresie obserwowalności | grupowanie awarii produkcyjnych w kategorie problemów, sporządzanie wniosków o wprowadzenie zmian (PR) oraz ocen |
| Sygnały fabryczne | platforma dla jednego agenta | wykrywanie wzorców utrudniających przebieg sesji oraz automatyczne zgłaszanie zgłoszeń |
| gh-aw – podsumowanie sesji (GitHub) | sesje na jednej platformie | zautomatyzowane raporty z analizy sesji w ramach przebiegów przepływów pracy agentów (przykład obejmujący 50 sesji) |
| Koło zamachowe sprzężenia zwrotnego (Garg) | materiały jednego zespołu | wykorzystanie zdobytej wiedzy do opracowania dokumentów przygotowawczych, poleceń, scenariuszy postępowania oraz wytycznych |
Proszę ponownie przeczytać środkową kolumnę: jeden specjalista, jedna sesja, jedna platforma, jeden stos technologiczny. Prawie każda pętla w tej dziedzinie działa na poziomie indywidualnym lub floty: osoba i jej agent lub dostawca i cała jego baza instalacyjna. Jedynie model koła zamachowego Garga obejmuje zespół, a jego lista rytmów wymienia miejsce (punkt porządku obrad w istniejącej retrospektywie sprintu) bez wprowadzania go w życie. Tak właśnie interpretujemy ten fragment i właśnie w tym miejscu ujawnia się specyficzne podejście niniejszego przewodnika: poziom zespołu stanowi warstwę otwartą — wiele osób, wiele agentów, więcej niż jedno narzędzie, a osoby odpowiedzialne za poprawki uczestniczą w tej samej rozmowie. Jeśli stosują Państwo którąkolwiek z powyższych pętli, proszę ją kontynuować; warstwa zespołu wykorzystuje jej wyniki, nie konkuruje z nią.
Systemy klasyfikacji
Aby zgrupować czynniki powodujące tarcia, potrzebne są kategorie, a schematy poszczególnych dziedzin służą do klasyfikacji różnych zjawisk; nie są one raczej konkurentami, co narzędziami ukierunkowanymi na różne zagadnienia:
| Schemat | Co obejmuje ta klasyfikacja | Kształt | Wiarygodność / pochodzenie |
|---|---|---|---|
| MAST | w jaki sposób systemy wieloagentowe ulegają awarii | 14 trybów / 3 kategorie | 150 śladów zweryfikowanych przez ekspertów, zweryfikowanych na próbie ponad 1600; współczynnik κ między anotatorami = 0,88 |
| Szkoła analizy błędów (Husain/Shankar) | niezależnie od tego, co wskazują Państwa własne ślady | o charakterze otwartym; kategorie wyłaniają się z Państwa danych | metodologia, a nie sztywny zestaw; analiza Państwa zapisów stanowi „najważniejsze zadanie w ramach ocen” |
| Czterowarstwowa (Greyling) | która warstwa stosu uległa awarii | 4 warstwy | podsumowanie zgłoszeń dotyczących awarii w terenie; około 9,9% awarii przypisano wnioskowaniu opartemu na modelu |
| TraceProbe | działania związane z obsługą błędów w śladach | 9 działań | zautomatyzowana analiza śladowa |
| Sygnały fabryczne | jaki objaw tarcia występuje podczas sesji | 7 rodzajów sygnałów | sesje agentów kodujących w środowisku produkcyjnym |
| Nasze słownictwo dotyczące przyczyn źródłowych | dlaczego doszło do problemów we współpracy | 10 etykiet / 5 grup; grupa określa stałą wysokość | sesje robocze, zarówno dla programistów, jak i dla osób niebędących programistami; nie zmierzono jeszcze zgodności między oceniającymi: eksperyment jest w toku, a słownik jest wersjonowany i podlega aktualizacji |
agent-errorDwie uwagi dotyczące interpretacji. Po pierwsze, osie rzeczywiście się od siebie różnią: schematy objawów (sygnały Factory) wskazują, że sesja przebiegła nieprawidłowo; schematy warstw (Four-Layer) wskazują, w którym miejscu stosu; słownik przyczyn wyjaśnia dlaczego, co pozwala etykiecie częściowo wytyczyć drogę do własnego rozwiązania (ustaleniework-material-friction wskazuje na sam materiał — dług techniczny w kodzie lub zagmatwane konto, tablicę lub szablon poza nim; etykieta briefingowa wskazuje na proces). Po drugie, napięcie między podejściem uniwersalnym a emergentnym jest rzeczywiste: stałe taksonomie zapewniają porównywalność i mierzalną wiarygodność etykietowania (punktem odniesienia jest współczynnik κ = 0,88 w modelu MAST), natomiast kategorie emergentne dostosowują się do rzeczywistego rozkładu niepowodzeń. Praktycznym kompromisem jest zachowanie niewielkiego, stałego słownika do celów agregacji, uzupełnionego o otwarte, zakodowane notatki dowodowe pod każdą etykietą. Należy również pamiętać o ostrzeżeniu, na które cała dziedzina zasłużyła: etykiety typu „-style” powinny stanowić rozwiązanie rezerwowe, a nie domyślne. Szkoła inżynierii harnessu wyraźnie odrzuca ten odruch, w którym inżynier obwinia model i odkładają go do kategorii „poczekaj na następną wersję”; zamiast tego należy naprawić harness (Osmani, Agent Harness Engineering). Analiza czterowarstwowa przypisuje jedynie około 9,9% niepowodzeń rozumowaniu modelowemu.
Zlokalizuj się
Krótka analiza diagnostyczna. Proszę przejść przez poszczególne etapy i zaznaczyć, co już Państwo posiadają:
- Dysponują Państwo śladami lub logami sesji (narzędzia do monitorowania, pliki JSONL na dysku, historia po stronie serwera) → Kwestie wykrywania i rejestrowania są uwzględnione. Dane LangChain wskazują, że większość zespołów na tym etapie kończy swoje działania.
- Coś przypomina agentowi o konieczności rejestrowania zdarzeń (umiejętność, punkt zatrzymania, konwencja dotycząca plików kontekstowych) → Kwestia monitorowania jest uwzględniona; jeśli nic takiego nie ma miejsca, jest to zazwyczaj najtańsze pierwsze rozwiązanie.
- Aktualizują Państwo pliki AGENTS.md / CLAUDE.md, gdy coś się powtarza → stosują Państwo metodę syntezy na poziomie indywidualnym, co stanowi powtórzenie tego samego błędu z Kodeksu.
- Państwa platforma zajmuje się selekcjonowaniem wspomnień za Państwa (konsolidacja w stylu „Dreaming”, pamięć Copilot) → gromadzenie i synteza na poziomie floty w ramach tej platformy.
- Państwa stos obserwowalności grupuje awarie i wstępne rozwiązania (Engine, Topics, Signals) → synteza na poziomie stosu, dotycząca ruchu obserwowanego przez ten stos.
- Ktoś okresowo analizuje dane z różnych sesji, od różnych osób i z różnych narzędzi, a osoby odpowiedzialne za rozwiązania podejmują decyzje wspólnie → gromadzenie i synteza na poziomie zespołu. Jest to wiersz, który większość zespołów pozostawia pusty.
Z naszych obserwacji wynika, że najczęstszą luką jest właśnie ten ostatni wiersz: całościowy obraz obejmujący narzędzia i osoby oraz wynikające z niego decyzje: zachować czy usunąć, na jakim poziomie, czyja to priorytetowa sprawa. Proszę zwrócić uwagę na związane z tym pytanie dotyczące zakresu przeglądu: które zadania należy umieścić w jednej kategorii w ramach jednej dyskusji? Repozytorium, produkt, konto reklamowe, skrzynka wsparcia technicznego, relacje z klientami? Zakres należy określić na podstawie tego, gdzie zostaną wdrożone poprawki, a sprawy niezwiązane z kodem powinny być kierowane tak samo naturalnie, jak te dotyczące kodu.
W dalszej części niniejszego przewodnika omówimy poszczególne elementy po kolei: sekcja opener przedstawia historię w formie narracyjnej; kolejne rozdziały dotyczą uchwycenia tarcia w danej chwili, gromadzenia wyników z różnych sesji, decyzji o zmianie perspektywy oraz tego, jak miejsce spotkań na poziomie zespołu wygląda w praktyce. Zacznij od miejsca, w którym znajduje się pusty wiersz.
Następny rozdział: Jak wygląda dobry zapis zdarzeń związanych z tarciem — rejestrowanie w czasie rzeczywistym, oznaczenia przyczyn źródłowych oraz zasady dotyczące zdarzeń, których nie należy rejestrować.