Как использовать LangChain с MongoDB для production-агентов: полный стек

Ваш агент умный, но беспамятный и слепой. Вот как это починить

Вы собрали демку. Агент на LangChain шустро отвечает на вопросы по вашей документации, использует инструменты и даже шутит. Коллеги в восторге. Вы запускаете это в production, и начинается тихий ужас.

Агент забывает, о чем вы говорили три сообщения назад. На каждый запрос он заново лезет в базу, хотя ответ уже был в истории. Вместо JSON присылает стихи. А трассировка его действий напоминает археологические раскопки — непонятно, где что сломалось.

Знакомо? Проблема не в ваших промптах. Проблема в фундаменте. Вы строили прототип, а нужна production-система. И тут на сцену выходит партнерство, о котором все говорят в 2026: LangChain и MongoDB.

Это не просто "еще одна интеграция". Это попытка убить сразу трех зайцев: дать агенту память, дать ему знания и дать вам глаза, чтобы за всем этим следить. И все в одной экосистеме.

Почему именно этот стек? Потому что все остальное — костыли

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

LangChain + MongoDB Atlas решают это радикально:

• Векторный поиск встроен прямо в базу данных. Индексируете документы один раз, ищете моментально. Не нужно синхронизировать данные между системами.
• Оперативная память (memory) — это просто коллекция в той же базе. Сессии, история чата, промежуточные состояния агента живут рядом с вашими основными данными.
• Наблюдаемость (observability) через LangSmith интегрируется на уровне middleware в LangChain 1.x. Каждый вызов агента, каждый запрос к базе, каждый шаг в LangGraph оставляет след.
• Развертывание через LangGraph Deploy CLI упаковывает вашего агента в Docker-контейнер вместе со всей логикой подключения к MongoDB.

Звучит как маркетинг? Отчасти да. Но после шести месяцев работы с этим стеком в продакшене, я могу сказать: это работает. И вот как это настроить, чтобы не наступить на грабли.

1 Подготовка MongoDB Atlas: не просто база, а AI-движок

Первая ошибка — создать кластер Atlas по умолчанию. Для агентов нужны специфичные настройки.

Заходите в Atlas (на март 2026 интерфейс сильно изменился, но суть та же). Создаете кластер M60 или выше — на более слабых инстансах векторный поиск будет тормозить. Включаете опцию "Atlas Vector Search". Это важно: старый "Atlas Search" и новый "Vector Search" — разные вещи. Вам нужен второй.

# Через Atlas CLI (актуально на 2026)
atlas clusters create AgentCluster \
  --provider AWS --region EU_WEST_1 \
  --instanceSize M60 \
  --enableVectorSearch

В настройках базы данных создаете пользователя с правами `readWriteAnyDatabase`. И вот первый нюанс: для production-агентов создайте отдельную базу, а не лепите все в `test`. Назовем ее `agent_prod`.

2 Векторный поиск: как перестать кормить LLM мусором

Большинство агентов получают информацию из двух источников: промпт разработчика и контекст из векторного поиска. Если второй источник дает хлам, агент начинает генерировать хлам.

В Atlas Vector Search на март 2026 доступны новые типы индексов. Старый добрый `knnVector` еще работает, но для текста теперь есть `vectorSearch` с предобученными профилями для OpenAI, Cohere и открытых моделей.

Создаем индекс для коллекции `knowledge_base`:

// В Atlas UI переходим в Vector Search -> Create Index
// Используем JSON Editor
{
  "fields": [
    {
      "type": "vector",
      "path": "embedding",
      "numDimensions": 1536, // Для text-embedding-3-large
      "similarity": "cosine",
      "indexOptions": {
        "type": "vectorSearch",
        "profile": "openAIEmbeddingsV3" // Новая опция 2026 года
      }
    },
    {
      "type": "filter",
      "path": "tenant_id" // Важно для multi-tenant архитектуры
    }
  ]
}

Теперь подключаем это к LangChain. В версии 1.x интеграция стала проще, но появились новые абстракции.

# langchain-mongodb версии 0.3.x (актуально на март 2026)
from langchain_mongodb.vectorstores import MongoDBAtlasVectorSearch
from langchain_openai import OpenAIEmbeddings

