问题：如何让多个机器人为用户与聚合器机器人提供的同一个团队聊天窗口提供答案。
描述： 几个不同的团队创建了可以回答与其领域相关的问题的机器人。想象一下服务机器人，目录机器人等等。所有这些机器人都是由他们各自的区域所有者维护，拥有自己的LUIS意图集等。这很有效，但你必须知道在哪里寻找每种类型的问题
现在我们希望有一个机器人可供任何人连接，无论问题涉及哪个领域，都可以回答他们的问题。这个想法是这个聚合器机器人然后将问题转发到适当的区域机器人，然后机器人将提供答案。这里的情况是，某个问题的故障排除者可以在同一个地方提出跨越多个区域的问题，而无需了解每个区域的机器人。
机器人目前托管在团队中并且是C＃。到目前为止，我们的解决方案有这样的流程：
我们找到了bot-to-bot handoff项目，但在readme.MD中，它说：
注意：主机器人和每个子机器人共享相同的AppID和 AppPassword。这允许所有机器人共享同一个对话 ID，
Dialog Stack， 和Bot State Data。
这在Azure中是不可能的，因为您无法使用相同的AppId创建多个机器人。
基于此尝试黑客，我们发现如果我们更改机器人配置以在Azure的应用程序设置中为所有机器人使用相同的MicrosoftAppId和MicrosoftAppPassword，那么一切都可以通过聚合器机器人工作。此时，您再也无法再直接连接到各个机器人了。虽然这显然是一个黑客而不是解决方案，但它意味着问题是基于身份验证而不是隐含不可能的事情。
周围有很多东西似乎可能有所帮助，但我们还没有找到适合他们的文档。这似乎应该是一种常见的情况。理想情况下，我们可以在更高级别指定某种机器人信任，而不必直接指定AppId和AppPassword，但在这种情况下我们愿意这样做，因为我们都是同一家公司。
我们尝试过的事情：
3号实际上解决了auth问题，让聚合器机器人询问每个机器人在我们使用它来标记这些功能时回答问题的信心。在单个区域机器人的规范中为聚合器机器人指定AppId和AppPassword工作得很好。但它没有修复单个区域机器人发回聚合器机器人所拥有的对话的能力。在这种情况下，聚合器机器人本身正在消耗答案，这是一个答案，而不是流程。
我们从这里尝试什么？有没有我们错过的东西，或者我们开始使用的方法是否存在根本性的错误？