---
title: "LangGraph: jak kontrolować pracę agentów AI"
url: "https://majchrzycki.com/blog/langgraph-autonomous-mult-ai-agent-system"
description: "Poznaj LangGraph: stan, przerwania i wznawianie pracy agenta. Zobacz przykład procesu oraz pytania o uprawnienia, koszty i kontrolę błędów."
---

# LangGraph: jak kontrolować pracę agentów AI

19 maja 2024· Aktualizacja: 29 września 2026·4 min czytania·Krzysztof Majchrzycki

Temat: [Architektura systemów AI](https://majchrzycki.com/blog/filar/architektura-systemow-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](https://docs.langchain.com/oss/python/langgraph/overview).

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](https://docs.langchain.com/oss/python/langgraph/interrupts). 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](https://docs.langchain.com/oss/python/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](https://majchrzycki.com/system). 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](https://majchrzycki.com/blog/langsmith-ai-application-lifecycle-management-alm) 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ę.

-   Copilot
-   Agenci AI
-   Modele i LLM
-   Microsoft 365

## Przełóż temat na projekt w Twojej firmie

Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI.

[Zobacz współpracę](https://majchrzycki.com/wspolpraca)

## Czytaj dalej

-   [LangChain: kiedy framework pomaga aplikacji AI](https://majchrzycki.com/blog/langchain-ai-llm-apps)
-   [Microsoft AutoGen: jak ocenić system wielu agentów](https://majchrzycki.com/blog/co-to-jest-microsoft-autogen-multi-agent-system-mas)
-   [Semantic Kernel: kiedy orkiestracja AI ma sens](https://majchrzycki.com/blog/co-to-jest-microsoft-semantic-kernel)
-   [Technologie AI dla firm: jak porównać warstwy systemu](https://majchrzycki.com/blog/technologie-ai-dla-firm-przewodnik)