إطلاق agent-pool لـ Google AI وGemini CLI: خطوط معالجة وcron وآلية bounce-back

ظهرت طبقة جديدة مفتوحة المصدر لتنسيق الوكلاء مع Google AI وGemini CLI. يجمع خادم MCP المسمّى agent-pool عمليات التفويض المتفرقة في خطوط معالجة (pipelines)، ويستطيع إعادة المهام للتحسين، وتشغيلها وفق جدول زمني، ونقل التنفيذ إلى أجهزة بعيدة.

تنسيق آلي

تواجه معظم سيناريوهات الوكلاء المتعددين مشكلة بسيطة: يقضي الوكيل الرئيسي وقتاً طويلاً في التوزيع والإدارة بدلاً من العمل الفعلي. فإذا كانت الخطوات تعتمد على بعضها — التحليل، ثم إعادة الهيكلة، ثم الاختبارات، ثم النشر — فعلى المنسّق أن يستعلم عن الحالات، ويحلل الردود، ويشغّل المنفّذ التالي يدوياً. ينقل agent-pool هذا المنطق إلى خدمة خلفية (daemon). فعبر create_pipeline تُوصَف الخطوات والاعتماديات مسبقاً، وتبقى العملية قائمة حتى بعد إعادة تشغيل IDE.

الفكرة الأساسية ليست تشغيل عامل (worker) فحسب، بل منح الوكلاء لغة للتنسيق. بعد انتهاء المرحلة يرسل المنفّذ إشارة جاهزية، وإذا نقصت البيانات يمكن أن تعود المهمة إلى الخلف للتحسين مع توضيح السبب. تشبه آلية bounce-back هذه خيار Request Changes في مراجعة الشيفرة: تستكمل الخطوة السابقة النتيجة وتعيدها إلى السلسلة. وبذلك لا يكون خط المعالجة سكربتاً خطياً، بل حلقة مُدارة بحدّ أقصى لعدد مرات الإرجاع.

«يمكن للعامل أن يفوّض المهام بنفسه إلى مستوى أبعد — وعلى هذا يقوم

التنسيق الفركتالي بأكمله».

يصف المقال الآليات الأساسية لهذا المخطط:

• on_complete — يشغّل الخطوة التالية بعد اكتمال عامل محدد
• on_complete_all — ينتظر المجموعة بأكملها وينفّذ fan-in قبل المرحلة التالية
• on_file — يستجيب لظهور ملف على القرص
• signal_step_complete — يبلغ الـ daemon بأن الخطوة اكتملت فعلاً
• bounce_back — يعيد المهمة إلى الخلف، ويحدّ maxBounces عدد الدورات

cron وSSH

خُصّصت للجدولة أداة مستقلة. تستخدم الأداة schedule_task صيغة cron المعتادة، ولذلك يمكن جدولة الوكيل للتشغيل يومياً أو كل ساعة دون مجدول منفصل. والمهم أن الـ daemon يضع أقفال ملفات ذرية (atomic): فحتى لو فُتحت عدة نوافذ IDE في وقت واحد، تُنفَّذ المهمة نفسها مرة واحدة فقط. تُحفظ النتائج في مجلد scheduled-results، ما يتيح استخدام السيناريو في الفحوصات الدورية للخوادم وفي إعداد التقارير الأسبوعية.

وإذا لم يكفِ الجهاز المحلي، يمكن إرسال العمال إلى خادم بعيد عبر SSH. يُعرَّف المشغّل (runner) في إعدادات agent-pool، ثم تبدأ مهام محددة بالتنفيذ على جهاز مخصص مثبّت عليه Gemini CLI. والفائدة العملية واضحة: تستمر الاختبارات أو إعادة الهيكلة أو التحليل الجماعي للشيفرة حتى بعد إغلاق الحاسوب المحمول. ويصف المؤلف سير العمل المعتاد هكذا: يعمل الوكلاء في فرع منفصل، وينفّذون commits، ويدفعون النتيجة، وفي الصباح يفتح المطوّر pull request ويراجع الحصيلة.

السياق والتحكم

من التفاصيل المفيدة أيضاً نقل السياق بين الوكلاء عبر الجلسات المدمجة في Gemini CLI. يمكن لعامل أن ينهي بحثه ويحفظ session_id، ثم يلتقط العامل التالي المحادثة نفسها ويواصل العمل دون إعادة سرد ما وُجد. وفي السلاسل الطويلة يوفّر ذلك التوكنات ويقلّل الأخطاء عند حدود المراحل: فالوكيل الثاني يرى سجل التحليل الكامل لا مجرد ملخص جاف. ويمكن استعراض الجلسات النشطة بشكل منفصل، والاتصال بها يدوياً عند الحاجة.

هناك أيضاً طبقة قيود لازمة للعمل الجماعي الفعلي. فعبر policy يمكن منح الوكيل وضع القراءة فقط، أو تحريراً آمناً دون صلاحية تشغيل الأوامر. وإذا لم يكفِ ذلك، تُحدَّد القواعد بدقة أكبر عبر ملف YAML مستقل. ويكمل المعامل include_dirs هذا النموذج: فبشكل افتراضي لا يرى العامل سوى مجلد العمل، ويجب تفعيل الوصول إلى الإعدادات الخارجية أو المجلدات الإضافية صراحةً. ويجعل هذا النهج الأتمتة أكثر أماناً بكثير من منح وصول كامل غير مشروط إلى المشروع بأكمله.

وأخيراً، يقدّم agent-pool المجموعات (groups) — وهي في جوهرها قوالب لفرق فركتالية. يمكن تسجيل المشغّل والمهارة والسياسة وحدّ max_agents في المجموعة مرة واحدة، ثم إرسال عدة منفّذين منها دفعة واحدة دون تكرار الإعدادات. وتُحفظ هذه المجموعات بين عمليات إعادة تشغيل IDE وترتبط مباشرة بخطوط المعالجة. وإذا كان يجب تنفيذ خطوة بالتوازي، يشغّل الـ daemon عدة وكلاء ويوزّع عليهم الفهارس وينتظر النتيجة المشتركة. ويُطبَّق هنا مبدأ fail-fast: إذا تعطل أحد العمال بخطأ أو أرسل bounce-back، تُلغى العمليات الأخرى فوراً حتى لا يُهدر الوقت والموارد سدى.

ماذا يعني ذلك

بالنسبة للمطورين، هذه إشارة إلى أن AgentOps بدأ ينتقل من مستوى التجارب إلى مستوى الأدوات اليومية. فعندما تتجمع خطوط المعالجة والمجدول والمشغّلات البعيدة والتحكم بالصلاحيات حول اشتراك Google AI واحد، تتحول سيناريوهات الوكلاء المتعددين من عروض توضيحية إلى بنية تحتية عملية للشيفرة والاختبارات والأتمتة الروتينية.