Poradnik / Praktyka
Kiedy graf agenta opłaca się bardziej niż logika schowana w promptcie
Nowy, 25-stronicowy przewodnik na arXiv, opublikowany 21 lipca przez zespół Daniela Pearsona, argumentuje, że przy długich procesach warto wyjąć logikę sterowania z prompta i narysować ją wprost jako graf w LangGraph, zamiast zdawać się na ukrytą pętlę ReAct. Autorzy nie robią laurki bibliotece: pokazują, kiedy się nie opłaca, i odsyłają do zwykłej pętli albo DSPy, gdy chodzi tylko o dobór promptów, a tezę ilustrują trzy przepisy z kodem, w tym analityka SQL z pętlą naprawczą. Najcenniejsza jest nie sama biblioteka, tylko mapa, kiedy ta struktura się zwraca, a kiedy jest już tylko kosztem.
Napisała AI, żeby oszczędzić Ci czytania setek źródeł. · Jak to działa
Poradnik / Praktyka · 4 min ·
Większość agentów AI, które powstają dzisiaj, działa w jednej prostej pętli. Model dostaje prompt, wybiera narzędzie, ogląda wynik i na tej podstawie decyduje o następnym ruchu. Ten wzorzec nazywa się ReAct, od angielskiego "reason and act", czyli najpierw pomyśl, potem zadziałaj, i przy krótkich zadaniach sprawdza się bez zarzutu. Kłopot pojawia się wtedy, gdy proces robi się długi i wieloetapowy, bo cała logika sterowania tkwi ukryta w treści prompta: kolejność kroków, warunki przejścia, ponawianie nieudanych prób. Nie widać jej, ciężko ją debugować, a po fakcie nikt nie odtworzy, dlaczego agent podjął akurat taką, a nie inną decyzję.
Nowy przewodnik na arXiv, opublikowany 21 lipca przez zespół Daniela Pearsona, bierze ten ból na warsztat i proponuje odwrotne podejście. Zamiast upychać sterowanie w promptcie, rysujesz je wprost jako graf. Autorzy opisują to jako praktyczny przewodnik po LangGraph, niskopoziomowym narzędziu z rodziny LangChain, które służy do budowania agentów pamiętających swój stan. Zamiast jednej pętli masz zestaw węzłów połączonych krawędziami: każdy węzeł to konkretny krok, stan przepływa między nimi jako typowana struktura danych, a o tym, dokąd agent pójdzie dalej, decydują jawnie zapisane warunki, a nie zgadywanka wewnątrz prompta. Dochodzą do tego deterministyczne narzędzia, które przy tych samych danych zawsze zwracają to samo, oraz zapisy całego przebiegu, dzięki którym po każdym uruchomieniu widać krok po kroku, co się wydarzyło i w którym miejscu.
Najważniejsze jest to, że przewodnik nie jest kolejną laurką dla frameworka. Autorzy świadomie pokazują, kiedy LangGraph się nie opłaca, i właśnie to czyni go przydatnym. Do prostego użycia narzędzi lepsza bywa zwykła pętla ReAct albo goły SDK. Do wyciągania ustrukturyzowanych danych i ich walidacji rozsądniej sięgnąć po narzędzia oparte na schemacie. Kiedy głównym celem jest optymalizacja samych promptów, właściwym wyborem jest DSPy, narzędzie stworzone właśnie do tego, żeby dobierać i szlifować prompty automatycznie, zamiast robić to ręcznie. LangGraph autorzy ustawiają nie jako domyślną odpowiedź na wszystko, tylko jako opcję dobieraną pod złożoność konkretnego procesu.
Czytaj dalej za darmo
Podaj e-mail, aby odblokować pełną treść i cały serwis. Zapiszemy Cię do newslettera.
