يتم تحذير مطوري Microsoft Teams من أن تسمية كل إضافة بـ "bot" (بوت) تسبب الآن إخفاقات على مستوى بيئة الإنتاج. في عام 2026، ستؤدي قيود المنصة نفسها — من 10 إلى 15 ثانية للرد على الرسالة — إلى تحويل البوتات ذات البنية البرمجية الخاطئة إلى "عواصف مهلة" (timeout storms)، مما يجبر الفرق على إعادة تصميم مسارات العمل (pipelines) الخاصة بها.

لماذا يهم هذا التمييز

توفر Teams ثلاثة أنواع من الإضافات، كل منها مصمم لنمط تفاعل مختلف. ويؤدي الخلط بينها إلى فرض بيئة تشغيل (runtime) خاطئة، ومجموعة أدوات تطوير (SDK) خاطئة، ونموذج توسع (scaling model) خاطئ.

تطبيقات Teams، والبوتات، والوكلاء (Agents) – ما هي

  • Teams apps – عبارة عن علامات تبويب (tabs) سطحية، أو صفحات ثابتة، أو مكونات واجهة مستخدم بسيطة داخل عميل Teams. هي في الأساس تطبيقات ويب: عديمة الحالة (stateless)، يتم عرضها عند الطلب، ومستضافة مثل أي خدمة HTTP أخرى. ولا يُتوقع منها أي تدفق حواري.
  • Bots – تُبنى باستخدام Bot Framework SDK، وتتبع البوتات حوارات مكتوبة مسبقاً (scripted). منطقها عبارة عن شجرة "if/else" حتمية (deterministic) تقرر الرد التالي بناءً فقط على النشاط الوارد. ولأن مسار القرار معروف مسبقاً، فإن الرد يقع ضمن نافذة المهلة القصيرة للمنصة.
  • Agents – كيانات مدفوعة بالأهداف تتلقى هدفاً رفيع المستوى، ومجموعة من الأدوات، ونموذج لغة كبير (LLM). باستخدام Agents SDK أو Semantic Kernel، يختار الـ LLM الأداة التي سيتم استدعاؤها، وبأي ترتيب، ومتى يطلب توضيحاً من المستخدم. التدفق هنا ديناميكي، وغالباً ما يتطلب استدعاءات خارجية متعددة وعمليات استدلال (reasoning) مكثفة.

الفرق واضح وجلي: البوت حتمي (deterministic)؛ أما الوكيل (agent) فهو احتمالي (probabilistic) ويقوم بتنسيق استدعاءات الأدوات أثناء وقت التشغيل.

فخ المهلة (The timeout trap)

عندما يقوم المطورون بدمج عمليات استدلال ثقيلة — مثل مطالبات LLM، أو عمليات البحث في قواعد البيانات، أو استدعاءات API خارجية — مباشرة داخل معالج رسائل البوت، ترى Teams أن الطلب يستغرق وقتاً يتجاوز نافذة الـ 10-15 ثانية الخاصة بها. تقوم المنصة بإلغاء الرد وإعادة المحاولة، مما قد يؤدي إلى تكرار العمل وعمليات التقييد (throttling). تظهر الأعراض على شكل خطأ متقطع "bot not responding" (البوت لا يستجيب)، لكن السبب الجذري هو بنيوي (architectural).

بناء مسار عمل غير متزامن (async pipeline) جاهز للإنتاج

  1. Webhook entry point – يقبل نقطة نهاية HTTP الخاصة بالبوت نشاط Teams ويؤكد الاستلام فوراً.
  2. Queue the event – يقوم المعالج بدفع الحمولة (payload) إلى طابور دائم مثل Azure Service Bus.
  3. Background worker – تقوم Azure Durable Function، أو مشغل Service Bus، أو أي عامل يعمل لفترة طويلة بسحب الرسالة، وتشغيل استدلال الـ LLM أو تنسيق الأدوات، ثم إرسال الرد النهائي إلى Teams عبر واجهة برمجة تطبيقات الرسائل الاستباقية (proactive messaging API) الخاصة بـ Bot Framework.

نظرًا لأن الـ webhook الأولي يعود بالرد فوراً، فإن Teams لا تصل أبداً إلى مهلة الانتظار، ويستمر العمل الثقيل بوتيرته الخاصة. يقوم الطابور بامتصاص الارتفاعات المفاجئة (spikes)، ويقوم العمال بالتوسع التلقائي (auto-scale) بناءً على طول قائمة المهام المتراكمة (backlog).

دليل اتخاذ القرار السريع (اختبار السبورة البيضاء)

  • هل يمكنك رسم شجرة القرار بأكملها قبل كتابة أي كود؟ نعم ← ابنِ بوت (bot). التدفق الحتمي يناسب نموذج Bot Framework ويبقى ضمن نافذة الرد.
  • هل يتم تحديد المشكلة من خلال هدف رفيع المستوى وقائمة من الأدوات الممكنة؟ نعم ← ابنِ وكيلاً (agent). اترك الـ LLM يخطط ويستدعي الأدوات؛ وانقل عملية التخطيط إلى عامل يعمل في الخلفية (background worker).

ماذا تتابع لاحقاً

هذا الإرشاد هو الجزء الأول من سلسلة لمطوري .NET 9 الذين يبنون حلول Teams ذكية على Azure.

إذا كنت ترى بالفعل أخطاء "Bot timed out" في سجلات Teams، فإن الحل بسيط: افصل الـ webhook عن المهام الثقيلة، واعتمد عاملاً يعمل بناءً على الطابور (queue-driven worker)، واختر نوع الإضافة الصحيح منذ البداية. للمنصة حد أقصى للمهلة، ولكن يمكن لبنيتك البرمجية تجنب ذلك.

الخلاصة: إن تسمية إضافة Teams بشكل خاطئ على أنها بوت تفرض تصميماً متزامناً (synchronous) لا تستطيع Teams تحمله. افصل الطلب عن عملية الاستدلال، واختر الـ SDK المناسب، وسيبقى حل Teams الخاص بك مستجيباً حتى عندما يكون العقل المدبر وراءه وكيلاً مدعوماً بـ LLM.