# Jak odtworzyć awarię agenta programistycznego w różnych wersjach modelu? > Odtwórz awarię agenta programistycznego, zapisując cały przebieg jako wersjonowany fixture testowy, a następnie uruchamiając ten sam prompt, commit repozytorium, kontrakt narzędzi, środowisko i reguły zatrzymania na przypiętych identyfikatorach modeli. Porównuj zdarzenia strukturalne i końcowy stan repozytorium, nie tylko wypowiedź asystenta. # Jak odtworzyć awarię agenta programistycznego w różnych wersjach modelu? Użyteczna reprodukcja to wykonywalny eksperyment, a nie kopia transkryptu. Zacznij od stanu repozytorium, w którym wystąpił błąd, zamroź wszystkie dane widziane przez agenta i zdefiniuj maszynowo sprawdzalną asercję awarii. Następnie kilkukrotnie odtwórz fixture na przypiętych wersjach modeli. Przebieg agenta łączy zachowanie modelu, narzędzia, pliki, wyniki sieciowe, orkiestrację i czas. Zmiana któregokolwiek elementu oznacza, że inny wynik nie dowodzi winy ani naprawy modelu. ## Zdefiniuj awarię jako asercję Zapisz najmniejszy obserwowalny warunek odróżniający porażkę od sukcesu. Może to być nadal czerwony test, nieoczekiwana zmiana pliku, zakazane polecenie, brak migracji albo kompilująca się łatka zmieniająca zachowanie. Unikaj oceny "odpowiedź wygląda gorzej". Pakiet akceptacji może wymagać: * przejścia pierwotnego testu regresji; * przejścia wszystkich dotychczasowych testów; * braku zmian poza allowlistą; * zatrzymania agenta w limicie wywołań; * braku sekretów i driftu lockfile w końcowym diffie. ## Zapisz pełną kopertę przebiegu Prompt jest tylko jednym wejściem. Zachowaj obok fixture: | Warstwa | Co zamrozić | Dlaczego zmienia wynik | |---|---|---| | Repozytorium | Commit, submodules, niezacommitowana łata, nieśledzone fixtures | Agent rozumuje z dokładnego stanu źródła | | Instrukcje | Prompt systemowy, reguły repozytorium, zadanie użytkownika | Drobne różnice zmieniają plan | | Model | Dostawca, niezmienny ID, parametry | Aliasy i wartości domyślne mogą się zmieniać | | Narzędzia | Nazwy, schematy JSON, uprawnienia, timeouty | Dostępne działania kształtują plan | | Środowisko | Obraz kontenera, OS, architektura, blokady zależności | Polecenia i testy mogą działać inaczej | | Dane zewnętrzne | Mocki HTTP, zegary, dane losowe | Usługi live wprowadzają drift | | Orkiestrator | Limit pętli, retry, kompakcja kontekstu | Ten sam model może dostać inną historię | Usuń sekrety, ale zachowaj informację o dostępności i zakresie poświadczeń. ## Rejestruj zdarzenia strukturalne, nie tylko tekst Zapisuj każde żądanie i odpowiedź modelu, wywołanie i wynik narzędzia, ponowienie oraz decyzję o zatrzymaniu jako uporządkowane zdarzenie. Duże wyniki oznaczaj hashem, a oryginał przechowuj osobno. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Zdarzenia pokażą, czy nowy model wybrał inne narzędzie, inaczej odczytał błąd lub dostał inne dowody. ## Przypnij wersje i usuń wariancję live Używaj datowanych lub niezmiennych ID modeli. Nie porównuj historycznej awarii z aliasem `latest`, który może już wskazywać inną kompilację. Uruchamiaj w czystym kontenerze lub maszynie wirtualnej. Zastąp wyszukiwanie live i zmienne indeksy pakietów zapisanymi odpowiedziami lub snapshotem. Zamroź zegar dla logiki zależnej od daty. Jeśli sieć jest konieczna, rejestruj odpowiedzi i oznacz test jako częściowo kontrolowany. Ziarno losowe pomaga, lecz nie zamraża rozproszonego inference, czasu narzędzi ani zmian po stronie dostawcy. ## Odtwarzaj macierz, nie jedną parę Jeden przebieg na wersję nie odróżnia regresji od wariancji próbkowania. Utrzymaj stały fixture w małej macierzy: | Wersja modelu | Powtórzenia | Skuteczność | Mediana wywołań | Sygnatura awarii | |---|---:|---:|---:|---| | Przypięty baseline | 5 | 4/5 | 9 | Pominięty test przypadku brzegowego | | Przypięty kandydat | 5 | 1/5 | 13 | Zmieniony plik generowany | | Kandydat ze starym promptem | 5 | 1/5 | 12 | Ta sama sygnatura | Pięć powtórzeń daje pierwszy obraz. Zwiększ próbę dla błędów sporadycznych lub krytycznych. Utrzymuj te same parametry próbkowania, chyba że to one są przedmiotem testu. ## Porównaj decyzje i stan repozytorium Oddzielnie porównuj: * znormalizowane zdarzenia modelu i narzędzi; * polecenia oraz kody wyjścia; * końcowe drzewo plików i łatę; * testy akceptacyjne i zużycie zasobów. Nie wymagaj identycznego języka naturalnego. Różne ścieżki mogą prowadzić do równoważnych poprawek, a podobny tekst może ukrywać inne polecenie lub zmianę pliku. ## Po odtworzeniu zminimalizuj fixture Po powtórzeniu awarii usuwaj pojedynczo zbędne pliki, narzędzia, akapity promptu i wywołania zewnętrzne. Mały fixture działa szybciej i odsłania granicę przyczynową. Zachowaj pełne odtworzenie incydentu do audytu oraz minimalny test regresji do ciągłej ewaluacji. Dodaj przypadek do bramki aktualizacji modeli. ## Używaj przenośnego adaptera modeli Brama taka jak Atlas Cloud może udostępnić wiele modeli za jednym klientem zgodnym z OpenAI, ale zgodność nie oznacza identycznego zachowania. ID modeli, opcje dostawców i różnice formatów narzędzi trzymaj w adapterze. Wspólny harness powinien zarządzać fixtures, logami, retry i asercjami. Dzięki temu ta sama reprodukcja działa u wielu dostawców bez przepisywania ewaluacji. ## Podsumowanie Aby odtworzyć awarię agenta, zamroź pełną kopertę przebiegu, wielokrotnie uruchom przypięte modele i oceniaj wykonywalne wyniki. Jeśli dokładny incydent nie jest odtwarzalny, oznacz wejścia pozostające live i traktuj wynik jako porównanie, nie dowód regresji. ## FAQ ### Co trzeba zapisać, aby odtworzyć awarię agenta programistycznego? Zapisz commit i niezacommitowaną łatę repozytorium, prompt i instrukcje systemowe, identyfikator modelu, parametry, schematy i wyniki narzędzi, obraz środowiska, pliki blokad zależności, zasady poświadczeń i sieci oraz dokładną asercję sukcesu. ### Czy należy odtwarzać awarię z aliasem modelu latest? Nie. Użyj niezmiennych lub datowanych identyfikatorów modeli. Alias latest może zmienić wskazywaną wersję i uniemożliwić przypisanie wyniku. ### Dlaczego stałe ziarno losowe nie wystarcza? Ziarno nie zamraża infrastruktury dostawcy, czasu działania narzędzi, wyników wyszukiwania ani rewizji modelu. To tylko jedna z wielu kontroli, a nie gwarancja determinizmu. ### Jaki jest najlepszy sygnał sukcesu lub porażki agenta? Preferuj wykonywalne asercje: testy, lint, oczekiwane różnice w plikach, kontrolę zakazanych plików i kody wyjścia. Podobieństwo tekstu jest zwykle zbyt słabe dla zadań programistycznych. ### Ile powtórzeń wykonać dla każdej wersji modelu? Uruchom tyle powtórzeń, aby odróżnić deterministyczną regresję od wariancji. Pięć przebiegów to dobry punkt wyjścia, a awarie o dużym wpływie mogą wymagać dwudziestu lub więcej. ### Czy ten sam harness może porównywać modele różnych dostawców? Tak, jeśli znormalizujesz żądanie, kontrakt narzędzi, dziennik zdarzeń i asercje wyniku. Opcje specyficzne dla dostawców trzymaj w adapterach.