تحسين الأوامر لوكلاء الذكاء الاصطناعي: GEPA و DSPy (2026)

في سطر واحد: أصبح تحسين الـ Prompt للوكلاء الذكيين (AI agents) يتم بشكل تلقائي. GEPA — وهو مُحسن Genetic-Pareto تم قبوله كعرض شفوي (Oral) في ICLR 2026 — يقوم بإعادة كتابة الـ prompts الخاصة بالوكيل من خلال التأمل في عمليات التفكير وتتبع استدعاءات الأدوات (tool-call traces)، متفوقاً على التعلم التعزيزي (reinforcement learning) عبر ست مهام مع عدد تشغيلات أقل بما يصل إلى 35 مرة.¹

ملخص: لمدة عامين، كانت النصيحة لجعل الوكيل موثوقاً هي "اكتب system prompt أفضل". في عام 2026، يتم تسليم هذه المهمة لمُحسن تلقائي. يقوم GEPA (Genetic-Pareto) بقراءة تتبعات تنفيذ الوكيل — التفكير، استدعاءات الأدوات، ومخرجات تلك الأدوات — ويشخص ما حدث خطأ باللغة الإنجليزية البسيطة، ثم يطور الـ prompt بناءً على ذلك. لقد تم قبوله كعرض شفوي في ICLR 2026، ويأتي كمُحسن أساسي في DSPy (dspy.GEPA) ومكتبة مستقلة حصدت عدة آلاف من نجوم GitHub، ويشير إلى تفوقه على طريقة التعلم التعزيزي GRPO بنسبة تصل إلى 20% مع استخدام عدد عمليات rollout أقل بما يصل إلى 35 مرة.¹²³ لكن هناك ثغرة، نُشرت في يونيو، وهي أن هذه التقنية نفسها تصبح غير متوقعة في اللحظة التي توجهها فيها نحو نظام متعدد الوكلاء (multi-agent system).⁴

ما ستتعلمه

• ما هو GEPA وكيف يختلف "تطور الـ prompt التأملي" عن الضبط اليدوي للـ prompt
• أرقام المقارنة المرجعية (benchmark) التي جعلته يحصل على عرض شفوي في ICLR 2026 — وما تدعيه وما لا تدعيه
• لماذا يجعل قراءة تتبعات استدعاء الأدوات من هذه التقنية تقنية خاصة بـ الوكلاء (agents)، وليست مجرد خدعة LLM
• أين تجده حالياً في مجموعتك التقنية: dspy.GEPA، والمكتبة المستقلة، وأدوات الـ prompt في المختبرات الكبرى
• الثغرة: ما وجده MAS-PromptBench عندما التقى نفس المُحسن بأنظمة متعددة الوكلاء
• ما الذي يجب فعله فعلياً إذا كنت تقوم ببناء وكلاء ذكيين

ما هو GEPA في الواقع

GEPA — اختصار لـ Genetic-Pareto — هو مُحسن prompt "يدمج التأمل باللغة الطبيعية بشكل شامل لتعلم قواعد رفيعة المستوى من خلال التجربة والخطأ".¹ هذا التعريف، المأخوذ من ملخص الورقة البحثية، يلخص الفكرة كاملة في جملة واحدة. بدلاً من تعديل أوزان النموذج أو تحفيز مكافأة رقمية، يعمل GEPA في الوسط الذي يفهمه النموذج بالفعل بشكل أفضل: اللغة.

إليك دورة العمل. تعطي GEPA نظام ذكاء اصطناعي يحتوي على واحد أو أكثر من الـ prompts، بالإضافة إلى طريقة لتقييم مخرجاته. يقوم GEPA بتشغيل النظام على مجموعة من مهام التدريب ويسجل المسار الكامل — تفكير النموذج، استدعاءات الأدوات التي قام بها، والمخرجات التي أعادتها تلك الأدوات. ثم تأتي خطوة التأمل لتقرأ هذه التتبعات باللغة الطبيعية، وتشخص سبب الفشل، وتكتب prompt معدلاً. ومن الأهمية بمكان أنه يحتفظ بـ Pareto frontier (جبهة باريتو) لأفضل محاولاته بدلاً من "أفضل محاولة حالية" واحدة، بحيث يمكنه دمج دروس متكاملة من prompts نجح كل منها في أمثلة مختلفة.¹ والنتيجة هي تعليمات مُعاد كتابتها لم يكتبها بشر قط.

