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