Większość demo "agentów AI" to pętla while wokół modelu, który wywołuje narzędzia, aż uzna, że skończył. To działa na weekendowy projekt. Nie działa, gdy musisz rozumować o tym, co agent zrobi dalej, odzyskać się po nieudanym wywołaniu narzędzia albo wprowadzić człowieka do procesu przy decyzji o wysokiej stawce - a to jest właśnie luka, którą wypełnia orkiestracja grafowa.
01
Dlaczego orkiestracja grafowa, a nie pętle agentowe ad-hoc
Pętla agentowa ad-hoc - "wywołaj model, wykonaj wybrane przez niego narzędzie, powtórz" - nie ma jawnego modelu możliwych stanów systemu. Debugowanie oznacza czytanie transkryptu i zgadywanie, czemu model zdecydował, co zdecydował. Nie da się powiedzieć "ten krok musi zawsze uruchamiać się po tamtym" albo "jeśli to narzędzie zawiedzie, idź tutaj" bez kolejnego prompt engineeringu.
LangGraph czyni przepływ kontroli jawnym, inspekcjonowalnym grafem: węzły to jednostki pracy (wywołanie LLM, wywołanie narzędzia, fragment logiki biznesowej), krawędzie definiują, co może następować po czym, a stan grafu to jawny, typowany obiekt przepływający przez każdy węzeł. To różnica między agentem, o którym możesz rozumować, i takim, który możesz tylko obserwować.
02
Projektowanie stanu i pamięci w LangGraph
Schemat stanu grafu to najważniejsza decyzja projektowa w całym systemie - to wspólna pamięć, z której każdy węzeł czyta i do której zapisuje. Trzymaj go typowany i minimalny: dotychczasowa rozmowa, dane robocze zadania i już podjęte decyzje. Powstrzymaj chęć wrzucenia wszystkiego do stanu "na wszelki wypadek" - rozdmuchany obiekt stanu utrudnia rozumowanie o każdym węźle i zwiększa koszt każdego prompta budowanego na jego podstawie.
Dla dłużej działających lub wznawialnych agentów, checkpointing w LangGraph zachowuje stan między krokami, dzięki czemu przepływ pracy może się zatrzymać - czekając na narzędzie, człowieka lub zdarzenie zewnętrzne - i wznowić się dokładnie tam, gdzie się zatrzymał, a nie odtwarzać całą rozmowę od zera.
03
Węzły wywołań narzędzi i obsługa błędów
Traktuj każde wywołanie narzędzia jako coś, co może zawiść, bo w produkcji zawiedzie - timeout, zniekształcona odpowiedź, błąd uprawnień. Węzeł wywołania narzędzia powinien jawnie je przechwytywać i kierować do ścieżki odzyskiwania w grafie (ponowna próba z backoffem, przełączenie na inne narzędzie lub przekazanie awarii człowiekowi), a nie pozwalać nieobsłużonemu wyjątkowi zrzucić cały przebieg albo, co gorsze, pozwalać modelowi po cichu skonfabulować wynik wyglądający wiarygodnie.
Tutaj model grafowy się opłaca: logika retry i fallback jest widoczną częścią struktury grafu, nie zakopana w gigantycznym prompcie próbującym poinstruować model, by "obsługiwał błędy elegancko".
“Wartość grafu to nie diagram - to fakt, że ścieżki błędów i punkty kontrolne człowieka stają się strukturalne, nie tylko wypromptowane.”
04
Punkty kontrolne human-in-the-loop
Nie każda decyzja agenta powinna wykonywać się automatycznie - wysłanie e-maila do klienta, zatwierdzenie zwrotu czy scalenie kodu to właśnie te akcje, gdzie błędna decyzja jest kosztowna. LangGraph pozwala wstawić jawny węzeł przerwania: graf się zatrzymuje, stan jest checkpointowany, a przepływ czeka na zatwierdzenie (lub edycję) przez człowieka, zanim ruszy dalej z tym samym stanem, w którym się zatrzymał.
Decyzja, gdzie umieścić te punkty kontrolne, jest decyzją produktową w równym stopniu jak techniczną - celem jest umieszczenie ich w kilku krokach, gdzie błąd jest kosztowny, nie w każdym kroku, co po prostu zamieniłoby agenta z powrotem w człowieka wykonującego całą pracę, tylko z dodatkowym opóźnieniem.
05
Testowanie i debugowanie wieloetapowych agentów
Testuj węzły niezależnie najpierw - węzeł wywołania narzędzia z zamockowaną odpowiedzią narzędzia, węzeł decyzyjny z ustalonym stanem wejściowym - tak samo, jak testowałbyś jednostkowo każdą funkcję, przed testowaniem całego grafu end-to-end. Dla całego grafu zbuduj mały zestaw realistycznych scenariuszy (włącznie z tymi zaprojektowanymi, by wywołać ścieżki błędów i odzyskiwania) i sprawdzaj końcowy stan oraz ścieżkę przez graf, nie tylko końcowy tekst wyjściowy.
Ślad wykonania LangGraph - które węzły się uruchomiły, w jakiej kolejności, z jakim stanem na każdym kroku - to narzędzie do debugowania, którego pętle agentowe ad-hoc nie dają. Gdy coś idzie źle w produkcji, ten ślad zwykle wystarcza, by wskazać, który węzeł podjął błędną decyzję.
Orkiestracja grafowa nie robi agenta mądrzejszym - czyni jego zachowanie czytelnym, a tryby błędów strukturalnymi, nie przypadkowymi. Jeśli przenosisz agenta z prototypu do czegoś, od czego zależy biznes, ta czytelność jest zwykle warta więcej niż jakikolwiek trik prompt engineeringu.
Powiązane artykuły