Samodzielne hostowanie Agent Servera LangGraph z użyciem Postgres i Redis

Zachowaj LangGraph SDK, Studio oraz Agent Server dokładnie takimi, jakie są. Przenieś trwały stan do Postgresa, a zadania koordynacji powierz agentowi Redis – wszystko to bez konieczności posiadania klucza licencji do działania.

Napisanie agenta LangGraph zazwyczaj jest najprostszą częścią.

Zapусkasz graf lokalnie, narzędzia wykonują swoje zadania, a stan przepływa z węzła na węzeł. Wtedy ktoś zadaje pytanie, które zamienia prototyp w rzeczywisty problem operacyjny: jak faktycznie uruchomić to w warunkach rzeczywistego ruchu użytkowników?

Serwer agenta musi śledzić znacznie więcej niż to, co potrafi prosta API typu żądanie-odpowiedź. Rozmowy wymagają trwałych wątków, które przetrwają między sesjami. Niektóre procesy są wstrzymywane w oczekiwaniu na zatwierdzenie kroku przez człowieka, a następnie wznowiane znacznie później. Klienci oczekują strumienia zdarzeń, a nie pojedynczej odpowiedzi. Zadania zaplanowane muszą zostać uruchomione dokładnie raz, nawet gdy kilka procesorów próbuje je wykonać jednocześnie. A jeśli jeden z procesorów ulegnie awarii w trakcie działania, inny musi przejąć kontrolę bez uszkodzenia stanu.

langgraph dev nadaje się do lokalnego rozwoju, a sama dokumentacja LangChain przedstawia go jako serwer deweloperski, a nie produkcyjny. Przechowuje on stan w pamięci oraz lokalnej folderze. Uznaną drogą do wdrożenia w produkcji jest LangSmith Deployments, dostępny zarówno jako usługa zarządzana, jak i pod licencją samodzielnego hostowania.

Langhost proponuje inny sposób rozwiązania. Uruchamia nienaruszony LangGraph Agent Server na bazie Postgres i Redis, wykorzystując silnik trwałości danych udostępniony na licencji MIT.

Z pozoru wygląda to jak niewielka zmiana. Rzeczywiście jest to drobna modyfikacja, ale właśnie to sprawia, że zasługuje na uwagę.

Wybór projektowy, który czyni Langhost interesującym

Zamiast ponownie implementować Agent Protocol lub zmuszać aplikacje do korzystania z innej API, Langhost pozostawia niezmieniony oficjalny pakiet Agent Server, langgraph-api. Zmienia się natomiast warstwa pod nim: pakiet langgraph-runtime-pg przejmuje funkcję przechowywania danych.

Oto w przybliżeniu, jak te elementy ze sobą współpracują:

LangSmith Studio, SDK clients, Chat UI, MCP, A2A
                         |
                   langhost serve
                         |
              stock langgraph-api
                         |
              langgraph-runtime-pg
                    /          \
              Postgres        Redis

Aplikacje, które już istnieją, zachowują swoje definicje grafów oraz plik langgraph.json w niezmienionej formie. Klienci nadal komunikują się z langgraph-sdk. Studio nadal łączy się za pośrednictwem tej samej API Agent Server, której zawsze używało. Langhost celowo unika wykonywania jakichkolwiek istotnych działań w tym obszarze, co jest dokładnie właściwym instynktem dla infrastruktury.

Ponieważ oficjalny pakiet serwera pozostaje bez zmian, cały jego zestaw funkcji przetrwa również zamianę serwerów: zarządzanie asystentami, śledzenie wątków i poszczególnych wykonań, udostępnianie magazynu typu klucz-wartość, uruchamianie zadań zaplanowanych, wysyłanie danych w formie strumienia, wywoływanie webhooków oraz obsługa zarówno protokołu MCP, jak i A2A. Konkurencyjna implementacja serwera musiałaby ciągle śledzić każdą zmianę w protokole, aby to wszystko funkcjonowało. Langhost całkowicie unika tego obciążenia konserwacyjnego, pozostawiając zachowanie protokołu serwerowi oryginalnemu i skupiając się wyłącznie na przechowywaniu danych oraz koordynacji.

Czym zajmują się Postgres i Redis

