التعامل مع أخطاء الأدوات

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

زي الـ GPS اللي بيقولّك «الطريق مقفول» فتلاقي طريق تاني — أحسن بكتير من واحد بيسكت ويسيبك ماشي في الحيطة.

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

في كودك، حوّط تنفيذ الأداة بـ try/catch. لو حصل خطأ، متكسرش اللوب: رجّع للموديل tool result معلّم كـ error، فيه وصف مفيد وقابل للتصرّف («الإيميل مش موجود» أحسن من «Error 500»). الموديل ساعتها بيقرّر: يصلّح المدخلات، يجرّب أداة تانية، أو يسأل المستخدم. وحط سقف للمحاولات — لو الأداة فشلت ٣ مرات ورا بعض، وقّف اللوب ورجّع رد نظيف للمستخدم بدل حرق لفّات على خطأ ثابت.

🧪 جرّب بنفسك: أداة get_invoice بترجّع أحيانًا timeout. اكتب نسختين من رسالة الخطأ اللي بترجع للموديل: نسخة وحشة («Error») ونسخة كويسة («الاستعلام عن الفاتورة اتأخر أكتر من ٥ ثواني — ممكن تعيد المحاولة مرة واحدة أو تقول للمستخدم النظام بطيء»). جرّبهم وشوف الموديل بيتعافى إزاي مع كل واحدة، وحدّد فين بتحط سقف الإعادة.

أشهر الأخطاء: (1) تسيب الـ exception تطلع فوق وتكرش التطبيق كله. (2) ترجّع stack trace خام — بيلخبط الموديل وبيسرّب تفاصيل داخلية عن نظامك في محادثة المستخدم. (3) رسالة خطأ مبهمة زي «فشل» من غير سبب، فالموديل يعيد نفس المحاولة الغلط. (4) مفيش سقف للمحاولات فتفضل في لوب فشل-إعادة لا نهائي. (5) تخفي الفشل وترجّع نتيجة فاضية كأنها نجاح — فيؤلّف الموديل رد على داتا مش موجودة.

طبّق النمط ده على كل أداة بتكلّم العالم الخارجي: شبكة، داتابيز، APIs طرف تالت — أي حاجة ممكن تقع أو ترجّع فاضي.

الأخطاء البرمجية الحقيقية في كودك (bug في الـ handler نفسه) متتبعتش للموديل — دي بتتسجّل وتتصلّح عندك؛ الموديل مش هيصلّح الكود بتاعك.