به توسعهدهندگان Microsoft Teams هشدار داده شده است که نامیدن هر افزونهای به عنوان «بات» (bot)، اکنون میتواند باعث بروز شکستهای سطح عملیاتی (production-grade) شود. در سال ۲۰۲۶، محدودیتهای خودِ این پلتفرم — یعنی ۱۰ تا ۱۵ ثانیه برای پاسخ به یک پیام — باتهایی با معماری اشتباه را به «طوفانهای تایماوت» (timeout storms) تبدیل میکند و تیمها را مجبور به بازطراحی خط لولههای خود میسازد.
چرا این تمایز اهمیت دارد
Teams سه نوع افزونه ارائه میدهد که هر کدام برای یک الگوی تعامل متفاوت ساخته شدهاند. ترکیب آنها باعث استفاده از runtime، SDK و مدل مقیاسپذیری اشتباه میشود.
اپلیکیشنهای Teams، باتها و ایجنتها – آنها چه هستند
- Teams apps – تبها (tabs)، صفحات استاتیک یا اجزای ساده UI در داخل کلاینت Teams. آنها اساساً اپلیکیشنهای وب هستند: بدون وضعیت (stateless)، بر اساس تقاضا رندر میشوند و مانند هر سرویس HTTP دیگری میزبانی میشوند. هیچ جریان گفتگویی از آنها انتظار نمیرود.
- Bots – که با Bot Framework SDK ساخته میشوند، از دیالوگهای از پیش تعیینشده پیروی میکنند. منطق آنها یک درخت if/else قطعی (deterministic) است که پاسخ بعدی را صرفاً بر اساس فعالیت ورودی تعیین میکند. از آنجایی که مسیر تصمیمگیری از قبل مشخص است، پاسخ در بازه زمانی کوتاه تایماوت پلتفرم قرار میگیرد.
- Agents – موجودیتهای هدفمحور هستند که یک هدف سطح بالا، مجموعهای از ابزارها و یک LLM (مدل زبانی بزرگ) را دریافت میکنند. با استفاده از Agents SDK یا Semantic Kernel، مدل LLM انتخاب میکند که کدام ابزار را، با چه ترتیبی فراخوانی کند و چه زمانی برای شفافسازی از کاربر سوال بپرسد. جریان کار پویا است و اغلب به چندین فراخوانی خارجی و استدلال سنگین نیاز دارد.
تفاوت بسیار آشکار است: یک بات قطعی (deterministic) است؛ یک ایجنت احتمالی (probabilistic) است و فراخوانی ابزارها را در زمان اجرا مدیریت (orchestrate) میکند.
تلهی تایماوت
وقتی توسعهدهندگان استدلالهای سنگین — مانند پرامپتهای LLM، جستجو در پایگاه داده یا فراخوانیهای API خارجی — را مستقیماً داخل هندلر پیامِ یک بات قرار میدهند، Teams میبیند که درخواست از بازه ۱۰ تا ۱۵ ثانیهای خود فراتر رفته است. پلتفرم پاسخ را لغو کرده و دوباره تلاش میکند (retry)، که میتواند منجر به انجام کارهای تکراری و محدود شدن نرخ درخواستها (throttling) شود. علامت این مشکل، خطای متناوب «bot not responding» به نظر میرسد، اما علت اصلی، معماری است.
ساخت یک خط لوله ناهمگام (async) آماده برای عملیات
- نقطه ورود Webhook – نقطه پایانی HTTP بات، فعالیت Teams را میپذیرد و بلافاصله دریافت آن را تأیید میکند.
- قرار دادن رویداد در صف – هندلر، دادهها (payload) را به یک صف بادوام مانند Azure Service Bus میفرستد.
- کارگر پسزمینه (Background worker) – یک Azure Durable Function، یا یک trigger در Service Bus، یا هر کارگر (worker) با اجرای طولانیمدت، پیام را برمیدارد، استدلال LLM یا مدیریت ابزارها را اجرا میکند و پاسخ نهایی را از طریق API پیامرسانی پیشدستانه (proactive messaging API) در Bot Framework به Teams ارسال میکند.
از آنجایی که وبهوک اولیه بلافاصله پاسخ میدهد، Teams هرگز به محدودیت تایماوت نمیرسد و کارهای سنگین با سرعت خودشان پیش میروند. صف، اوجهای ترافیک را مدیریت میکند و کارگرها بر اساس طول صف (backlog) به صورت خودکار مقیاسپذیر میشوند.
راهنمای تصمیمگیری سریع (تست تختهسیاه)
- آیا میتوانید قبل از نوشتن هرگونه کد، کل درخت تصمیمگیری را رسم کنید؟ بله ← یک بات بسازید. جریان قطعی (deterministic) با مدل Bot Framework سازگار است و در بازه زمانی پاسخ باقی میماند.
- آیا مسئله با یک هدف سطح بالا و لیستی از ابزارهای ممکن تعریف شده است؟ بله ← یک ایجنت بسازید. اجازه دهید LLM برنامهریزی و ابزارها را فراخوانی کند؛ برنامهریزی را به یک کارگر پسزمینه بسپارید.
آنچه در ادامه باید منتظر باشید
این راهنما، بخش اول از مجموعهای برای توسعهدهندگان .NET 9 است که در حال ساخت راهکارهای هوشمند Teams روی Azure هستند.
اگر در حال حاضر با خطاهای «Bot timed out» در لاگهای Teams مواجه هستید، راه حل ساده است: وبهوک را از کارهای سنگین جدا کنید (decouple)، از یک کارگر مبتنی بر صف استفاده کنید و از همان ابتدا نوع افزونه صحیح را انتخاب کنید. پلتفرم محدودیت تایماوت دارد، اما معماری شما میتواند از آن اجتناب کند.
نکته کلیدی: برچسب زدن اشتباه به یک افزونه Teams به عنوان بات، باعث طراحی همگام (synchronous) میشود که Teams نمیتواند آن را تحمل کند. درخواست را از استدلال جدا کنید، SDK مناسب را انتخاب کنید و راهکار Teams شما حتی زمانی که مغز پشت آن یک ایجنت مبتنی بر LLM است، پاسخگو باقی خواهد ماند.