💻 computer science

Robust Agent Compensation (RAC): Teaching AI Agents to Compensate

تقدم الورقة البحثية "التعويض القوي للوكيل" (Robust Agent Compensation - RAC)، وهو نموذج استرداد قائم على السجلات يتكامل مع أطر عمل الوكلاء الحالية مثل LangChain لتوفير شبكة أمان للتنفيذ الموثوق، مُظهرةً أداءً فائقاً في زمن الاستجابة واقتصاد الرموز (token economy) مقارنةً بأحدث طرق الاسترداد في الاختبارات المعيارية المعقدة.

المؤلفون الأصليون: Srinath Perera, Kaviru Hapuarachchi, Frank Leymann, Rania Khalaf

نُشر 2026-05-06

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Srinath Perera, Kaviru Hapuarachchi, Frank Leymann, Rania Khalaf

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

إليك شرح لورقة بحثية بعنوان "التعويض القوي للوكيل (RAC)" باستخدام لغة بسيطة وتشبيهات من الحياة اليومية.

المشكلة: لحظة الـ "أوبس" (الخطأ غير المقصود) في الذكاء الاصطناعي

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

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

وكلاء الذكاء الاصطناعي الحاليون يشبهون ذلك الوكيل المهمل: عندما يتعثرون، غالبًا ما يتوقفون ببساطة، تاركين رحلتك وفندقك محجوزين. هم لا يعرفون كيف "يتراجعون" عما فعلوه بالفعل.

الحل: RAC (زر التراجع "Undo")

يقترح المؤلفون نظامًا جديدًا يسمى التعويض القوي للوكيل (Robust Agent Compensation - RAC). فكر في RAC كأنه شبكة أمان فائقة القوة أو زر "تراجع" رقمي يقع تحت وكيل الذكاء الاصطناعي.

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

كيف يعمل (التشبيه)

تخيل أن وكيل الذكاء الاصطناعي هو طاهٍ (شيف) يطبخ وجبة معقدة.

السجل: بينما يقوم الشيف بتقطيع البصل، وغلي الماء، وقلي اللحم، يكون RAC بمثابة كاتب يسجل كل إجراء في دفتر ملاحظات.
الخطأ: يحرق الشيف قطعة اللحم.
التعافي:
- الطريقة القديمة (بدون RAC): يصاب الشيف بالذعر، ربما يحاول كشط الجزء المحترق، أو يقدم اللحم المحترق كما هو. الوجبة تفسد تمامًا.
- طريقة RAC: يرى الكاتب عملية الحرق. يخبر RAC الشيف فورًا: "توقف! نحتاج إلى التراجع عن الخطوات الثلاث الأخيرة".
- ينظر RAC في السجل، ويجد خطوة "قلي اللحم"، ويقول: "حسنًا، نحتاج إلى عكس هذه الخطوة". ثم يبحث عن إجراء "تعويض" (مثل "ارمِ اللحم المحترق واسترد الأموال").
- إذا لم يستطع الشيف إصلاح اللحم، يعود RAC خطوة إلى الوراء: "حسنًا، تراجع عن غلي الماء". ثم "تراجع عن تقطيع البصل".
- النتي النتيجة: المطبخ يعود تمامًا كما كان قبل أن يبدأ الشيف. لا رائحة حريق، ولا أموال ضائعة. النظام نظيف.

خطة السلامة ذات الثلاث خطوات

عندما يفشل وكيل الذكاء الاصطناعي، لا يستسلم RAC فحسب، بل يتبع خطة صارمة من ثلاث خطوات:

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

لماذا هذا أفضل من الطرق الأخرى؟

تقارن الورقة البحثية بين RAC وطريقتين أخريين للتعامل مع الأخطاء:

طريقة "اسأل الذكاء الاصطناعي فقط" (ReAct): تشبه سؤال الشيف المرتبك: "مهلًا، لقد أحرقت اللحم، ماذا تفعل؟". قد يهلوس الشيف (يخترع أشياء غير موجودة) أو يرتبك بسبب التعقيد. إنها طريقة بطيئة وغير موثوقة.
طريقة "خطط لكل شيء أولاً" (SagaLLM): تشبه شيفًا يحاول كتابة كتاب وصفات مثالي مكون من 50 صفحة قبل طبخ أي شيء. إذا تعطل الفرن في منتصف الطريق، يجب على الشيف إعادة كتابة الكتاب الكامل المكون من 50 صفحة من البداية. هذا يستغرق وقتًا وجهدًا هائلين (توكنز/Tokens).

