Teams 2026 年连接器被弃用了，Webhook 用户该怎么办？

如果你正在使用 Teams 的 Office 365 连接器（Connectors）来接收来自第三方服务的自动通知——例如从 GitHub 接收代码提交提醒、从 Jira 接收工单更新、或从监控系统接收服务器告警——那么你需要关注一个重要的变化：微软正在弃用 Office 365 连接器功能。这意味着所有基于连接器的 webhook 集成将在未来某个时间点停止工作。作为替代方案，微软推荐使用 Workflows 应用（基于 Power Automate）来实现更强大、更安全的自动化。

连接器弃用：为什么要变

Office 365 连接器的定位

Office 365 连接器是微软 Teams 中的一个旧版功能，允许用户将第三方应用和服务的通知直接集成到 Teams 频道中。典型的应用场景包括：当某个事件在外部系统（如 GitHub、Jira、Trello、Jenkins、Zendesk）中发生时，通过传入的 webhook 自动向 Teams 频道发送消息。这一功能在过去几年中被许多团队广泛采用，成为连接 Teams 与外部系统的重要桥梁。

弃用的原因

微软弃用连接器的主要原因是推动更现代、更安全、更可扩展的集成架构。连接器的设计基于较旧的技术栈，在安全性、可维护性和功能扩展方面存在一定的局限。随着 Teams 生态的演进和自动化需求的日益复杂，微软决定用 Workflows 应用来替代连接器，该应用基于 Power Automate 的底层引擎，提供了更丰富的触发器、更灵活的条件判断、以及与企业级安全策略的更好兼容。

为什么选择 Workflows 应用

Workflows 应用是微软在 2026 年主推的自动化工具，它与 Teams 深度集成，提供了比连接器更强大的功能：支持超过 800 种数据源的连接器；支持条件分支、循环、并行处理等复杂逻辑；提供可视化设计界面，降低自动化开发门槛；与 Power Automate 共享同一个后端，支持企业级的安全管控和审计日志。对于用户来说，迁移到 Workflows 不仅是为了继续获得自动化能力，更是为了获得一个更强大的自动化平台。

微软的替代方案建议

微软明确表示，所有新的集成创建都应使用 Workflows 应用。对于现有的基于连接器的集成，微软建议用户逐步迁移到 Workflows。迁移窗口的具体截止日期尚未最终确定，但建议用户尽早开始规划和测试，避免在弃用生效日期之后出现关键集成中断。

哪些集成会受影响

基于连接器的所有传入 Webhook

受影响最直接的集成是那些通过 Office 365 连接器创建的传入 Webhook。如果你的某个外部系统（例如自定义脚本、CI/CD 管道、监控告警系统）是通过向一个以 https://yourtenant.webhook.office.com/… 开头的 URL 发送 HTTP POST 请求来向 Teams 频道发送消息的，那么这个集成将在连接器弃用后停止工作。

通过 Power Automate 创建的 Webhook 不受影响

需要特别注意的是：不是所有的 webhook 都会受影响。如果你使用的是 Power Automate 中的“当收到 HTTP 请求时”触发器创建的 webhook，这些集成不受影响，因为它们运行在 Power Automate 的引擎上，而不是 Office 365 连接器。区分方法是：检查你配置的 webhook URL 的域名——如果是 webhook.office.com 且来自“配置连接器”界面，那就是旧版连接器。

使用 Teams 内置 Workflows 的集成不受影响

如果你已经使用 Teams 中的 Workflows 应用来创建自动化，即使这些工作流内部使用了 webhook 来接收外部事件，它们也不会受到连接器弃用的影响。Workflows 应用是微软推荐的替代方案，它将持续获得新功能的更新和安全增强。

如何识别受影响的工作流

IT 管理员可以通过 Teams 管理中心的“应用管理”页面查看组织内安装的 Office 365 连接器。具体步骤：Teams 管理中心 → Teams 应用 → 管理应用，在应用列表中搜索“连接器”或“Connector”。查看哪些团队或频道正在使用这些连接器，并记录下这些团队的联系人，以便后续迁移沟通。

替代方案：Workflows 应用与 Power Automate

Workflows 应用是什么

Workflows 应用是微软在 2026 年推出的新一代自动化工具，它在 Teams 内部提供了一个简化的 Power Automate 体验。用户可以在 Teams 中直接创建、管理和运行工作流，无需离开 Teams 界面或学习复杂的 Power Automate 概念。Workflows 应用支持数百种数据源和触发器，包括 HTTP 请求触发器（用于替代旧版 webhook）。

