لماذا تتعثر أطر العمل عند التوسع
معظم أطر عمل الوكلاء تُنمذج تشغيلًا واحدًا: حلقة LLM تستدعي الأدوات، وتضيف إلى سجل المحادثة، وتنتهي عند تحقق شرط توقف. هذا التجريد كافٍ لدفتر ملاحظات ومضلل في الإنتاج. نظام الإنتاج ليس تشغيلًا واحدًا؛ بل هو العديد من التشغيلات المتزامنة التي تتنافس على نفس الموارد الشحيحة — حدود معدل النموذج، وتزامن الأدوات، وعرض النطاق الترددي للاسترجاع، وانتباه المشغلين الذين يراقبون قائمة الانتظار. مهمة إطار العمل هي وصف التشغيل. مهمة النظام هي تحديد أي التشغيلات تحدث، وبأي ترتيب، وعلى حساب من.
هذه مشكلات جدولة، وقد حُلَّت للحاويات منذ عقود. يقرر التحكم في القبول ما إذا كان الطلب مقبولًا أو في قائمة الانتظار أو مرفوضًا. تحدد الحصص المورد الذي قد يستهلكه المستأجر. يلغي الاستباق العمل ذا الأولوية المنخفضة لإفساح المجال للعمل ذي الأولوية الأعلى. ينتشر الضغط العكسي بالحمل الزائد إلى المنبع بدلًا من امتصاصه حتى ينهار شيء ما. لم تنشأ أي من هذه المفاهيم مع Kubernetes، لكن Kubernetes منحها مفردات وواجهة API يفهمها المهندسون بالفعل.
التقارب واضح في الأدوات. منسق AX مفتوح المصدر من Google إشارة إلى أن الصناعة تتعامل مع تنسيق الوكلاء كمشكلة مستوى تحكم وليس كمشكلة هندسة أوامر. الهندسة المثيرة ليست DSL جديدًا لوصف الوكلاء؛ بل هي المُجدول الذي يقرر متى يعملون.
ربط بدائيات التحكم
الربط من تنسيق الحاويات إلى تنسيق الوكلاء ليس مجازيًا. إنه بنيوي، وهو مفيد.
التحكم في القبول
عند تقديم تشغيل، يتوقع المُجدول تكلفته: استهلاك الرموز المتوقع، وعدد استدعاءات الأدوات حسب الفئة، والمدة الزمنية الفعلية. إذا تجاوز التوقع الميزانية المتبقية لذلك المستأجر أو للمجموعة، يُرفض التشغيل أو يُوضع في قائمة الانتظار. لا يحتاج التوقع إلى الدقة؛ بل يحتاج إلى أن يكون متحفظًا ورخيصًا. الآلية البسيطة هي تقدير تكلفة لكل تشغيل مستمد من حجم الأمر، ومجموعة الأدوات المعلنة، ومضاعف تاريخي لكل فئة أدوات. يقارن المُجدول هذا التقدير مقابل دلو الرموز. إذا كان الدلو فارغًا، ينتظر التشغيل.
هذا هو نفس منطق webhook القبول في Kubernetes الذي يرفض pod يطلب ذاكرة أكثر مما تسمح به مساحة الأسماء. الفرق هو أن المورد غير قابل للاستبدال: الرمز الذي يُنفق على تشغيل فاشل يضيع، واستدعاء أداة له تأثير خارجي لا يمكن استرجاعه.
الحصص
تُفرض الحصص قبل الإرسال، وليس بعده. للمستأجر ثلاث ميزانيات: الرموز لكل نافذة، واستدعاءات الأدوات لكل نافذة حسب الفئة، والتشغيلات المتزامنة. يتحقق المُجدول من الثلاثة عند القبول. إذا استُنفد أي منها، يُوضع التشغيل في قائمة الانتظار بدلًا من بدئه. هذا ممل عمدًا، وهو الآلية الأكثر فعالية لمنع حلقة مستأجر جامحة من تجويع كل مستأجر آخر.
المقايضة هي زمن الاستجابة. الحصة الصارمة تجعل التشغيل ينتظر حتى عندما يكون لدى المجموعة سعة احتياطية، لأن الحصة لكل مستأجر وليست عالمية. البديل — الجدولة العالمية مع ترجيح المشاركة العادلة — أكثر كفاءة وأصعب بكثير في الاستدلال. يجب أن تبدأ معظم الفرق بحصص صارمة وتخففها فقط عندما تتوفر لديها بيانات.
الاستباق
الاستباق هو البدائية التي نادرًا ما تنفذها أطر العمل وتتطلبها أنظمة الإنتاج في النهاية. عندما يحتاج تشغيل ذو أولوية عالية إلى أداة يحتفظ بها حاليًا تشغيل ذو أولوية منخفضة، يمكن للمُجدول إلغاء التشغيل ذي الأولوية المنخفضة وتحرير الأداة. يُعاد التشغيل الملغى إلى قائمة الانتظار، ولا يُفقد.
الاستباق قوي وخطير. لا يكون آمنًا إلا عندما يمكن استئناف التشغيل المستبق من نقطة تفتيش دون تكرار التأثيرات الجانبية. هذا الشرط لا يتحقق دائمًا، ولهذا يجب أن يكون الاستباق آخر بدائية تُدخل، وليس الأولى.
ما لا ينتقل
ثلاث خصائص لتشغيلات الوكلاء تكسر الربط النظيف بـ pods.
تشغيلات الوكلاء ليست عديمة الحالة. يمكن قتل pod وإعادة جدولته لأن حالته تعيش في وحدة تخزين أو قاعدة بيانات. حالة تشغيل الوكيل تعيش في سجل محادثته، وسجل استدعاءات أدواته، وذاكرته العاملة. يجب أن يلتقط إنشاء نقاط التفتيش الثلاثة جميعًا، ويجب أن يكون الاستئناف خاملًا فيما يتعلق بال
استدعاءات الأدوات لها تأثيرات جانبية خارجية. إلغاء تشغيل في منتصف استدعاء أداة لا يلغي الاستدعاء. دفعة، تذكرة، بريد إلكتروني، كتابة في قاعدة بيانات — هذه تستمر. لذلك لا يكون الاستباق آمنًا إلا للتشغيلات التي يكون عملها المتبقي خاليًا من التأثيرات الجانبية، أو للأدوات التي تدعم التعويض. يحتاج المُجدول إلى تصنيف لكل أداة: آمنة للاستباق، أو قابلة للتعويض، أو نهائية. بدون هذا التصنيف، الاستباق خطأ صحيح ينتظر الحدوث.
يجب أن تلتقط المراقبة المسارات. يهتم منسق الحاويات برموز الخروج واستخدام الموارد. يهتم منسق الوكلاء بتسلسل القرارات: أي أداة استُدعيت، وبأي وسائط، وما عاد، ولماذا سلك التشغيل ذلك الفرع. مراقبة رمز الخروج غير كافية لأن التشغيل يمكن أن يخرج بنجاح بينما فعل الشيء الخاطئ. يجب أن يصدر المُجدول سجل مسار منظم لكل تشغيل، ويجب أن يكون ذلك السجل وحدة التصحيح، وليس سطر السجل.
مسار الترحيل
لا تحتاج الفرق إلى تبني مُجدول كامل في اليوم الأول. المسار تدريجي وقابل للعكس.
الخطوة الأولى: أصدر سجل جدولة لكل تشغيل. قبل أي فرض، اجعل النظام يصف نفسه. يصدر كل تشغيل سجلًا يحتوي على الأولوية، وتقدير الميزانية، والتبعيات، وفئات الأدوات. هذه مراقبة، وليست تحكمًا، وهي آمنة. كما تنتج البيانات اللازمة لتعيين حصص غير اعتباطية.
الخطوة الثانية: أدخل الحصص قبل الاستباق. الحصص قابلة للعكس: المستأجر الذي يصل إلى الحد ينتظر، ويمكن رفع الحد. الاستباق غير قابل للعكس: قد يكون التشغيل الملغى قد تسبب بالفعل في تأثير جانبي. أدخل الحصص أولًا، وقس سلوك قائمة الانتظار، وعندها فقط فكر في الاستباق للمجموعة الفرعية من التشغيلات الآمنة للإلغاء.
الخطوة الثالثة: تعامل مع المُجدول كمكان وحيد تلتقي فيه التكلفة والسياسة. إذا كان منطق القبول يعيش في بوابة API، ومنطق الحصة في العامل، ومنطق الأولوية في الأمر، فلا يمكن لأحد أن يجيب لماذا انتظر تشغيل. مركزة القرار تجعل النظام قابلًا للتدقيق وتجعل تغييرات السياسة قابلة للاختبار. يصبح المُجدول المكون الذي يملك الإجابة عن "لماذا لم يبدأ هذا التشغيل؟"
المقايضة الصادقة
يضيف المُجدول زمن استجابة ونطاق فشل جديد. يدفع كل تشغيل ثمن فحص القبول، وخطأ في المُجدول يمكن أن يوقف الأسطول بأكمله. تتجنب أطر العمل هذا بعدم وجود مستوى تحكم؛ بل تدفع المشكلة إلى المشغل. هذا خيار مشروع للأنظمة الصغيرة. يتوقف عن كونه مشروعًا عندما يجعل عدد التشغيلات المتزامنة، أو المستأجرين، أو فئات الأدوات التحكيم اليدوي مستحيلًا. عند هذه النقطة لا يكون الخيار بين إطار عمل ومُجدول؛ بل بين مُجدول صريح ومُجدول عرضي متناثر عبر منطق إعادة المحاولة، ومعالجة حدود المعدل، وحكم الاستدعاء.
المُجدول الصريح أصعب في البناء وأسهل في التشغيل. هذه هي المقايضة. لأسراب الوكلاء في الإنتاج، إنها المقايضة الصحيحة.