RAC هو النهج المتوازن (الذهبي):

لا يعتمد على الذكاء الاصطناعي "ليفكر" في كيفية الخروج من كارثة (وهو أمر بطيء وعرضة للخطأ).
لا يتطلب إعادة كتابة الخطة بأكملها في كل مرة يحدث فيها خطأ ما.
ببساطة، يتحقق من السجل، ويعكس الخطوات المحددة التي تسببت في الفوضى، ويبقي بقية الخطة مستمرة.

النتائج: أسرع وأرخص

اختبر المؤلفون RAC في مهام صعبة (مثل حجز الرحلات وجدولة الوظائف) حيث تم تصميم بعض الأمور لتتعطل.

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

المكون "السحري": السجل (The Log)

السر وراء RAC هو سجل المعاملات (Transaction Log).

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

الملخص

التعويض القوي للوكيل (RAC) هو طريقة جديدة لجعل وكلاء الذكاء الاصطناعي موثوقين. بدلاً من الأمل في أن يكون الذكاء الاصطناعي ذكيًا بما يكفي لإصلاح فوضاه، يعمل RAC كمحاسب صارم يحتفظ بسجل مثالي لكل حركة. إذا ارتكب الذكاء الاصطناعي خطأً، يقوم RAC فورًا بعكس الخطوات لتنظيف الفوضى، مما يضمن أن النظام لن يترك خلفه حالة "معطلة" أبدًا. إنه يجعل وكلاء الذكاء الاصطناعي أسرع، وأرخص، وأكثر موثوقية بكثير.

ملخص تقني: التعويض القوي للوكلاء (RAC)

1. بيان المشكلة

تتناول الورقة البحثية التحدي الحاسم المتمثل في الموثوقية في تنفيذ الوكيل الذكي (AI agent execution)، مع التركيز بشكل خاص على منع "الآثار الجانبية غير المقصودة للتنفيذ". وبينما تعتمد تطبيقات الذكاء الاصطنا الأولى بشكل متزايد على الوكلاء (المعرفين ككيانات تدرك بيئتها وتتفاعل معها) لأداء مهام معقدة، فإن هؤلاء الوكلاء غالباً ما يعملون ضمن سير عمل يتحدد ديناميكياً أثناء وقت التشغيل (مثل أنماط ReAct أو Plan-and-Execute).

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

الاسترداد اليدوي: مطالبة المطورين بتوقع جميع مسارات التنفيذ الممكنة وكتابة كود الاسترداد للسيناريوهات الديناميكية هو أمر غير قابل للتطبيق ومعرض للخطأ.
الاسترداد القائم على النماذج اللغوية الكبيرة (ReAct/هندسة الأوامر): الاعتماد على النموذج اللغوي الكبير لاستنتاج خطوات الاسترداد أو إجراءات "التراجع" هو أمر غير موثوق. كما لوحظ في أعمال سابقة، تعاني النماذج اللغوية الكبيرة من صعوبة في التعامل مع سياقات الفشل المعقدة، مما يؤدي إلى أخطاء، خاصة عندما تكون أمثلة التعلم من أمثلة قليلة (few-shot) غير كافية.
الاسترداد القائم على التخطيط (مثل SagaLLM): النهج الذي يعتمد على التخطيط المسبق وإعادة التخطيط المتكرر يمكن أن يصبح مكلفاً للغاية من حيث عدد الرموز (tokens) وزمن الاستجابة (latency) عند مواجهة أخطاء غير معروفة. وغالباً ما تؤدي هذه النهج إلى حلقات إعادة تخطيط غير ضرورية وقد تترك آثاراً جانبية بسبب الهلوسة أثناء مرحلة التخطيط.