السبب في أهمية ذلك هو "الوسط المستخدم". الحجة الأساسية للورقة البحثية هي أن "الطبيعة القابلة للتفسير للغة غالباً ما توفر وسط تعلم أغنى بكثير لنماذج LLMs، مقارنة بتدرجات السياسة (policy gradients) المشتقة من مكافآت عددية متفرقة".¹ إشارة التعلم التعزيزي تخبر النموذج بأنه} حصل على درجة 0.3؛ أما التأمل فيخبره لماذا} — "لقد استدعيت أداة البحث قبل أن تحصل على معرف حساب المستخدم". إحدى هاتين المعلومتين قابلة للتنفيذ بشكل أكبر بكثير، وهي التي يستخدمها GEPA.

الأرقام التي جعلته يحصل على عرض تقديمي (Oral) في ICLR 2026

تم قبول GEPA في ICLR 2026 كعرض تقديمي (Oral) — وهي أعلى فئة من القبول — بعد مراجعة الإصدار الثاني (v2) التي نُشرت في فبراير 2026.¹ قائمة المؤلفين ليست مجموعة من المجهولين: فهي تضم مبتكر DSPy عمر خطاب، ومؤسسي Databricks ماتي زاهاريا وإيون ستويكا، وكريستوفر بوتس من ستانفورد، ودان كلاين من بيركلي، إلى جانب عشرات آخرين.¹ هذا النسب المرموق هو جزء من سبب انتشار هذه النتائج.

المقارنة الرئيسية كانت ضد التعلم التعزيزي (reinforcement learning). عبر ست مهام، "تفوق GEPA على GRPO بنسبة 6% في المتوسط وبنسبة تصل إلى 20%، بينما استخدم عدد مرات تنفيذ (rollouts) أقل بـ 35 مرة".¹ GRPO — Group Relative Policy Optimization — هي طريقة RL شائعة، ووفقاً لنفس الورقة، فهي "غالباً ما تتطلب آلاف الـ rollouts لتعلم مهام جديدة".¹ اقرأ الادعاء بعناية، لأن الصياغة تفرق: التفوق المتوسط على GRPO هو 6%، و20% هي الفجوة في أفضل الحالات، وليست الحالة المعتادة. رقم الكفاءة هو الجزء المذهل حقاً. تحويل "آلاف الـ rollouts" إلى مهمة يمكن تشغيلها بعدد أقل بكثير هو ما يجعل تحسين المطالبات (prompt optimization) رخيصاً بما يكفي للجوء إليه بشكل افتراضي.

استهدف GEPA أيضاً الحالة الراهنة من الفن (state of the art) في تحسين المطالبات. فقد "تفوق على أفضل مُحسن مطالبات، MIPROv2، بنسبة تزيد عن 10% (على سبيل المثال، +12% دقة في AIME-2025)".¹ MIPROv2 هو المُحسن الذي حل محله GEPA فعلياً داخل DSPy، لذا هذه هي النتيجة الأكثر مباشرة للمقارنة لأي شخص يقوم بالفعل بالبحث الآلي عن المطالبات.

لماذا تعتبر هذه تقنية وكلاء (Agent)، وليست مجرد خدعة LLM

هناك الكثير من الأدوات التي تعيد كتابة المطالبة. ما يجعل GEPA يقع تماماً في نطاق الوكلاء هو ما يتأمل فيه (reflects on). المسارات التي يأخذ منها عينات تشمل صراحة "الاستدلال، واستدعاءات الأدوات، ومخرجات الأدوات".¹ هذا هو تشريح تشغيل الوكيل، وليس مجرد إكمال نصي واحد. عندما يفشل الوكيل، عادة لا يكون الفشل بسبب "صياغة الكلمات كانت غير دقيقة قليلاً" — بل لأن الوكيل استدعى الأداة الخطأ، أو استدعى الأداة الصحيحة بترتيب خاطئ، أو أخطأ في قراءة مخرجات الأداة واستمر في العمل. هذه هي بالضبط الأحداث الموجودة في سجل التتبع (trace)، وهي بالضبط ما يمكن لخطوة التأمل (reflection step) تسميته وتصحيحه.

