我正在构建具有多个意图的DialogFlow代理，其中一些变量存在冲突，并且我正在努力创建干净的对话流程-特别是围绕意图之间来回移动的区域。
例如，假设我支持向每位建立相应意图的人提供有关天气和航班的信息。考虑以下对话框：
在这一点上，除了以前保存的“今天”参数之外，我希望能有一个获得识别的飞行意图，并以“罗马”为参数。 但是，我无法确定系统是否会识别航班或天气意图，因为这句话可能会同时适用于这两种情况-取决于上下文。
我设法通过为每个对话框主题定义一个主要的和2个与上下文相关的参数意图来获得所需的行为（即，以飞行为输出上下文的飞行，以飞行为输入和输出上下文的飞行时间，以飞行为目的地的飞行目的地为输入和输出上下文，对于天气也是如此），方法是将每个上下文的生命周期设置为1，并在其他意图最终确定之后将其恢复为代码-以保留已经填充的空位，并支持诸如此类的短语作为“罗马”，并理解它们是上下文的。我还考虑过动态更改意图优先级，但不确定是否可以实现。
话虽这么说，感觉这是我应该从基础结构中直接获得的东西。我指的是类似堆栈的意图优先级，以便最后一个未实现的意图上下文具有最高优先级。你们有没有遇到过这样的问题？我是否缺少一些可以帮助我更自然地实现这种行为的关键功能？也许是一种干扰意图识别的方法？
答案 0 :(得分：0)
我认为让您的方法困扰的是，对话不一定像栈一样，并且Dialogflow模型中的“意图”没有“实现”。意图仅与用户所说的相匹配，并具有在适当的情况下根据上下文缩小范围的功能。能够设置上下文可以使您确定如何处理用户响应的方向，但是仍然需要您使用这些输入来确定用户的响应。
通常，我使用一个长期存在的Context，其参数仅保持我要保留的所有状态，从而使用户朝着他们的目标迈进。每次用户说些什么，我都可以根据寿命较短的上下文和触发的实际Intent更新该状态。我在很大程度上避免了跟进意图，因为它们最终变成了重复的老鼠巢。