通过 Workflows 创建接收外部 Webhook 的工作流

步骤一：在 Teams 左侧栏点击“…”更多应用，搜索“Workflows”并打开。步骤二：在 Workflows 应用中选择“创建新工作流”。步骤三：选择“当收到 HTTP 请求时”作为触发器。步骤四：系统会生成一个唯一的 URL，将该 URL 提供给外部系统作为新的 webhook 接收端点。步骤五：添加一个“在 Teams 频道中发布消息”的动作，将收到的 HTTP 请求中的内容转换为 Teams 消息格式。

Workflows 相比连接器的优势

与旧版连接器相比，Workflows 提供了多项优势：支持请求验证（可以要求传入的请求携带 API Key 或共享密钥，防止伪造请求）；支持对传入数据进行解析和处理（例如从 JSON 中提取特定字段）；支持条件判断（例如只有状态为“紧急”的告警才发送到 Teams）；支持更丰富的输出格式（自适应卡片、附件、@提及）。这些能力是旧版连接器完全不具备的。

为每个 Webhook 独立生成 URL

在旧版连接器中，一个频道的 webhook URL 是固定的，所有外部系统都可以向同一个 URL 发送消息。在 Workflows 中，你可以为每个外部系统或每种类型的通知创建独立的工作流和独立的 URL，实现更精细的访问控制和日志审计。

迁移步骤：从连接器到 Workflows

第一步：审计现有集成

列出当前所有使用 Office 365 连接器的 Teams 频道。检查每个连接器的配置，记录下正在接收哪些外部系统的通知。这一步的目的是全面了解迁移的范围，并评估每个集成的优先级。对于关键业务通知（如生产环境告警、客户工单提醒），建议优先迁移。

第二步：在 Workflows 中重建同等功能

对于每个需要迁移的集成场景，在 Workflows 中创建对应的工作流。如果原连接器只是简单地将一个 JSON 消息转换为 Teams 消息，那么 Workflows 中可以快速完成相同的功能。如果原连接器涉及更复杂的逻辑（如解析 XML、根据消息内容路由到不同频道），Workflows 也完全支持，但可能需要更复杂的配置。

第三步：更新外部系统的 webhook 地址

在 Workflows 中创建好新的工作流并获取到新的 URL 后，需要更新外部系统中的 webhook 配置。这通常需要登录到第三方系统的管理界面，将原来发送到 webhook.office.com 的 URL 替换为 Workflows 生成的新 URL。建议在更新后进行一次测试，确保消息能够成功到达 Teams。

第四步：测试与验证

在正式切换前，先在测试频道中进行端到端测试。触发外部系统产生一条通知，确认 Teams 频道能够正常接收到消息。如果消息内容中包含特定的格式要求（如 markdown 或 HTML），确认在 Workflows 中能够正确渲染。

第五步：清理旧连接器

确认新的工作流稳定运行后，返回 Teams 频道，移除旧的 Office 365 连接器配置。这样可以避免重复通知，也可以保持频道设置整洁。如果后续发现问题需要回退，旧连接器在弃用日期之前仍然可用。

迁移过程中的注意事项

迁移窗口尽早开始

虽然连接器弃用的最终日期尚未完全确定，但微软建议用户尽早开始规划迁移。越早开始，就越有充足的时间处理复杂集成场景，避免在截止日期临近时仓促操作。建议将连接器迁移纳入 2026 年上半年的 IT 工作计划中。

监控告警类集成的双写策略

对于监控告警这类关键业务通知，建议采用“双写”策略：在新工作流验证通过之前，保持旧连接器和 Workflows 同时运行一段时间，确保告警不会因为配置错误而丢失。确认新工作流稳定运行后，再关闭旧连接器。

使用 Workflows 的日志功能进行审计

Workflows 应用与 Power Autome 共享同一个运行日志后端。管理员可以在 Power Automate 的管理门户中查看每个工作流的运行历史、失败原因、响应时间等。这对于排查迁移过程中的问题非常有帮助。

考虑使用代理（Bot）替代 Webhook

对于一些高级集成场景，微软也建议考虑使用 Teams 代理（Bot）来代替 webhook。代理提供了双向交互的能力——不仅可以从外部系统向 Teams 发送消息，还可以接收用户在 Teams 中的回复并进行处理。如果你的集成需要用户点击按钮或输入文本，代理是比 webhook 更合适的选择。