DeepSeek تفتح مصدر النموذج الأولي Super-agent: انخفاض p95 لزمن إنجاز المهمة من 29,5 إلى 15,7 دقيقة

نشرت DeepSeek في مصدر مفتوح النموذج الأولي Super-agent، وهو نظام متعدد الوكلاء يفصل التواصل مع البشر عن تنفيذ العمل في جلسات مستقلة. تستقبل جلسة موجّه واحدة الطلبات وتوزّع المهام، بينما ينفذها عمّال معزولون بالتوازي، ويبدؤون العمل عند وقوع أحداث GitHub. في اختبار أجرته DeepSeek بنفسها، انخفض p95 لزمن إنجاز المهمة من 29,5 إلى 15,7 دقيقة مقارنةً بجلسة واحدة. وكتب عن الإصدار محلل أخبار الذكاء الاصطناعي @kimmonismus، وحصد منشوره على X نحو 91,6 ألف مشاهدة.

الموجّه منفصل والعمّال منفصلون

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

في Super-agent تُفصل هذه الأدوار. يبقى الموجّه «واجهة» النظام: يتحدث مع البشر، ويفهم ما يريدونه، ويمرّر العمل إلى غيره. أما العمل نفسه فيذهب إلى العمّال. كل عامل معزول، أي إنه يعمل في بيئة مستقلة بسياقه الخاص ولا يؤثر في العمّال الآخرين. وتشغّل العمّال أحداث GitHub: ظهور مهمة جديدة، أو تعليق، أو pull request، وإشارات مشابهة. فالوكيل لا ينتظر أمرًا في المحادثة، بل يتفاعل مع ما يجري في المستودع.

لهذا النهج ميزتان واضحتان. فالمهام المتوازية لا تقف في طابور واحد، وخطأ أحد العمّال أو تعطّله لا يفسد سياق الآخرين ولا يعطّل الحوار مع الإنسان.

ماذا أظهر قياس DeepSeek

الرقم العلني الوحيد في الرسالة هو p95 لزمن التنفيذ. وهو الزمن الذي تُنجز خلاله 95% من المهام، أي مؤشر «الذيل الطويل» الذي يعكس أبطأ الحالات. وهذا ما يهم العمل الجماعي، فمتوسط السرعة لا يقول الكثير إذا كانت كل مهمة عشرين تعلق نصف ساعة. بلغ p95 لدى الجلسة الواحدة 29,5 دقيقة، ولدى النظام المؤلف من موجّه وعمّال 15,7 دقيقة. أي إن ذيل التأخيرات تقلّص بنحو النصف، بحوالي 47%.

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

ما ينقص في الرسالة

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

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

ماذا يفعل المطورون

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

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