8 октября 2026 г.

Автор:

Редактор:

Создание многоканального ИИ-агента с помощью Twilio и Conversations

Создание многоканального ИИ-агента с помощью Twilio Conversations и eve

Заставить ИИ-агента отвечать на SMS клиента довольно просто. Но как сделать так, чтобы он вспомнил этого клиента на следующей неделе, когда тот напишет вам по другому каналу? Именно на этом этапе большинство проектов по созданию агентов сдаются и начинают писать собственный уровень памяти.

Twilio помогает упростить этот шаг с помощью одного из инструментов, выпущенных нами ранее в этом году: Twilio Conversations. Объедините его с фреймворком eve от Vercel, и вместе они проведут четкую границу между двумя типами памяти, необходимыми агенту:

eve от Vercel: хранит кратковременную память — текущую расшифровку разговора.
Twilio Conversations: хранит долговременную память — знания о конкретном человеке (профили клиентов и автоматически извлеченные наблюдения).

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

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

Хотите сначала взглянуть на код? Полный пример проекта доступен на GitHub по ссылке IObert/twilio-conversations-eve-agent. Клонируйте его, установите зависимости, добавьте свои учетные данные и идентификаторы сервисов в файл .env, а остальная часть этой статьи послужит вам пошаговым руководством.

Что вы создадите

Представьте: клиент пишет в вашу службу поддержки, спрашивая о правилах возврата синих кроссовок, которые он заказал. Через десять дней он пишет вам в WhatsApp, уточняет детали того же заказа и задает новый вопрос.

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

Это разделение ответственности, которое вы реализуете ниже. eve хранит компактную расшифровку для текущей цепочки разговора. Memory Store от Twilio хранит извлеченные факты для всех прошлых диалогов. Динамическая инструкция объединяет эти два типа информации в начале каждой сессии.

Рисунок 1: Схема архитектуры, показывающая, как Twilio Conversations и eve от Vercel интегрируются друг с другом.

Знакомство со стеком

— это фреймворк от Vercel, ориентированный на файловую систему, для создания надежных ИИ-агентов. Вы создаете файлы, а eve компилирует их в среду выполнения, которая управляет сессиями, вызовами инструментов, потоковой передачей и сохранением состояния при сбоях и перезапусках. Проект также является открытым исходным кодом на GitHub.

Twilio Conversations — это наш набор ИИ-продуктов, выходящих за рамки традиционных коммуникационных API. В его основе лежат три компонента:

Conversation Orchestrator: надежный многоканальный ресурс для общения, который объединяет SMS, WhatsApp, RCS, чат и голосовые сообщения в одну цепочку для каждого клиента. Как разработчик, вы решаете, как обрабатывать трафик по каждому каналу и подключать ли его к двум другим подпродуктам Conversations, описанным ниже.
Memory Store: база данных профилей клиентов с характеристиками (такими как имя, телефон, предпочтения) и наблюдениями (фактами, извлеченными из прошлых разговоров).
Conversation Intelligence: запускает языковые операторы для создания сводок, анализа тональности и извлечения наблюдений из разговоров в режиме реального времени или по завершении диалога.

Ментальная модель: Orchestrator отвечает на вопрос «кто это и куда мне ответить?». Memory Store отвечает на вопрос «что я уже знаю об этом человеке?», а Intelligence записывает новые факты в Memory Store.

Предварительные требования

Перед началом вам понадобится следующее:

Node.js версии 24 или новее.
Учетная запись Twilio с Account SID и Auth Token (их можно найти в консоли Twilio).
Как минимум один номер телефона Twilio с поддержкой SMS.
WhatsApp-отправитель, привязанный к номеру телефона. Это может быть тот же номер, что вы используете для SMS, или отдельный выделенный номер. Оба варианта работают с этой настройкой.
API-ключ OpenAI или другого провайдера на ваш выбор (поддерживается любой провайдер AI SDK).
Оболочка (shell) для команд подготовки. macOS и Linux поставляются с curl. В Windows каждая команда подготовки ниже также имеет версию для PowerShell с использованием `Invoke-RestMethod`, поэтому дополнительные инструменты не требуются; если вы предпочитаете использовать версии curl, используйте WSL или Git Bash.

