AWS собрала мультимодального WhatsApp-ассистента для заказов
AWS опубликовала развертываемый пример ассистента для ресторанных заказов в WhatsApp. Клиент пишет сообщение, отправляет голосовую заметку или звонит на один бизнес-номер, а три агентных процесса используют общий каталог, корзину, историю и память. Текст обрабатывает Amazon Nova 2 Lite, речь - Nova 2 Sonic, а бизнес-операции доступны агентам через управляемый шлюз MCP.
Что изменилось
Один номер обслуживает три способа общения
Пользователю не требуется отдельное приложение ресторана или новый вход. В одной переписке он может набрать заказ, записать голосовое сообщение либо начать звонок. Для каждого канала работает свой контейнер в AgentCore Runtime, потому что текстовый запрос, готовая аудиозапись и потоковая речь имеют разные требования к задержке. При этом канальный слой отделен от меню и заказов: добавление нового способа связи не должно менять правила цены, доступности блюда и расчета налога.
Общая память узнает клиента между сообщением и звонком
Все каналы получают один хешированный customer_id и обращаются к общей AgentCore Memory. Там могут храниться прошлые заказы, любимые позиции и явно названные предпочтения. Человек, написавший сегодня, при звонке завтра не выглядит новым клиентом. Такое удобство требует аккуратной идентификации номера, срока хранения и исправления фактов. Предпочтение без лука нельзя превращать в медицинскую аллергию, а старый адрес выдачи не должен автоматически считаться текущим.
Агент не считает итоговую цену сам
Меню, корзины, заказы, точки, часы работы и налоговые правила хранятся в DynamoDB и обслуживаются детерминированными функциями. Агент выбирает именованный инструмент, например PlaceOrder, но итог и цена рассчитываются серверной частью. Это важная граница: языковая модель ведет разговор и распознает намерение, а система учета остается источником истины. Если модель назвала несуществующую скидку, инструмент должен отклонить ее, а не записать произвольную сумму.
MCP отделяет рассуждение от внутренних API
AgentCore Gateway выступает управляемым MCP-сервером и превращает конечные точки ресторанного REST API в инструменты. Каждый контейнер входит со своей ролью IAM и получает только нужные операции. Агент не вызывает Lambda напрямую и не знает устройство обработчика. Благодаря этому backend можно менять независимо, а права текстового и голосового каналов ограничивать отдельно. Название инструмента, схема параметров и описание становятся частью безопасности: расплывчатая схема повышает шанс неверного вызова.
Входящий webhook отделен от медленной обработки
Подпись Meta проверяется при приеме, сообщение быстро помещается в очередь SQS, а отдельный worker запускает обработку и отправку ответа. Такой маршрут защищает webhook от превышения времени ожидания и позволяет повторять неудавшуюся операцию. Голосовой звонок использует WebRTC и отдельный runtime в VPC. Для реального запуска одной схемы мало: нужны лимиты повторов, идемпотентность заказа, защита от двойной оплаты, мониторинг задержки и ручной маршрут, когда агент не понял позицию или адрес.
Что это дает пользователю
Начинать стоит с текстового канала и узкого меню. Проверьте поиск позиции, модификаторы, недоступный товар, смену точки, налог, отмену и повтор доставки webhook. Только после стабильной корзины добавляйте голосовые заметки и звонки.
Для каждого заказа используйте идентификатор идемпотентности. Повтор сообщения из очереди или обрыв связи не должен создавать второй заказ. До подтверждения ассистент обязан прочитать позиции, количество, точку, время, итог и способ получения.
Память ограничьте полезными подтвержденными сведениями. Покажите клиенту, что было запомнено, и дайте команды исправить или забыть предпочтение. Платежные реквизиты, свободный текст звонка и чувствительные выводы не следует сохранять автоматически.
Измеряйте канал по доле заказов без вмешательства, ошибкам корзины, отменам после подтверждения и времени ответа отдельно для текста, заметок и звонка. Единая средняя цифра скрывает проблемы потоковой речи или распознавания названий блюд.
Что нужно учитывать
Это архитектурный пример AWS, а не готовый ресторанный продукт с поддержкой и кассовой сертификацией.
Для запуска нужны аккаунты AWS и Meta, WhatsApp Business, номера, токены и настроенные webhooks.
Качество голоса зависит от языка, шума, связи, названий меню и возможностей выбранной модели.
Команда самостоятельно отвечает за оплату, возвраты, хранение данных и передачу разговора человеку.
Коротко
Пример AWS показывает практичный мультимодальный паттерн: три интерфейса остаются разными, но используют одну память и один детерминированный контур заказов. Ценность не в том, что модель умеет разговаривать, а в правильных границах между диалогом, инструментами и учетом. Перед реальным рестораном нужно доказать идемпотентность, точность итогов, управляемость памяти и надежную передачу оператору. Иначе удобный единый номер станет единым источником ошибок. Отдельный контроль нужен для повторного webhook после уже подтвержденной корзины.