# Инициализация эмбеддингов с новой моделью text-embedding-3-large
embeddings = OpenAIEmbeddings(
    model="text-embedding-3-large",
    dimensions=1536  # Можем уменьшить размерность для экономии
)

# Подключение к векторному хранилищу
vector_store = MongoDBAtlasVectorSearch(
    collection=your_mongo_collection,
    embedding=embeddings,
    index_name="your_vector_index_name",
    text_key="content",  # Поле с текстом
    embedding_key="embedding",  # Поле с векторами
)

# Поиск с фильтрацией по tenant_id
retriever = vector_store.as_retriever(
    search_type="similarity",
    search_kwargs={
        "k": 5,
        "pre_filter": {"tenant_id": {"$eq": "company_123"}}  # Новый параметр 2026
    }
)

Зачем `pre_filter`? Без него агент будет искать документы по всем клиентам, что нарушает изоляцию данных. Это частая ошибка в multi-tenant системах.

3 Оперативная память: чтобы агент не страдал склерозом

Память в агентах — это больное место. В прототипах используют `ConversationBufferMemory`, который хранит все в оперативке. Перезапустили сервер — история стерлась. В production так нельзя.

В LangChain 1.x появилась абстракция `ChatMessageHistory` с бэкендами для разных хранилищ. Нас интересует MongoDB.

from langchain_mongodb.chat_message_histories import MongoDBChatMessageHistory
from langchain_core.chat_history import BaseChatMessageHistory
from langchain_core.runnables.history import RunnableWithMessageHistory

# Создаем историю сообщений, привязанную к сессии
message_history = MongoDBChatMessageHistory(
    session_id="user_123_session_456",
    connection_string=MONGO_URI,
    database_name="agent_prod",
    collection_name="chat_histories",
)

# Добавляем TTL индекс для автоматической очистки старых сессий
# Это делается один раз в MongoDB:
# db.chat_histories.createIndex({ "created_at": 1 }, { expireAfterSeconds: 604800 }) # 7 дней

Теперь интегрируем память в агента. Самый надежный способ в 2026 — использовать `RunnableWithMessageHistory`.

# Создаем базового агента (упрощенно)
agent = create_agent_chain(llm, tools, prompt)

# Оборачиваем в RunnableWithMessageHistory
get_session_history = lambda session_id: MongoDBChatMessageHistory(
    session_id=session_id,
    connection_string=MONGO_URI,
    database_name="agent_prod",
    collection_name="chat_histories",
)

agent_with_memory = RunnableWithMessageHistory(
    agent,
    get_session_history,
    input_messages_key="input",
    history_messages_key="chat_history",
)

Теперь история каждого диалога сохраняется в MongoDB и подгружается при новом обращении. Агент помнит контекст даже после перезапуска сервиса.

4 Собираем агента с LangGraph: state management для взрослых

Простые цепочки (chains) ломаются в production. Агент должен уметь принимать решения, возвращаться назад, обрабатывать ошибки. Для этого LangChain развивает LangGraph — фреймворк для построения агентов с управлением состоянием.

Состояние (state) агента мы тоже храним в MongoDB. Это позволяет перезапускать агента с того же места.

from langgraph.graph import StateGraph, MessagesState
from langgraph.checkpoint.mongodb import MongoDBCheckpointSaver
from langchain_openai import ChatOpenAI

# Определяем состояние агента
class AgentState(MessagesState):
    retrieved_docs: list = []
    tool_calls: list = []
    tenant_id: str

# Создаем чекпоинты в MongoDB
checkpointer = MongoDBCheckpointSaver(
    namespace="agent_checkpoints",
    connection_string=MONGO_URI,
    db_name="agent_prod",
    collection_name="agent_states",
    ttl_seconds=86400,  # Автоочистка через 24 часа
)

# Строим граф агента
graph_builder = StateGraph(AgentState)
# ... добавляем ноды и ребра ...

graph = graph_builder.compile(checkpointer=checkpointer)

Теперь каждый запуск агента создает чекпоинт в MongoDB. Если агент упал посреди выполнения, вы можете восстановить его состояние. Это критично для долгих многошаговых задач.