В Windows каждая команда подготовки ниже также имеет версию для PowerShell с использованием `Invoke-RestMethod`, поэтому дополнительные инструменты не требуются; если вы предпочитаете использовать версии curl, используйте WSL или Git Bash.

ngrok или аналогичный инструмент для локального туннелирования вебхуков. ngrok — это инструмент, который предоставляет общедоступный HTTPS-URL, перенаправляющий запросы на порт вашего ноутбука, чтобы Twilio мог связаться с вашим вебхуком во время разработки.

Инициализация проекта

Давайте инициализируем новый проект и установим все необходимые пакеты. В терминале выполните следующую команду:

Скопировать код

Вас могут попросить «установить следующие пакеты» и указать ссылку на последнюю версию eve. Можно нажать «y», чтобы установить eve.

Пакет twilio npm понадобится позже для проверки подписей вебхуков Orchestrator. @ai-sdk/openai — это провайдер AI SDK, через который вы подключите модель.

eve init создает каркас проекта со всем необходимым для агента «hello-world»:

Скопировать код

Для этого руководства файл instructions.md по умолчанию вполне подходит.

Вы можете расширять инструкции дополнительными слотами по мере необходимости:

agent/tools/, типизированные действия, которые может вызывать модель.
agent/skills/, процедуры по требованию, которые может использовать модель.
agent/instructions/, дополнительные или динамические инструкции.
agent/channels/, входящие точки входа.

Мастер уже создал agent/channels/eve.ts, который предоставляет локальный CLI-канал: запустите pnpm dev, и вы получите интерактивный терминал для общения с агентом без обращения к внешним сервисам. Ваш канал Twilio будет находиться в этой же папке.

Настройка модели

Теперь давайте настроим файл agent/agent.ts. Откройте его в редакторе, и вы увидите следующее содержимое:

Скопировать код

Чтобы использовать другого провайдера, установите его пакет AI SDK и замените модель там, где она упоминается в файле.

Примечание для организаций с политикой Zero Data Retention: если в вашей организации OpenAI включена политика Zero Data Retention, вызов API Responses по умолчанию завершится ошибкой "Items are not persisted for Zero Data Retention organizations". Добавьте modelOptions: { providerOptions: { openai: { store: false } } } в конфигурацию, и все заработает.

Настройка переменных окружения

Создайте файл .env в корне проекта. Комментарии ниже подскажут, откуда берется каждое значение, чтобы вы могли заполнить верхний блок перед переходом к следующему шагу.

Скопировать код

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

Запустите ngrok перед подготовкой

Вам нужен общедоступный HTTPS-URL перед созданием конфигурации Orchestrator, поскольку этот вызов curl регистрирует URL вебхука, к которому будет обращаться Twilio. Если вы используете бесплатную учетную запись ngrok, при каждом запуске она будет получать новое случайное имя хоста. Запустите туннель сейчас и вставьте URL в файл .env как PUBLIC_BASE_URL:

Скопировать код

Скопируйте имя хоста https://…ngrok… из вывода ngrok и установите его в файле .env как PUBLIC_BASE_URL.

После сохранения файла на диске загрузите каждую переменную в текущую оболочку (shell), чтобы curl и pnpm dev видели одни и те же значения:

Скопировать код

Подготовка стороны Twilio

Memory Store и конфигурация Orchestrator настраиваются один раз. Оба являются ресурсами REST.

Если вы используете PowerShell, создайте заголовок basic-auth один раз и используйте его повторно для всех четырех вызовов ниже.

Скопировать код

Создание Memory Store

Теперь давайте создадим Memory Store. В терминале используйте следующие команды:

Скопировать код

В ответ придет код 202 с параметром statusUrl, который выглядит как https://memory.twilio.com/v1/ControlPlane/Operations/mem_configop_XXXXXXXX. Это способ Twilio сказать: «Я принял задачу, проверьте этот URL, когда будете готовы». Подтвердите выполнение с помощью простого «GET» по адресу statusUrl из вашего собственного ответа (замените op_... id на заполнитель ниже):

Скопировать код

