LangGraph: jak kontrolować pracę agentów AI

Agent przygotował poprawną odpowiedź, ale po wznowieniu zadania ponownie wysłał wiadomość do klienta. Gdzie powinien znajdować się punkt kontroli? LangGraph pomaga sterować przebiegiem pracy agenta, lecz odpowiedzialność za dopuszczone działania pozostaje w projekcie aplikacji. Nie potrzebujesz wielu agentów, żeby skorzystać z kontroli stanu i kolejności kroków.

Stan funkcji sprawdzono 15 września 2026 r. Ten poradnik wyjaśnia kryteria wyboru i odbioru, bez obietnicy gotowego wdrożenia jednym kliknięciem.

Czym jest LangGraph

LangGraph to framework i środowisko wykonawcze do organizowania stanowych, także długotrwałych procesów agentowych. Pozwala łączyć kroki opisane regułami z krokami wykorzystującymi model językowy. Nie wymaga używania całego LangChain. Źródło: aktualny przegląd LangGraph.

W praktyce graf opisuje kroki i możliwe przejścia. Stan przechowuje informacje potrzebne w dalszej pracy. Węzeł może pobierać dane, sprawdzać warunek, wywoływać model albo przygotowywać propozycję działania.

Sam graf nie jest modelem AI. Nie zastępuje również systemu uprawnień w CRM czy ERP. To aplikacja musi ustalić, jakie narzędzia udostępnia i na jakich danych mogą pracować.

Kiedy ten poziom kontroli jest potrzebny

Jeśli zadanie obejmuje pojedynczą odpowiedź bez dalszych działań, dodatkowa warstwa może być zbędna. Warto ją rozważyć, gdy proces potrzebuje przerwania, wznowienia, kilku zależnych etapów albo zatwierdzenia przez człowieka.

Potrzeba	Co należy zaprojektować
Praca po przerwaniu	Trwały zapis stanu i identyfikator sprawy
Akceptacja człowieka	Punkt zatrzymania oraz uprawnionego decydenta
Kilka ścieżek	Warunki wyboru następnego kroku
Błąd narzędzia	Zasady ponowienia i zakończenia
Działanie w systemie	Autoryzację i ochronę przed powtórzeniem

Większa liczba agentów nie jest automatycznie korzyścią. Każde przekazanie może zwiększać koszt, opóźnienie i liczbę miejsc, w których gubi się kontekst. Najpierw pokaż, że podział rozwiązuje konkretny problem.

Przykład obsługi zapytania o zamówienie

Załóżmy modelowy proces: pracownik chce przygotować odpowiedź o statusie zamówienia. Aplikacja sprawdza jego dostęp, pobiera dane i proponuje treść. Wysłanie wymaga zatwierdzenia.

Etap	Wynik	Warunek przejścia
Identyfikacja	Numer sprawy i użytkownik	Dane są kompletne
Autoryzacja	Decyzja o dostępie	Użytkownik ma prawo do zamówienia
Odczyt	Status ze źródła	Źródło odpowiedziało poprawnie
Szkic	Propozycja wiadomości	Treść nie wykracza poza dostępne dane
Akceptacja	Zatwierdzenie lub korekta	Decyzja właściwej osoby
Wysłanie	Potwierdzony wynik operacji	Brak wcześniejszej wysyłki tej samej wersji

To projekt przykładowy, nie funkcja włączana automatycznie po instalacji biblioteki. LangGraph organizuje przebieg, a integracje, reguły dostępu i odbiór wymagają implementacji.

W prostszym wariancie można zakończyć proces na szkicu. Wtedy użytkownik wysyła wiadomość sam. Taki zakres bywa wystarczający do sprawdzenia wartości, zanim firma dopuści zapis w zewnętrznym systemie.

Minimalny przykład przerwania i wznowienia

Poniższy przykład nie wywołuje modelu ani nie wysyła prawdziwej wiadomości. Dzięki temu da się najpierw sprawdzić najważniejszą własność procesu: ten sam wątek zostaje zatrzymany przed skutkiem i wznowiony dopiero po decyzji człowieka. Składnia interrupt(), Command(resume=...), thread_id i InMemorySaver odpowiada aktualnej dokumentacji LangGraph. Przed użyciem przypnij wersję langgraph w pliku zależności projektu.

from typing import TypedDict
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import START, END, StateGraph
from langgraph.types import Command, interrupt

class State(TypedDict):
    draft: str
    status: str

def approve(state: State) -> dict:
    accepted = interrupt({"draft": state["draft"], "question": "Wysłać?"})
    return {"status": "approved" if accepted else "rejected"}

builder = StateGraph(State)
builder.add_node("approve", approve)
builder.add_edge(START, "approve")
builder.add_edge("approve", END)
graph = builder.compile(checkpointer=InMemorySaver())
config = {"configurable": {"thread_id": "zamowienie-42"}}

