Главная / Статьи / Сервер агента LangGraph с самостоятельным хостингом и использованием Postgres и Redis

LangGraphPostgresRedisSelf-HostingLLMAgents

Сервер агента LangGraph с самостоятельным хостингом и использованием Postgres и Redis

Узнайте, как Langhost заменяет слой сохранения данных LangGraph на Postgres и Redis, позволяя командам самостоятельно развертывать неизмененный Agent Server под лицензией MIT.

1503 слов

Сохраните LangGraph SDK, Studio и Agent Server в том виде, в котором они существуют. Перенесите постоянные данные в Postgres, а задачи координации — в Redis, причем для этого не потребуется лицензионный ключ для работы программы.

Написание агента LangGraph обычно является самой простой частью.

Вы запускаете графовую структуру локально, инструменты выполняют свои действия, данные передаются от узла к узлу. Затем возникает вопрос, который превращает прототип в реальную задачу для эксплуатации: как на самом деле запустить это решение для работы с производственным трафиком?

Сервер-агент должен отслеживать гораздо больше информации, чем это требуется от простого API синхронного запроса-ответа. Для ведения диалогов необходимы устойчивые потоки, сохраняющиеся между сессиями. Некоторые процессы приостанавливаются в ожидании одобрения человеком определенного шага, а затем возобновляются значительно позже. Клиенты ожидают потока событий, а не единственного ответа. Запланированные задачи должны выполняться ровно один раз, даже если несколько работников пытаются их обработать одновременно. А если один из работников выходит из строя в процессе выполнения, другой должен без проблем взять на себя его обязанности, не нарушая целостность состояния.

langgraph dev подходит для локальной разработки, и сама документация LangChain описывает его как сервер для разработки, а не для производственного использования. Он хранит состояние в памяти и локальной папке. Официальным способом перехода к производственному использованию является LangSmith Deployments, доступный как в виде управляемой услуги, так и по лицензии для самостоятельной развертки.

Langhost предлагает иной подход. Он запускает неизмененный LangGraph Agent Server поверх Postgres и Redis, используя среду выполнения для сохранения данных, выпущенную под лицензией MIT.

На первый взгляд это кажется незначительной заменой. И действительно, она незначительная. Именно поэтому ей стоит уделять внимание.

Решение по дизайну, делающее Langhost интересным

Вместо того чтобы переимплементировать Agent Protocol или заставлять приложения использовать другой API, Langhost оставляет официальный пакет Agent Server langgraph-api без изменений. Изменяется только слой под ним: пакет langgraph-runtime-pg берет на себя функции сохранения данных.

Примерно так соединяются все компоненты:

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

Существующие приложения сохраняют свои определения графа и файл langgraph.json в неизменном виде. Клиенты продолжают взаимодействовать с langgraph-sdk. Студия по-прежнему подключается через тот же API Agent Server, который использовался ранее. Langhost намеренно избегает выполнения каких-либо значимых действий на этой границе, что является совершенно правильным подходом для инфраструктуры.

Поскольку официальный пакет сервера остается без изменений, вся его функциональность сохраняется и при смене сервера: управление ассистентами, отслеживание тредов и отдельных запусков, предоставление хранилища в формате ключ-значение, выполнение запланированных задач, передача потокового вывода, вызов webhook-функций, а также поддержка как MCP, так и A2A. Для конкурирующих реализаций сервера потребуется постоянно отслеживать каждое изменение протокола, чтобы всё это продолжало работать. Langhost полностью избегает такой нагрузки по техническому обслуживанию, оставляя поведение протокола на уровне исходного сервера и сосредотачиваясь только на хранении данных и координации.

Что делают Postgres и Redis

Postgres хранит всё, что необходимо для продолжения работы после перезагрузки: настройки помощников, историю потоков, записи выполнения задач, определения запланированных заданий, точки контроля, а также любые данные приложения, сохранённые в базе. Миграции схем выполняются с помощью Alembic. Для производственных развертываний рекомендуется сначала применять миграции, а затем отключать автоматические миграции при запуске сервера.

Redis предназначен для краткосрочных задач координации. Он уведомляет рабочие процессы о поступлении новой задачи в очередь, передаёт события потока на все подключённые серверы и отслеживает статус рабочих процессов.

Это разделение становится важным, когда вы расширяете систему до нескольких реплик. Когда рабочий процесс хочет взять на себя выполнение задачи, он занимает соответствующую строку в Postgres с использованием параметра SKIP LOCKED, что предотвращает одновременное захватение той же задачи другими процессами. Сигналы жизнеспособности от Redis подтверждают, что процесс продолжает работать; если сигнал пропадает, очередь может переназначить задачу кому-то другому. Набор тестов проекта покрывает вопросы эксклюзивности доступа к задачам, восстановления после сбоев процессов, работы одновременных потоков, поведения при стриминге данных, отмены задач и обновления состояния во время их выполнения.

