Procedural Graphs. Jak agent może poprawiać własne procedury
Na arXiv pojawiła się interesująca praca Procedural Graphs, poświęcona błędom agentów AI podczas długich zadań. Autorzy próbują ograniczyć gubienie kolejności działań i powtarzanie nieskutecznych prób.
Opis narzędzia może dokładnie wyjaśniać, jak go użyć, a mimo to pozostawiać otwarte pytanie, kiedy należy po nie sięgnąć. W programowaniu uruchomienie testów przed edycją i po edycji służy innym celom. Sam zapis, że agent wykonał testy, nie wystarcza do stwierdzenia, że sprawdził gotową poprawkę. Procedura musi uwzględniać zależność między tymi czynnościami.
Wskazówka we właściwym momencie
Wcześniejsze AutoGuide wykorzystuje doświadczenia z wykonanych zadań do tworzenia warunkowych instrukcji. Porównuje próby o różnych wynikach, szuka momentu, w którym ich przebieg się rozchodzi, i wyciąga z tego radę. Później dobiera wskazówki do bieżącej sytuacji agenta i umieszcza je w prompcie. Model otrzymuje więc informację o tym, jakie działanie sprawdzało się w podobnych okolicznościach.
Procedural Graph (PG) zapisuje kroki jako węzły, a przejścia opisuje warunkami, wskazówkami i pułapkami. Dopasowuje ostatnią czynność agenta do węzła; model pomocniczy czyta dwa kolejne poziomy przejść i ostatnie działania, po czym układa podpowiedź do promptu. Agent zachowuje swobodę wyboru.
Dla wspomnianych testów taka procedura mogłaby wiązać udane sprawdzenie z konkretną wersją plików. Kolejna edycja oznaczałaby konieczność ponownej weryfikacji. To przykład możliwego zastosowania: w opisie przejścia trzeba zapisać, co uzasadnia zakończenie pracy, a także ostrzec przed powołaniem się na nieaktualny wynik. Obowiązkowy warunek powinien dodatkowo sprawdzać kod obsługujący narzędzia, ponieważ wskazówka w prompcie sama nie blokuje operacji.
Poprawianie procedury
Między seriami zadań model proponuje zmiany kroków, połączeń i wskazówek. Poprawny strukturalnie wariant zostaje przyjęty, jeśli nie pogarsza wyniku na osobnych zadaniach sprawdzających. Odrzucone propozycje są zapamiętywane. Graf pozostaje stały podczas zadania, a wagi modeli bez zmian. Opis aktualizacji
W badaniu autorów na 56 zadaniach dialogowych MultiChallenge, z Gemini 3.5 Flash ocenianym przez Gemini 3.1 Pro, ręczny graf obniżył skuteczność z 87,50% do 58,93%. Iteracyjne poprawianie podniosło ją do 92,86%. Wynik dotyczy konkretnego grafu i małej próby. Wyniki eksperymentu
Przy projektowaniu własnego systemu warto potraktować instrukcje jako hipotezę do sprawdzenia. Reguła „po nieudanym teście zmień kod” może pomagać przy błędzie w funkcji, lecz szkodzić, gdy test nie wystartował z powodu brakującej zależności. Zestaw sprawdzający procedurę powinien obejmować oba przypadki. Inaczej można nagrodzić agenta za nawyk, który działa tylko w części sytuacji.
Osobny pomiar na ALFWorld z Gemini 3.5 Flash pokazał koszt lokalnych wskazówek: zużycie tokenów wzrosło o 55,4%, a skuteczność z 72,58% do 81,53% względem wariantu bez grafu. Pomiar jakości i kosztu
W zastosowaniu do programowania należałoby porównać ten dodatkowy koszt z czasem traconym na kolejne próby i sprawdzanie błędnych poprawek. Pomiar powinien obejmować całe zadanie, łącznie z pracą człowieka przy odbiorze wyniku. Dopiero wtedy można ocenić, czy dodatkowe podpowiedzi usprawniają pracę na tyle, żeby uzasadnić ich koszt.
Źródła
- Yuxing Lu i współautorzy, Procedural Graphs: Self-Evolving Execution Structures for LLM Agents, 2026.
- Yao Fu i współautorzy, AutoGuide: Automated Generation and Selection of Context-Aware Guidelines for Large Language Model Agents, NeurIPS 2024. Wcześniejsza metoda dobierania wskazówek do sytuacji agenta.