FDE-Gym: لماذا يتعثّر أفضل وكيل ذكاء اصطناعي في «الميل الأخير» من تسليم المشاريع؟

معظم معايير الوكلاء البرمجيين تسأل سؤالاً واحداً: هل نجح الكود في اجتياز الاختبارات؟ لكن من عمل يوماً على مشروع حقيقي لعميل يعرف أن الاختبارات هي الجزء الأسهل. الصعب هو أن تفهم ما لم يُقَل لك، وأن تعدّل نظاماً حياً دون أن تكسره، وأن ترفع مؤشراً تجارياً فعلياً. هذا بالضبط ما تحاول ورقة بحثية نُشرت في أكتوبر 2026 باسم FDE-Gym: The Last Mile of AI Delivery قياسه، ونتيجتها صادمة بعض الشيء: أفضل إعداد جُرّب حلّ 14 مهمة فقط من أصل 95.

ما هو FDE-Gym؟

الاختصار FDE يعني Forward-Deployed Engineer، أي «المهندس المنتشر ميدانياً»: المهندس الذي يُرسَل إلى بيئة العميل نفسها ليحوّل منتجاً عاماً إلى حلّ يعمل فعلاً في سياق محدّد. هذا الدور صار شائعاً في شركات الذكاء الاصطناعي، وتتحدث الأخبار عن مبادرات كبيرة لتدريب آلاف المهندسين عليه. فجاء السؤال الطبيعي: هل يستطيع الوكيل أن يؤدي هذا الدور؟

بحسب الورقة، يتكوّن المعيار من:

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

كيف يعمل الاختبار؟

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

الفكرة الأساسية في FDE-Gym أن «الشيفرة التي تعمل» ليست هي المنتج؛ المنتج هو نتيجة الأعمال التي تحرّكت بعد أن وصل الحل إلى العميل.

ماذا قالت النتائج؟

قيّم الباحثون 13 إعداداً لنماذج من سبعة مزوّدين. وأهم الأرقام:

المؤشر	النتيجة
متوسط درجة أفضل إعداد في الوضع الواقعي	0.56
المهام المحلولة بدرجة 0.8 فأكثر دون حادث	14 من 95
مهام حصل فيها أفضل إعداد على كل الحقائق المفتاحية من أصحاب المصلحة	23
منها ما بلغ 0.8 فأكثر	10 فقط

يتضح من الجدول أن المشكلة ليست مجرد «أسئلة ناقصة». حتى حين حصل الوكيل على كل المعلومات اللازمة في 23 مهمة، لم ينجح بالمستوى المطلوب إلا في 10 منها.

عنق الزجاجة: القيود غير المصرّح بها

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

وماذا بعد الاكتشاف؟

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

ما الذي يعنيه هذا للمطوّر؟

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

قيود يجب أن تضعها في الحسبان

المعيار يستخدم أصحاب مصلحة مبرمجين سلفاً، وهم أبسط من البشر الحقيقيين الذين يتناقضون ويغيّرون رأيهم. والـ95 مهمة، على تنوّعها، تبقى عيّنة محدودة من 18 قطاعاً. لذلك ينبغي النظر إلى الرقم 0.56 كمؤشر على الفجوة وليس كحكم نهائي على قدرات الوكلاء. وللتوضيح، هناك ورقة منفصلة اسمها FDE-Bench تعالج مشكلة قريبة بـ49 حالة، فلا تخلط بين المعيارين.

كيف تطبّق الدرس في فريقك خلال أسبوع؟

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

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

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

أسئلة شائعة

هل يعني هذا أن الوكلاء غير صالحين للعمل مع العملاء؟

لا. يعني أنهم ما زالوا بحاجة إلى إشراف في المهام التي تتطلب اكتشاف قيود غير معلنة. هم مفيدون في المهام المحددة جيداً، لكن «الميل الأخير» ما زال يحتاج خبرة بشرية.

ما الفرق بين FDE-Gym ومعايير مثل SWE-bench؟

المعايير البرمجية التقليدية تقيس إصلاح مشكلة في مستودع كود بوجود اختبارات. أما FDE-Gym فيقيس تسليم نتيجة أعمال في بيئة عميل، مع أسئلة مكلفة وقيود خفية ومؤشر مرتبط ببيانات محجوزة.

كيف أستفيد منه عملياً دون تشغيله؟

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

الخلاصة

يذكّرنا FDE-Gym بأن الفارق بين وكيل يكتب كوداً جيداً ووكيل يسلّم قيمة لعميل ما زال كبيراً: أفضل إعداد بلغ 0.56 وأنجز 14 مهمة من 95 بمستوى مقبول. العائق الأكبر ليس الكتابة بل اكتشاف ما لم يُقَل. فإن كنت تبني بالوكلاء، فاستثمر في الأسئلة والقيود والمؤشرات قبل أن تستثمر في نموذج أكبر.

المصادر: ورقة FDE-Gym على arXiv، صفحة الورقة على Hugging Face، FDE-Bench على arXiv.