Обмен тем же разговором с несколькими ботами - PullRequest
0 голосов
/ 05 мая 2018

Вопрос: Как сделать, чтобы несколько ботов предоставляли ответы на одно и то же окно чата Команд, которое есть у пользователя с ботом-агрегатором.

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

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

Боты в настоящее время размещены в командах и являются C #. Пока наше решение имеет такой поток:

  1. Бот-агрегатор получает вопрос и спрашивает каждого бота (через другую конечную точку, специфичную для этого потока), насколько он уверен, что может ответить на вопрос.
  2. Агрегатор-бот решает, каким ботам задать вопрос, и отправляет вопрос в обычную конечную точку / api / messages для бота.
  3. [Сломан] Зональный бот при необходимости выдает ответ / запрос аутентификации / или начало разговора для уточнения возможного ответа.

Мы нашли проект передача сообщений между ботами , но в файле readme.MD написано:

Примечание: основной бот и каждый из суб-ботов имеют один и тот же AppID и AppPassword. Это позволяет всем ботам вести один и тот же разговор. ID, Dialog Stack, и Bot State Данные .

Это невозможно в Azure, поскольку вы не можете создать несколько ботов с одним и тем же идентификатором приложения.

Попробовав взлом на основе этого, мы обнаружили, что если мы изменим конфигурацию бота, чтобы использовать один и тот же MicrosoftAppId и MicrosoftAppPassword в настройках приложения в Azure для всех ботов, то через бот-агрегатора все будет работать нормально. В этот момент вы больше не можете напрямую подключаться к отдельным ботам. Хотя это явно хак, а не решение, оно подразумевает, что проблема основана на аутентификации, а не на чем-то невозможном.

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

Вещи, которые мы пробовали:

  1. Использование TrustServiceUrl для доверия боту-агрегатору из каждой области бот, и все боты области от бота агрегатора. Звонок был сделано в Application_Start в Global.asax для каждого бота.
  2. Взлом, описанный выше
  3. Указание AppId и AppPassword в атрибуте BotAuthentication

Номер 3 фактически решил проблему аутентификации, позволив боту-агрегатору спрашивать каждого бота на его уверенность в ответе на вопрос, когда мы использовали его для обозначения этих функций. Определение AppId и AppPassword для бота-агрегатора в спецификации для этой конечной точки в отдельных ботах области работало отлично. Но это не исправило возможность для отдельного бота области возвращаться к разговору, принадлежащему боту-агрегатору. В этом случае сам агрегатор-бот потребляет ответ, и это ответ, а не поток.

Что мы попробуем отсюда? Есть ли что-то, что мы упустили, или есть что-то принципиально неправильное в подходе, с которого мы начали?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...