هذا يعيد صياغة معنى "هندسة الأوامر (prompt engineering) للعملاء الذكيين (agents)". كانت الحرفة القديمة عبارة عن إنسان يحدق في أمر النظام، ويخمن الصياغات، ويعيد تشغيل بعض الأمثلة يدويًا. أما الشكل الجديد فهو حلقة تحسين (optimization loop): حدد مقياسًا، والتقط آثارًا (traces) حقيقية، واترك "العاكس" (reflector) يقترح تغييرات يمكنه الدفاع عنها بناءً على تلك الآثار. بدأت هندسة الأوامر تبدو أقل شبهاً بكتابة النصوص الإعلانية وأكثر شبهاً بانضباط التقييم والتكرار الذي غطاه هذا الموقع حول اختبار أوامر LLM في CI — مع تحول الإنسان من مؤلف إلى مراجع.

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

إنها موجودة بالفعل في مجموعة أدواتك

لا يوجد شيء من هذا القبيل كأثر بحثي يتعين عليك إعادة تنفيذه. تتوفر GEPA بطريقتين.

داخل DSPy، هي مُحسن مدمج، موثق كـ "dspy.GEPA: Reflective Prompt Optimizer."³ تقوم بتزويده بـ GEPAFeedbackMetric يعيد كلاً من درجة (score) وسلسلة نصية من feedback (التغذية الراجعة) — هذه التغذية الراجعة النصية هي إشارة التحسين، وهذا هو الهدف الأساسي — وتختار ميزانية باستخدام معامل auto مضبوط على light أو medium أو heavy.³ المقياس الذي يحمل التغذية الراجعة هو الجزء الذي يستحق الاستيعاب: تكون GEPA في أفضل حالاتها عندما يستطيع المقياس الخاص بك قول شيء ما، وليس مجرد إصدار رقم.

كما أنها موجودة كمكتبة مستقلة، gepa-ai/gepa، والتي تقدم نفسها كوسيلة لـ "تحسين الأوامر، والأكواد، وأكثر من ذلك" من خلال التحسين العاكس المدعوم بالذكاء الاصطناعي.² حتى وقت كتابة هذه السطور، يمتلك المستودع عدة آلاف من النجوم ومئات التفرعات (forks) — وهو انتشار سريع لمُحسن يعود تاريخ ورقتة البحثية إلى عام مضى.²

و GEPA ليست الوحيدة في تعميم هذه الفكرة. تقوم المختبرات الكبرى الآن بشحن أدوات تحسين الأوامر الخاصة بها: يقوم Prompt Improver من Anthropic بإعادة كتابة أمر موجود باستخدام أفضل ممارسات هندسة الأوامر،⁵ وتقدم OpenAI لوحة تحكم Prompt Optimizer تقوم بنفس الشيء بناءً على الإرشادات الحالية.⁶ هذه أدوات تحسين أخف وزنًا وليست حلقات تطورية مدفوعة بالآثار، ولكن الاتجاه واضح — الأوامر المكتوبة يدويًا أصبحت نقطة بداية، وليست منتجًا نهائيًا.

العقبة: الأنظمة متعددة العملاء تكسر هذه القصة المثالية

إليك الجزء الذي تتجاهله معظم المقالات. أرقام GEPA هي أرقام لعميل واحد. ما يحدث عند توسيع نفس التحسين العاكس ليشمل فريقًا من العملاء الذكيين تم قياسه مباشرة في MAS-PromptBench، وهو اختبار مرجعي من يونيو 2026 يطرح عنوانه السؤال الجوهري: "متى يؤدي تحسين الأوامر إلى تحسين أنظمة LLM متعددة العملاء؟"⁴

