يحول Foreman وكلاء النماذج اللغوية الكبيرة (LLM) إلى موارد Kubernetes أصلية، مما يتيح للفرق تشغيل الكود المولد بواسطة الذكاء الاصطناعي في بيئة الإنتاج مع إبقاء التكاليف والسلامة تحت رقابة صارمة.
كيف تتناسب هذه الفكرة مع سير عمل التطوير اليوم
بدأت الشركات في تجربة النماذج اللغوية الكبيرة (LLMs) القادرة على كتابة الكود، لكن معظم التطبيقات تتعامل مع النموذج كصندوق أسود موثوق. فإشارة "تم" (done) واحدة من النموذج يمكن أن تدفع بتغييرات غير مختبرة مباشرة إلى المستودع (repository)، مما يثير مخاوف تتعلق بالأمن والموثوقية. وفي الوقت نفسه، يمكن أن يصبح تشغيل خدمات الذكاء الاصطناعي على السحابة مكلفًا بسرعة، خاصة عند استدعاء النموذج نفسه بشكل متكرر من خطوط أنابيب التكامل المستمر (CI pipelines).
يتمثل حل Foreman في دمج حلقة البرمجة بأكملها داخل عنقود Kubernetes. يعمل Foreman كموارد Kubernetes.
الكائنات الأربعة الأساسية التي تجعل ذلك ممكناً
- Agent – يحدد العامل. يحدد الـ LLM المراد استدعاؤه، ويسرد الأدوات التي قد يستخدمها النموذج (مثل
file-writeأوgit-push)، ويضع ميزانية تحد من استدعاءات النموذج. يتم ربط الأدوار هنا؛ حيث يقوم وكيل المبرمج (coder agent) بكتابة الكود، ويقوم وكيل التحقق (verifier agent) بفحصه. - Workload – وحدة العمل التي يكتبها المستخدم. تحتوي على النية عالية المستوى (مثل "إضافة اختبارات وحدة لـ module X")، ومرجع للمستودع المستهدف، وقائمة بالوكلاء الذين يجب أن يتولوا المهمة.
- AgenticTask – المهمة الملموسة التي ينشئها الـ Workload. مع تقدم المهمة، يسجل كل AgenticTask تحديثات الحالة، مما يسمح للمشغلين بمراقبة خط الأنابيب في الوقت الفعلي.
- FleetNode – عقدة Kubernetes التي تقوم بتشغيل المهام فعلياً. يقوم المجدول المدمج بمطابقة الـ AgenticTasks المعلقة مع الـ FleetNodes التي تمتلك الدور والموارد المطلوبة.
التحقق يحل محل الثقة العمياء
لا يفترض Foreman أن مخرجات النموذج صحيحة. فعندما ينتهي وكيل المبرمج من عمله، فإنه يرسل طلباً بدلاً من النتيجة النهائية. يقوم وكيل التحقق (verifier) — والذي عادة ما يكون نصاً برمجياً حتمياً (deterministic script) وليس نموذج LLM آخر — بتشغيل الكود عبر أدوات فحص التنسيق (linters)، أو اختبارات الوحدة (unit tests)، أو عمليات البناء الكاملة (full builds). وفقط إذا اجتازت هذه الفحوصات، يقوم Foreman بكتابة الفرع (branch) الجديد مرة أخرى إلى المستودع.
إذا فشل وكيل التحقق، يتم وضع علامة "مرفوض" على المهمة ولا يتم تطبيق التغييرات أبداً. يسمح هذا الفصل للنموذج بالتوليد بإبداع بينما تظل شبكة الأمان تحت السيطرة البشرية الكاملة.
تثبيت الحزمة على عنقود (cluster)
- قم بنشر مخطط (chart) LLMKube الأساسي باستخدام Helm.
- قم بنشر مخطط Foreman، أيضاً عبر Helm.
- قم بتغيير وضع الوكيل إلى "native" لتفعيل حلقة الطلب والاستجابة الحقيقية.
- قم بتعيين الأدوار (coder، verifier) لعقد FleetNodes التي ستستضيف العمل.
هناك مجموعتان من بيانات الاعتماد مطلوبة: بيانات اعتماد git لقراءة المشكلات (issues) ودفع الفروع (pushing branches)، وبيانات اعتماد النموذج لاستدعاء إما واجهة برمجة تطبيقات (API) مستضافة أو خدمة استدلال (inference service) مستضافة ذاتياً.
أدوات التحكم في التكلفة والأمان التي يمكنك ضبطها فعلياً
يتيح Foreman للمشغلين الحد من صلاحيات النموذج عن طريق حذف الأدوات من تعريف الوكيل. فإزالة "bash" أو "write_file" تمنع النموذج من تنفيذ أوامر shell عشوائية أو الكتابة خارج مساحة العمل المحددة.
يضع حد عدد الدورات (turn limit) حداً أقصى لعدد استدعاءات النموذج لكل مهمة، مما يتحكم مباشرة في الإنفاق. كما أن تعديل نافذة السياق (context window) — أي مقدار ما يراه النموذج من المطالبة (prompt) — يقلل بشكل أكبر من استهلاك الرموز (tokens). وعندما يعمل النموذج محلياً على أجهزة داخل المنشأة (on-prem)، لا تخرج أي بيانات من المؤسسة، مما يلبي سياسات خصوصية البيانات الصارمة.
أين تتألق المنصة، وأين لا تزال تتعثر
يتفوق Foreman في المهام الميكانيكية محددة النطاق:
- إصلاح خطأ (bug) موثق.
- إضافة حالات اختبار مفقودة.
- تحديث التوثيق من أجل الوضوح أو الأسلوب.
تمتلك هذه المهام معايير نجاح واضحة يمكن لوكيل التحقق فحصها تلقائياً. ومع ذلك، لا يزال النظام يعاني مع إعادة التصميم المعماري رفيع المستوى أو العمل على الميزات الغامضة حيث تعتمد "الصحة" على التقدير البشري.
الخلاصة
من خلال التعامل مع المبرمجين المدفوعين بالنماذج اللغوية الكبيرة (LLM) كموارد Kubernetes من الدرجة الأولى وفرض خطوة تحقق حتمية، يوفر Foreman مساراً عملياً لتوليد كود الذكاء الاصطناعي في بيئة الإنتاج مع إبقاء الإنفاق مرئياً والأمن تحت السيطرة. إنه ليس حلاً سحرياً لكل أعمال التطوير، ولكنه يوفر سير عمل قابل للتدقيق للمهام القابلة للتكرار والاختبار، مما يتناسب بشكل طبيعي مع العمليات السحابية الأصلية (cloud-native) الحالية.