我在概念化 Dialogflow 代理中的“意图”和“操作”之间的关系时遇到了一些麻烦。
我了解到意图将用户的口头请求映射到我的履行服务的特定功能，并可选择携带参数作为输入变量。这就是意图的定义方式官方文档 https://dialogflow.com/docs/intents:
“意图代表用户所说内容和内容之间的映射
您的软件应该采取行动。”
那么什么是行动呢？他们的定义 https://dialogflow.com/docs/actions-and-parameters读起来几乎完全相同：
“操作对应于您的应用程序在以下情况下将采取的步骤：
特定意图已由用户的输入触发。”
操作是在意图上下文中定义的，这意味着每个意图只能有一个操作，并且一个操作不能附加到多个意图。一个操作似乎不只是它的名称，这也是完全可选的，因为无论我是否指定操作名称，意图都是相同的。
那么他们的目的是什么？为什么我的服务要对操作而不是意图做出反应？
您的问题中有一个轻微的错误陈述，但它说明了 Dialogflow 意图和操作之间的区别。该声明
一个操作不能附加到多个意图
不是真的。您可以对多个 Intent 名称使用相同的 Action 名称。在这种情况下，这意味着您可以使用 Action 作为实现中函数的映射，而无需列出代码中映射的每个 Intent。
在 Dialogflow 中，意图不仅仅匹配特定的用户短语 - 它还用于匹配处于特定状态（由设置的上下文确定）或特定非短语事件的对话。由于您可能希望将其中几个映射到后端的相同操作（例如，如果您有两个不同的传入上下文，需要与不同的用户短语匹配），因此您可以为它们设置相同的操作，但使用不同的操作用于识别它们的意图名称。
一些库，例如谷歌行动 https://github.com/actions-on-google/actions-on-google-nodejs v2 and 多声部 https://github.com/afirstenberg/multivocal让您可以使用其中任何一个，以最有意义的为准。
当我命名意图时，我通常会启动所有执行大致相同操作的意图，并使用与操作相同的名称，但添加一个后缀来指示意图为何不同。 （使用不同的上下文、事件或参数的名称。）
Update澄清一些事情
我通常使用操作名称作为触发我的函数的名称，但是在某些情况下，我仍然可以按操作对事物进行分组（因为以这种方式组织它们是有意义的），但为其中一个意图开辟了一个例外。将其视为 OO 模型中的子类化。经验法则是使用操作名称，但如果有充分的理由不这样做，则不要严格保留它。 （一个例子是使用多音，库定义了一个“未知”操作，它涵盖了被误解的输入和无输入。但是，有时我想以不同的方式处理其中一个，所以我将定义一个仅适用于意图。）
操作名称应在 Dialogflow 发送您的履行的 JSON 中可用queryResult.action。我不确定为什么文档现在忽略了这一点。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
