Microsoft Teams 开发者正收到警告：将所有扩展都称为“机器人 (bot)”现在会导致生产级故障。到 2026 年，平台自身的限制——即在 10 到 15 秒内响应消息——会将架构设计不当的机器人变成“超时风暴”，迫使团队重新设计其流水线。

为什么这种区别很重要

Teams 提供三种扩展类型，每种类型都针对不同的交互模式而构建。混用这些类型会导致错误的运行时、错误的 SDK 以及错误的扩展模型。

Teams 应用、机器人与智能体 —— 它们是什么

  • Teams apps – Teams 客户端内的标签页、静态页面或简单的 UI 组件。它们本质上是 Web 应用：无状态、按需渲染，并像任何其他 HTTP 服务一样进行托管。不需要对话流。
  • Bots – 使用 Bot Framework SDK 构建，遵循脚本化的对话。其逻辑是一个确定性的 if/else 决策树，完全根据传入的活动来决定下一个回复。由于决策路径是预先知道的，因此响应能够落在平台较短的超时窗口内。
  • Agents – 目标驱动的实体，接收高层目标、一组工具和一个 LLM（大语言模型）。使用 Agents SDK 或 Semantic Kernel，LLM 会选择调用哪个工具、调用顺序以及何时向用户请求澄清。其流程是动态的，通常需要多次外部调用和重度推理。

这种区别非常显著：机器人是确定性的；而智能体是概率性的，并在运行时编排工具调用。

超时陷阱

当开发者将重度推理（LLM 提示词、数据库查询或外部 API 调用）直接嵌入机器人的消息处理程序中时，Teams 会发现请求超过了其 10-15 秒的窗口期。平台会中止响应并重试，这可能会级联导致重复工作和限流。症状表现为间歇性的“机器人未响应”错误，但根本原因是架构问题。

构建生产级异步流水线

  1. Webhook 入口点 – 机器人的 HTTP 端点接收 Teams 活动并立即确认收到。
  2. 将事件入队 – 处理程序将负载推送到持久化队列（如 Azure Service Bus）。
  3. 后台工作进程 – Azure Durable Function、Service Bus 触发器或任何长时间运行的工作进程提取消息，运行 LLM 推理或工具编排，并通过 Bot Framework 的 proactive messaging API 将最终回复发回 Teams。

由于初始 Webhook 会立即返回，Teams 永远不会触发超时，重型任务可以按照自己的节奏进行。队列可以缓冲峰值，工作进程可以根据积压长度自动扩展。

快速决策指南（白板测试）

  • 在编写任何代码之前，你能画出完整的决策树吗？ 是 → 构建机器人 (bot)。确定性的流程符合 Bot Framework 模型，并能保持在响应窗口内。
  • 问题是否由一个高层目标和一系列可能的工具来定义？ 是 → 构建智能体 (agent)。让 LLM 进行规划并调用工具；将规划工作交给后台工作进程。

后续关注

本指南是为在 Azure 上构建智能 Teams 解决方案的 .NET 9 开发者准备的系列文章的首篇。

如果你在 Teams 日志中已经看到了 “Bot timed out” 错误，解决方法很简单：将 Webhook 与重型任务解耦，采用队列驱动的工作进程，并从一开始就选择正确的扩展类型。平台有超时限制，但你的架构可以规避它。

核心要点： 将 Teams 扩展错误地标记为机器人，会迫使采用 Teams 无法维持的同步设计。将请求与推理分离，选择正确的 SDK，这样即使背后的“大脑”是基于 LLM 的智能体，你的 Teams 解决方案也能保持响应。