【机器人程序】如何将现有机器人程序集成到Microsoft Teams中-优点和缺点

我想分享我支持企业向Microsoft Teams公开现有机器人程序的常见请求的经验。有几种方法可以实现这一点，有优点也有缺点，本文旨在引导您了解这些不同的选项，并帮助您确定最适合您需求的解决方案。这不是一个详尽的比较指南，所以如果你看到决策标准缺失或被低估，请发表你的评论。

我认为“现有机器人”不是建立在微软机器人解决方案的基础上的，如微软机器人框架、微软机器人编辑器、微软虚拟助理或微软Power虚拟代理——如果是这样的话，请遵循作为这些框架一部分提供的可用文档，将微软团队作为一个渠道激活。

让我们来看一下Microsoft Teams中应用程序的总体情况和不同集成点

团队应用程序集成点
 

通过Microsoft Teams webhook进行Bot集成

团队中的网络挂钩是什么？

Webhook和连接器是将您的web服务连接到Microsoft teams内部的渠道和团队的简单方法。

• 传入网络挂钩是团队中的一种特殊类型的连接器，它为外部应用程序提供了一种在团队渠道中共享内容的简单方式，通常用作跟踪和通知工具。
• 传出webhook将数据从Teams发送到任何能够接受JSON有效负载的选定服务。
   

我应该何时使用此选项？

• 当你的机器人只需要就特定事件通知团队/频道中的用户时
• 当你想触发你的机器人将运行的团队的操作时——操作结果/状态将被发送回原始通道
   

这种技术集成是什么样子的？

webhook集成
 

优点

• Bot可以被@提及-（注意：不支持预先配置的“操作”）
• 集成用于通知的发送/接收消息的非常简单的解决方案（但不适用于1:1的机器人讨论）
• 不需要深度集成
   

缺点

• 传入/传出消息需要2个独立的Teams应用程序
• 难以大规模部署和管理（仅在安装期间进行配置）
• 仅支持团队渠道消息
• 没有用户身份验证（但是您可以在消息负载中获得用户AAD名称和ID）
• 不适用于用户和机器人之间的“对话模式”（仅适用于简单的问答模式）

通过Microsoft Graph API进行Bot集成

什么是适用于团队的Microsoft Graph API？
Microsoft Graph公开了统一的REST API和客户端库，您可以使用这些API和库来访问数据和管理Microsoft 365核心服务（包括Microsoft Teams）、EMS和Windows 10。

这些API要求由Microsoft身份平台Azure AD保护。若要访问这些API，您的应用程序必须向Azure AD注册，并由用户或管理员授权访问其所需的Microsoft Graph资源。

我应该何时使用此选项？

• 如果您需要通过自动化流程管理O365服务，包括团队，以及发送和接收消息，则此选项是首选选项。
• 你需要在你的机器人和微软团队中的用户之间实现一个简单的回答/回复对话流
   

这种技术集成是什么样子的？

优点

• 机器人程序可以向团队发送主动消息，也可以1:1、群组和会议聊天+作为1:1的通知源
• 支持“批处理模式”，这在一些非交互式场景中很有用（例如，出于合规原因，机器人需要在整个组织范围内提取聊天消息）
• Microsoft Graph API使用受Azure AD身份验证保护。
• 可以通过自适应卡处理用户和机器人之间的简单“对话流”。
   

缺点

• 只有在用户授权的情况下才支持发送消息–这种方法有一些限制，并不总是适用
• 消息无法通过MS Graph更新（仅更新policyViolation）
• 你的机器人在团队中不被视为应用程序（Microsoft Graph应用程序未在应用程序目录中发布）
• 无法@提及该机器人程序（需要Azure AD中的“服务帐户”）
   

通过Microsoft Teams选项卡（网络聊天视图）进行Bot集成

什么是Microsoft Teams选项卡（和网络聊天视图）？

选项卡是嵌入在Microsoft Teams中的团队意识网页。它们是简单的HTML＜iframe＞标记，指向应用程序清单中声明的域，可以作为团队、群聊或个人应用程序中的通道的一部分添加。您可以在应用程序中包含自定义选项卡，以将您自己的web内容嵌入到Teams中，或将Teams特定的功能添加到您的web内容中。

选项卡可以固定在Teams的左侧导航栏上，以便于访问。

我应该何时使用此选项？

