خطأ الأداة وفشل دور الوكيل ليسا وصفين متطابقين في عقد Agents API الذي نقرأه. قد ترسل نتيجة للأداة تخبر الوكيل بمشكلة، وقد يسجل النظام فشل الدور نفسه. نرسم حالتين مؤلفتين كي يبقى نوع الدليل واضحا قبل القول إن الوكيل توقف أو أصلح المشكلة.
الخلاصة السريعة
لا يلزم ذلك؛ نتيجة الأداة التي تصف خطأ وحالة فشل الدور إشارتان مختلفتان، ويجب قراءة كل منهما في موضعها الموثق.
- في عقد Functions، تعاد نتيجة الخطأ بقيمة success: false ورسالة error يمكن للوكيل استخدامها. [1] ليست الرسالة في مثالنا نتيجة قراءة ناجحة.
- يوثق Agents API فشل الدور عبر حالته وخطئه، ولا يعني فشل الدور دائما فشل الجلسة. [2] نراجع الحالتين منفصلتين.
- في بطاقاتنا، وجود رسالة «البطاقة غير مقروءة» لا يثبت استدعاء بديلا أو نجاح قراءة لاحقة؛ يلزم دليل مستقل للخطوة الجديدة.
- احفظ هوية الدور والاستدعاء والإشارة التي راجعتها وما بقي مجهولا. لا تحول غياب الإشارة من سجل ناقص إلى نفي لها؛ لم ننفذ استدعاء أو تعافيا.
ما الذي يحمل خطأ الأداة إلى المسار؟
تصف وثائق Functions إرجاع خطأ الأداة بقيمة success: false ورسالة error يستطيع الوكيل استخدامها. [1]
نخترع بطاقة نتيجة لدالة read_card: الاستدعاء ك 1 متعلق بالبطاقة ب 4، والرسالة «البطاقة غير مقروءة». هذه رسالة خطأ اخترناها للتمرين، وليست رمزا رسميا أو تشخيصا لملف. لا نستبدلها بمحتوى البطاقة ولا نسجل القراءة ناجحة.
نوع الرسالة يحدد ما وصل في بطاقة المثال. لا يخبرنا سبب عدم القراءة بالتفصيل: لم نقدم بيانات عن تلف أو ترميز أو صلاحية وصول. إضافة تفسير معقول لا تجعله سببا ثبت في السجل.
أين نقرأ فشل الدور والجلسة؟
عند agent.session.turn.failed، توجه الوثائق إلى مراجعة status وerror في الدور. وتوضح أن فشل الدور لا يعني دائما فشل الجلسة؛ تراجع حالة الجلسة أيضا. [2]
نضع بطاقة ثانية مستقلة للدور د 2، معلنين فيها حالة failed وخطأ مسجلا. هذه الحالة تخص الدور الذي سميناه. لا نصلها بالاستدعاء ك 1 لمجرد ظهور كلمة خطأ في الاثنين؛ المثال لم يقرر أنهما واقعة واحدة.
وبالمثل، لا نعلن أن الجلسة كلها انتهت من بطاقة الدور وحدها. يحتاج السؤال عن الجلسة إلى حالتها الفعلية. نتركها مجهولة إذا لم نقدم سجلها، بدلا من رسم نهاية لا يسندها ما أمامنا.
هل معرفة الخطأ تعني إصلاحه؟
نفترض في فرع آخر أن الوكيل تلقى بطاقة ك 1، ثم كتب طلبا مقترحا لقراءة البطاقة بطريقة أخرى. الطلب الجديد في سجلنا يدل على طلب خطوة؛ لا يثبت تنفيذها أو نجاحها. نحتاج إلى نتيجتها المرتبطة قبل وصف ما قرأ.
ولو أضفنا يدويا نتيجة جديدة تحمل نصا، نراجع ماذا تغطي: هل البطاقة ب 4 نفسها؟ هل النص كامل بحسب المهمة؟ نجاح خطوة لاحقة لا يحول رسالة الخطأ الأولى إلى قراءة ناجحة، ولا يمحو الفرق بين الخطوتين.
لم نقرر هنا سياسة إعادة محاولة أو إجراء تلقائيا لكل خطأ. فالمقال يفسر موضع الإشارة، ولا يعد بأن النظام سيختار بديلا مفيدا أو يواصل دون تدخل.
كيف نسجل ما ثبت وما لم يثبت؟
نقترح أعمدة للدور، والاستدعاء إن وجد، ونوع الإشارة، ومحتواها، ودليل المتابعة. تكتب بطاقة ك 1 نتيجة خطأ في قراءة معلنة، وتكتب بطاقة د 2 فشل دور معلن. لا تجمعهما تحت عنوان «فشل كل شيء».
إذا كانت المواد ناقصة، نقول إننا لم نراجع نتيجة متابعة أو حالة جلسة. لا يعني ذلك أنها لم توجد داخل النظام، كما لا يبرر افتراض وجودها. هذا حدود ما يعرفه المراجع من الورقة التي أعطيناه إياها.
الرسم يبين دليلين مختلفين ومراجعة لكل منهما، دون تشغيل نموذج أو دالة أو متابعة حالة. الفائدة هي تجنب قرار مبني على كلمة مشتركة بدل نوع السجل الذي وردت فيه.
المصادر ومتابعة القراءة
- OpenAI: Agents API Functions (يفتح في نافذة جديدة)developers.openai.com
- OpenAI: Agents API Errors and recovery (يفتح في نافذة جديدة)developers.openai.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.
