Bot Framework 中的 ID 字段

适用于： SDK v4

本指南介绍 Bot Framework 中 ID 字段的特征。

通道 ID

每个 Bot Framework 通道都由唯一 ID 标识。

示例："channelId": "slack"

通道 ID 充当其他 ID 的命名空间。 Bot Framework 协议中的运行时调用必须在通道的上下文中进行;通道为通信时使用的对话和帐户 ID 提供意义。

按照约定，所有通道 ID 都是小写的。 通道保证它们发出的通道 ID 具有一致的大小写，因此机器人可以使用序号比较来建立等效性。

通道 ID 的规则

• 通道 ID 区分大小写。

机器人句柄

向 Azure AI 机器人服务注册的每个机器人都有一个机器人句柄。

示例：FooBot

机器人句柄表示机器人通过联机 Azure AI 机器人服务注册。 此注册与 HTTP Webhook 终结点和通道注册相关联。

Azure AI 机器人服务可确保机器人句柄的唯一性。 Azure 门户执行不区分大小写的唯一性检查（这意味着机器人句柄的事例变体被视为单个句柄），尽管这是 Azure 门户的特征，但不一定是机器人处理本身。

机器人句柄的规则

• 机器人句柄在 Bot Framework 中是唯一的（不区分大小写）。

应用 ID

已注册到 Azure AI 机器人服务的每个机器人都有一个应用 ID。

注意

以前，应用通常称为“MSA 应用”或“MSA/AAD 应用”。现在，应用通常称为“应用”，但某些协议元素可能以永久的方式将应用称为“MSA 应用”。

示例："msaAppId": "00001111-aaaa-2222-bbbb-3333cccc4444"

应用表示向标识团队的应用门户注册，并充当 Bot Framework 运行时协议中的服务到服务标识机制。 应用可能具有其他非机器人关联，例如网站和移动/桌面应用程序。

每个已注册的机器人都有一个应用。 尽管机器人所有者无法独立更改与其机器人关联的应用，但 Bot Framework 团队可以在一些特殊情况下执行此操作。

机器人和通道可以使用应用 ID 来唯一标识已注册的机器人。

应用 ID 保证为 GUID。 应比较应用 ID 而不区分大小写。

应用 ID 的规则

• 应用 ID 在 Microsoft 应用平台中是唯一的（GUID 比较）。
• 每个机器人都有一个相应的应用。
• 更改与机器人关联的应用需要 Bot Framework 团队的帮助。

频道帐户

每个机器人和用户在每个通道中都有一个帐户。 该帐户包含标识符（id）和其他信息丰富的机器人非结构数据，例如可选名称。

示例："from": { "id": "john.doe@contoso.com", "name": "John Doe" }

此帐户描述可以发送和接收消息的通道中的地址。 在某些情况下，这些注册存在于单个服务（如 Facebook）中。 在其他人中，它们跨许多系统（电子邮件地址、电话号码）进行注册。 在更多匿名频道（如网上聊天）中，注册可能是临时的。

通道帐户嵌套在通道中。 例如，Facebook 帐户只是一个数字。 此数字在其他通道中可能有不同的含义，并且在所有通道之外没有意义。

通道帐户与用户（实际人员）之间的关系取决于与每个通道关联的约定。 例如，短信号码通常是指一个人，但该号码可能会转移到其他人。 相反，Facebook 帐户通常是指一个人永久，尽管两个人共享 Facebook 帐户并不罕见。

在大多数频道中，可以将频道帐户视为可以传递邮件的邮箱。 大多数通道通常允许多个地址映射到单个邮箱。 例如，“jdoe@contoso.com”和“john.doe@service.contoso.com”可能解析为同一收件箱。 某些通道会进一步，并根据机器人访问帐户的地址更改帐户地址。 例如，Facebook 会更改用户 ID，以便每个机器人都有不同的地址来发送和接收消息。

虽然在某些情况下可以在地址之间建立等效性，但在邮箱之间建立等效性，并且人员之间的等效性需要了解通道中的约定，但在许多情况下是不可能的。

机器人通过发送到机器人的活动 recipient 字段通知其通道帐户地址。

频道帐户的规则

• 频道帐户仅在其关联的通道内具有意义。
• 多个 ID 可以解析为同一帐户。
• 序号比较可用于确定两个 ID 是相同的。
• 通常没有比较可用于确定两个不同的 ID 是否解析为同一帐户、机器人或人员。
• ID、帐户、邮箱和人员之间的关联稳定性取决于通道。

对话 ID

消息在会话的上下文中发送和接收，可通过 ID 进行标识。

示例："conversation": { "id": "1234" }

会话包含消息和其他活动的交换。 每个对话都有零个或多个活动，每个活动都出现在一个对话中。 对话可能是永久性的，也可能具有不同的开始和结束。 创建、修改或结束会话的过程发生在通道内（仅在通道知道会话时存在），并且通道会建立这些进程的特征。

聊天中的活动由用户和机器人发送。 用户“参与”对话的定义因频道而异，理论上可以包括演示用户、曾经收到消息的用户、发送消息的用户。

多个通道（例如短信，可能还有其他通道）具有分配给 1：1 会话的聊天 ID 是远程通道帐户 ID 的怪癖。 此怪癖有两个副作用：

1. 对话 ID 是主观的，具体取决于谁正在查看它。 如果参与者 A 和 B 正在交谈，参与者 A 将看到对话 ID 为“B”，参与者 B 将看到对话 ID 为“A”。
2. 如果机器人在此通道中有多个通道帐户（例如，如果机器人有两个短信），则聊天 ID 不足以唯一标识机器人视野中的会话。

因此，即使对于单个机器人，会话 ID 也不一定唯一地标识通道中的单个聊天。

对话 ID 的规则

• 对话仅在其关联的通道内具有意义。
• 多个 ID 可以解析为同一对话。
• 序号相等性不一定确定两个会话 ID 是相同的对话，尽管在大多数情况下，它确实如此。

活动 ID

活动在 Bot Framework 协议中发送和接收，这些活动有时是可识别的。

示例："id": "5678"

活动 ID 是可选的，供通道使用，以便机器人在后续 API 调用中引用 ID（如果可用）：

• 回复特定活动
• 在活动级别查询参与者列表

由于尚未建立进一步的用例，因此没有其他规则用于处理活动 ID。