本文档介绍使用 Dialogflow CX 的基础知识。 它简要介绍最重要的概念。
代理
Dialogflow CX 代理是负责与最终用户同时对话的虚拟客服。它是一种自然语言理解模块，能够理解人类语言的细微差别。Dialogflow 可以在对话过程中将最终用户输入的文字和音频转换为应用和服务可以理解的结构化数据。您可以设计并构建 Dialogflow 代理来负责您的系统所需的各种对话。
Dialogflow 代理类似于人类呼叫中心代理。 二者都需要经过训练，以处理预期的对话场景，并且内容不必过于明确。
流
复杂的对话框通常涉及多个对话主题。例如，披萨外卖代理可能具有“食品订单”、“客户信息”和“确认”作为不同的主题。每个主题都需要多轮对话才能让代理获取最终用户的相关信息。
流用于定义这些主题和关联的对话路径。每个代理都有一个名为默认初始流的流。对于简单的代理，您可能只需要这一个流。较复杂的代理可能需要更多的流，不同的开发团队成员可以负责构建和维护这些流。例如，披萨外卖代理的流可能如下所示：
Dialogflow CX 流与 Dialogflow ES 超级代理的子代理类似。流可以更好地控制对话，而不会产生额外费用。
页面
Dialogflow CX 对话（会话）可以描述并直观呈现为状态机。CX 会话的状态由页面表示。
您可以为每个流定义多个页面，其中组合页面可以处理该流所针对的主题的完整对话。在任何给定时刻，只有一个页面是“当前页面”，当前页面被视为活跃页面，与该页面关联的流被视为活跃流。每个流都有一个特殊的初始页面。当流最初处于活跃状态时，初始页面将变为当前页面。每轮对话期间，当前页面要么保持不变，要么转换到其他页面。
您可以将每个页面配置为从最终用户处收集与该页面所表示的对话状态相关的信息。 例如，您可以在下图中为披萨外卖代理的食品订单流创建页面（蓝色）。图的“初始”节点表示“食品订单”流的初始页。流完成后，它将转换为“确认”流。
实体类型
实体类型用于控制最终用户输入数据的提取方式。CX 实体类型与 ES 实体类型非常相似。Dialogflow 提供预定义的系统实体，这些系统实体可以匹配许多常见数据类型。例如，有用于匹配日期、时间、颜色、电子邮件地址等类型的系统实体。您还可以自行创建自定义实体来匹配自定义数据。例如，您可以定义一个 vegetable 实体，来匹配杂货店代理出售的蔬菜类型。
参数
参数用于捕获和引用最终用户在会话期间提供的值。每个参数都有一个名称和一个实体类型。与原始的最终用户输入不同，参数是结构化数据，可以轻松用于执行某些逻辑或生成响应。CX 参数与 ES 参数类似，但实用性和范围已扩展，并且引用参数的语法已更改。
表单
您需要为每个页面定义一个表单，该表单上列出应从该页面的最终用户处收集的参数。代理会与最终用户进行多轮对话，直到收集到所有表单参数（也称为“页面参数”）。代理会按照页面上定义的顺序收集这些参数。您还需要针对每个所需表单参数提供“提示”，供代理用于向最终用户询问该信息。此过程称为“表单填充”。
举例来说，您可以创建一个表单，用于为 Collect Customer Info 页面收集最终用户的姓名和电话号码。
CX 表单填充与 ES 槽位填充类似。
意图
“意图”用于对一轮对话中的最终用户意图进行分类。 与 ES 意图相比，CX 意图已经过简化，使其成为更可重复使用的资源。
意图包含以下数据：
| 术语 | 定义 |
|---|---|
| 显示名称 | 控制台上显示的 intent 名称。 |
| 标签 | 有助于对 intent 进行分类的标签。例如：head intent。 |
| 训练短语 | 训练短语是最终用户可能输入或说出的示例短语，称为最终用户输入。如果最终用户输入与这些短语中的其中一个相似，Dialogflow 便会将其与该意图匹配。您无需定义所有可能的示例，因为 Dialogflow 的内置机器学习功能可使用其他相似的短语扩展您的列表。 |
| 参数 | 您可以定义训练短语，以使用参数从最终用户输入的特定部分提取值。 |
| DTMF 模式 | 请参阅适用于电话集成的 DTMF。 |
Webhook
网络钩子是托管业务逻辑或调用其他服务的服务。在会话期间，借助网络钩子，开发者可以使用通过 Dialogflow 的自然语言处理提取的数据来生成动态响应、验证收集的数据或在后端触发操作。webhook 可以是标准 webhook，也可以是灵活 webhook。 使用标准网络钩子时，请求和响应字段由 Dialogflow 定义。借助灵活的 webhook，您可以定义请求和响应字段。
Fulfillment
每轮对话过程中，代理必须通过回答问题，询问信息或终止会话来响应最终用户。您的代理可能还需要与您的服务联系，以生成动态响应或执行操作。Fulfillment 用于完成所有这些操作。
fulfillment 可能包含以下任一选项：
- 静态响应消息。
- 用于动态响应和/或执行操作的网络钩子调用。
- 用于设置或替换参数值的参数预设。
在代理每轮对话期间，系统可以（且有时需要）调用多个 fulfillment，每个 fulfillment 都可以生成响应消息。Dialogflow 会在响应队列中维护这些响应。 代理的每轮对话结束后，Dialogflow 会将已排序的响应发送给最终用户。
ES fulfillment 仅限于连接 webhook 服务。 CX 的 fulfillment 范围扩大了，因此现在涵盖了所有类型的提示和响应。
状态处理程序
状态处理程序（简称“处理程序”）用于通过为最终用户创建响应和/或转换当前页面来控制对话。对于每轮对话，系统都会评估处理程序，而处理程序可能会影响会话。处理程序包含三种常规类型的数据：| 术语 | 定义 |
|---|---|
| 处理程序要求 | 必须满足这些要求，才能使处理程序对会话产生影响。如果处理程序满足其要求并以某种方式影响会话，才可以说“已调用”处理程序。 |
| 处理程序 fulfillment | 如果调用处理程序，则使用可选的 fulfillment 为最终用户创建响应。这些响应可以在静态代理数据中定义，也可以从网络钩子服务中动态检索。 |
| 处理程序转换目标 | 如果调用了处理程序，则使用可选的转换目标来更改当前页面。下一页只能是流初始页面或当前活跃流中的页面。 |
状态处理程序的类型有以下两种，而且处理程序要求也不同：
| 术语 | 定义 |
|---|---|
| 路线 | 当最终用户输入匹配某个意图和/或会话状态的某个条件得以满足时，系统将调用路由。具有意图要求的路由也称为意图路由。 仅具有条件要求的路由也称为条件路由。 |
| 事件处理程序 | 事件处理程序在调用事件时调用。在收到意外的最终用户输入或发生网络钩子错误时，系统会触发一些内置事件。您还可以定义在对话之外发生什么情况时调用的自定义事件。 |
处理状态处理程序共需三个步骤：
| 术语 | 定义 |
|---|---|
| 1.范围 | 处理程序必须在范围内才能对会话产生影响。范围取决于处理程序是应用于流、页面还是表单参数，也取决于关联的流是否处于活跃状态、关联的页面是否处于活跃状态，或者代理当前是否正在尝试填充关联的表单参数。 |
| 2. 评估版 | 范围内的每个处理程序都会被按顺序评估。如果处理程序的要求得到满足，则其通过了评估。 |
| 3. 通话 | 如果处理程序在范围内，并且通过了评估，则系统将调用它。系统会调用所有关联的 fulfillment，并且任何关联的转换目标都将应用到会话。 |
区域化和位置设置
创建代理时，您必须指定区域作为代理的位置。发送到代理的请求由该区域中的 Google 服务处理，Dialogflow 在地理区域或位置内物理保存静态数据。为了获得最佳性能，您应该选择靠近您的服务和最终用户的区域。
代理创建后，其位置便无法更改。如需更改代理的位置，您必须在另一个位置导出和恢复为新代理。
每个位置都有关联的设置，这些设置应用于整个项目。在大多数情况下，您无需修改这些位置设置，默认设置即可运行良好。如果您的系统需要客户管理的加密密钥（通常政府机构或受监管的行业有此要求），请详细了解位置设置。
控制台
Dialogflow 提供了一个网页界面，称为 Dialogflow CX 控制台（访问文档，打开控制台）。您可以使用此控制台创建、构建和测试 CX 代理。CX 控制台与 ES 控制台的用途相似，但 CX 控制台界面更直观。它将每个流显示为对话状态机图，使复杂代理更易于设计和理解。
Dialogflow CX 控制台与 Google Cloud Platform (GCP) Console 不同（查看文档，打开控制台）。Dialogflow CX 控制台用于管理 Dialogflow CX 代理，而 GCP Console 用于管理 GCP 专有的 Dialogflow CX 设置（例如结算）和其他 GCP 资源。
在大多数情况下，您应该使用 Dialogflow CX Console 来构建代理，但您还可以使用 Dialogflow CX API 构建适用于高级场景的代理。
集成
Dialogflow CX 目前为其他对话平台提供了多项内置集成。这些集成会为最终用户提供界面，并且会为您调用 Dialogflow API。您只需构建代理并选择性地实现网络钩子服务即可。每项集成服务均以平台特定的方式处理互动。如需了解详情，请参阅具体的集成文档。
互动次数
对于每个对话回合，均会发生互动。在互动期间，最终用户向 Dialogflow 发送输入，而 Dialogflow 发送响应。实现系统以处理互动时，您可从两个选项中选择：使用 API 或使用集成。
使用 API 时，您的系统需要处理以下操作：
- 构建代理。
- 为最终用户提供界面。
- 为每轮会话调用 Dialogflow API，以向 API 发送最终用户输入。
- 除非您的代理响应是完全静态的（不常见），否则您需要托管网络钩子服务，才能处理启用了网络钩子的 fulfillment。
使用集成时，您的系统只需要处理以下操作：
- 构建代理。
- （可选）实现网络钩子服务。
下图显示了在会话的一轮对话中执行的步骤。
- 最终用户输入或说出某些内容（称为“最终用户输入”）。
- 您的界面或集成系统会收到输入，并在检测意图请求中将其转发到 Dialogflow API。
- Dialogflow API 会接收检测意图请求。它会将输入与意图或表单参数相匹配，根据需要设置参数，并更新会话状态。如果 Dialogflow API 需要调用启用了网络钩子的 fulfillment，它会向网络钩子服务发送网络钩子请求，否则将转到第 6 步。
- 您的网络钩子服务会收到网络钩子请求。您的服务会执行所有必要的操作，例如调用外部 API、查询或更新数据库等。
- 您的网络钩子服务构建一个响应，并将网络钩子响应发送回 Dialogflow。
- Dialogflow 会创建一个检测意图响应。如果调用了网络钩子，它将使用网络钩子响应中提供的响应。如果未调用网络钩子，则它将使用代理中定义的静态响应。Dialogflow 会向您的界面或集成系统发送检测意图响应。
- 您的界面或集成系统会收到检测意图响应，并将文本或音频响应转发给最终用户。
- 最终用户看到或听到响应。