技能概述

适用于：SDK v4

可以使用“技能”机器人扩展机器人。 一项技能可供各种其他机器人使用，促进重复使用。你可以通过这种方式创建一个面向用户的机器人，使用你自己的或第三方的技能来扩展它。

• “技能”是一个机器人，它可以为另一个机器人执行一组任务；机器人可以是技能，也可以是面向用户的机器人。
• 技能使用者是可以调用一项或多项技能的机器人。 面向用户的技能使用者也称为根机器人。
• 技能清单是一个 JSON 文件，用于描述技能可以执行的操作、其输入和输出参数以及技能的终结点。
  • 无权访问技能源代码的开发人员可以使用清单中的信息来设计其技能使用者。
  • 技能清单架构是一个 JSON 文件，用于描述技能清单的架构。
  • 了解如何实现技能以及如何为示例技能清单编写技能清单。

换言之，用户直接与根机器人交互，而根机器人则将其部分聊天逻辑委托给一项技能。

技能旨在实现以下目的：

• 技能和使用者使用 Bot Framework 协议通过 HTTP 进行通信。
• 技能使用者可以使用多项技能。
• 无论用于实现技能的语言如何，技能使用者都可以使用技能。 例如，C# 机器人可以使用通过 JavaScript 实现的技能。
• 技能也可以是技能使用者，并调用其他技能。
• 技能支持用户身份验证，但用户身份验证局限于技能，不能转给其他机器人。
• 技能可同时适用于 Bot Framework 适配器和自定义适配器。

此图显示了一些可能的排列。

技能和技能使用者是独立的机器人，你单独发布它们。

• 技能使用者需要用于管理技能（例如何时调用或取消技能，等等）的新增逻辑。 除了常用的机器人和适配器对象之外，使用者还包括一些与技能相关的对象，这些对象用于与技能交换活动。 技能使用者至少实现了两个 HTTP 终结点：
  • 消息传递终结点从用户或通道接收活动。 这是所有机器人都实现的一般消息传递终结点。
  • 用于接收技能活动的技能主机终结点。 它充当一个回叫 URL，即该技能要回复的服务 URL。 （技能使用者需要将从技能接收 HTTP 方法请求的代码与技能处理程序配对。）
• 技能需要添加的逻辑，以便在完成时发送 endOfConversation 活动，使技能使用者知道何时停止向技能转发活动。

下图概述了活动流：从用户到根机器人再到技能，然后又反方向流动。

1. 根机器人的适配器接收来自用户的活动，并将其转发到根机器人的活动处理程序。 （来自用户的活动通过根机器人的消息接收终结点。）
2. 根机器人使用技能 HTTP 客户端向技能发送活动。 客户端从技能定义和技能聊天 ID 工厂获取使用者-技能聊天信息。 这包括供技能用于回复活动的服务 URL。
3. 技能的适配器接收来自技能使用者的活动，并将其转发给技能的活动处理程序。 （来自使用者的活动通过技能机器人的消息接收终结点。）
4. 当技能响应时，根机器人的技能处理程序会接收该活动。 它从技能聊天 ID 工厂获取根用户聊天信息。 然后，它将活动转发到根机器人的适配器。 （在根机器人的技能主机终结点接收来自技能的活动。）
5. 根机器人的适配器会在内部生成一条主动消息，目的是恢复与用户的聊天。
6. 根机器人的适配器会向用户发送来自技能的任何消息。

以下对象可帮助管理技能并路由技能流量：

• Bot Framework 技能描述技能的路由信息，可以从技能使用者的配置文件中读取。
• 技能 HTTP 客户端向技能发送活动。
• 技能处理程序接收来自技能的活动。
• 技能聊天 ID 工厂在用户-根聊天引用和根-技能聊天引用之间进行转换。
• Bot Connector 服务提供通道和机器人到机器人身份验证。 使用身份验证配置对象，可以将声明验证添加到技能或技能使用者，对哪些应用程序或用户可以有访问权限进行限制。

技能客户端和技能处理程序对象均使用聊天 ID 工厂在根机器人用来与用户交互的聊天和根机器人用来与技能交互的聊天之间进行转换。

“技能清单”是一个 JSON 文件，用于描述技能可以执行的操作、其输入和输出参数、技能的终结点以及技能的分派模型。

有关技能清单架构的信息，请参阅如何编写技能清单。

请务必了解此设计的某些方面，不管你设计什么机器人。

某些技能可以执行多个任务或“操作”。 例如，待办事项技能可能允许创建、更新、查看和删除可作为独立聊天访问的活动。

• 有关实现一个操作的简单技能，请参阅如何实现技能。
• 有关使用对话来实现多项操作的技能，请参阅如何在技能中使用对话。

用户-根聊天不同于根-技能聊天。

聊天 ID 工厂可帮助管理技能使用者和技能之间的流量。 工厂会在根用于用户的聊天 ID 以及根用于技能的聊天 ID 之间进行转换。 换言之，它会生成一个在根和技能之间使用的聊天 ID，并从根-技能聊天 ID 恢复原始的用户-根聊天 ID。

根和技能机器人通过 HTTP 通信。 因此，从技能接收活动的根机器人的实例可能不是发送启动活动的实例；换言之，可能由不同的服务器处理这两个请求。

• 在将活动转发给技能之前，始终在技能使用者中保存状态。 这确保从某一技能接收流量的实例可以在调用该技能之前，在上一个实例停止的位置重新开始。
• 当技能处理程序从某一技能接收活动时，它会将其转换为适用于技能使用者的形式，并将其转发到使用者的适配器。

技能使用者和技能分别管理自己的状态。 但是，使用者会创建用于与技能通信的聊天 ID。 这可能会影响技能中的聊天状态。

在 Bot Framework Emulator 中以本地方式测试技能和技能使用者不需要应用 ID 和密码。 将技能部署到 Azure 仍然需要 Azure 订阅。

服务级别身份验证由 Bot Connector 服务管理。 框架使用持有者令牌和机器人应用程序 ID 来验证每个机器人的标识。 （Bot Framework 使用身份验证配置对象来验证传入请求的身份验证标头。）

必须将声明验证程序添加到身份验证配置。 声明在身份验证标头之后进行评估。 在验证代码中引发错误或异常来拒绝请求。

拒绝已通过其他方式进行身份验证的请求可能有多种原因：

• 技能使用者应该只接受已与之启动聊天的技能的流量。
• 某个技能是付费服务的一部分，不在数据库中的用户不应有访问权限。
• 你希望只允许特定的技能使用者访问该技能。

由于技能与技能使用者之间的流量已经过身份验证，因此调试此类机器人时会执行额外的步骤。

• 技能使用者及其直接或间接使用的所有技能都必须处于运行中。
• 如果机器人在本地运行，并且任何机器人有应用 ID 和密码，则所有机器人都必须具有有效的 ID 和密码。
• 如果所有机器人都已部署，请参阅如何使用 devtunnel 从任何通道调试机器人。
• 如果某些机器人在本地运行，并且部署了一些机器人，请参阅如何调试技能或技能使用者。

或者，可以像调试其他机器人一样调试技能使用者或技能。 有关详细信息，请参阅调试机器人和使用 Bot Framework Emulator 执行调试。

从用户的角度来看，他们正在与根机器人交互。 从技能的角度来看，技能使用者是技能与用户通信的通道。

• 有关技能使用者的详细信息，请参阅关于技能使用者。