Các nhà phát triển Microsoft Teams đang được cảnh báo rằng việc gọi mọi tiện ích mở rộng là “bot” hiện đang gây ra các lỗi ở cấp độ vận hành thực tế (production-grade failures). Vào năm 2026, chính các giới hạn của nền tảng này—từ 10 đến 15 giây để trả lời một tin nhắn—sẽ biến các bot có kiến trúc sai lầm thành các đợt bùng phát lỗi timeout (timeout storms), buộc các đội ngũ phải thiết kế lại các đường ống (pipelines) của họ.

Tại sao sự phân biệt này lại quan trọng

Teams cung cấp ba loại tiện ích mở rộng, mỗi loại được xây dựng cho một mô hình tương tác khác nhau. Việc trộn lẫn chúng sẽ dẫn đến việc sử dụng sai môi trường thực thi (runtime), sai SDK và sai mô hình mở rộng (scaling model).

Teams apps, bots, và agents – chúng là gì

  • Teams apps – Các tab bề mặt, trang tĩnh hoặc các thành phần UI đơn giản bên trong ứng dụng Teams. Về bản chất, chúng là các ứng dụng web: không lưu trạng thái (stateless), được hiển thị theo yêu cầu và được lưu trữ giống như bất kỳ dịch vụ HTTP nào khác. Không có luồng hội thoại nào được kỳ vọng ở đây.
  • Bots – Được xây dựng với Bot Framework SDK, các bot tuân theo các kịch bản hội thoại đã được lập trình sẵn. Logic của chúng là một cây if/else mang tính xác định (deterministic), quyết định phản hồi tiếp theo chỉ dựa trên hoạt động (activity) gửi đến. Vì lộ trình quyết định đã được biết trước, phản hồi sẽ nằm trong cửa sổ thời gian chờ (timeout) ngắn của nền tảng.
  • Agents – Các thực thể hướng mục tiêu, nhận được một mục tiêu cấp cao, một bộ công cụ và một LLM (mô hình ngôn ngữ lớn). Sử dụng Agents SDK hoặc Semantic Kernel, LLM sẽ chọn công cụ nào cần gọi, gọi theo thứ tự nào và khi nào cần yêu cầu người dùng làm rõ. Luồng hoạt động mang tính động, thường đòi hỏi nhiều lệnh gọi bên ngoài và khả năng suy luận mạnh mẽ.

Sự khác biệt rất rõ rệt: một bot mang tính xác định; một agent mang tính xác suất và điều phối các lệnh gọi công cụ tại thời điểm thực thi.

Bẫy timeout

Khi các nhà phát triển nhúng các tác vụ suy luận nặng—như các prompt LLM, truy vấn cơ sở dữ liệu hoặc gọi API bên ngoài—trực tiếp vào trình xử lý tin nhắn (message handler) của bot, Teams sẽ thấy yêu cầu kéo dài quá cửa sổ 10-15 giây của nó. Nền tảng sẽ hủy bỏ phản hồi và thử lại, điều này có thể dẫn đến tình trạng xử lý trùng lặp và bị giới hạn lưu lượng (throttling). Triệu chứng trông giống như lỗi “bot không phản hồi” chập chờn, nhưng nguyên nhân gốc rễ nằm ở kiến trúc.

Xây dựng một pipeline bất đồng bộ sẵn sàng cho production

  1. Điểm đầu vào Webhook – Endpoint HTTP của bot chấp nhận hoạt động (activity) từ Teams và ngay lập tức xác nhận đã nhận được.
  2. Đưa sự kiện vào hàng đợi – Trình xử lý đẩy payload vào một hàng đợi bền vững (durable queue) như Azure Service Bus.
  3. Worker chạy ngầm – Một Azure Durable Function, trình kích hoạt Service Bus, hoặc bất kỳ worker chạy lâu dài nào sẽ lấy tin nhắn, thực hiện suy luận LLM hoặc điều phối công cụ, sau đó gửi phản hồi cuối cùng lại cho Teams thông qua proactive messaging API của Bot Framework.

Vì webhook ban đầu phản hồi ngay lập tức, Teams sẽ không bao giờ gặp lỗi timeout, và các tác vụ nặng sẽ tiếp tục diễn ra theo tốc độ riêng của chúng. Hàng đợi sẽ đệm các đợt tăng đột biến, và các worker sẽ tự động mở rộng dựa trên độ dài của hàng đợi chờ (backlog).

Hướng dẫn quyết định nhanh (bài kiểm tra bảng trắng)

  • Bạn có thể vẽ toàn bộ cây quyết định trước khi viết bất kỳ dòng mã nào không? Có → Hãy xây dựng một bot. Luồng mang tính xác định sẽ phù hợp với mô hình Bot Framework và nằm trong cửa sổ phản hồi.
  • Vấn đề được xác định bởi một mục tiêu cấp cao và một danh sách các công cụ khả thi? Có → Hãy xây dựng một agent. Hãy để LLM lập kế hoạch và gọi các công cụ; chuyển việc lập kế hoạch sang một worker chạy ngầm.

Những gì cần theo dõi tiếp theo

Hướng dẫn này là phần đầu tiên trong một loạt bài dành cho các nhà phát triển .NET 9 đang xây dựng các giải pháp Teams thông minh trên Azure.

Nếu bạn đã thấy các lỗi “Bot timed out” trong nhật ký (logs) của Teams, cách khắc phục rất đơn giản: tách rời webhook khỏi các tác vụ nặng, áp dụng worker dựa trên hàng đợi và chọn đúng loại tiện ích mở rộng ngay từ đầu. Nền tảng có giới hạn timeout, nhưng kiến trúc của bạn có thể tránh được nó.

Điểm mấu chốt: Việc dán nhãn sai một tiện ích mở rộng của Teams là bot sẽ buộc phải sử dụng một thiết kế đồng bộ mà Teams không thể duy trì. Hãy tách biệt yêu cầu khỏi quá trình suy luận, chọn đúng SDK, và giải pháp Teams của bạn sẽ luôn phản hồi nhanh chóng ngay cả khi "bộ não" đằng sau nó là một agent chạy bằng sức mạnh LLM.