لا تفشل معظم مسارات عمل الوكلاء المتعددين في الأجزاء الصعبة؛ فالوكيل يكتب الكود البرمجي، ويشغّل الاختبارات، ويفتح طلب السحب (pull request). بل تفشل عند نقاط الالتقاء: في اللحظة التي يغادر فيها العمل وكيلاً ويُفترض أن يصل إلى جهة أخرى. يُنهي وكيل الواجهة الخلفية (backend Agent) بناء نقطة نهاية (endpoint) دون أن يعلم وكيل الواجهة الأمامية (frontend Agent) أبداً أنها أصبحت جاهزة. وتصل تعديلات إعادة الهيكلة إلى مساحة عمل (worktree) وتستقر هناك بنجاح ودون أخطاء، لمجرد أنه لم يُطلب من أي شخص مراجعتها. المشكلة لم تكن في تعطل المهمة، بل في تعطل عملية التسليم.
تتمثل عملية تسليم مهام وكلاء الذكاء الاصطناعي (AI agent handoff) في نقل جزء من العمل وسياقه الكامل من جهة تنفيذ إلى أخرى: من وكيل إلى وكيل، أو من وكيل إلى عنصر بشري. عندما تشغّل وكيلاً برمجياً واحداً في نافذة طرفية واحدة، تكاد تكون عمليات التسليم غير مرئية لعدم وجودها أصلاً. ولكن بمجرد تشغيل وكيلين، أو وكيل واحد ومراجع بشري، يجب أن تستقر كل خطوة مكتملة في مكان محدد يسهل على المنفّذ التالي العثور عليه. ومكان الاستقرار هذا هو جوهر العملية بأكمله.
يستعرض هذا المقال أنماط التسليم التي أثبتت كفاءتها عملياً، بالاعتماد على Sharkly كمنظومة لمسار العمل: وهي الطبقة التي تعمل فوق وكلائك البرمجيين لتحافظ على وضوح السياق، ومستوى التقدم، والعوائق، والنتائج، والمراجعة البشرية من مرحلة تقديم الطلب وحتى إطلاقه. لديك بالفعل وكلاء للبرمجة، وما يعالجه هذا المقال هو ما يحدث في الفجوات الفاصلة بينهم.
باختصار
التسليم هو انتقال العمل وسياقه من جهة تنفيذ إلى أخرى. ينقل التسليم بين الوكلاء مهمة فرعية مكتملة إلى الوكيل التالي، بينما يوقف التسليم من الوكيل إلى الإنسان العمل المستقل عند بوابة مراجعة. اجعل كلا المسارين صريحين ومحددين عبر الحالات (statuses): ينقل الوكلاء المهمة (Task) إلى حالة «جاهز للمراجعة» (Ready for review)، بينما ينقلها البشر إلى حالة «مكتمل» (Done). وعندما تصبح عملية التسليم تغييراً في حالة مهمة مشتركة بدلاً من رسالة عابرة في نافذة طرفية، فلن يسقط أي عمل في طي النسيان.
ما هو تسليم مهام الوكيل تحديداً؟
تتكون عملية التسليم من ثلاثة أركان رئيسية، وتجاهل أيٍّ منها يتسبب في ضياع العمل: المخرَج المنجز (فروقات الكود أو diff، أو طلب السحب PR، أو ملف الترحيل migration)، والسياق (ما طُلب تنفيذه، وما تغيّر، وما زال غير محسوم)، والمستلم (الوكيل أو الشخص المحدد المسؤول عن الخطوة التالية).
تحتفظ مسارات العمل المعتمدة على سطر الأوامر (Terminal) بالمخرج المنجز لكنها تفقد الركنين الآخرين؛ إذ يوجد التعديل المحفوظ (commit)، لكن الأسباب والمنطق وراءه تظل حبيسة سجل التمرير الذي لم يره سوى وكيل واحد، أما «من التالي» فيُترك لمن يتصادف تفقده للأمر. ولهذا السبب، فإن إدارة وتنسيق الوكلاء لا تتعلق بمجرد إطلاقهم، بل بتوجيه ومسار ما ينتجونه.
أما عملية التسليم السليمة، فتنقل هذه العناصر الثلاثة معاً: التغيير نفسه، وملخص ما تم إنجازه وما لم يُنجز، وإشارة واضحة لا لبس فيها إلى أن الدور قد حان على المستلم. ووفقاً لمنظومة Sharkly، تعود تفاصيل التنفيذ والعوائق والنتائج والنقاشات اللاحقة كلها إلى الجدول الزمني للمهمة (Task timeline)، بحيث يطّلع المنفّذ التالي على سجل واحد شامل بدلاً من إعادة تجميع الصورة من ثلاثة مصادر متفرقة.
نمطان لعمليات التسليم
يبدو النمطان متشابهين ظاهرياً، لكن الإعدادات الافتراضية لكل منهما متعاكسة تماماً. يجب أن يسير التسليم من وكيل إلى وكيل تلقائياً: يستلم الوكيل التالي مهمة فرعية جاهزة ويواصل العمل دون انقطاع. في المقابل، يجب أن يتوقف التسليم من وكيل إلى إنسان بشكل افتراضي: يُنهي الوكيل الجزء الخاص به وينتظر، لأن اتخاذ القرار يتطلب تقييماً بشرياً.
| من وكيل إلى وكيل | من وكيل إلى إنسان | |
|---|---|---|
| محفز البدء | تحديد مهمة فرعية على أنها جاهزة | وصول العمل إلى بوابة مراجعة |
| الوضع الافتراضي | المتابعة تلقائياً | التوقف والانتظار |
| ما تنقله العملية | المخرج المنجز + السياق + معايير القبول | فروقات الكود (Diff) + ملخص التغييرات + القيود المعروفة |
| المخاطر عند الغياب | ازدواجية العمل أو تضاربه | دمج كود غير مراجع دون تدقيق |
إليك المعيار الثنائي الحاسم لاتخاذ القرار الصائب: اجعل التسليم بين الوكلاء مؤتمتاً عندما تكون الخطوة التالية محددة بوضوح ومعايير قبولها مكتوبة مسبقاً، مثل: «تشغيل مجموعة الاختبارات»، أو «إنشاء ملف الترحيل»، أو «تحديث مواصفات OpenAPI». في المقابل، افرض تسليماً من الوكيل إلى الإنسان عندما تتطلب الخطوة التالية تقييماً لا يستطيع الوكيل تحمّل مسؤوليته، مثل: الدمج في الفرع الرئيسي (main)، أو تعديل العقود والواجهات العامة، أو المساس بالتحقق من الهوية والفوترة، أو اعتماد النتيجة كعمل منتهٍ.
يكمن الخطأ في التعامل مع جميع عمليات التسليم بالطريقة ذاتها؛ فإذا جعلت كل شيء يتدفق تلقائياً، ستدمج كوداً برمجياً لم يخضع للمراجعة، وإذا وضعت بوابات تدقيق لكل خطوة، فستجد نفسك قد أعدت بناء خط أنابيب يدوي بطيء بخطوات إضافية مرهقة. ويرتبط هذا ارتباطاً وثيقاً بمعرفة أين تضع بوابات الموافقة بحيث يتوقف الوكلاء قبل ارتكاب أخطاء فادحة ومكلفة، وليس بعد كل خطوة يسيرة.
الحالات تحوّل التسليم إلى بوابة حقيقية لا مجرد أمنية
يرتكز نموذج التشغيل على أربعة أفعال رئيسية والجهة المسؤولة عن كلٍّ منها: مَن يُسنِد، ومَن يُنفّذ، ومَن يُراجع، ومَن يعتمد. يتولى الوكلاء مهمة البحث، والتنفيذ، والاختبار، وتقديم التقارير؛ بينما يحدد البشر التوجه العام، ويمنحون الصلاحيات، ويعتمدون النتائج. وتتوقف الأتمتة تماماً عند النقطة التي تتطلب حكماً وتقدير الفريق.
تُمثّل الحالات الوسيلة التي تجعل هذا الاتفاق سارياً بشكل منهجي تلقائي بدلاً من كونه مجرد رغبة نظرية؛ حيث تمر كل مهمة عبر المسار ذاته:
- Todo: مُسندة، ولم يبدأ العمل عليها بعد. وضعها هنا إما شخص أو وكيل قيادي.
- In progress: استلمها وكيل وبدأ العمل عليها في مساحة عمل (worktree) معزولة.
- Ready for review: الحد الفاصل لدور الوكيل؛ حيث ينتهي من فحص الأنواع (typecheck)، وتشغيل الاختبارات، وبناء المشروع، ويرفق ملخص التغييرات والقيود المعروفة، ثم يتوقف.
- Done: الحد الخاص بالعنصر البشري؛ حيث يقوم شخص باعتماد النتيجة واتخاذ قرار الدمج والإطلاق.
والقاعدة التي تمنح المنظومة بأكملها وضوحاً تاماً هي: ينقل الوكلاء المهمة إلى Ready for review، بينما ينقلها البشر إلى Done. لا يقوم الوكيل أبداً بتحديد عمله كـ Done، ولا يضطر الإنسان إلى التخمين عما إذا كانت المهمة ذات المؤشر الأخضر آمنة بالفعل. فالحالة هنا هي التسليم نفسه. وعندما يعمل عشرة وكلاء في آنٍ واحد، لن تحتاج إلى تفقّد عشر نوافذ طرفية؛ بل تلقي نظرة على اللوحة لترى بدقة ما ينتظر تدخلك، وما ينتظر وكيلاً آخر، وما لا يزال قيد التنفيذ. هذا الوضوح هو الفارق الجوهري بين تتبّع ما أنجزه الوكلاء وبين التعلق بأمل أن يروي سجل التعديلات (commit log) القصة لاحقاً.
مثال عملي: من تذكرة العمل وحتى دمج طلب السحب
لنتناول مهمة تحاكي بيئة العمل الواقعية، وهي المهمة SH-312: «إضافة تحديد معدل الطلبات إلى واجهة برمجة التطبيقات العامة». راقب هنا مراحل التسليم، وليس الكود البرمجي فحسب.
يصف أحد الأشخاص الاحتياج بلغة طبيعية ويقوم بإسناد المهمة. يبحث الوكيل القيادي في قاعدة الكود وسجل المهام السابقة، ويحدد نطاق العمل ومعايير القبول (تحديد المعدل لكل مفتاح API، وإرجاع رمز الحالة 429 مع ترويسة Retry-After، وتغطية نقاط النهاية الثلاث الأكثر استخداماً)، ثم يقسم المهمة SH-312 إلى ثلاث مهام فرعية قابلة للتنفيذ. هذا هو التسليم الأول بين الوكلاء: استلام الهدف، وإخراج مهام فرعية جاهزة للتنفيذ.
تتدفق المهام الفرعية تلقائياً؛ حيث يستلم وكيل الواجهة الخلفية منطق تحديد المعدل، ويتولى وكيل الاختبار تغطية الاختبارات. وبما أن كلاً منهما يعمل في مساحة عمل معزولة، فإنهما لا يتعارضان في الملفات نفسها، وتعود نتيجة كل منهما إلى المهمة SH-312 بدلاً من البقاء في جلسة عمل خاصة. وعندما ينتهي وكيل الواجهة الخلفية، فإنه لا يرسل تنبيهاً لمراجع بشري، بل يحدد مهمته الفرعية على أنها جاهزة، ليبدأ وكيل الاختبار في التعامل مع التنفيذ البرمجي الحقيقي بدلاً من الاعتماد على نموذج وهمي (stub).
بعد ذلك، يتبدل نمط التسليم؛ فبمجرد بناء محدد المعدل، واجتياز فحص الأنواع والاختبارات بنجاح، واكتمال البناء دون أخطاء، يصل العمل إلى بوابة التسليم من الوكيل إلى الإنسان. ينقل الوكيل المهمة SH-312 إلى حالة Ready for review ويرفق معها فروقات الكود (diff)، وملخص التغييرات، وقيداً واحداً معروفاً: «يعتمد العدّاد المستند إلى Redis على وجود منطقة جغرافية واحدة؛ وتتطلب التغطية متعددة المناطق مهمة متابعة لاحقة». يطّلع مراجع بشري على كل ذلك في مكان واحد، ويتحقق من استجابة الرمز 429، ثم ينقل المهمة إلى Done، مما يؤدي تلقائياً إلى دمج الكود. مسار متكامل من التذكرة وحتى دمج طلب السحب (PR)، مع توثيق دقيق لكل مَن نفّذ عملاً عند كل نقطة التقاء. هذا هو ذاته مسار تحويل المتطلبات إلى كود برمجي قابل للتتبع من البداية إلى النهاية.
أين تفشل عمليات التسليم، وكيف تضبط إحكامها؟
تفشل عمليات التسليم بثلاث طرق يمكن التنبؤ بها، ولكل منها حل هيكلي جذري بدلاً من الاعتماد على مجرد محاولات التذكر والتنبيه الفردي.
تبخّر السياق: يعرف الوكيل سبب اتخاذه لقرار معين، بينما يجهله المراجع. والحل: أن ينقل التسليم ملخص التغييرات والقيود المعروفة كجزء أساسي من الانتقال إلى Ready for review، وليس كفكرة لاحقة مهملة. ضبابية المسؤولية: قد يستلم وكيلان العمل نفسه، أو لا يلتفت إليه أيٌّ منهما. والحل: تحديد مسؤول (Assignee) لكل مهمة رئيسية وفرعية، بحيث يصبح «دورك في العمل» حقلاً صريحاً ومحدداً وليس مجرد تخمين مبهم. غياب المراجعة تماماً: دمج العمل المستقل تلقائياً لعدم وجود توجيه بإيقافه. والحل: حالة لا يستطيع الوكيل تجاوزها بمفرده دون مراجعة بشرية.
يمكنك بناء هذه المنظومة بأكملها يدوياً باستخدام مساحات العمل (worktrees)، ومعايير التسمية، والانضباط المنهجي. وقد ينجح ذلك إلى أن تتضاعف أعداد الوكلاء والمهام والمستودعات البرمجية، ويكون ذلك الانضباط أول ما ينهار. فإذا كنت تشغّل بالفعل عدة وكلاء، فإن Sharkly يوفر لك بيئة مركزية لإدارة مهامهم ونتائجهم: مهام مشتركة، وتعيين مسؤول لكل مهمة، ومساحات عمل معزولة، ومسار حالات يصل فيه الوكلاء إلى Ready for review بينما يقرر البشر الانتقال إلى Done. احتفظ بوكلائك البرمجيين الحاليين كما هم، وأضف الطبقة التي تجعل عمليات تسليمهم مرئية وواضحة. حمّل Sharkly عندما تبدأ الفواصل بين وكلائك في استنزاف وقت وتكلفة تفوق العمل نفسه.
الأسئلة الشائعة
ما هي عملية تسليم مهام وكيل الذكاء الاصطناعي؟ هي نقل المهمة، مصحوبة بسياقها الكامل وإشارة واضحة تفيد بأن الدور قد حان على طرف آخر، من جهة تنفيذ إلى التالية. ولها شكلان: من وكيل إلى وكيل (حيث تنتقل المهمة الفرعية المكتملة إلى الوكيل التالي)، ومن وكيل إلى إنسان (حيث يتوقف العمل المستقل عند بوابة مراجعة).
ما الفرق بين التسليم من وكيل إلى وكيل والتسليم من وكيل إلى إنسان؟ يجب أن يستمر التسليم من وكيل إلى وكيل تلقائياً عندما تكون معايير القبول للخطوة التالية محددة مسبقاً. أما التسليم من وكيل إلى إنسان فيجب أن يتوقف وينتظر، لأن الأمر يتطلب حكماً بشرياً؛ مثل اتخاذ قرار الدمج، أو تعديل واجهة عامة، أو اعتماد النتيجة النهائية.
هل ينبغي للوكلاء تحديد عملهم كمكتمل بأنفسهم؟ لا؛ دع الوكلاء ينقلون المهمة إلى حالة Ready for review بعد تشغيل الاختبارات وإرفاق الملخص، واترك خطوة النقل إلى Done وقرار الدمج للشخص المسؤول. فالفصل بين هذين الحدين هو ما يمنع إطلاق كود غير مراجع. طالع المزيد حول الوكلاء البرمجيين مع التدخل البشري.
كيف تمنع الحالات (statuses) ضياع المهام؟ عندما تكون عملية التسليم تغييراً في حالة مهمة مشتركة بدلاً من رسالة عابرة في نافذة طرفية، يرى المنفّذ التالي بدقة ما ينتظر تدخله، ولا يعود أي شيء متوقفاً على متابعة سجل التمرير الصحيح في اللحظة المناسبة. كما يُبرز صندوق وارد الوكلاء المهام التي تحتاج إلى اهتمامك.
هل أحتاج إلى أداة مخصصة لذلك، أم يمكنني تطبيق الأمر يدوياً؟ يمكنك إدارة ذلك يدوياً باستخدام مساحات العمل ولوحة مهام مشتركة. ومع ذلك، تظهر الفائدة الحقيقية لوجود طبقة مخصصة بمجرد تنسيق عدة وكلاء عبر مستودعات برمجية متعددة وعندما يصبح التتبع اليدوي هو العائق الأكبر. قارن بين النموذج الذهني: المساعد مقابل الزميل في الفريق لتحديد خيارك الأنسب.