Найдите "status": "COMPLETED" и идентификатор mem_store_... в теле ответа. Скопируйте этот идентификатор в файл .env как MEMORY_STORE_ID, затем перезагрузите оболочку:

Скопировать код

Создание конфигурации Orchestrator с помощью GROUP_BY_PROFILE

Теперь все значения, необходимые для ваших запросов, находятся в вашей среде. Используйте heredoc, чтобы Bash подставил переменные внутри строки. В PowerShell нет heredoc, но его расширяемая here-строка (@" ... "@) выполняет ту же задачу; обратите внимание, что закрывающая "@ должна находиться в самом начале своей строки.

Скопировать код

Стоит выделить две настройки:

conversationGroupingType: GROUP_BY_PROFILE объединяет одного и того же клиента по разным каналам в одну беседу, ориентируясь на профиль Memory Store, а не на адрес, который использует клиент. Значение по умолчанию, GROUP_BY_PARTICIPANT_ADDRESSES_AND_CHANNEL_TYPE, разделяет SMS и WhatsApp на разные беседы. GROUP_BY_PARTICIPANT_ADDRESSES группирует каналы вместе, но только если клиент использует один и тот же адрес для каждого из них. Это означает, что если клиент отправляет SMS с одного номера, а сообщение WhatsApp с другого, эти каналы не будут сгруппированы. GROUP_BY_PROFILE — это то, что Twilio рекомендует для промышленной эксплуатации.
memoryExtractionEnabled: true включает интеллектуальный конвейер, который записывает наблюдения обратно в Memory Store при закрытии беседы.

Примечание: не настраивайте вебхук на номере телефона или отправителе WhatsApp. Правила captureRules, указанные выше, отвечают за получение трафика, а единственный URL statusCallbacks — это место, куда Orchestrator доставляет его.

Вот что дает вам GROUP_BY_PROFILE, когда все нижеперечисленное настроено:

Рисунок 2: Одна непрерывная беседа, которая началась слева через SMS и продолжается справа через WhatsApp

Обратите внимание, что сообщение WhatsApp не содержало информации о продукте, заказе или каких-либо напоминаний о предыдущей беседе. Этот контекст был получен из профиля Memory Store, в который Conversation Orchestrator объединил оба канала.

Этот вызов также возвращает 202 с параметром statusUrl. Вы можете подтвердить вызов таким же образом, подставив свой собственный op_... id:

Скопировать код

Как только в ответе появится "status": "COMPLETED", скопируйте идентификатор conv_configuration_... в файл .env как ORCHESTRATOR_CONFIG_ID.

Первая попытка: встроенный адаптер Twilio для eve

Прежде чем писать что-то свое, попробуйте встроенный адаптер Twilio для eve:

Скопировать код

Направьте вебхук входящих сообщений вашего номера телефона Twilio на $PUBLIC_BASE_URL/eve/v1/twilio/messages, запустите pnpm dev и отправьте SMS на свой номер. Потрясающе, вы создали работающего SMS-агента всего за несколько строк кода!

Рисунок 3: Зеленый исходящий пузырек с текстом "Hi 👋 This is a test"; серый ответ под ним повторяет сообщение

Если вы создали этот файл, удалите его перед переходом к следующим шагам. Очистите входящий вебхук, который вы только что установили на номере телефона, и удалите файл agent/channels/twilio.ts. Настройка Orchestrator получает трафик через правила захвата (capture rules), и если вебхук для конкретного номера все еще указывает на встроенный адаптер, оба пути будут срабатывать при каждом входящем сообщении, и ваш клиент получит два ответа.

Адаптер Twilio для Eve — это хорошо организованный кластер из восьми модулей TypeScript в packages/eve/src/public/channels/twilio, которые обрабатывают:

Проверку подписи вебхука по схеме HMAC от Twilio
Разбор тела запроса в формате form-encoded (SMS, метаданные MMS, обратные вызовы транскрипции голоса)
Создание токенов продолжения, чтобы вызывающий абонент сохранял одну и ту же сессию между сообщениями
Вспомогательную функцию sendMessage, которая определяет отправителя и получателя ответа из входящего сообщения
Поддержку голоса через <Gather> и обратные вызовы статуса
Стандартные обработчики для message.completed и turn.failed, чтобы вы получали работающий ответ «из коробки»

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