Больше о построении production-агентов с управлением контекстом читайте в нашем руководстве по middleware в LangChain 1.0.

5 Наблюдаемость с LangSmith: что делает ваш агент в 3 часа ночи?

Без наблюдаемости агент в production — черный ящик. Вы не знаете, почему он принял то или иное решение, сколько токенов потратил, как часто ошибается.

LangSmith интегрируется с LangChain через middleware. Настраивается один раз.

from langsmith import Client
from langchain_core.tracers.langsmith import LangSmithTracer

client = Client(
    api_url="https://api.langchain.com",  # Актуальный URL на 2026
    api_key="your_langsmith_api_key",
)

tracer = LangSmithTracer(
    client=client,
    project_name="production-agent-mongodb",
    tags=["mongodb", "atlas", "production"],
)

# Добавляем tracer к вашему агенту
agent_with_tracing = agent.with_config({
    "callbacks": [tracer],
    "run_name": "Agent with MongoDB backend",
})

Теперь в LangSmith вы видите каждый шаг: вызовы к LLM, запросы к векторной базе, использование инструментов, время выполнения. Особенно полезно отслеживать префильтры векторного поиска — убедитесь, что агент не видит данные чужих клиентов.

Подробнее о мониторинге читайте в статье LangChain: практическое руководство по мониторингу AI-агентов в production.

6 Развертывание: из кода в Docker одной командой

Самая новая часть стека — LangGraph Deploy CLI. Она превращает вашего агента в Docker-контейнер с API, метриками и health-checks.

Устанавливаете CLI (версия 2.x на март 2026):

pip install langgraph-deploy

# Создаете конфигурацию развертывания
langgraph deploy init --stack mongodb-atlas

В файле `deploy.yaml` указываете подключение к MongoDB и настройки агента:

# deploy.yaml
version: '2'
stack: mongodb-atlas
services:
  agent:
    type: langgraph
    entrypoint: agent.graph:graph
    env:
      MONGO_URI: ${MONGO_URI}
      OPENAI_API_KEY: ${OPENAI_API_KEY}
    resources:
      memory: 2Gi
      cpu: 1000m

mongodb:
  atlas_cluster: AgentCluster
  database: agent_prod
  vector_indexes:
    - name: knowledge_base_vector
      collection: knowledge_base
  # Автоматически создаст индексы при первом развертывании

Запускаете развертывание:

langgraph deploy up --env prod

CLI соберет Docker-образ, запустит его в вашем кластере Kubernetes (или совместимом облаке), проверит подключение к MongoDB Atlas и поднимет API. Весь процесс занимает 5-7 минут.

Больше о развертывании читайте в обзоре LangGraph Deploy CLI.

Где этот стек ломается? Реальные кейсы из 2026

Технологии идеальны в демках. В production все иначе. Вот три проблемы, с которыми столкнулись команды, и как их решали.

Самая частая ошибка — пытаться использовать одну коллекцию MongoDB для всего. Разделяйте данные: отдельная коллекция для чат-историй, отдельная для векторных документов, отдельная для чекпоинтов агента. Это упростит масштабирование и резервное копирование.

А что дальше? Куда движется экосистема

К концу 2026 LangChain и MongoDB планируют еще более глубокую интеграцию. Ходят слухи о встроенном кэшировании промптов прямо в Atlas, где результаты запросов к LLM будут автоматически сохраняться и использоваться при повторении одинаковых вопросов. Это сократит costs и latency.

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

Но главный совет на сегодня: не гонитесь за новыми фичами. Возьмите этот стек, настройте базовую наблюдаемость через LangSmith, надежно сохраняйте состояние в MongoDB и убедитесь, что ваш агент не пересекает границы данных между клиентами. Остальное приложится.

И помните: самый опасный агент — не тот, который ошибается, а тот, который ошибается молча. Наблюдаемость — не опция, а необходимость. Без нее вы никогда не узнаете, что ваш production-агент уже неделю дает клиентам советы из документации конкурента потому, что векторный индекс случайно проиндексировал не те файлы.

Подписаться на канал