paused = graph.invoke({"draft": "Status zamówienia: gotowe", "status": "pending"}, config)
assert "__interrupt__" in paused
result = graph.invoke(Command(resume=True), config)
assert result["status"] == "approved"

InMemorySaver służy tu tylko demonstracji; po restarcie procesu pamięć znika. W produkcji potrzebny jest trwały zapis i identyfikator sprawy. Osobny, idempotentny krok wysyłki powinien używać klucza operacji, sprawdzić wcześniejsze wykonanie i dopiero wtedy zapisać rezultat. Samo przerwanie węzła nie chroni przed podwójnym wysłaniem po ponowieniu żądania. W teście dodaj więc drugie wznowienie i awarię po wysyłce, ale przed zapisaniem potwierdzenia.

Zatwierdzenie musi dotyczyć konkretnej propozycji

Mechanizm przerwania pozwala zatrzymać pracę i wznowić ją z dostarczoną odpowiedzią. Dokumentacja opisuje potrzebę zapisu stanu i identyfikacji wątku. Wskazuje też, że przy wznowieniu kod węzła może wykonywać się ponownie od początku. Źródło: LangGraph — interrupts.

Dlatego operacje powodujące skutki wymagają szczególnej uwagi. Jeśli przed punktem zatrzymania wyślesz wiadomość, ponowienie nie powinno wysyłać jej kolejny raz. Sposób ochrony trzeba zaprojektować i przetestować.

Akceptacja powinna odnosić się do treści i danych, które osoba widziała. Gdy po zatwierdzeniu zmieni się odbiorca, kwota lub zakres, aplikacja potrzebuje reguły ponownej oceny. Sam status „zaakceptowano” nie wystarczy.

Dane wejściowe nie mogą nadawać uprawnień

Treść wiadomości klienta lub dokumentu jest materiałem do przetworzenia. Nie powinna samodzielnie zmieniać dostępu ani zakresu narzędzi.

W teście uwzględnij polecenie umieszczone w dokumencie, które próbuje skłonić model do ujawnienia innych danych. Kontrola dostępu musi działać przy odczycie i wykonaniu operacji, także wtedy, gdy model wygeneruje niepoprawną propozycję.

Nie powierzaj modelowi roli jedynego strażnika. Warunki biznesowe, które można jednoznacznie sprawdzić, warto wykonywać jako reguły. Przykładem jest zgodność identyfikatora użytkownika z uprawnieniem do sprawy.

Przygotuj odbiór przed rozbudową

Zaproponuj zestaw przypadków: poprawne zadanie, brak informacji, odmowa dostępu, awaria źródła, odrzucenie propozycji i wznowienie po przerwaniu. W każdym zapisz oczekiwany efekt oraz operacje, które nie mogą wystąpić.

Sprawdź również powtórne kliknięcie i ponowienie po utracie połączenia. Użytkownik powinien otrzymać czytelny status, a system nie może ukrywać niepewności, czy operacja została wykonana.

Jeśli proces działa tylko przy idealnym przebiegu, nie jest jeszcze gotowy do rozszerzenia. Lista obsłużonych wyjątków daje więcej wiedzy niż demonstracja kilku agentów rozmawiających ze sobą.

Policz koszt całej ścieżki

Uwzględnij wywołania modeli, przechowywanie stanu, integracje, monitoring i pracę człowieka. Oddziel bibliotekę od płatnych usług hostingu lub obserwacji; wybór jednego nie przesądza automatycznie zakupu wszystkich pozostałych.

Mierz koszt zakończonej poprawnie sprawy. Liczba tokenów wyjaśnia część wydatku, ale nie pokazuje kosztu korekty, powtórzenia i obsługi błędu. Porównuj identyczny zakres zadania.

Powiązanie działania agenta z procesem rozwija Inteligentny System Operacyjny Firmy. Najpierw potrzebujesz granic zadania i odpowiedzialności, potem sposobu ich wykonania.

W protokole odbioru uwzględnij stan niepewny: narzędzie nie odpowiedziało, ale operacja mogła już nastąpić. Aplikacja powinna najpierw sprawdzić wynik, zamiast bezwarunkowo ponawiać działanie. To szczególnie ważne przy wysyłce wiadomości i zapisie zamówienia.

Zacznij od procesu, który potrafisz prześledzić

Poradnik LangSmith pokazuje, jak zbierać ślady i oceniać wyniki takiego procesu. Obserwacja pomaga ustalić, gdzie powstał błąd, zamiast obwiniać cały model.

W poniedziałek narysuj jedną ścieżkę zadania. Zaznacz odczyty, decyzje, zatwierdzenia i operacje powodujące skutki. Przy każdym punkcie zapisz, co stanie się po przerwaniu. Dopiero wtedy zdecyduj, czy LangGraph daje potrzebną kontrolę.