LangGraph يكتسب تحمّل الأعطال: عمليات إعادة المحاولة والمهلات ومعالجات الأخطاء لوكلاء الإنتاج

نشرت LangChain دليلاً مفصلاً عن ثلاثة بدائيات مرونة مدمجة في LangGraph — بدونها، أي وكيل إنتاج سيفشل حتماً حيث عمل النموذج الأولي بسلاسة.

لماذا تفشل النماذج الأولية في الإنتاج في ظروف المختبر، يبدو وكيل

LangGraph موثوقاً: بيانات الإدخال ثابتة، واجهات برمجية التطبيقات الخارجية تستجيب بسرعة، المستخدم متاح دائماً. في التشغيل الفعلي، الصورة مختلفة. الخدمات الخارجية تتعطل أو تعيد 503 تحت الحمل. موفرو LLM في ذروة الطلب يؤخرون الاستجابات لدقائق. في سيناريوهات human-in-the-loop، قد لا يجيب الشخص لساعات. كل حالة من هذه الحالات، بدون معالجة خاصة، تتحول إلى وكيل معطل أو محطم. الحل الكلاسيكي — لف كل استدعاء في try/except، كتابة مؤقتات، إضافة منطق إعادة المحاولة يدويًا. هذا يعمل، لكن الكود الدفاعي ينمو، يختلط مع منطق العمل وينسج نفسه كمصدر أخطاء. تقدم LangGraph نهجاً مختلفاً: ثلاثة بدائيات مدمجة في المحرك وتعمل بشكل إعلاني.

RetryPolicy: محاولات إعادة تلقائية **RetryPolicy** تكوّن محاولات إعادة

تلقائية مع تراجع أسي. المعاملات القابلة للتكوين: الحد الأقصى لعدد المحاولات، التأخير الأولي، التأخير الأقصى ومعامل نموه بين المحاولات. يمكن تعيين السياسة بدقة — لعقدة معينة تستدعي واجهة برمجية خارجية غير مستقرة — أو تطبيقها على الرسم البياني بالكامل كافتراضي عام. الخيار الثاني مناسب عندما يجب أن يتبع كل التفاعل مع الخدمات الخارجية قواعد استرجاع موحدة.

TimeoutPolicy: حدود زمنية **TimeoutPolicy** تحل مهمة مختلفة — تحد من

الوقت المسموح للعقدة بأخذه. يتم دعم نوعين من الحدود: `wall_clock_timeout` — الحد الأقصى للوقت المنقضي لتنفيذ العقدة من البداية إلى النهاية `idle_timeout` — أقصى وقت عطل. مهم بشكل خاص في سيناريوهات human-in-the-loop: إذا لم يجب المستخدم في غضون N دقيقة، يجب أن يستمر الوكيل على فرع بديل أو ينتهي بخطأ يمكن دمج كلا الحدين في سياسة واحدة — سيتم تفعيل ما يأتي أولاً عند تجاوز الحد، يرفع المحرك تلقائياً استثناءً * السياسة قابلة للتطبيق على عقدة أو رسم بياني فرعي أو رسم بياني كامل الميزة الرئيسية لكلا البدائيات — تعيش داخل المحرك وترى السياق الكامل لحالة الرسم البياني. لا يستطيع المزينات والأغلفة الخارجية فعل ذلك.

error_handler وعمل SAGA **error_handler** — البدائية الثالثة، التي

تُطلق بعد استنزاف كل محاولات إعادة المحاولة. هذه هي نقطة الاسترجاع النهائية: التراجع عن الإجراءات المكتملة بالفعل، إرسال الإشعارات، حفظ التشخيصات، نقل الوكيل إلى حالة آمنة. للوكلاء متعددي الخطوات ذات التأثيرات الجانبية الحقيقية — حجز الموارد، خصم الأموال، إنشاء السجلات في الأنظمة الخارجية — توصي LangChain بنمط SAGA. الفكرة: كل خطوة من خطوات الوكيل مصحوبة بعملية تعويضية تبطل تأثيرها. إذا فشلت الخطوة N بعد الانتهاء الناجح من الخطوات من 1 إلى N-1، يتم إطلاق العمليات التعويضية بالترتيب العكسي — يعود النظام إلى حالة متسقة. يسمح LangGraph بدمج SAGA مباشرة في الرسم البياني: يتم تخزين التعويضات بجانب العقد، و error_handler ينفذ سلسلتها عند الفشل.

"وجود سياسات المرونة داخل المحرك، وليس خارجه — يشكل فرقاً جوهرياً: منطق الاسترجاع يحصل على السياق الكامل لحالة الرسم البياني," — مدونة

LangChain.

ما يعنيه هذا توفر

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