• 如果您的机器人程序具有网络聊天视图，并且可以集成到网页中，则此选项是集成到团队中所需开发较少的选项。
• 这可能是在进行更深入的本地机器人集成之前，将机器人部署到团队中的第一步，也是“唾手可得的成果”。
• 仅提供1:1的用户到机器人的对话体验（没有团队/小组到机器人）
   

这种技术集成是什么样子的？

优点

• 低代码到无需代码（仅添加Teams SDK并启用iFrame）
• 团队和您的机器人之间没有特定的基础设施或组件（公共端点+HTTPS访问）
• 可以发布到Teams应用程序目录中（使用应用程序策略）
• 无需集成Microsoft Bot Framework SDK或任何特定服务
• UI和消息格式的完全灵活性（无需实现特定于团队的聊天消息JSON格式）
   

缺点

• 在仅限于Tab体验的团队中访问机器人：从团队的角度来看，这不是机器人（例如，消息不是标准的团队聊天/不支持自适应卡）
• 你不能@提及标签页（但你可以使用深度链接提供快速访问）
• 不支持主动消息（除非选项卡已打开）
• 消息不会出现在聊天历史记录或活动中（需要自定义开发人员）
• 机器人程序中的内容无法作为聊天/在团队内轻松共享。

通过Microsoft Power虚拟代理进行Bot集成

什么是Power Virtual Agent for Teams？

Power Virtual Agents使您组织中的任何人都可以创建人工智能机器人，与用户就特定主题进行聊天。他们可以回答日常问题，解决常见问题，或自动化占用宝贵客户或员工时间的任务。

这些机器人可以在不需要数据科学家或开发人员的情况下轻松创建。

我应该何时使用此选项？

• 您希望将本地机器人集成到团队中，甚至扩展到其他渠道（例如自定义网站/Facebook/Slack/移动应用程序）
• 您的开发人员资源有限和/或更喜欢低代码的方法
• 与Azure bot开发框架相比，您更熟悉Power Platform
   

这种技术集成是什么样子的？

Aucun texte alternatif pour cette image
 

优点

• 本地机器人与团队的集成
• 低代码/无代码解决方案
• SaaS解决方案（最大限度地减少管理服务的工作量）
• 简化了团队对用户身份验证的激活（SSO正在制定路线图）
• 可以通过Microsoft Bot Framework技能进行扩展（例如QnA制造商）
• 内置人工智能功能，可检测意图和实体（自然语言）
• 集成分析和仪表盘（例如用户满意度）
   

缺点

• 不支持自适应卡-答案将主要以文本形式提供，格式简单/无图像-但此功能可以通过Azure Bot Framework或Composer进行扩展。
• 不支持主动消息（目前）
• 需要Power Platform高级连接器来集成机器人API
• 与Azure bot等“专业开发”和全代码方法相比，管理生命周期/“代码”版本控制/部署/调试的功能有限
   

通过Microsoft Teams Bot框架/Composer进行Bot集成

什么是适用于团队的Microsoft Bot框架？

Bot框架与Azure Bot服务一起提供了在一个地方构建、测试、部署和管理智能机器人的工具。机器人框架包括用于构建机器人的模块化和可扩展的SDK，以及工具、模板和相关的人工智能服务。有了这个框架，开发人员可以创建使用语音、理解自然语言、处理问题和答案等的机器人。

Bot Framework Composer是一个用于构建机器人的开源可视化创作画布。

我应该何时使用此选项？

• 您希望将本地机器人集成到团队中，甚至扩展到其他渠道（例如自定义网站/Facebook/Slack/移动应用程序）
• 您有高级场景，需要自定义开发，对用户体验具有完全的灵活性，并且不想在功能上做出妥协
• 您拥有软件开发方面的开发人员技能和经验

这种技术集成是什么样子的？

bot框架

优点

• 本地机器人集成到团队中，包括消息扩展/命令/1:1、小组和团队聊天
• 提供完整的开发套件和工具
• 提供高级功能，如多回合对话、集成认知服务（LUIS/Vision/…）、自适应卡、主动消息等…
• Composer提供了一个可视化的机器人创作UI来加速开发
   

缺点

• 学习曲线更重要
• 需要在Azure AD中部署和管理Azure服务，包括Azure Bot服务和应用程序注册，但两者都是免费的，并且都是SaaS
   

希望本指南有用-如果您不想了解更多关于Microsoft Teams应用程序开发的信息，请点击此链接【link】