لماذا قد يستنزف الوكلاء الفرعيون حصة أسبوع في 30 دقيقة
كل ذهاب وإياب لاستدعاء أداة يعيد إرسال السجل كاملًا

كل وكيل فرعي يحتفظ بسجل محادثته ويعيد إرساله باستقلالية، لذا فإن M من الوكلاء الفرعية المتوازية تضرب استخدام محادثة واحدة في M تقريبًا؛ وإذا أضفنا إلى ذلك أن الاستخدام التراكمي لوكيل فرعي واحد ينمو أصلًا بشكل تربيعي تقريبًا مع الجولات، فإن الاستهلاك خلال النافذة القصيرة يتضخم بدرجة كبيرة.

إنه يخفض التكلفة المحتسبة للبادئات المتكررة، لكن الحصة/حدود معدل الطلبات تُحسب عادةً استنادًا إلى tokens المعالجة فعليًا أو خصائص الطلب — فلا يمكنك الاعتماد كليًا على التخزين المؤقت لتجنب بلوغ الحد.

قدّر العدد المتوقع لجولات استدعاء الأدوات ومتوسط حجم السجل لكل جولة، ثم اسقطه على أساس تربيعي تقريبًا بدلًا من معادلة بسيطة هي «استخدام الجولة × عدد الجولات».

ثمة مقايضة — فزيادة التوازي تُنهي المهمة أسرع، لكنها ترفع أيضًا ضغط استهلاك الحصة خلال نافذة قصيرة؛ عليك موازنة ذلك مع حصتك المتبقية ومدى إلحاح المهمة.

من حيث المبدأ، فإن أي إطار وكلاء مبني على واجهات API المحادثة عديمة الحالة السائدة يتسم بهذه الخاصية؛ وكلما كانت استراتيجية ضغط السجل/تلخيصه في الإطار أفضل، كان الاستهلاك الذي تشعر به فعليًا أقل، لكن السبب المعماري الكامن مشترك.

سيرفض النموذج/الحساب الذي بلغ الحد الطلبات الجديدة، وعادةً ما تتعطل المهمة أو تنتهي بخطأ؛ ويُعد توجيه بعض الوكلاء الفرعية بشكل استباقي إلى نماذج أخرى طريقة شائعة لتجنب تعلق المهمة بأكملها عند حد نموذج واحد.