Postgres przechowuje wszystko, co jest potrzebne do funkcjonowania po ponownym uruchomieniu: konfiguracje asystentów, historię wątków, zapisy wykonywań, definicje zadań zaplanowanych, punkty kontrolne oraz wszelkie dane aplikacji przechowywane w bazie. Migracje schematu są realizowane za pomocą Alembic. W przypadku wdrożeń produkcyjnych zaleca się przeprowadzenie migracji przed uruchomieniem systemu oraz wyłączenie automatycznych migracji przy starcie serwera.

Redis jest przeznaczony do krótkotrwałych zadań koordynacyjnych. Powiadamia pracowniki o nowych zadaniach trafiających do kolejki, przekazuje wydarzenia strumieniowe do wszystkich połączonych procesów serwerowych oraz śledzi aktywność pracowników.

To rozdzielenie staje się ważne, gdy rozszerzasz system o kilka replik. Gdy pracownik chce przejąć bieżącą operację, rezerwuje wiersz w Postgresie za pomocą opcji SKIP LOCKED, co zapobiega temu, by inny pracownik mógł jednocześnie przejąć tę samą operację. Sygnały serca od Redis potwierdzają, że pracownik nadal funkcjonuje; jeśli sygnał zostanie przerwany, kolejka może przypisać tę operację komuś innemu. Zestaw testów projektu obejmuje sprawdzanie wyłączności rezerwacji, odzyskiwanie po awarii pracownika, działanie wątków równoczesnych, zachowanie przy transmisji danych strumieniowej, anulowanie operacji oraz aktualizacje stanu, które zachodzą, gdy operacja jest jeszcze w trakcie wykonywania.

To właśnie ten aspekt jest często pomijany w wielu przewodnikach typu „jak zainstalować swój agent”. Uruchomienie serwera ASGI jest proste. Prawdziwym wyzwaniem inżynieryjnym jest zapewnienie prawidłowego funkcjonowania mechanizmów zarządzania kolejką i odzyskiwania po awariach pod obciążeniem równoczesnym.

Przenoszenie istniejącego projektu

Jeśli masz już projekt Python LangGraph z plikiem langgraph.json, wdrożenie Langhost zajmuje zaledwie kilka kroków.

Zainstaluj go:

uv add langhost

Następnie skieruj go na swoje instancje Postgres i Redis:

DATABASE_URI=postgresql+asyncpg://postgres:postgres@localhost:5432/langgraph?sslmode=disable
REDIS_URI=redis://localhost:6379/0

I uruchom serwer:

uv run langhost serve --reload

Dla środowiska produkcyjnego powiąż go wyraźnie z interfejsem sieciowym i ustaw stałą liczbę pracowników:

uv run langhost serve --host 0.0.0.0 --workers 4

Domyślnie nasłuchuje na porcie 31296. Po uruchomieniu wyświetla się baner z linkami do samej API, jej dokumentacji, LangSmith Studio oraz interfejsu Agent Chat. Twój istniejący kod klienta nadal działa bez zmian, korzystając z standardowego SDK:

import asyncio
from langgraph_sdk import get_client

client = get_client(url="http://127.0.0.1:31296")async def main():
    async for chunk in client.runs.stream(
        None,
        "agent",
        input={
            "messages": [
                {"role": "human", "content": "What is LangGraph?"}
            ]
        },
    ):
        print(chunk.event, chunk.data)asyncio.run(main())

Ten prosty w użyciu sposób migracji jest chyba największą zaletą Langhost. Zespół może go wypróbować bez konieczności modyfikowania kodu aplikacji czy wymiany bibliotek klienta.

Warunki licencji wymagają uważnego przeczytania

CLI langhost oraz langgraph-runtime-pg są dostarczane pod licencją MIT. Standardowy pakiet langgraph-api natomiast nadal podlega licencji Elastic License 2.0. Langhost faktycznie zastępuje własną warstwę wykonawczą opartą na Postgres i Redis. Nie ma to wpływu na warunki licencjonowania samego oficjalnego pakietu serwera.

Ta subtelność często umyka uwadze, gdy ludzie określają cały zestaw jako „otwarty kod”. Warstwa persistencji, którą uruchamiasz i możesz modyfikować za pośrednictwem Langhost, rzeczywiście jest objęta licencją MIT. Jednak komponent serwera znajdujący się nad nią pozostaje dostępny w formie źródłowej pod licencją Elastic 2.0, więc nadal jesteś związany tymi warunkami.

