Microsoft Teams developers are being warned that calling every extension a “bot” now causes production-grade failures. In 2026 the platform’s own limits—10 to 15 seconds to answer a message—turn mis-architected bots into timeout storms, forcing teams to redesign their pipelines.

Dlaczego to rozróżnienie jest ważne

Teams oferuje trzy typy rozszerzeń, z których każdy został zbudowany pod inny wzorzec interakcji. Mieszanie ich wymusza użycie niewłaściwego środowiska uruchomieniowego (runtime), niewłaściwego SDK i niewłaściwego modelu skalowania.

Aplikacje Teams, boty i agenci – czym są

  • Aplikacje Teams – karty (tabs), statyczne strony lub proste komponenty interfejsu użytkownika wewnątrz klienta Teams. Są to w zasadzie aplikacje webowe: bezstanowe, renderowane na żądanie i hostowane jak każda inna usługa HTTP. Nie oczekuje się od nich przepływu konwersacyjnego.
  • Boty – Zbudowane przy użyciu Bot Framework SDK, boty podążają za zaprogramowanymi dialogami. Ich logika to deterministyczne drzewo instrukcji if/else, które decyduje o kolejnej odpowiedzi wyłącznie na podstawie przychodzącej aktywności (activity). Ponieważ ścieżka decyzyjna jest znana z góry, odpowiedź mieści się w krótkim oknie timeoutu platformy.
  • Agenci – Podmioty ukierunkowane na cel, które otrzymują zadanie wysokiego poziomu, zestaw narzędzi oraz LLM (duży model językowy). Korzystając z Agents SDK lub Semantic Kernel, LLM wybiera, które narzędzie wywołać, w jakiej kolejności i kiedy poprosić użytkownika o wyjaśnienie. Przepływ jest dynamiczny, często wymagający wielu zewnętrznych wywołań i intensywnego wnioskowania.

Podział jest wyraźny: bot jest deterministyczny; agent jest probabilistyczny i orkiestruje wywołania narzędzi w czasie rzeczywistym (at runtime).

Pułapka timeoutu

Kiedy deweloperzy osadzają intensywne wnioskowanie — prompty LLM, wyszukiwanie w bazie danych lub wywołania zewnętrznych API — bezpośrednio w handlerze wiadomości bota, Teams widzi, że żądanie przekracza 10–15-sekundowe okno. Platforma przerywa odpowiedź i ponawia próbę, co może prowadzić do kaskadowych duplikatów pracy i ograniczania przepustowości (throttling). Objawem jest przerywany błąd „bot nie odpowiada”, ale przyczyną źródłową jest architektura.

Budowanie asynchronicznego potoku gotowego na produkcję

  1. Punkt wejścia Webhook – Punkt końcowy (endpoint) HTTP bota przyjmuje aktywność Teams i natychmiast potwierdza jej otrzymanie.
  2. Kolejkowanie zdarzenia – Handler przesyła ładunek (payload) do trwałej kolejki, takiej jak Azure Service Bus.
  3. Worker w tle – Azure Durable Function, wyzwalacz Service Bus lub jakikolwiek długo działający worker pobiera wiadomość, przeprowadza wnioskowanie LLM lub orkiestrację narzędzi, a następnie przesyła końcową odpowiedź z powrotem do Teams za pomocą Bot Framework’s proactive messaging API.

Ponieważ początkowy webhook zwraca odpowiedź natychmiast, Teams nigdy nie przekracza limitu timeoutu, a ciężka praca toczy się we własnym tempie. Kolejka buforuje skoki natężenia ruchu, a workerzy automatycznie skalują się w zależności od długości kolejki (backlog).

Szybki przewodnik decyzyjny (test białej tablicy)

  • Czy potrafisz narysować całe drzewo decyzyjne, zanim napiszesz jakikolwiek kod? Tak → Zbuduj bota. Deterministyczny przepływ pasuje do modelu Bot Framework i mieści się w oknie odpowiedzi.
  • Czy problem jest zdefiniowany przez cel wysokiego poziomu i listę możliwych narzędzi? Tak → Zbuduj agenta. Pozwól LLM planować i wywoływać narzędzia; przenieś planowanie do workera w tle.

Co dalej

Ten poradnik to pierwsza część serii dla deweloperów .NET 9 budujących inteligentne rozwiązania Teams na Azure.

Jeśli w logach Teams widzisz już błędy „Bot timed out”, rozwiązanie jest proste: rozdziel webhook od ciężkich zadań, zastosuj workera opartego na kolejce i od samego początku wybierz właściwy typ rozszerzenia. Platforma ma limit timeoutu, ale Twoja architektura może go uniknąć.

Podsumowanie: Błędne etykietowanie rozszerzenia Teams jako bota wymusza projekt synchroniczny, którego Teams nie jest w stanie utrzymać. Oddziel żądanie od wnioskowania, wybierz odpowiednie SDK, a Twoje rozwiązanie Teams pozostanie responsywne nawet wtedy, gdy „mózgiem” stojącym za nim jest agent napędzany przez LLM.