لا ينبغي التعامل مع وكلاء الذكاء الاصطناعي ومشغلات Kubernetes بوصفهما بديلين متكافئين داخل حلقة التحكم. فالمشغّل مصمم لمراقبة الحالة الفعلية، ومقارنتها بالحالة المطلوبة، ثم تنفيذ قواعد محددة بصورة قابلة للتكرار حتى يقترب النظام من النتيجة المعلنة. أما الوكيل فيكون أكثر فائدة عندما تكون النتيجة معروفة، لكن الطريق إليها يحتاج إلى تحقيق وجمع معلومات وموازنة مفاضلات.
تقول المادة، التي رعتها Cloud Native Computing Foundation (CNCF)، إن إدخال الوكلاء إلى البنية السحابية الأصلية يجعل تحديد حدود الصلاحيات مسألة تصميم لا مجرد convention. وتتمثل الصيغة الأكثر أماناً في إبقاء الوكيل مسؤولاً عن التفكير والسياق والاقتراح، بينما تحتفظ المشغلات ومحركات السياسات والأنظمة الحتمية بسلطة التنفيذ.
حلقة تشغيل تفصل التفكير عن التنفيذ
يقترح هذا النموذج تسلسلاً عملياً من ست مراحل: المراقبة، ثم التشخيص، ثم الاقتراح، فالموافقة، والمطابقة، وأخيراً التحقق. يستطيع الوكيل في المراحل الأولى فحص الموارد والسجلات والأحداث والمقاييس والوثائق، لكنه لا يحصل تلقائياً على صلاحية تطبيق التغييرات أو تعديل الموارد أو حذفها. ويمكن تنفيذ عمليات القراءة غير الحساسة آلياً، في حين تمر التغييرات المؤثرة عبر موافقة صريحة أو بوابة سياسات.
يعرض مشروع kagent، وهو مشروع مفتوح المصدر ضمن CNCF Sandbox، مثالاً على ذلك. فهو يشغّل وكلاء كموارد Kubernetes ويربطهم بـ Kubernetes وHelm وأدوات الرصد وأدوات مخصصة، بما يسمح بالتحقيق في المشكلات أو تنسيق وكلاء متخصصين من دون إزالة الحواجز بين التحليل والتنفيذ.
لماذا لا ينبغي استبدال المشغلات بنموذج لغوي؟
توضح حالة Karpenter الفرق بجلاء. فـ Karpenter مشغّل يتعامل مع قيود الجدولة ويطابق موارد NodePools وNodeClaims. وإذا ظهرت عقد غير مستغلة أو تقلبات في موارد Spot أو وحدات تنتظر الجدولة، يستطيع وكيل تشغيلي فحص إعدادات NodePool وEC2NodeClass، والأحداث والسجلات وPod Disruption Budgets ومقاييس Prometheus للبحث عن السبب.
قد يكشف التحقيق أن سياسة تعطيل الإخلاء تمنع الدمج، أو أن ميزانية الاضطراب تعيق الإخلاء، أو أن قيمة consolidateAfter تؤدي إلى تقلبات يمكن تجنبها في حمل متغير. لكن الناتج المطلوب ليس توصية عامة مثل «حسّن NodePool»، بل رقعة إعداد محددة تشرح الأدلة والمفاضلة وعدد العقد المحتمل تأثرها ومدة مراقبة الاستقرار.
بعد الموافقة، ينفذ Karpenter التغيير وفق منطق الجدولة والاضطراب القائم لديه. ثم يراقب الوكيل النتيجة ويتحقق من تحسن الدمج من دون زيادة زمن انتظار الوحدات أو التسبب في اضطراب ضار. وإذا لم تتحقق معايير القبول، يمكن اقتراح التراجع عبر المسار نفسه.
المثال الآخر: Argo CD وترقيات Helm
في ترقية مخطط Helm تديره Argo CD، يكون تغيير الإصدار في Git سهلاً نسبياً، لكن تقدير أثره على التطبيق الجاري أصعب. يستطيع الوكيل مقارنة ملاحظات الإصدار والقيم الحالية والبيانات المولدة لاكتشاف، مثلاً، أن اسماً جديداً لقيمة تستخدم لضبط readiness probe قد يؤدي إلى الرجوع بصمت إلى قيمة افتراضية.
ينبغي تحويل هذه النتيجة إلى طلب دمج مركز يحدّث الإصدار والقيم المتأثرة، ويشرح الخطر التشغيلي، ويحدد فحوص ما قبل النشر. بعد المراجعة والدمج، تتولى Argo CD توليد البيانات ومزامنتها وفق سياسة التطبيق. ولا يكفي نجاح المزامنة وحده لإثبات سلامة الترقية؛ إذ يجب فحص مؤشرات زمن الاستجابة ومعدلات الأخطاء والتوافر. وإذا فشلت الفحوص، يمكن للوكيل اقتراح عكس التغيير أو خطة تعافٍ، مع مراعاة أن تغييرات البيانات أو المخطط قد لا يمكن التراجع عنها بالكامل.
الاستقلالية تُكتسب تدريجياً
توصي المادة بالبدء بوكيل للقراءة والتحقيق فقط، ثم السماح له بإنشاء الرقع أو طلبات الدمج، وبعد ذلك تنفيذ تغييرات منخفضة المخاطر ومحددة النطاق، على أن تكون لها شروط تراجع واضحة. ولا يصبح الإجراء مستقلاً إلا عندما يكون مفهوماً وقابلاً للقياس.
القراءة التحريرية: التغيير الحقيقي هنا ليس إضافة وكيل يستطيع استدعاء kubectl أو Helm، بل إعادة رسم حلقة التحكم بحيث لا يتحول الاستدلال الاحتمالي إلى سلطة تنفيذية غير محدودة. القيمة العملية للنموذج تعتمد على وجود تفويض قابل للتدقيق، ونطاق محدود، ومراقبة، وإمكانية عكس الأثر. وتبقى المسؤولية البشرية قائمة في تحديد سرعة الانتقال من الاقتراح إلى الاستقلالية، كما أن المادة لا تثبت أن هذا النهج يلغي مخاطر الأخطاء أو يجعل التراجع ممكناً في كل الحالات.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.