Разработчиков Microsoft Teams предупреждают: называть каждое расширение «ботом» теперь чревато критическими ошибками в продакшене. В 2026 году ограничения самой платформы — от 10 до 15 секунд на ответ на сообщение — превращают неправильно спроектированных ботов в источник лавины таймаутов, что вынуждает команды пересматривать архитектуру своих конвейеров.

Почему это различие важно

Teams предлагает три типа расширений, каждое из которых предназначено для определенного паттерна взаимодействия. Смешивание этих типов приводит к использованию неподходящего runtime, неверного SDK и неправильной модели масштабирования.

Teams apps, bots и agents — что они собой представляют

  • Teams apps — вкладки (tabs), статические страницы или простые компоненты пользовательского интерфейса внутри клиента Teams. По сути, это веб-приложения: они не сохраняют состояние (stateless), рендерятся по запросу и хостятся как любые другие HTTP-сервисы. От них не ожидают ведения диалога.
  • Bots — созданные с помощью Bot Framework SDK, боты следуют заранее прописанным сценариям диалогов. Их логика представляет собой детерминированное дерево «if/else», которое принимает решение о следующем ответе исключительно на основе входящего события (activity). Поскольку путь принятия решения известен заранее, ответ укладывается в короткое окно таймаута платформы.
  • Agents — сущности, ориентированные на достижение цели, которые получают высокоуровневую задачу, набор инструментов и доступ к LLM (большой языковой модели). Используя Agents SDK или Semantic Kernel, LLM сама выбирает, какой инструмент вызвать, в каком порядке и когда запросить уточнение у пользователя. Поток взаимодействия динамичен и часто требует множества внешних вызовов и сложных логических рассуждений.

Различие принципиально: бот детерминирован; агент вероятностен и оркестрирует вызовы инструментов во время выполнения (runtime).

Ловушка таймаута

Когда разработчики встраивают сложные рассуждения — промпты LLM, запросы к базам данных или вызовы внешних API — непосредственно в обработчик сообщений бота, Teams фиксирует, что запрос длится дольше положенных 10–15 секунд. Платформа прерывает ответ и повторяет попытку, что может привести к дублированию работы и троттлингу. Симптом выглядит как периодическая ошибка «бот не отвечает», но первопричина кроется в архитектуре.

Создание асинхронного конвейера, готового к продакшену

  1. Точка входа Webhook — HTTP-эндпоинт бота принимает активность Teams и немедленно подтверждает получение.
  2. Постановка события в очередь — обработчик отправляет полезную нагрузку в отказоустойчивую очередь, например, Azure Service Bus.
  3. Фоновый обработчик (Background worker) — Azure Durable Function, триггер Service Bus или любой другой долгоживущий обработчик извлекает сообщение, выполняет логику LLM или оркестрацию инструментов и отправляет финальный ответ обратно в Teams через Bot Framework proactive messaging API.

Поскольку первоначальный webhook отвечает мгновенно, Teams никогда не достигает таймаута, а тяжелая работа продолжается в своем темпе. Очередь сглаживает скачки нагрузки, а обработчики автоматически масштабируются в зависимости от длины очереди.

Краткое руководство по принятию решений (тест у доски)

  • Можете ли вы нарисовать всё дерево решений еще до написания кода? Да → Создавайте бота. Детерминированный поток соответствует модели Bot Framework и укладывается в окно ответа.
  • Определена ли проблема высокоуровневой целью и списком возможных инструментов? Да → Создавайте агента. Позвольте LLM планировать действия и вызывать инструменты; перенесите процесс планирования на фоновый обработчик.

Что дальше

Данное руководство является первым выпуском серии материалов для разработчиков .NET 9, создающих интеллектуальные решения для Teams на базе Azure.

Если вы уже видите ошибки «Bot timed out» в логах Teams, решение простое: отделите webhook от ресурсоемких задач, внедрите обработчик на основе очереди и с самого начала выбирайте правильный тип расширения. У платформы есть лимит по таймауту, но ваша архитектура может помочь его избежать.

Итог: Неправильное определение расширения Teams как «бота» навязывает синхронную архитектуру, которую Teams не может поддерживать. Отделите запрос от процесса рассуждения, выберите подходящий SDK, и ваше решение для Teams будет оставаться отзывчивым, даже если «мозгом» системы является агент на базе LLM.