Procedural Graphs. Jak agent może poprawiać własne procedury

Wyobraźmy sobie agenta, który naprawia błąd w aplikacji. Odtwarza problem, zmienia kod i uruchamia testy. Jeden test nadal nie przechodzi, więc agent wprowadza kolejną poprawkę. Teraz powinien sprawdzić właśnie tę wersję kodu. Jeśli zakończy pracę na podstawie wcześniejszego wyniku, pomyli wykonanie czynności ze spełnieniem warunku: testy uruchomiono, ale poprawka pozostaje niesprawdzona.

Taką zależność można zapisać w procedurze. Trzeba jeszcze dostarczyć ją agentowi we właściwym momencie i rozpoznać, kiedy sama wymaga poprawy.

Rada dopasowana do sytuacji

Wcześniejsze AutoGuide wydobywa wskazówki z porównania udanych i nieudanych prób wykonania zadań. Szuka miejsca, w którym przebiegi zaczynają się różnić, opisuje sytuację i zapisuje radę dotyczącą działania. Podczas następnego zadania model rozpoznaje bieżący kontekst i wybiera pasujące wskazówki. Wiedza z doświadczenia przyjmuje więc postać warunkowej instrukcji, którą można dodać do promptu.

To użyteczny punkt wyjścia dla naszego przykładu. Ogólne „pamiętaj o testach” można zastąpić radą: „po zmianie kodu ponownie uruchom sprawdzenia, których dotyczy poprawka”. Taka instrukcja od razu określa moment, w którym jest potrzebna. Nadal trzeba jednak połączyć ją z decyzją, co zrobić po otrzymaniu wyniku.

Kroki i warunki przejścia

Procedural Graph (PG) zapisuje kroki jako węzły grafu, a przejścia opisuje warunkiem, wskazówką i pułapkami. System dopasowuje ostatnią czynność do węzła. Model pomocniczy czyta przejścia sięgające dwa kroki naprzód oraz ostatnie działania i układa wskazówkę do następnego kroku. Agent dostaje ją w prompcie, zachowując swobodę wyboru.

Własny przykład takiej procedury dla poprawki w kodzie mógłby zawierać trzy przejścia:

• Edycja → testy: sprawdź bieżącą wersję zmienionych plików.
• Testy → diagnoza: jeśli sprawdzenie się nie powiedzie, przeczytaj przyczynę błędu przed kolejną edycją.
• Testy → zakończenie: jeśli wymagane sprawdzenia przeszły, opisz poprawkę i wynik weryfikacji.

Pierwsze przejście warto uzupełnić o pułapkę: wynik dotyczący wcześniejszej wersji plików nie potwierdza nowej poprawki. Węzeł „testy” sam tego nie mówi. Dopiero opis warunku wiąże działanie z konkretnym stanem repozytorium.

W takim projekcie warto zapisywać razem wynik sprawdzenia i identyfikator sprawdzonej wersji. Jeżeli przejście ma być obowiązkowe, jego warunek powinien sprawdzać również kod obsługujący narzędzia. Samo zdanie w prompcie nie jest blokadą wykonania operacji.

Procedura podlega sprawdzeniu

W PG po serii zadań model porównuje przebiegi i proponuje dodanie lub usunięcie kroków, zmianę połączeń i wskazówek. Poprawnego strukturalnie kandydata przyjmuje się, jeśli wynik na osobnych zadaniach walidacyjnych nie spada. Odrzucone propozycje są zapamiętywane. Podczas pojedynczego zadania graf pozostaje stały; wagi modeli się nie zmieniają. Algorytm aktualizacji

W eksperymencie autorów na 56 zadaniach dialogowych MultiChallenge, z Gemini 3.5 Flash i oceną Gemini 3.1 Pro, ręczny graf obniżył skuteczność z 87,50% do 58,93%. Iteracyjne poprawianie podniosło ją do 92,86%. To wynik konkretnego grafu i małej próby. Warunki eksperymentu

Przenosząc tę ideę do naszego agenta, do zestawu sprawdzającego dodałbym różne przyczyny niepowodzenia testów. Błąd w poprawianej funkcji wymaga innej reakcji niż brak zależności albo niedostępna usługa. Procedura nakazująca po każdym nieudanym uruchomieniu zmieniać kod mogłaby zwiększyć liczbę niepotrzebnych edycji. Oceniałbym więc zarówno naprawione błędy, jak i poprawne zatrzymanie pracy z wyjaśnieniem przeszkody.

Za podpowiedzi płaci się dodatkowymi obliczeniami. W osobnym porównaniu na ALFWorld z Gemini 3.5 Flash lokalne wskazówki zwiększyły zużycie tokenów o 55,4% względem wariantu bez grafu. Skuteczność wzrosła z 72,58% do 81,53%. Pomiar kosztu

Dla agenta programującego porównałbym zatem koszt całej poprawki: wywołania modeli, testy, ponowne próby i czas potrzebny człowiekowi na sprawdzenie rezultatu. Dodatkowa wskazówka miałaby sens, gdyby ograniczała konkretny błąd, na przykład kończenie pracy po nieaktualnym teście. Dopiero taki pomiar uzasadniałby rozbudowę procedury o kolejne kroki.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.