الإجابة هي: أحياناً، وأحياناً أخرى تجعل الأمور أسوأ بكثير. يوضح الشكل 1 من المعيار نفسه الأمر ببساطة: "بينما يحسن GEPA باستمرار أداء الوكيل الواحد عبر جميع المهام الخمس المتنوعة، فإن امتداده الطبيعي متعدد الوكلاء ينتج تأثيرات متغيرة للغاية عبر المهام وطوبولوجيا سير العمل، تتراوح من مكاسب كبيرة إلى انخفاضات حادة في الأداء".⁴ وبالأرقام، "تصل التحسينات إلى 24.0 نقطة مئوية"، ولكن "يمكن أن ينخفض الأداء بمقدار 16.0 نقطة مئوية لبعض التكوينات".⁴

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

ماذا يعني هذا إذا كنت تبني وكلاء (agents)

هناك بعض الاستنتاجات العملية التي تخرج من هذا البحث.

أولاً، تعامل مع هندسة المطالبات (prompt engineering) كمشكلة تحسين ذات مقياس، وليس كتمرين في صياغة الكلمات. يحتاج GEPA وكل أداة تشبهه إلى طريقة لتقييم المخرجات؛ جودة مطالبتك المُحسَّنة مقيدة بجودة هذا المقياس. إذا لم تتمكن من قياسه، فلن تتمكن من تحسينه.

ثانياً، اجعل مقياسك يتحدث. أكبر رافعة في تصميم GEPA هي أن ملاحظاته تكون بلغة طبيعية، وليست مجرد قيمة عددية.¹³ المقياس الذي يعيد "فشل: استدعاء refund قبل التحقق من حالة الطلب" سينتج مطالبة أفضل من المقياس الذي يعيد 0.0. ابذل جهدك في هذا الجانب.

ثالثاً، قم بالتحسين بناءً على آثار (traces) حقيقية، بما في ذلك استدعاءات الأدوات. السبب الرئيسي الذي يجعل هذا يتفوق على إعادة كتابة المطالبات العامة للوكلاء هو أنه يفكر فيما فعله الوكيل فعلياً. قم بتزويده بتشغيلات تمثيلية، وليس أمثلة بسيطة.

رابعاً، لا تفترض أن نجاحات الوكيل الواحد تنتقل إلى إعداداتك متعددة الوكلاء. إذا كنت تشغل منسقاً (orchestrator) مع وكلاء فرعيين، فإن MAS-PromptBench هو التحذير الذي يجب أن تبقيه أمام عينيك: قم بالقياس قبل وبعد لكل طوبولوجيا، وكن مستعداً لأن يجعل المُحسِّن التكوين أسوأ.⁴ وهذا سبب إضافي يجعل البنية التحتية للإنتاج التي يتم بناؤها حول بيئات تشغيل الوكلاء تدمج بشكل متزايد التقييم والتتبع — فأنت بحاجة لكليهما لمعرفة ما إذا كانت المطالبة "المُحسَّنة" قد ساعدت فعلياً.

الخلاصة

تجاوز تحسين الأوامر لوكلاء الذكاء الاصطناعي مرحلة فارقة في عام 2026: النهج التأملي القائم على آثار التنفيذ الذي يمثله GEPA أصبح الآن مراجعاً علمياً، ومغلفاً برمجياً، ومتاحاً عبر عملية استيراد واحدة في DSPy. بالنسبة للوكلاء المنفردين، فإن الحجة قوية — فهو يتفوق على التعلم التعزيزي في مهام الورقة البحثية بينما يستهلك جزءاً بسيطاً من الحوسبة، ويفعل ذلك من خلال قراءة آثار استدعاء الأدوات الدقيقة حيث يفشل الوكلاء فعلياً.¹ أما النقطة التي تستوجب الحذر فهي الأنظمة متعددة الوكلاء، حيث تتأرجح الفكرة نفسها بين مكاسب كبيرة وتراجعات حقيقية.⁴ العبرة ليست "توقف عن كتابة الأوامر"، بل هي أن العمل الأكثر تأثيراً ينتقل إلى مستوى أعلى — من صياغة التعليمات إلى تحديد المقاييس والملاحظات وآثار التنفيذ التي تسمح للمُحسِّن بكتابتها نيابة عنك.