Gdy zmiana agenta kodującego przechodzi lokalnie, a pada w CI

Trzy miejsca, z których bierze się różnica

Lokalne środowisko agenta może być hostowanym sandboxem, runnerem podobnym do CI albo kontenerem na czyjejś maszynie, każde złożone przez własną konfigurację. Stąd trzy różne źródła sytuacji, w której zaliczony test zamienia się w porażkę.

• Środowisko się różni: wersje środowiska uruchomieniowego lub narzędzi, zależność zainstalowana bez lockfile'a, baza danych albo kolejka działająca tylko w jednym miejscu, reguły sieci albo poświadczenia dostępne w jednym środowisku, a w drugim nie.
• Komendy się różnią: agent uruchomił jeden plik testów, pominął lint albo sprawdzanie typów albo kierował się plikiem instrukcji, który podaje inną komendę niż workflow CI.
• Test jest niedeterministyczny: zależy od kolejności, czasu, równoległego wykonania albo współdzielonego stanu i na tym samym commicie raz przechodzi, a raz nie. Niestabilność mogła istnieć przed zmianą albo zostać przez nią wprowadzona.

Procedura, która zawęża przyczynę

1. 1

   Przeczytaj, co agent faktycznie uruchomił

   Otwórz log sesji, a nie podsumowanie agenta. Zapisz dokładne komendy, ich kody wyjścia i to, czy uruchomił się cały zestaw testów. Poradnik Anthropic o ewaluacji odróżnia to, co agent mówi o swojej pracy, od faktycznego wyniku w środowisku, i to rozróżnienie obowiązuje także tutaj.

2. 2

   Powtórz nieudany job z logowaniem debug

   W GitHub Actions powtórz tylko nieudane joby z diagnostycznym logowaniem runnera i logowaniem debug kroków. Ponowne uruchomienie używa tego samego commita i refa co oryginał, więc inny wynik wskazuje na środowisko albo niedeterminizm, a nie na nowy kod.

3. 3

   Porównaj commit bazowy z commitem agenta

   Zaliczenie przy powtórce nie oczyszcza zmiany, bo wyścig wprowadzony przez agenta też pada tylko czasami. Uruchamiaj padający test wielokrotnie na commicie bazowym i na commicie agenta, z tymi samymi zależnościami i usługami, i porównaj częstość porażek oraz sygnatury błędów. Porażki tylko ze zmianą wskazują na zmianę. Porażki w obu też jej nie oczyszczają, bo zmiana może sprawić, że istniejący niestabilny test pada częściej albo inaczej. Sklasyfikuj test, daj mu właściciela i zgłoszenie i nie pozwól agentowi doprowadzić go do zaliczenia przez poluzowanie asercji.

4. 4

   Odtwórz komendę CI w czystym kontenerze

   Użyj obrazu i wersji z CI, uruchom dokładną komendę CI i porównaj wersje środowiska uruchomieniowego, zainstalowane pakiety, zmienne środowiskowe i działające usługi ze środowiskiem agenta.

5. 5

   Sprawdź log konfiguracji agenta

   Szukaj nieudanych kroków konfiguracji i zablokowanych żądań. Niektórzy agenci hostowani pracują dalej po nieudanym kroku konfiguracji, co opisujemy niżej.

gh run rerun RUN_ID --failed --debug

Objawy i gdzie szukać najpierw

• Brak modułu albo inna wersja tylko w CI: agent instalował bez lockfile'a albo użył innej wersji środowiska uruchomieniowego.
• Testy integracyjne padają tylko w jednym miejscu: baza danych, kolejka albo dane startowe istnieją w jednym środowisku, a w drugim nie.
• Błędy lintera lub typów tylko w CI: agent uruchomił testy, ale nie pełne sprawdzenie, albo jego instrukcje podają inną komendę.
• Błędy sieci lub uwierzytelniania: host dozwolony w jednym środowisku jest blokowany w drugim albo poświadczenie nie dociera w formie, jakiej oczekuje program.
• Wyniki zmieniają się między powtórzeniami tego samego commita: coś jest niedeterministyczne, w teście, w zmianie albo w obu. Zanim to sklasyfikujesz, porównaj powtarzane uruchomienia na bazie i na zmianie.

Pułapki typowe dla agentów hostowanych

Copilot cloud agent od GitHuba przed startem uruchamia job copilot-setup-steps. Jeśli któryś krok się nie powiedzie, agent pomija pozostałe i pracuje w środowisku takim, jakie jest, więc brakująca zależność wychodzi później jako dziwny wynik testu. Żądania zablokowane przez jego firewall pojawiają się jako ostrzeżenie w pull requeście, z adresem i komendą. A w pull requeście Copilota workflowy nie startują, dopóki ktoś z prawem zapisu nie wybierze Approve and run workflows, więc brak wyniku CI nie oznacza zaliczenia.

W Codex Cloud od OpenAI sekrety sieciowe docierają do programów jako placeholdery, które proxy podmienia dla dozwolonych celów HTTPS. Narzędzie, które czyta surową wartość, dostaje placeholder i pada w sposób, którego w CI nie ma. Istniejące zadania Codex zachowują też własne zapisane pliki i zainstalowane narzędzia, więc długo trwające zadanie może nie odpowiadać nowo opublikowanemu środowisku.

Popraw harness, a nie tylko zmianę

Przypadek hipotetyczny: CI uruchamia testy równolegle w shardach, a agent w jednym procesie. Test, który polega na stanie pozostawionym przez inny test, przechodzi u agenta i pada w shardzie trzecim. Naprawa tego jednego pull requesta pomaga raz. Trwałe poprawki są w harnessie:

• Jedna komenda sprawdzająca, którą wskazuje plik instrukcji i uruchamia CI, z tą samą kolejnością testów i równoległością
• Wersje środowiska uruchomieniowego i narzędzi przypięte w jednym miejscu, z którego czytają oba środowiska
• Usługi uruchamiane z tej samej definicji kontenera dla agenta i dla CI
• Reguła, że opis pull requesta wymienia uruchomione komendy i ich wyniki
• Testy uznane za niestabilne po porównaniu bazy i zmiany oznaczone, z właścicielem i śledzone, a do czasu naprawy poza szybkim zestawem agenta

Jeśli CI przy jakimś typie zadań wciąż pada z powodów środowiskowych, przenieś ten typ z powrotem do pracy interaktywnej, dopóki harness nie zostanie poprawiony. Taka diagnoza i naprawa to część naszej pracy nad harness engineering z zespołami platformowymi.

Przygotowanie repozytorium na agentów kodującychHarness engineering