Создание канала с поддержкой Orchestrator

Вебхук Twilio Messaging API срабатывает для каждого входящего сообщения, и вы можете получить детали из его собственного payload в формате form-encoded. Conversation Orchestrator находится на уровень выше, где вы подписываетесь на события самой конфигурации Orchestrator, и каждое сообщение (входящее или исходящее) и дополнительные типы событий поступают на единый JSON-вебхук, сгруппированный по conversationId.

Это другой формат вебхука, нежели тот, который обрабатывает встроенный адаптер eve. Поэтому давайте напишем адаптер для обработки JSON-payload.

Импорты и настройка

Создайте agent/channels/twilio-orchestrator.ts со следующими разделами:

Скопировать код

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

AGENT_ADDRESSES — это фильтр эха, создаваемый один раз при запуске (подробнее об этом ниже).
! в process.env.PUBLIC_BASE_URL — это обещание для TypeScript, что переменная установлена. Если вы забудете ее заполнить, проверка подписи будет сравниваться с undefined/eve/... В рабочей среде замените ! на реальную проверку при запуске, которая вызывает ошибку.
Два типа и вспомогательная функция withChannel объявлены здесь, чтобы остальная часть файла могла свободно ссылаться на них. Читайте дальше, чтобы увидеть, где используется каждый компонент.

Проверка вебхука

Стандартный verifyTwilioRequest в eve/channels/twilio реализует схему HMAC-over-form-params от Twilio. Это схема, которую использует каждый классический вебхук Twilio Messaging или Voice. Однако вебхуки Orchestrator отличаются.

Для Conversation Orchestrator тело запроса — это JSON, а не form-encoded. Twilio добавляет параметр запроса bodySHA256 и подписывает URL на основе необработанных байтов тела. Таким образом, вам нужно открыть определение канала и его первый маршрут:

Скопировать код

Функция validateRequestWithBody в Node SDK от Twilio считывает необработанное тело запроса один раз, проверяет его, а затем выполняет парсинг. Функция toPublicUrl восстанавливает URL, который фактически вызвал Twilio (используя PUBLIC_BASE_URL).

Парсинг и фильтрация эхо-сообщений

Orchestrator отправляет множество типов событий (CONVERSATION_CREATED, PARTICIPANT_ADDED, COMMUNICATION_CREATED и т. д.).

Два из них наиболее важны для нас:

PARTICIPANT_ADDED: срабатывает, когда клиент присоединяется к беседе (Conversation). Это хук, который используется для связывания их идентификаторов по разным каналам (подробнее об этом ниже).
COMMUNICATION_CREATED: содержит тело сообщения.

Правила захвата являются двунаправленными. Когда ваш агент отправляет ответ, Orchestrator также захватывает это сообщение и доставляет новое событие COMMUNICATION_CREATED на ваш вебхук.

Без фильтра агент будет отвечать на свой собственный ответ бесконечно. (Не спрашивайте, откуда я это знаю!)

Именно для этого нужен AGENT_ADDRESSES — это статический набор, созданный при запуске: единственные адреса, с которых вы когда-либо отправляете сообщения, — это два отправителя, уже указанные в файле .env.

TWILIO_WHATSAPP_NUMBER содержит префикс whatsapp:, так как он необходим для исходящих сообщений, но вебхук не всегда сообщает автора в таком же виде. Нормализация до чистого номера и хранение обоих вариантов написания означает, что фильтр сработает в любом случае.

Скопировать код

Twilio Memory идентифицирует клиентов по признакам: SMS, Voice, RCS и MMS ищутся по номеру телефона, а WhatsApp — по идентификатору whatsapp.

Один и тот же человек в обоих каналах создал бы два профиля (и попал бы в две разные беседы!), если бы вы не выполнили гидратацию идентификатора связанного канала в тот самый момент, когда создается первый профиль. Именно это делает функция linkCrossChannelIdentity.

Отправка хода беседы

