Создание серверless диалогового агента на LangGraph и Amazon Bedrock: архитектура для обработки заказов

Почему ваши чат-боты для заказов все еще тупые

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

Проблема не в модели. Claude 3.5 Sonnet на Amazon Bedrock умнее половины ваших менеджеров. Проблема в архитектуре. Вы пытаетесь впихнуть сложный многозадачный диалог в линейный скрипт. Это как собрать Ferrari, но забыть про руль и педали.

LangGraph: граф разговора вместо линейного скрипта

Забудьте про if-else лабиринты. LangGraph - это фреймворк для построения агентов как графов состояний. Каждый узел - шаг логики (распознать намерение, уточнить детали, вызвать API). Ребра - переходы между шагами на основе данных или решений модели.

Почему граф? Потому что человеческий диалог нелинеен. Клиент может уточнить адрес, потом передумать насчет размера пиццы, спросить про акцию, и все это в одном сообщении. Граф это переваривает. Агентные фреймворки в 2025 доказали: для продакшена нужна предсказуемость, а не только креативность LLM.

1 Архитектура: три слоя, которые не сломаются под нагрузкой

Наша система для обработки заказов строится на трех ключевых стадиях, реализованных как подграфы в LangGraph:

1. Распознавание и классификация намерения. Модель анализирует запрос: это новый заказ, изменение существующего, вопрос по доставке или жалоба? Используем Claude 3.5 Haiku - он быстрый, дешевый и идеально справляется с классификацией.
2. Управление диалогом и сбор контекста. Основной подграф, который ведет беседу, запрашивает недостающие данные (адрес, телефон, предпочтения). Здесь работает Claude 3.5 Sonnet с продвинутым контекстом в 200K токенов.
3. Действие и интеграция. Вызов внешних систем: создание заказа в базе данных через API, проверка наличия товара, расчет стоимости. Здесь LangGraph вызывает Lambda-функции или Step Functions.

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

Пошаговый план: от нуля до работающего агента

Говорят, что демо на ноутбуке и продакшн на AWS - это две разные вселенные. Сломаем этот стереотип. Вот как построить систему, которая выдержит тысячу заказов в час.

1 Настройте Amazon Bedrock и получите доступ к Claude 3.5

Заходите в консоль AWS. Bedrock - это не регион, а сервис. Включаете его в us-east-1 или другом регионе, где доступна последняя версия Claude 3.5 (на 08.03.2026 это Claude 3.5 Sonnet с улучшенной скоростью и точностью). Запросите доступ к модели через консоль. Ждете одобрения (обычно несколько минут).

# Проверяем доступные модели через AWS CLI (убедитесь, что у вас установлена последняя версия)
aws bedrock list-foundation-models --region us-east-1 --query "modelSummaries[?contains(modelName, 'Claude 3.5')]" --output table

2 Создайте граф LangGraph с тремя ключевыми узлами

Установите LangGraph версии 0.2 или новее. Они исправили баги с сохранением состояния, которые были в ранних релизах. Пишем граф на Python.

from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, END
from langchain_aws import ChatBedrock
from langchain_core.messages import HumanMessage
import operator

# Состояние графа - все данные диалога
class AgentState(TypedDict):
    messages: Annotated[list, operator.add]  # История сообщений
    intent: str  # Распознанное намерение
    order_details: dict  # Собранные детали заказа
    next_step: str  # Следующий шаг в графе

# Узел 1: Классификатор намерений
def intent_classifier(state: AgentState):
    llm = ChatBedrock(
        model_id="anthropic.claude-3-5-haiku-20241007-v1:0",
        region_name="us-east-1",
        temperature=0.1  # Низкая температура для стабильной классификации
    )
    # Анализируем последнее сообщение пользователя
    last_msg = state['messages'][-1].content if state['messages'] else ""
    prompt = f"""Классифицируй намерение пользователя: {last_msg}
    Варианты: NEW_ORDER, MODIFY_ORDER, DELIVERY_QUERY, COMPLAINT, OTHER.
    Верни ТОЛЬКО одно слово-намерение."""
    response = llm.invoke([HumanMessage(content=prompt)])
    return {"intent": response.content.strip()}

# Узел 2: Диалоговый менеджер
def dialog_manager(state: AgentState):
    llm = ChatBedrock(
        model_id="anthropic.claude-3-5-sonnet-20241007-v1:0",
        region_name="us-east-1",
        temperature=0.3
    )
    # Системный промпт с бизнес-логикой
    system_prompt = """Ты агент службы заказа пиццы. Собери информацию: тип пиццы, размер, адрес, телефон. Если чего-то не хватает, вежливо спроси. Не придумывай данные."""
    # Собираем историю диалога
    history = ["Система: " + system_prompt] + [f"{msg.type}: {msg.content}" for msg in state['messages'][-5:]]
    response = llm.invoke([HumanMessage(content="\n".join(history))])
    # Здесь логика анализа ответа и определения next_step
    # Если все данные собраны -> next_step = "fulfill_order"
    # Если нет -> next_step = "continue_dialog"
    return {"messages": [response], "next_step": "continue_dialog"}

