我在Dialogflow代理中概念化“意图”和“动作”之间的关系时遇到了一些麻烦 .
我得到的意图将用户口头请求映射到我的履行服务的特定功能，可选地将参数作为输入变量 . 这是在official documentation中定义意图的方式：
“意图表示用户所说的内容与软件应采取的操作之间的映射 . ”
但那么行动呢？ Their definition几乎完全相同：
“操作对应于当用户输入触发特定意图时应用程序将执行的步骤 . ”
动作是在意图的上下文中定义的，这意味着每个意图只能有一个动作，并且动作不能附加到多个意图 . 一个动作似乎不仅仅是它的名字，这也是完全可选的，因为意图与我指定动作名称的工作方式相同 .
那他们的目的是什么？为什么我的服务会对操作做出反应而不是意图？
1 回答
您在问题中有一个轻微的错误陈述，但它说明了Dialogflow Intent和Action之间的区别 . 该声明
不是真的 . 您可以为多个Intent名称使用相同的Action名称 . 在这种情况下，这意味着您可以将Action用作实现中函数的映射，而无需列出代码中映射的每个Intent .
在Dialogflow中，Intent不仅仅匹配特定的用户短语 - 它还用于匹配特定状态的对话（由设置的上下文确定）或特定的非短语事件 . 由于您可能希望将其中的一些映射到后端的相同操作（例如，如果您有两个不同的传入上下文，您需要与不同的用户短语匹配），您可以为它们设置相同的操作但使用不同的操作用于识别它们的意图名称 .
某些库，例如actions-on-google v2和multivocal允许您使用哪一个，无论哪个最有意义 .
当我命名Intents时，我通常会将它们全部启动，它们使用与我用于Action的相同名称大致相同的东西，但添加一个后缀，指示为什么Intents不同 . （使用上下文，事件或不同参数的名称 . ）
Update 澄清了一些事情
我通常使用Action名称作为触发我的函数的名称，但是在某些情况下我仍然可以按行动对事物进行分组（因为以这种方式组织它们是有意义的），但是为其中一个Intents创建了一个例外 . 可以将其视为OO模型中的子类 . 经验法则是使用动作名称，但如果有充分的理由不这样做，则不要严格控制 . （这个例子的一个例子就是使用multiocal，这个库定义了一个“未知”的Action，它涵盖了被误解的输入和没有输入 . 有时我想以不同的方式处理其中一个，所以我将定义一个仅适用于意图 . ）
Action语言名称应该在Dialogflow在
queryResult.action中发送您的履行的JSON中可用 . 我不确定文档为何暂时省略了这一点 .