Используйте auth.attributes, а не state, для канала ответа, так как состояние eve является постоянным. Оно устанавливается один раз при создании сессии и используется повторно без изменений на каждом последующем шаге. Атрибуты auth.attributes обновляются при каждой отправке, поэтому, если вы поместите туда канал и адреса, eve ответит по тому же каналу, который только что использовал клиент.

Применение к вашей отправке:

Скопировать код

Обратите внимание: в параметрах отправки нет состояния (state). Все, что нужно для ответа, находится в auth.attributes, которые обновляются на каждом шаге.

participantId берется из Twilio Conversations: это идентификатор Orchestrator для одного участника в рамках одной беседы. principalId берется из eve — это тег актора на уровне приложения, который eve хранит в сессии, чтобы ваш код мог различать вызывающих абонентов.

participantId ограничен рамками беседы в Twilio Memory, что соответствует области действия сессии eve. Долгосрочная идентификация — это задача Memory Store, и в следующем разделе мы правильно ее реализуем.

Чтение auth.attributes на стороне ответа

Функция context в defineChannel вызывается каждый раз, когда обработчику событий нужно связаться с каналом. Именно там вы считываете свежую информацию о маршрутизации:

Скопировать код

withChannel повторно добавляет префикс whatsapp:, когда канал — WhatsApp, а адрес его еще не имеет. Twilio требует этого для исходящих сообщений, чтобы обеспечить правильную маршрутизацию.

Привязка событий к отправке

Наконец, нам нужно сказать eve, что когда модель завершает ход, вы хотите, чтобы готовое сообщение было направлено через sendMessage:

Скопировать код

И это все! Канал получает вебхуки Orchestrator, фильтрует эхо-сообщения, передает ходы в eve и направляет ответы обратно по правильному каналу.

Обогащение промптов с помощью Memory Store

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

Вспомогательный инструмент Memory Store

Создайте новый файл agent/lib/memory.ts:

Скопировать код

Вы используете базовую аутентификацию для REST API Memory Store, небольшую вспомогательную функцию для причуды с префиксом whatsapp:, linkCrossChannelIdentity для POST-запроса связывания идентификаторов, который вы видели в канале, и Promise.all, чтобы профиль и его наблюдения возвращались параллельно. Ограничения pageSize=20 достаточно для такого руководства.

Динамическая инструкция

Теперь мы вернулись в папку agent/instructions/, как и раньше.