المشكلة الجوهرية هي كيفية تنفيذ رسم بياني (graph) من الوكلاء يحقق تنفيذاً موثوقاً — أي لا يترك أبداً آثاراً جانبية غير مقصودة بغض النظر عن النتيجة — دون إثقال كاهل المطور أو الاعتماد على قدرات الاستدلال الضعيفة للنماذج اللغوية الكبيرة في منطق الاسترداد.

2. المنهجية: التعويض القوي للوكلاء (RAC)

يقترح المؤلفون التعويض القوي للوكلاء (Robust Agent Compensation - RAC)، وهو نموذج استرداد قائم على السجلات (log-based) يتم تنفيذه كامتداد معماري متوافق مع معظم أطر عمل الوكلاء الحالية (مثل LangGraph و CrewAI). يقوم RAC بفصل آلية الاسترداد عن حلقة استدلال الوكيل، مما يوفر "شبكة أمان" تعمل بشكل مستقل عن قدرات الوكيل في معالجة الأخطاء.

البنية الأساسية

يقدم RAC ثلاثة مكونات رئيسية:

اعتراض الأدوات (Tool Interceptor): طبقة وسيطة تعترض جميع استدعاءات الأدوات. تقوم بتسجيل كل إجراء (البدء، الاكتمال، الخطأ) في سجل معاملات (Transaction Log) مستمر.
اعتراض الأخطاء (Error Interceptor): يكتشف حالات الفشل (سواء كانت أخطاء على مستوى المنصة أو أخطاء دلالية محددة من قبل المستخدم) ويقوم بتفعيل عملية الاسترداد.
مدير الاسترداد والتعويض (RCManager): محرك المنطق المركزي الذي يتعامل مع حل الفشل.

سير عمل الاسترداد

عند حدوث فشل، ينفذ RCManager عملية حتمية مكونة من ثلاث خطوات:

إعادة المحاولة (Retry): بالنسبة للأخطاء العابرة (التي يتم تحديدها عبر أكواد الخطأ أو تحليل النموذج اللغوي)، يحاول النظام إعادة المحاولة مع تأخير تدريجي (backoff).
البحث عن بديل (Alternative Search): إذا فشلت إعادة المحاولة، يقوم النظام بتحفيز النموذج اللغوي الكبير لإيجال أداة بديلة لتحقيق الهدف.
التعويض (التراجع/Rollback): إذا فشلت كل من إعادة المحاولة والبدائل، يبدأ RC-Manager عملية التراجع. يقوم بإعادة بناء رسم التنفيذ البياني من سجل المعاملات، ويرتب الإجراءات طوبولوجياً لضمان تعويض التبعيات قبل "الآباء" الخاصة بها، وينفذ إجراءات التعويض بترتيب "آخر من يدخل هو أول من يخرج" (LIFO).

تعريف أزواج التعويض

متطلب حرج لـ RAC هو القدرة على ربط الإجراء بعكسه (مثلاً: book_flight $\leftarrow$ cancel_flight). يدعم RAC ثلاثة آليات لاكتشاف هذه الأزواج، مرتبة حسب الأولوية كالتالي:

واجهة برمجة تطبيقات إطار عمل الوكيل (Agent Framework API): يحدد المطورون صراحةً أزواج التعويض وخرائط المدخلات في إعدادات الوكيل.
بروتوكول سياق النموذج (Model Context Protocol - MCP): تتضمن تعريفات الأدوات ملاحظات (مثل x-compensation-tool) تسمح بالاكتشاف الدينامي من قبل أي وكيل يستخدم الأداة.
الاكتشاف بواسطة النموذج اللغوي الكبير (LLM Discovery): إذا كانت التعريفات الصريحة مفقودة، يقوم النظام بتحفيز النموذج اللغوي الكبير لاستنتاج إجراء التعويض وربط المدخلات من نتائج التنفيذ السابقة.

إذا تعذر العثود على إجراء تعويض، يفترض RAC أن الأداة ليس لها آثار جانبية (وهو افتراض تبسيط تم ذكره كعمل مستقبلي).

3. المساهمات الرئيسية

تحدد الورقة ست مساهمات رئيسية:

