AWS собрала WhatsApp-ассистента для заказов с общей памятью текста и голоса

Один WhatsApp-номер вместо трёх разрозненных каналов

AWS опубликовала готовую архитектуру мультимодального помощника для ресторанных заказов. Клиент пишет текст, отправляет voice note или звонит на один WhatsApp Business номер, а AI-агент проводит заказ от приветствия до подтверждения. Все способы общения используют один backend и общую долговременную память, поэтому человек, написавший сегодня и позвонивший завтра, распознаётся как тот же клиент.

Решение построено на Amazon Bedrock AgentCore и Amazon Nova 2. Текст обрабатывает Nova 2 Lite через Bedrock Converse API, голосовые заметки и звонки — Nova 2 Sonic в speech-to-speech режиме. За пользовательский вход отвечает Meta WhatsApp Business Platform, а связь агентов с меню, корзиной, заказами и точками выдачи проходит через Model Context Protocol.

Это не демонстрация одного большого prompt. AWS разделяет систему на слой канала, три специализированных agent runtime и детерминированный ordering backend. Такое деление позволяет менять способ общения без переписывания расчёта корзины и одновременно не поручать языковой модели цены, налоги и сохранение заказа.

Webhook отвечает быстро, агент работает через очередь

Входящий трафик приходит на единственный публичный HTTPS webhook в Amazon API Gateway. Webhook Ingest Lambda проверяет подпись Meta, кладёт событие в Amazon SQS и немедленно возвращает HTTP 200. Загрузка медиа, вызов модели, обращение к инструментам и отправка ответа происходят уже асинхронно в Webhook Worker, поэтому длительная обработка не удерживает запрос Meta открытым.

Очередь снабжена dead-letter queue. При временной ошибке сообщение возвращается на повторную обработку, а после нескольких неудач откладывается для расследования. Для production-сценария это принципиальнее красоты диалога: заказ не должен исчезнуть только потому, что модель, Media API или внутренний сервис ответили медленно.

Публичная поверхность при этом остаётся узкой. Клиентский webhook — единственная внешняя точка входа, тогда как backend API авторизован через IAM. Секреты Meta — Access Token, App Secret и Verify Token — хранятся в AWS Secrets Manager и заполняются вне CDK-шаблона, чтобы значения не попадали в синтезированную инфраструктуру или исходный код.

Три runtime, одна память

AgentCore запускает отдельный runtime для чата, voice note и voice call; каждая беседа исполняется в изолированной microVM. При этом все runtime читают и записывают один ресурс AgentCore memory. Ключом служит псевдонимный `customer_id`, полученный из номера E.164 и секретного pepper, а не сам телефон.

AWS приводит формулу `wa-` + первые 16 символов SHA-256 от номера и pepper. Сырой телефон не сохраняется в памяти или session state. Это снижает распространение персональных данных, но авторы прямо оговаривают: схема даёт распознавание, а не проверку личности. Если бизнесу нужна аутентификация, поверх неё требуется отдельный шаг, например одноразовый код.

В начале сессии агент получает долгосрочные insights — прошлые заказы, предпочтения и упомянутые клиентом любимые позиции. В конце события возвращаются в memory. Общий ключ устраняет отдельную задачу синхронизации истории между текстом и голосом, но одновременно делает качество identity resolution критичным: ошибка связывания повлияет сразу на все каналы.

MCP отделяет разговор от бизнес-операций

Ни один agent runtime не вызывает ordering Lambda напрямую. AgentCore Gateway работает как управляемый MCP server: он выставляет REST endpoints как именованные инструменты `GetMenu`, `AddToCart`, `PlaceOrder` и другие. Runtime подключается по HTTPS под собственной IAM role, обнаруживает разрешённые tools и вызывает их по имени.

Цены и итоговые суммы считает backend, а не модель. Заказ сохраняется в DynamoDB с признаком канала `whatsapp`; отдельные таблицы содержат профили, историю заказов, меню, корзины и точки. Amazon Location Service геокодирует адрес или ZIP code и помогает найти ближайшую точку выдачи.

Разделение даёт понятную границу ответственности. Модель интерпретирует намерение и ведёт разговор, MCP описывает допустимые действия, а backend проверяет данные и владеет денежной логикой. Если ресторан добавит новый инструмент или заменит обработчик, разговорный слой не обязан знать конкретную Lambda-функцию.

Голос без промежуточной транскрипции

Voice note загружается из Meta Media API как OGG Opus, преобразуется в PCM 16 kHz и передаётся в ограниченную по времени сессию Nova 2 Sonic. Ответ возвращается голосовым сообщением. AWS подчёркивает, что отдельного сервиса транскрипции в цепочке нет: это voice-in, voice-out с доступом к тем же MCP tools и общей памяти.

Для звонка используется WebRTC. Meta присылает SDP offer, runtime в режиме `turnOnly` получает credentials для управляемого TURN relay через Amazon Kinesis Video Streams и формирует единый SDP answer после ICE gathering. Только call-runtime помещён в VPC и использует NAT gateway; текстовый и voice-note runtime такой сетевой конфигурации не требуют.

Три тракта различаются транспортом, но сходятся перед бизнес-слоем. Это делает пример полезным не только для ресторанов: та же форма подходит поддержке, записи на обслуживание и другим процессам, где клиент ожидает продолжения контекста при переходе от сообщения к звонку.

Что действительно разворачивает пример

AWS опубликовала sample repository с тремя контейнерами агентов, CDK-инфраструктурой и setup scripts для подключения WhatsApp webhook. Развёртывание последовательно создаёт VPC, backend, DynamoDB и Location Service, AgentCore Gateway и memory, затем собирает ARM64 images через CodeBuild, помещает их в ECR и запускает runtime. Первая сборка каждого контейнера, по оценке авторов, занимает примерно 8–12 минут.

Meta-часть остаётся внешней предпосылкой: CDK не создаёт Developer App, WABA или номер. Для demo подходит sandbox test number, однако нужны App ID, App Secret, Access Token, Business portfolio ID, Verify Token и включённый Calling API для звонков. Временный Meta token годится только для короткого теста; для длительной работы AWS рекомендует System User token с нужными scopes.

Пример не является бесплатным serverless-шаблоном без хвостов. Пользователь платит отдельно за AWS и WhatsApp messaging; голосовые сессии потребляют больше ресурсов, а VPC с NAT gateway добавляет базовую стоимость. Cleanup script удаляет историю заказов, pepper, secrets и ECR images, поэтому перед уничтожением stack требуется сохранить нужные данные и отдельно отключить Meta webhook.

Практический смысл архитектуры

Самая важная часть публикации — не ресторанный сценарий, а явные системные границы. Быстрое подтверждение webhook отделено от медленного inference, память — от session runtime, инструменты — от свободного текста модели, а денежные расчёты — от агента. Это уменьшает число мест, где вероятностный компонент может превратиться в операционную ошибку.

Ограничения также названы прямо. Решение не обрабатывает изображения и документы, хотя Nova 2 Lite уже мультимодальна; распознавание по телефону не равно identity verification; production deployment должен дополнительно рассмотреть Bedrock Guardrails, мониторинг, бюджеты и собственные правила хранения данных.

Поэтому sample стоит читать как воспроизводимый reference architecture, а не как готовую кассу. Он показывает, как собрать единый conversational front door и сохранить continuity между каналами, но ответственность за верификацию клиента, бизнес-правила, поддержку Meta-конфигурации и контроль расходов остаётся у команды, которая разворачивает систему.