Amp Spaces توزّع المهام على الوكلاء وتدير حتى 16 مسارًا متوازيًا

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

اقترحت Sourcegraph واجهة مختلفة. فقد ظهرت في Amp ميزة Spaces، وهي مساحات عمل مشتركة يؤدي فيها أحد الوكلاء دور المنسّق. يحدد المستخدم له هدفًا، فينشئ مسارات منفصلة، ويربط بها الوكلاء، ويبلغ عن سير العمل في الدردشة المشتركة. وبالنسبة للفريق، يبدو الأمر أقرب إلى إدارة مجموعة صغيرة من المنفذين منه إلى الحديث مع مساعد واحد.

كيف يعمل ذلك في مثال بسيط

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

إذا اكتشف زميل خطأ في تقريب قسيمة، فلا حاجة إلى فتح محادثة جديدة يدويًا وشرح السياق من جديد. سينشئ المنسّق مسارًا للخطأ، ويسنده إلى مشارك أو وكيل محدد، ثم يعيد الحالة إلى الخلاصة المشتركة. وعند الحاجة يفتح الإنسان المسار بجوار الدردشة ويطّلع على التصحيح أو النقاش أو نتائج الاختبارات.

وتقول Sourcegraph إن Spaces نفسها طُوّرت بهذه الطريقة. فكان الفريق يترك الملاحظات والأفكار في الغرفة المشتركة، ويوزعها الوكيل على مسارات. ومثال آخر هو إطلاق حسابات الخدمة: ففي مساحة واحدة نشر الفريق الميزة، وتتبّع الرسائل في الشبكات الاجتماعية وSlack، وأصلح الأخطاء، وأرسل رسائل البريد، وأجرى عمليات استرداد للمستخدمين المتضررين.

وفي فحص أمان دوري، قسّم الوكيل قاعدة الشيفرة إلى 16 منطقة، وفحص كل واحدة في مسار منفصل، وأعاد التحقق من المشكلات المكتشفة، وحفظ ملخصًا للإنسان. وهذا يوضح جيدًا الفكرة الأساسية لـ Spaces: يبقى العمل المتوازي مرئيًا دون أن يحوّل الدردشة الرئيسية إلى مكب للرسائل الوسيطة.

لماذا يهم هذا المطورين وفرق المنتجات

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

ولدى Spaces طبقة للعمل الجماعي أيضًا. إذ يمكن للأشخاص مناقشة العمل في الغرفة المشتركة، والرد على الرسائل، والانضمام إلى مسارات محددة. وتؤكد Sourcegraph أن جزءًا من النقاشات داخل الشركة انتقل إلى هناك من Slack. وهذا يجعل المساحة ليست مجرد غرفة عمليات للوكلاء، بل سجلًا للقرارات أيضًا: يظهر من وضع المهمة، وكيف قُسّمت، وما الناتج.

أين ينبغي توخي الحذر

حتى الآن يستند الوصف في الغالب إلى تجربة فريق Sourcegraph نفسه. ولا تقدم الشركة بيانات مقارنة: إلى أي مدى تقلّص Spaces زمن التطوير، وكم خطأً يفوّته المنسّق، وكيف ترتفع التكلفة مع كثرة الوكلاء المتوازين. والرقم 16 يخص مثالًا واحدًا لفحص الأمان، وليس حدًا معلنًا للنظام.

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

والخلاصة العملية بسيطة: يستحق Spaces التجربة في المهام التي تتضمن أصلًا عدة اتجاهات عمل مستقلة. ابدأوا بسيناريو آمن، مثل فحص وحدات المستودع، وحدّدوا مسبقًا الإجراءات التي يستطيع الوكيل تنفيذها بنفسه. فإذا كان التحقق من النتائج أسهل فعلًا من إدارة عشرات المحادثات يدويًا، فإن الواجهة الجديدة توفّر لا وقت كتابة الشيفرة، بل انتباه الشخص الذي يدير هذه العملية.