لماذا تحتاج وكلاء الذكاء الاصطناعي إلى أدلة قبل إعادة المحاولة

كيف تمنع تحوّل فقدان الاستجابة إلى إجراء مكرّر

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

هذا افتراضي بحت. يوضّح المثال مشكلة لا يمكن حلها بالاعتماد على دقة النموذج وحدها. ما الإجراءات التي ينبغي للوكيل اتخاذها إذا لم يتمكن من تحديد ما إذا كان إجراء سابق قد غيّر حالة البيئة؟

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

عدم ورود استجابة لا يثبت فشل العملية

عدم ورود استجابة لا يثبت أن الإجراء قد فشل. فهو لا يبيّن ما إذا كان خطأ قد وقع قبل التنفيذ، أو ما إذا كان الإجراء قد اكتمل من دون تأكيد، أو ما إذا كانت العملية لا تزال جارية.

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

قد تؤدي هذه القرارات إلى تغييرات في طريقة سير العمل التجاري. فعلى سبيل المثال، لا تُعد إعادة محاولة ردّ الأموال بمبلغ مختلف مجرد تكرار آخر للطلب نفسه. وبالمثل، فإن اختيار خدمة دفع ثانية بعد توقف الأولى عن الاستجابة ليس مجرد تكرار آخر للطلب نفسه.

يجب على الفرق التمييز بين منح الإذن بتنفيذ إجراء ومنح الإذن بالتعافي من نتيجة مجهولة. فالموافقة الأصلية لا تعني أن إعادة تنفيذ الإجراء آمنة.

أبحاث حديثة تقيس المخاطر

قدّمت ورقة بحثية أولية نُشرت في سبتمبر 2026، بعنوان «أين تتحقق خاصية التنفيذ مرة واحدة بالضبط؟»، معيار LIMBO واختبرت 25,930 حالة على تسعة نماذج. واختُبرت الخدمات المحاكاة في ظل فقدان إشعارات التأكيد، وتأخر المعالجة، وتسليم الطلبات المكررة.

من أصل 1,279 حالة نتج فيها أثر مكرر خلال الاختبار الرئيسي للمؤلفين، أفادت الوكلاء بإتمام العملية بنجاح في 90% منها. لذلك، قد يعلن الوكيل نجاح العملية حتى عندما يكون التنفيذ قد جرى على نحو غير صحيح.

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

وتتناول الورقة أيضًا أسباب عدم كفاية التحقق من الحالة الراهنة. فقد يصبح للطلب الذي لا يزال قيد المعالجة أثر بعد إجراء التحقق. وحتى الاستجابة الفارغة للحالة لا تعني أن الطلب لن يُنفَّذ في نهاية المطاف.

المحاولات المتكررة يجب أن تعبّر عن النية نفسها

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

تقدّم وثائق واجهة برمجة التطبيقات لدى Stripe أمثلة على آليات مفاتيح منع التكرار وحدودها. وفي API v1، يمكن حذف المفاتيح بعد مرور 24 ساعة على الأقل. وسيؤدي استخدام مفتاح محذوف مرة أخرى إلى إنشاء طلب جديد. كما تتحقق Stripe من تطابق المعلمات التي يقدّمها صاحب الطلب مع المعلمات الواردة في الطلب الأولي.

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

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

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

أوصاف الأدوات لا تكفي

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

تعامل مع عدم اليقين بوصفه حالة تشغيلية

الشكل 1. مسار تعافٍ مقترح للإجراءات ذات التبعات. وتتطلب كل محاولة إعادة أيضًا تفويضًا ساريًا.

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

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

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

قد يتطلب التعافي من الإخفاق اتباع إجراءات عمل مختلفة

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

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

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

اختبر المحاولة الثانية قبل النشر

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

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

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

ينبغي صياغة سؤال التقييم بوضوح: هل تمكّن النظام من توضيح ما يلي؟

• ما العملية التي جرى التفويض بها؟
• ما الأدلة المتاحة لإثبات نتيجتها؟
• لماذا كان مسموحًا إجراء محاولة أخرى؟

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