تم إطلاق agent-pool لـ Google AI و Gemini CLI مع pipelines و cron و bounce-back

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

التنسيق التلقائي

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

من خلال create_pipeline، يتم وصف الخطوات والتبعيات مسبقاً، والعملية نفسها تبقى حية حتى بعد إعادة تشغيل IDE. الفكرة الأساسية ليست مجرد تشغيل worker بل إعطاء الوكلاء لغة تنسيق. بعد انتهاء المرحلة، يرسل المنفذ إشارة جاهزية، وإذا كانت البيانات ناقصة، يمكن إعادة المهمة للمراجعة مع شرح.

هذا الارتداد يشبه Request Changes في مراجعة الكود: الخطوة السابقة تكمل الأثر وتعيده للسلسلة. هذا يجعل خط الأنابيب ليس نصًا خطيًا بل حلقة مدارة مع حد للعودات.

"يمكن للعامل أن يفوض المهام بنفسه - هذا هو ما تُبنى عليه كل التنسيق الكسوري."

تصف المقالة الآليات الرئيسية لهذا النظام:

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

Cron و SSH

يتم التعامل مع الجدولة بشكل منفصل. تستخدم أداة schedule_task صيغة cron قياسية، لذلك يمكن تعيين وكيل للتشغيل يومياً أو كل ساعة بدون جدول زمني منفصل. المهم: المراقب يضع أقفال ملفات ذرية: حتى لو فتحت نوافذ IDE متعددة في نفس الوقت، ستُنفذ نفس المهمة مرة واحدة فقط.

تُخزّن النتائج في مجلد scheduled-results، لذا يمكن استخدام السيناريو للفحوصات الروتينية للخوادم والتجميع الدوري للتقارير الأسبوعية. إذا لم تكن الآلة المحلية كافية، يمكن إرسال العمال إلى خادم بعيد عبر SSH. يوصف العداء في إعدادات agent-pool، وبعدها تبدأ المهام المحددة في التنفيذ على آلة مخصصة مع تثبيت Gemini CLI.

القيمة العملية واضحة: الاختبارات والإعادة وتحليل الكود بالجملة تستمر حتى بعد إغلاق الكمبيوتر المحمول. يصف المؤلف سير عمل نموذجي: يعمل العمال في فرع منفصل، ويرتكبون التغييرات، ويدفعون النتائج، وفي الصباح يفتح المطور ببساطة طلب دمج ويراجع النتيجة.

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

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

يمكن عرض الجلسات النشطة بشكل منفصل والاتصال بها يدويًا إن لزم الأمر. هناك أيضًا طبقة تقييد مطلوبة للعمل الحقيقي في الفريق. من خلال السياسة، يمكنك إعطاء الوكيل وضع القراءة فقط أو التحرير الآمن دون الحق في تشغيل الأوامر.

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

وأخيراً، يقدم agent-pool المجموعات - في الأساس قوالب للفرق الكسورية. يمكنك تسجيل عداء ومهارة وسياسة وحد max_agents في مجموعة واحدة، ثم إرسال عدة منفذين منها دون تكرار الإعدادات. تُحفظ هذه المجموعات بين إعادة تشغيل IDE وتتصل مباشرة بخطوط الأنابيب.

إذا كان يجب تنفيذ خطوة بالتوازي، سيطلق المراقب عدة وكلاء ويوزع الفهارس عليهم وينتظر النتيجة المشتركة. ينطبق fail-fast: إذا تعطل عامل مع خطأ أو أرسل bounce-back، يتم إلغاء العمليات الأخرى على الفور لتجنب إهدار الوقت والموارد.

ما يعنيه هذا

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