نموذج RAC: بنية استرداد قائمة على السجلات يمكن دمجها في معظم أطر عمل الوكلاء عبر نقاط الامتداد، مما يضمن التنفيذ الموثوق دون تعديل كود الوكيل الحالي.
توسيع الاختبارات المرجعية (Benchmark Extension): تحديد وتوسيع الاختبارات المرجعية الحالية ( $\tau^2$ -bench و REALM-Bench) لتشمل "الأعطال الديناميكية" (الأعطال غير الموصوفة صراحة في الأوامر) و"السيناريوهات غير القابلة للحل" التي تتطلب تعويضاً متعدد الخطوات.
معيار التوافق التشغيلي: استخدام مواصفات MCP لتعريف أزواج التعويض، مما يخلق طريقة معيارية وقابلة للتشغيل البيني لأطر العمل لاكتشاف منطق الاسترداد.
تحليل الأداء: تقديم أدلة تجريبية تظهر تفوق RAC على أساليب الاسترداد القائمة على النماذج اللغوية الكبيرة (تحديداً SagaLLM) من حيث زمن الاستجداء واقتصاد الرموز للمشكلات المعقدة.
فصل الاستدلال: إثبات أن فصل منطق الاسترداد عن وكلاء ReAct يسمح لهؤلاء الوكلاء بحل مشكلات أصعب من خلال إزالة عبء معالجة الأخطاء من حلقات الاستدلال الخاصة بهم.
التنفيذ مفتوح المصدر: توفير تنفيذ مرجعي لـ RAC يعتمد على LangChain/LangGraph.

4. نتائج التقييم

قيم المؤلفون RAC مقابل ثلاثة خطوط أساسية (baselines):

SagaLLM: نهج متطور قائم على التخطيط.
LG (LangGraph): وكيل ReAct تقليدي.
LG(PE): وكيل ReAct مع هندسة أوامر للاسترداد.

الإعداد التجريبي:

الاختبارات المرجعية: توسيع $\tau^2$ -bench (الطيران، التجزئة، الاتصالات) و REALM-Bench (التخطيط/الجدولة).
النماذج: بشكل أساسي gemini-2.5-flash مع دراسات استئصال باستخدام GPT-5.4.
المقاييس: معدل النجاح، معدل الإكمال، زمن الاستجابة (latency)، وكفاءة الرموز (token efficiency).

النتائج الرئيسية:

كفاءة الرموز وزمن الاستجابة: في المشكلات المعقدة (خاصة في REALM-Bench)، أظهر RAC أداءً أفضل بمقدار 1.5 إلى 8 أضعاف في كل من زمن الاستجابة واقتصاد الرموز مقارنة بـ SagaLLM. غالباً ما دخل SagaLLM في حلقات إعادة تخطيط مكلفة عند مواجهة اضطرابات غير متوقعة، مستهلكاً رموزاً أكثر بكثير (على سبيل المثال: 20 ضعف الوقت و 34 ألف عملية تعويض غير ضرورية في حالات فشل محددة).
الأعطال الديناميكية: في السيناريوهات ذات الأعطال الديناميكية (مثل P12، P13، P14)، فشلت وكلاء ReAct التقليدية (LG) وحتى النسخ المطورة بالأوامر (LG(PE)) بشكل متكرر أو امتنتت عن الإجابة. عانى SagaLLM من حلقات إعادة التخطيط وحدود الرموز. نجح RAC في التعامل مع هذه الحالات بالاعتماد على التراجع الحتمي بدلاً من إعادة تخطيط سير العمل بالكامل.
النماذج عالية الاستدلال: أظهرت دراسات الاستئصال باستخدام نموذج عالٍ الاستدلال (GPT-5.4) نتائج مختلطة. بينما حسن النجاح في بعض الحالات، إلا أنه أدى أيضاً إلى هلوسة وزيادة التكاليف (تصل إلى 1.5 مليون رمز لكل مهمة) دون ضمان الموثوقية، مما يشير إلى أن الاستدلال العالي وحده غير كافٍ للاسترداد القوي.
الارتقاء بـ ReAct: من خلال نقل معالجة الأخطاء إلى RCManager، تمكنت وكلاء ReAct داخل إطار عمل RAC من معالجة سياقات الفشل بشكل أكثر فعالية، وبدت قادرة على حل مشكلات أصعب مما يمكنها فعله بمعزل عن الإطار.

5. الأهمية والادعاءات

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

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

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