Именно этот аспект часто упускается из виду в руководствах типа «как развернуть ваш агент». Запуск сервера ASGI — дело простое. Настоящей инженерной задачей является обеспечение корректного управления очередью и восстановления после сбоев при одновременной нагрузке.

Перемещение существующего проекта

Если у вас уже есть проект Python LangGraph с файлом langgraph.json, настройка работы с Langhost занимает всего несколько шагов.

Установите его:

uv add langhost

Затем настройте подключение к вашим инстансам Postgres и Redis:

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

И запустите сервер:

uv run langhost serve --reload

Для производственной среды явно указайте сетевой интерфейс и установите фиксированное количество рабочих процессов:

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

По умолчанию сервер прослушивает порт 31296. При запуске отображается информация с ссылками на сам API, его документацию, LangSmith Studio и интерфейс Agent Chat. Ваш существующий клиентский код продолжает работать без изменений, используя стандартный 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())

Такой простой способ миграции, пожалуй, является главным преимуществом Langhost. Команда может его опробовать, не меняя код приложения и не заменяя клиентские библиотеки.

Условия лицензии требуют внимательного прочтения

Инструменты командной строки langhost и langgraph-runtime-pg распространяются под лицензией MIT. Однако стандартный пакет langgraph-api по-прежнему находится под лицензией Elastic License 2.0. Langhost фактически заменяет проприетарный слой выполнения Postgres и Redis; это не влияет на условия лицензирования самого официального серверного пакета.

Эта тонкость часто упускается из виду, когда люди называют всю стек-технологии «открытым исходным кодом». Слой сохранения данных, который запускается и может быть изменён с помощью Langhost, действительно распространяется под лицензией MIT. Но серверный компонент, находящийся поверх него, остаётся доступным по исходному коду под лицензией Elastic 2.0, и вы по-прежнему обязаны соблюдать её условия.

Тем не менее для многих организаций такой практический сдвиг имеет большое значение. Они получают возможность запускать стабильные рабочие нагрузки LangGraph на самоуправляемых базах данных без необходимости использования ключей лицензии для среды выполнения. Это также означает, что состояние приложения может полностью находиться внутри их собственного облачного аккаунта или внутренней сети. Тем не менее те, кто рассматривает возможность использования этого решения в компании, должны попросить юридические или отделы закупок внимательно изучить обе лицензии, а не полагаться на рекламные краткие описания.

Что вы берете на себя при самостоятельном хостинге

Langhost снимает ограничения, связанные с лицензированием и средой выполнения. Однако он не уменьшает операционную нагрузку.

Вы несете ответственность за планирование мощностей Postgres, создание резервных копий, проведение тестов восстановления, управление лимитами пула подключений и миграцию схем. Вы также отвечаете за стабильную работу Redis и политику освобождения памяти. Кроме того, вам необходим контроль — метрики и логи, которые показывают, выполняются ли резервные копии из очереди задач, застряли ли рабочие процессы или тихо пропадают ли потоки данных. И прежде чем открыть API для доступа извне доверенной сети, его необходимо надлежащим образом защитить.

Имейте в виду, что этот проект находится на ранней стадии развития. текущая версия на PyPI — это 0.11.1.post1, помеченная как бета-версия. Она фиксирует определённую версию langgraph-api, что обеспечивает стабильную совместимость для данной версии, но в то же время требует от проекта постоянного отслеживания изменений в исходном коде, чтобы оставаться актуальным. Набор тестов репозитория выполняет как собственные тесты, так и тесты на интеграцию Python SDK против рабочего сервера Agent, что является обнадёживающим фактором — однако это не заменяет проверку собственных графов, шаблонов трафика, сценариев сбоев и процедур обновления.

Для команд, которые предпочитают не заниматься всем этим самостоятельно, более разумным вариантом остается использование управляемой версии LangSmith Deployment. Langhost лучше подходит для команд, уже уверенно работающих с Postgres и Redis, которым необходим строгий контроль над местоположением хранения данных, или для тех, кто просто не может использовать лицензируемую самостоятельно развернутую среду выполнения.

Практический способ оценки

Вместо того чтобы начинать с списка функций, возьмите пробную копию приложения LangGraph, уже работающего у вас, и настройте его на использование Langhost.

Используйте тот же файл langgraph.json, тот же клиент SDK и ту же рабочую схему Studio, на которых вы работаете сейчас. Создайте долговечный поток. Осуществляйте передачу данных в реальном времени для длительных операций. Прервите их в процессе выполнения и возобновите позже. Запустите более одного рабочего процесса. Остановите один из рабочих процессов во время выполнения задачи и убедитесь, что операция всё равно завершится корректно. Затем сделайте резервную копию в Postgres, восстановите её в отдельной среде и проверьте, что история потоков сохраняется полностью нетронутой.

Если ваша конфигурация проходит все эти проверки, вы ответите на самый важный вопрос — может ли Langhost беспроблемно интегрироваться в вашу инфраструктуру, не став при этом источником проблем.

Исходный код, руководство по настройке и трекер проблем доступны по адресу langhost/langhost на GitHub.

Связанная литература

Все статьиПрислать бриф