أنهى الوكيل مهمته لكن Telegram متوقف: طابور التسليم في agent-hub المكتوب بلغة Rust

موقف مألوف: قرأ الوكيل الشيفرة، وعدّل الملفات، وتحقق من النتيجة، وكتب ردًا ممتازًا. وفي تلك اللحظة يكون Telegram غير متاح. بالنسبة للوكيل انتهى العمل، أما بالنسبة للمستخدم فلم يحدث شيء. ولا يرغب أحد في إعادة تشغيل المهمة: فهذا يستهلك وقتًا ورموزًا (tokens)، ويحمل خطر أن يغيّر الوكيل شيئًا مرة أخرى. هذا بالضبط ما واجهه مؤلف agent-hub، وهو تطبيق مكتوب بلغة Rust يشغّل وكلاء الذكاء الاصطناعي محليًا ويتواصل معهم عبر مواضيع (topics) مجموعة Telegram.

فصل النتيجة عن التسليم

الفكرة الرئيسية بسيطة: استلام الرد وإرساله حدثان مختلفان. عندما ينتهي دور الوكيل بنجاح، يحفظ المحور (hub) النص النهائي أولًا في الملف المحلي topics.results.json ويضعه في الطابور، وبعد ذلك فقط يتصل بـ Telegram. وتتولى مهمة منفصلة الإرسال وإعادة المحاولة. وبعد إعادة التشغيل تقرأ الحالة من القرص وتواصل التسليم دون استدعاء جديد للنموذج.

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

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

كيف يصمد أمام الأعطال

دورة العمل هي: العثور على سجل جاهز، وحجزه لمدة 60 ثانية وحفظ ذلك على القرص، ثم إرسال الجزء الحالي، وتسجيل التأكيد، والانتقال إلى التالي. الحجز ضروري تحسبًا لانقطاع العملية في منتصف طلب الشبكة: فلا يبقى السجل محجوزًا إلى الأبد. وطلب Telegram محدود بـ 20 ثانية، ويجري الإرسال بمعدل لا يزيد على جزء واحد في الثانية.

عند حدوث خطأ مؤقت تطول المهل: 5 و15 و30 و60 و120 و300 و600 ثانية. وبعد ثماني محاولات فاشلة متتالية يتوقف التسليم حتى إعادة المحاولة يدويًا. وإذا طلب Telegram نفسه الانتظار (RetryAfter)، تُحفظ هذه المهلة لطابور المجموعة كلها ولا تُختصر لا بإعادة محاولة يدوية ولا بإعادة تشغيل. وإذا رفض Telegram شيفرة HTML، يحاول المحور إرسال نص عادي، وإن لم ينجح ذلك أيضًا ينتظر تدخل إنسان.

يمكن التحكم بالطابور من داخل الموضوع: يعرض الأمر /last آخر رد محفوظ دون استدعاء النموذج، ويعرض /outbox العناصر المنتظرة للتسليم مع زرّي «إعادة المحاولة» و«حذف». وفي الواجهة، عند حدوث خطأ في قراءة التخزين يظهر «غير معروف» لا صفر، حتى لا يبدو عطل القرص كأنه طابور فارغ.

أين تنتهي الضمانات

يتحلى المؤلف بالصراحة فلا يعد بالتسليم مرة واحدة بالضبط. فقد يكون Telegram قبل الرسالة وضاع التأكيد؛ أو لم يتمكن المحور من تسجيله على القرص قبل التوقف. عندها يُرسل الجزء مرة أخرى. ولهذا يبدأ كل جزء بمعرّف الدور ورقم مثل «الجزء 2/3»: هذه العلامة لا تزيل التكرار، لكنها توضح أنه إعادة إرسال وليس ردًا جديدًا.

وهناك حدود صارمة: حتى 50 ردًا منتظرًا و8 ميبيبايت (MiB) في الطابور، والاحتفاظ حتى 7 أيام، وحتى 64 كيبيبايت (KiB) للنص الواحد. وإذا امتلأ الطابور لا تُزاح السجلات القديمة، بل يُرسل الرد الجديد دون إعادة محاولة تلقائية ومع تحذير. يُنشأ الملف بصلاحيات 0600، لكنه يحتوي على ردود الوكيل، فينبغي الانتباه إلى النسخ الاحتياطية.

أُجريت الاختبارات على Linux مع محاكاة لـ Telegram وتخزين مؤقت: شبكة غير متاحة، وإعادة تشغيل بعد إرسال جزئي، وفقدان التأكيد، وRetryAfter، وخطأ HTML، والامتلاء، وتغيير المجموعة. ولم تُحاكَ حالة انقطاع الكهرباء.

ما يمكن الاستفادة منه

هذا النمط عام وصالح لأي أداة قائمة على الوكلاء: احفظ النتيجة قبل التسليم، وخزّن التقدم على مستوى الأجزاء، وامنح عمليات إعادة الإرسال معرّفات، ولا تَعِد بـ exactly-once حيث لا وجود له. إنه في جوهره نمط outbox صغير مألوف من الأنظمة الخلفية، لكنه هنا للوكلاء الذين تكون إعادة تشغيلهم مكلفة وغير آمنة. الشيفرة مفتوحة المصدر بترخيص MIT.