Mimo to dla wielu organizacji praktyczna zmiana ta ma znaczenie. Zyskują one możliwość uruchamiania wydajnych zadań LangGraph w bazach danych samodzielnie zarządzanych bez konieczności posiadania klucza licencji do środowiska wykonawczego. Oznacza to również, że stan aplikacji może pozostać w całości w ich własnym koncie chmurowym lub sieci wewnętrznej. Niemniej jednak wszyscy, którzy rozważają tę opcję do użycia w firmie, powinni poprosić zespoły prawnicze lub ds. zakupów o dokładne przejrzenie obu licencji, zamiast polegać na streszczeniach marketingowych.

Co niesie ze sobą samodzielne hostowanie

Langhost znosi ograniczenia licencyjne i związane ze środowiskiem wykonawczym. Nie eliminuje jednak obciążeń operacyjnych.

Jesteś odpowiedzialny za planowanie przepustowości Postgres, tworzenie kopii zapasowych, ćwiczenia przywracania danych, ustalanie limitów puli połączeń oraz migracje schematów. Odpowiadasz również za ciągłość działania Redis oraz politykę zwalniania pamięci. Ponadto potrzebujesz możliwości monitorowania – metryk i dzienników, które pokazują, czy kolej zadań przeprowadza kopie zapasowe, czy procesy się zatrzymały, czy strumienie są cicho przerywane. A zanim udostępnisz API poza zaufaną siecią, musisz je odpowiednio zabezpieczyć.

Należy pamiętać, że projekt ten znajduje się jeszcze we wczesnej fazie rozwoju. obecna wersja na PyPI to 0.11.1.post1, oznaczona jako wersja beta. Przytrzymuje ona określoną wersję langgraph-api, co zapewnia stabilną kompatybilność dla tej konkretnej wersji, ale jednocześnie oznacza, że projekt musi stale śledzić zmiany w oryginalnym oprogramowaniu, aby pozostać aktualny. Zbiór testów w repozytorium uruchamia zarówno własne testy, jak i testy integracyjne SDK Pythona przeciwko działającemu serwerowi Agent, co jest uspokajające – ale nie zastępuje weryfikacji własnych grafów, wzorców ruchu, scenariuszy awarii oraz procedur aktualizacji.

Dla zespołów, które woleją nie zajmować się tym samodzielnie, zarządzana implementacja LangSmith pozostaje rozsądniejszym wyborem. Langhost jest lepszy dla zespołów, które już dobrze radzą sobie z obsługą Postgres i Redis, potrzebujących ścisłej kontroli nad tym, gdzie fizycznie znajduje się ich stan, lub których po prostu nie uda się przekonać do używania licencjonowanego, samodzielnie hostowanego środowiska.

Praktyczny sposób na ocenę

Zamiast zaczynać od listy funkcji, weź kopię w fazie testowej aplikacji LangGraph, którą już uruchamiasz, i skieruj ją zamiast tego na Langhost.

Możesz ponownie używać tego samego pliku langgraph.json, tego samego klienta SDK oraz tego samego procesu pracy w Studio, na którym polegasz obecnie. Uruchom trwałe wątki, przesyłaj dane w formie strumieniowej podczas długotrwałych operacji, przerywaj je w trakcie wykonywania i wznowiaj później. Uruchom więcej niż jeden proces roboczy, zakończ działanie jednego z nich w trakcie wykonywania zadania i sprawdź, czy operacja nadal zostanie prawidłowo zakończona. Następnie utwórz kopię zapasową w Postgresie, przywróć ją do oddzielnego środowiska i upewnij się, że historia wątków pozostanie nienaruszona.

Jeśli twoja konfiguracja przejdzie wszystkie te testy, odpowiesz na naprawdę ważne pytanie – czy Langhost może spokojnie wdrożyć się w twoją infrastrukturę bez stanowienia obciążenia.

Kod źródłowy, przewodnik konfiguracji oraz narzędzie do śledzenia problemów są dostępne pod adresem langhost/langhost na GitHubie.

Powiązane materiały

• Budowanie bezpiecznych agentów AI z ograniczeniami i przejściówkami LangChain — Dowiedz się, w jaki sposób deterministyczne i oparte na modelach ograniczenia działają w LangChain, aby wykrywać wycieki danych osobowych, egzekwować zasady biznesowe oraz dodawać kroki zatwierdzenia przez człowieka do agentów AI.
• Co tak naprawdę automatyzuje LangChain po stworzeniu pętli agenta — Wyjaśnia, jak LangChain, LangGraph oraz podobne SDK-y otaczają tę samą podstawową pętlę agenta zbudowaną od zera, oraz kiedy korzystanie z frameworku jest pomocne, a kiedy szkodliwe.