# Узел 3: Исполнитель заказа (интеграция с API)
def order_fulfiller(state: AgentState):
    # Здесь вызов реального API вашей системы заказов
    # Например, через AWS Lambda или прямой HTTP-запрос
    order_data = state['order_details']
    # Имитация успешного создания заказа
    order_id = "ORD-2026-" + str(hash(str(order_data)))[:8]
    return {
        "messages": [HumanMessage(content=f"Заказ создан! Номер: {order_id}")],
        "next_step": "END"
    }

# Собираем граф
workflow = StateGraph(AgentState)
workflow.add_node("classify_intent", intent_classifier)
workflow.add_node("manage_dialog", dialog_manager)
workflow.add_node("fulfill_order", order_fulfiller)

# Определяем переходы
workflow.set_entry_point("classify_intent")
workflow.add_conditional_edges(
    "classify_intent",
    # В зависимости от намерения выбираем следующий узел
    lambda x: "manage_dialog" if x["intent"] == "NEW_ORDER" else "END",
)
workflow.add_edge("manage_dialog", "fulfill_order")
workflow.add_edge("fulfill_order", END)

graph = workflow.compile()

Это упрощенный код, но он показывает силу графов. Состояние автоматически передается между узлами. История диалога накапливается. Вы можете добавлять узлы для проверки адреса, расчета стоимости, применения промокодов. Более полный туториал разбирает каждую деталь.

3 Упакуйте агента в серверные функции AWS Lambda

LangGraph граф - это просто Python-объект. Его можно сериализовать и запустить в Lambda. Но есть нюанс: холодный старт. Если граф большой, инициализация занимает секунды. Решение - слои Lambda или использование Provisioned Concurrency.

Создайте слой Lambda со всеми зависимостями: langgraph, langchain-aws, boto3. Упакуйте граф в отдельный модуль. Триггером может быть API Gateway, WebSocket или напрямую AWS AppSync для GraphQL.

# serverless.yml фрагмент для развертывания
functions:
  pizzaAgent:
    handler: handler.graph_invoke
    layers:
      - arn:aws:lambda:us-east-1:123456789012:layer:langgraph-deps:1
    timeout: 30  # LLM могут работать долго
    memorySize: 1024  # Минимум 1GB для Claude
    environment:
      BEDROCK_REGION: us-east-1
    events:
      - http:
          path: /chat
          method: post

4 Добавьте мониторинг и управление моделями через MLflow

Запускать LLM без мониторинга - все равно что вести бизнес с завязанными глазами. Вы не знаете, сколько стоите, какие запросы падают, где модель галлюцинирует.

Разверните MLflow на Amazon SageMaker. Настройте трекинг всех вызовов к Bedrock: промпты, ответы, латентность, стоимость. Полный стек для агентов на Bedrock включает готовые шаблоны для этого.

Важный трюк: логируйте не только сырые промпты, но и версию модели, параметры температуры. Когда Anthropic выпустит Claude 3.6, вы сможете A/B тестировать старую и новую модель на реальных данных, прежде чем переключать продакшн.

Где все ломается: нюансы, которые не пишут в документации

Теория гладкая, практика колючая. Вот что я узнал, развертывая такие системы для ритейла.

Холодный старт Lambda убивает UX

Клиент ждет ответа 10 секунд, потому что Lambda только просыпается и загружает граф. Решение: используйте Lambda Provisioned Concurrency или переходите на AWS App Runner или контейнеры на Fargate. Для высоконагруженных систем лучше Amazon ECS с автоскейлингом.

Claude иногда слишком креативен

Вы просите собрать адрес, а модель начинает сочинять стихи про пиццу. Температура 0.3 - это не панацея. Нужны жесткие output parsers и валидация. Например, проверяйте, что в ответе есть номер телефона в определенном формате, прежде чем двигаться дальше. LangGraph позволяет вставлять узлы-валидаторы между диалоговыми шагами.

Контекст в 200K токенов - это ловушка

Да, Claude 3.5 Sonnet помнит огромную историю. Но если вы будете передавать в каждый запрос всю переписку с начала времен, счет за Bedrock будет космическим. Реализуйте суммаризацию контекста. Каждые 10 сообщений сжимайте историю в краткий вывод: "Клиент заказал пепперони на 35 см, живет на ул. Ленина, 15, ждет доставку к 19:00". И передавайте только сумму, а не сырые сообщения.

Вопросы, которые вы стеснялись задать

Создание агента - это не про написание промпта. Это про инженерию: графы, состояние, интеграции, мониторинг. Клиент не должен догадываться, что с ним говорит машина. Он просто получает свою пиццу с двойным сыром, без грибов. И заказывает снова.

P.S. Если вы junior-разработчик и думаете, что это слишком сложно, посмотрите реальный опыт старта с AI-агентами. Начните с простого графа на двух узлах. Добавляйте сложность постепенно. Через месяц вы будете смеяться над своими старыми линейными ботами.

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