Файл instructions.md содержит ваш базовый промпт, написанный вручную, а файлы в папке instructions/* дополняют его во время выполнения. Динамические инструкции eve позволяют внедрять текст в системный промпт при session.started или turn.started — здесь мы будем использовать session.started.

Создайте файл instructions/customer-context.ts прямо сейчас.

Скопировать код

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

Скопировать код

Теги <customer_context> — это формат, который я выбрал, чтобы помочь модели понять, что именно мы внедряем.

Twilio Intelligence автоматически извлекла эти наблюдения в конце предыдущей беседы. И самое лучшее? Вы не написали ни одной строки кода для извлечения.

При самом первом сообщении от нового клиента поиск в Memory Store через defineDynamic возвращает null, поэтому модель видит только ваш базовый файл instructions.md. Twilio заполняет профиль после завершения первой беседы с клиентом, поэтому блок <customer_context> выше появляется в начале следующей беседы с этим клиентом.

Запуск

Запустите агента в новом терминале (оставьте ngrok запущенным):

Скопировать код

Вы должны увидеть что-то вроде этого (хотя ваша версия eve, скорее всего, будет отличаться):

Скопировать код

Отправьте SMS на ваш номер Twilio с какой-нибудь информацией, чтобы у Intelligence был материал для извлечения в будущем. Что-то вроде этого:

"Привет, я заказал синие кроссовки для бега на прошлой неделе. Какая у вас политика возврата?"

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

Теперь отправьте последующее сообщение через WhatsApp с того же телефона и намеренно опустите детали:

"На самом деле, могу ли я все еще их вернуть?"

"Их" — это и есть проверка: вы намеренно ничего не раскрываете во втором сообщении и используете другой канал. Вы должны получить ответ в WhatsApp, и eve воспримет это как ту же самую сессию, потому что Orchestrator сгруппировал оба канала в одну беседу. Когда беседа закрывается (по тайм-ауту неактивности Orchestrator или явно через PATCH со статусом CLOSED), Conversation Intelligence извлекает наблюдения из транскрипта и записывает их в профиль Memory Store. Из двух сообщений выше это будут: "Спрашивал о политике возврата синих кроссовок для бега" и "Заказал синие кроссовки для бега". А в следующий раз, когда этот клиент напишет вам через дни, недели или месяцы? Эти наблюдения снова появятся в промпте на первом же шаге.

Если ничего не происходит, не паникуйте. Попробуйте следующее: откройте инспектор ngrok по адресу http://127.0.0.1:4040 и найдите POST-запрос к /eve/v1/twilio-orchestrator/webhook. Если это 401, значит, проверка подписи не удалась (обычно потому, что PUBLIC_BASE_URL не совпадает с хостом ngrok, который фактически вызвал Twilio). Если это 200, но ответа нет, следите за терминалом pnpm dev, чтобы увидеть вызов модели.

Заглянем внутрь Memory Store

Круто, правда? Но прежде чем радоваться, давайте посмотрим на память, которую Twilio создал для вас.

Откройте консоль Twilio, нажмите «Conversation Memory» в разделе Orchestration, выберите хранилище, которое вы подготовили (то, чей id находится в MEMORY_STORE_ID), и нажмите на профиль, который был создан, когда ваш номер телефона впервые написал агенту.

Профиль разделен на четыре вкладки:

Traits содержит структурированные поля (имя, телефон, идентификаторы каналов).
Identifiers содержит список адресов, сгруппированных Orchestrator.
Summaries содержит краткие сводки по каждой беседе.
Observations — это факты, которые Intelligence извлекла из расшифровки и связала с беседой, в которой они были получены.

Рисунок 4: Страница профиля Memory Store в консоли Twilio, отображающая все текущие наблюдения.

Это также место для проверки того, что именно Intelligence извлекла (или не извлекла). Если наблюдение выглядит неверно, вы можете удалить его из консоли.

Обратите внимание, что тайм-ауты Twilio для каждой беседы обычно измеряются минутами или часами (поля statusTimeouts.inactive и statusTimeouts.closed в вашей конфигурации Orchestrator), в то время как время жизни сессии eve по умолчанию составляет 30 дней (limits.sessionTimeoutMs). Когда беседа в Orchestrator закрывается, следующее сообщение клиента поступает с новым conversationId, что означает новую сессию eve и свежую расшифровку. Это желаемое поведение. В таких случаях долгосрочная память перемещается в Memory Store Twilio. Если вы хотите, чтобы кратковременная память сохранялась дольше, увеличьте тайм-аут закрытия Orchestrator, чтобы обе системы были согласованы в том, когда беседа действительно завершена.

Что делать дальше

Если вы хотите развивать проект дальше, вы можете сделать несколько вещей, имея уже работающую базу для SMS и WhatsApp:

Добавьте голосовую связь. Twilio Conversation Relay подключается к той же конфигурации Orchestrator, поэтому один и тот же агент может отвечать на телефонные звонки, используя ту же сессию и память.
Отправляйте более содержательные ответы. Каждое сообщение, которое ваш агент отправляет сегодня, — это обычный текст. Если вы хотите использовать изображения, кнопки или списки в ответе, определите шаблон контента (Content Template) один раз и предоставьте модели инструмент, который ссылается на SID шаблона для заполнения переменных. Обзор типов контента содержит полный список того, что вы можете отправлять: twilio/media для изображений, twilio/quick-reply для кнопок, twilio/list-picker для списков с возможностью выбора и многое другое.

Подводя итоги работы с eve и Twilio Conversations

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

Вы объединили хорошо настроенную конфигурацию Orchestrator, Memory Store с автоматическим извлечением наблюдений и модель сессий eve в единый конвейер, создав агента, который легко масштабируется на голосовую связь, RCS и любой другой канал, поддерживаемый Orchestrator, помнит клиентов между сессиями без какого-либо специального кода для хранения данных и остается гибким на уровне модели.

Теперь ваша очередь развивать это. Создайте решение, которое понравится всем нам, и поделитесь им в нашем сабреддите — нам не терпится увидеть, что вы создадите.