هل يفتقر تنسيق وكلاء الذكاء الاصطناعي إلى الموثوقية؟ المشكلة لا تكمن في البروتوكولات، بل في المعايرة وحلقات التغذية الراجعة

إن أطر العمل الحالية السائدة لوكلاء الذكاء الاصطناعي تشكل في جوهرها هياكل «تنسيقية ضعيفة» — وليس هذا نقصًا، بل هو تسوية هيكلية مع عدم اليقين المتأصل في نماذج اللغة الكبيرة (LLM). ففحص التعليمات البرمجية والوثائق العامة المتاحة لأطر العمل AutoGen الإصدار 0.4.1، وLangGraph الإصدار 0.2.0، وVertex AI Agent Builder يكشف أن طبقات تمرير الرسائل فيها لا تفرض أي مخطط منظم، ولا توفّر معاني مضمنة لإشارات التأكيد أو الرفض (ACK/NACK)، ولا تسجّل تلقائيًّا الطوابع الزمنية على مستوى كل خطوة (البدء/التأكيد/انتهاء المهلة)، كما تفوّض التحكم في الصلاحيات إلى أنظمة إدارة الهوية والوصول (IAM) الخارجية بدلًا من تضمين آلية التفويض داخل البروتوكول ذاته. وهذه الإغفلات ليست أخطاءً، بل هي استجابة مباشرة لثلاث خصائص جوهرية في نماذج اللغة الكبيرة: عدم اليقين في المخرجات (أي تنوُّع الاستجابات الدلالية لنفس المدخلات تحت إعدادات مختلفة لمعامل الحرارة)، والتأخر العالي في الاستجابة (تقلبات زمن استدعاء واجهة برمجة التطبيقات + زمن الاستنتاج لتصل إلى نطاق الثواني)، والغموض الدلالي (فقد تعني عبارة «اكتمل التأكيد» عرض واجهة المستخدم، أو كتابة البيانات في قاعدة البيانات، أو موافقة المراجعة البشرية). ففرض بروتوكولات التوزيع التقليدية (مثل بروتوكول العمليتين) على هذه البنية التحتية سيؤدي إلى عواصف من انتهاء المهلات، وحدوث عمليات تجمُّد متكررة، وصعوبات غامضة في التصحيح — لأن مطلب البروتوكول بالـ«الذرية» يتناقض وجوديًّا مع «التوليد الدلالي الاحتمالي» الخاص بنماذج اللغة الكبيرة. وبالتالي، فقد توصّل مجتمع المهندسين تلقائيًّا إلى نموذج بديل: وهو ربط التنسيق بقابلية المراقبة، واستخدام التدخل البشري كصمام أمان. فتتبع حالة StateGraph في LangGraph، وعرض المسارات من طرف إلى طرف في LangSmith، والاستخدام المنتشر في الإنتاج لوسيلة نقل الأحداث RabbitMQ، كلُّها تقدّم قيمةً ليس من خلال ضمان الاتساق القوي، بل من خلال جعل الانحرافات قابلةً للموقع، وجعل القرارات قابلةً للتتبع، وتمكين التدخلات في الوقت المناسب. وجوهر هذا التحوّل النموذجي هو إعادة تعريف موثوقية التنسيق — من «موثوقية مضمونة بالبروتوكول» إلى «موثوقية مدفوعة بقابلية المراقبة وحلقة التدخل البشري».

ومع ذلك، فإن رفع «قابلية المراقبة + التدخل البشري» إلى مبدأ شمولي شامل يخلق تحيّز تأكيد جديد. ويُشير الناقدون إلى أن StateGraph في LangGraph لا توفّر وظيفة «اللقطة» (snapshot) — فهذه العبارة لا تظهر في الوثائق الرسمية على الإطلاق؛ كما أن تمرير الحالة فيه يعتمد على تسلسل نماذج Pydantic، ما يُطبّق ضمنيًّا آلة حالة مركزية، مما يناقض نواة النموذج المزعوم للنشر والاشتراك اللامركزي. وهذا يكشف عن امتزاجٍ حرجٍ: إذ تُطبَّق حلول «النشر والاشتراك + قابلية المراقبة» المزعومة غالبًا في الممارسة العملية على أنها «مراقبة مركزية للحالة»، ما يُخفي انهيار مقدماتها النظرية. والأهم من ذلك أن حدود حلقة التدخل البشري نفسها هشّة — فعند وضع نقطة التدخل البشري عند مرحلة تحويل الأموال، يمكنها بالفعل اعتراض الأخطاء، لكنها لا تستطيع منع تراكم إنتروبيا التنسيق الناتج عن انحراف النوايا عبر ١٢ جولة سابقة من الحوار؛ وعندما يحكم مهندس العمليات بأن «سير العمل طبيعي» استنادًا إلى مسار في LangSmith، فإنه يعتمد على الاستمرارية البصرية بين عُقد المسار — وليس على التحقق المتقاطع للالتزامات الدلالية بين العُقد. وهذا يعني أن قابلية المراقبة تضخّم فقط مدى ظهور المشكلة دون أن تمنح تلقائيًّا القدرة على الحكم؛ كما أن التدخل البشري يمنح سلطة النقض النهائية، لكنه لا يخفّف العبء المعرفي المطلوب لكل تدخل. وبالتالي، فإن إمكانية تطبيق هياكل التنسيق الضعيفة تعتمد صراحةً على شرطين ضمنيين: أولهما أن يمتلك المشغلون القدرة المستمرة على معايرة الانحرافات في نموذج العالم بين الوكلاء؛ وثانيهما أن تكون المؤسسة قد أرست بالفعل عادات فوقية تدعم حلقات التغذية الراجعة السريعة — كأن تُلزم، على سبيل المثال، بمقارنة نموذج العالم (بمواجهة النتيجة المتوقعة مقابل النتيجة الفعلية) بعد كل استيلاء بشري على التحكم، وإلا فإن قابلية المراقبة تتحوّل إلى وهم زخرفي.

ويؤدي هذا التحليل إلى رؤية قابلة للنقل: فكل أداة تدّعي أنها «تحل مشكلة تنسيق الوكلاء» ستتعرّض حتمًا لتدهور موثوقيتها على المدى الطويل إذا لم تدعم صراحةً التضمين المؤسسي للمعايرة وحلقات التغذية الراجعة. فمهما كانت دقة تعريف واجهة gRPC، فإن غياب الإعلانات القابلة للتفنيد لمخرجات الوكلاء (مثل: «تقييم حالة معرفة العميل (KYC) الذي يقدمه هذا الوكيل يحمل ثقة ≥٩٢٪، ويستند إلى أحدث قائمة تنظيمية للفترة الثانية من عام ٢٠٢٤») يجعلها صحيحة نحوياً لكنها خاملة دلالياً؛ ومهما كانت قوة آلة حالة سير العمل في Temporal، فإن غياب الآليات المدمجة لإيقاف التشغيل التلقائي وإعادة تحميل نموذج العالم عند اكتشاف الانحراف يجعلها تحوّل التعطلات العشوائية إلى عمليات تجمُّد مؤكدة. فمرونة التنسيق الحقيقية تبدأ بالاعتراف بأن مخرجات نماذج اللغة الكبيرة تحمل الانحراف في جوهرها — وتتوجّ ببناء بنية تحتية تكشف هذا الانحراف، وتقارنه، وتصحّحه. وهذه ليست مهمة برمجية فحسب، بل هي تصميم لهيكل معرفي تنظيمي.

إن مقارنة نظام ROS2 DDS — وهو وسيط للروبوتات — بتنسيق وكلاء الذكاء الاصطناعي تمثّل خطأً فئويًّا كلاسيكيًّا، ينبع من تجاهل الاختلافات الجوهرية في درجة التفصيل الدلالي، وقدرة التعافي من الأعطال، وقابلية تتبع السببية. فنظام ROS2 DDS ينجح لأنه يعمل ضمن قيود الوقت الحقيقي الصارمة: فبيانات المستشعرات تتميز بمخططات موضوعية مُعرَّفة بدقة (مثل: '/lidar/points' المُعرَّف كمصفوفة PointStamped)، وتسمح التسامحات الزمنية من رتبة الميلي ثانية بتطبيق سياسات جودة الخدمة (QoS) التي تفرض الترتيب والموثوقية، ويمكن التعويض عن أعطال النقطة الواحدة عبر أخذ عيّنات فيزيائية جديدة. أما في تفاعلات وكلاء نماذج اللغة الكبيرة، فإن رسالة «تم التحقق من الهوية» التي يرسلها «مساعد مصرفي» تملك مخططًا يتم توليده بلغة طبيعية — وقد تتضمّن قيودًا غير مُعلَّنة ضمنيًّا مثل «استنادًا إلى وثائق ممسوحة ضوئيًّا بواسطة تقنية التعرف الضوئي على الحروف (OCR)»، أو «بدون التحقق المتقاطع من بيانات رقاقة جواز السفر»، أو «صالحة حتى مارس ٢٠٢٥»؛ كما أن تقلبات زمن الاستجابة تخلق فراغًا دلاليًّا بين «استلام الرسالة» و«فهمها»؛ وبمجرد وقوع خطأ، فإن عمليات إعادة المحاولة البسيطة — كما في إعادة مسح ليزر الليدار — تكون مستحيلة، لأن الأخطاء غالبًا ما تنبع من انحرافات في نموذج العالم لدى وكلاء سابقين (مثل: تصنيف «تصريح الإقامة المؤقت» خطأً على أنه «حق الإقامة الدائم»)، ما يعني أن عمليات إعادة المحاولة لا تعيد سوى نفس الانحراف. وهكذا، فإن نموذج النشر والاشتراك يعمل جيدًا في استدعاءات الأدوات ذات القفزة الواحدة (مثل: «استدعِ واجهة برمجة تطبيقات الطقس وأعِدْ بيانات بصيغة JSON») حيث تكون الحدود الدلالية واضحة وحالات الفشل واحدة؛ لكنه في السيناريوهات التي تتضمّن خمس قفزات فأكثر، وأدوارًا متعددة (مساعد مصرفي + مدقق امتثال + شخص بشري في الحلقة)، ومتطلبات امتثال عالية (مثل: تقليل تتبع البيانات وفقًا للائحة العامة لحماية البيانات GDPR)، فإن غياب الالتزامات الصريحة بالحالة وآليات عزل الأعطال أدّى إلى انجرافات متكررة في الحالة في حالات واقعية مثل المشكلتين رقم ٢١٨٧ و٣٠٤٢ في مستودع GitHub الخاص بـAutoGen — حيث يعتقد وكيل ألف أن سير العمل اكتمل، بينما ينتظر وكيل باء شروطًا مسبقة بسبب بيانات مخبأة قديمة.

ويكشف هذا التباين أكثر عن سوء استخدام مصطلح «التنسيق»: ففي الأنظمة الروبوتية، يضمن التنسيق تزامن الإجراءات الفيزيائية؛ أما في أنظمة وكلاء الذكاء الاصطناعي، فيضمن التنسيق استقرار الإجماع الدلالي. وعندما يتعاون عدة وكلاء حول ملف عميل واحد، فإن نقطة الفشل الحقيقية نادرًا ما تكون فقدان الرسائل — بل الانجراف التدريجي التراكمي لنموذج العالم الذي يحتفظ به كل وكيل على حدة. فعلى سبيل المثال، يفترض نموذج العالم الخاص بمدقق الامتثال أن «مواطني الاتحاد الأوروبي يحتاجون إلى رقم ضريبي إضافي»، بينما لا يزال نموذج العالم الخاص بالمساعد المصرفي يتبع لوائح عام ٢٠٢٣ القديمة؛ وكلاهما يتبادل باستمرار «تحديثات الحالة» عبر قناة النشر والاشتراك، دون أن يُفعِّل أي منهما كشف التعارض الدلالي. وهنا، فإن التبني الواسع للمنسقين المركزيين (مثل Temporal.io) أو واجهات برمجة التطبيقات التي تعتمد على العقود المُرقَّمة (gRPC + Protobuf) لا يعود إلى تفوّق بروتوكولاتها، بل لأنها تُجبر العقود الدلالية على الظهور على مستوى الواجهة: فسير عمل Temporal يتطلب من كل خطوة أن تعرّف صراحةً مخططات المدخلات والمخرجات واستراتيجيات إعادة المحاولة؛ كما يجب أن تعلن واجهات gRPC عن إصدارات الخدمة وجدول إلغاء الحقول. وهذه المطالبة الصريحة توفر نقاط ارتكاز للمعايرة — فعند إطلاق إصدار جديد لمدقق الامتثال، يؤدي تغيير واجهة gRPC الخاصة به إلى تفعيل فحوصات التوافق فورًا في المساعد المصرفي، بدلًا من انتظار تراكم الانحراف الدلالي الصامت حتى يتحول إلى فشل منهجي.

وهذا يؤدي إلى رؤية رئيسية: إن قيمة اختيار البروتوكول لا تكمن في قوة الاتساق النظري، بل في قدرته على تحويل الانحراف الضمني إلى أحداث معايرة صريحة. فميزة «الارتباط المرن» في نموذج النشر والاشتراك غالبًا ما تتحوّل في سياقات نماذج اللغة الكبيرة إلى «انفصال دلالي»؛ والعكس صحيح، فإن تكلفة «الارتباط الوثيق» في واجهات برمجة التطبيقات (RPC) أو آلات الحالة تشتري بالضبط التوقيت المحدَّد لاكتشاف الانحراف. وهذا يفسّر لماذا تقبل الفرق العاملة في المجالات عالية المخاطر مثل المالية والرعاية الصحية تعقيد تطوير واجهات برمجة التطبيقات (RPC) برضى، وتتخلى عن نموذج النشر والاشتراك «الأكثر مرونة» — فهدفها الأساسي ليس التكرار المرن، بل ضمان أن يصبح كل انحراف في نموذج العالم حدثًا مسجلًا رسميًّا، وقابلًا للنسب، ومُحفِّزًا للمعايرة. وإدارة إنتروبيا التنسيق تبدأ برفع البروتوكولات من كونها أنابيب اتصال إلى واجهات معايرة.

إن انتهاك الترتيب الجزئي لمبتكر لامبورت (Lamport) يبدو سطحيًّا كخلل في الطوابع الزمنية، لكنه في جوهره يعكس انهيار السببية الدلالي في الأنظمة متعددة الوكلاء. ففي سيناريو نموذجي: يستدعي وكيل ألف واجهة برمجة تطبيقات الدفع ويسجّل «أُرسِلت»؛ بينما يولّد وكيل باء، المعتمد على ذاكرة التخزين المؤقت المحلية، حالة «مُؤكَّدة»؛ ويعكس كلا الطابعين الزمنيين وقت النظام المحلي، لكن حالة «مُؤكَّدة» الخاصة بوكيل باء تسبق في الواقع استلام وكيل ألف لاستجابة واجهة برمجة التطبيقات — وبالتالي فإن الاعتماد الوحيد على الطوابع الزمنية لترتيب الأحداث يؤدي إلى استنتاج خاطئ بأن وكيل باء تصرف قبل وكيل ألف، ما يُفكّك تمامًا منطق «الحدوث قبل». وتدعم منصة OpenTelemetry انتشار سياق التتبع، لكن تكوينها الافتراضي (أخذ العيّنات دائمًا) يبلغ بسهولة حدود عمق السجلات (مثل: الحد الافتراضي ١٢٨ مستوى) تحت أحمال عالية، ما يؤدي إلى اقتطاع السجلات اللاحقة في السلاسل الطويلة؛ أما خفض معدل أخذ العيّنات يدويًّا فيخفّف الضغط على الموارد، لكنه يعرّض مسارات الفشل الحرجة بالضبط لخطر الغياب. ونظريةً، يمكن لساعات المتجهات (Vector clocks) حل مشكلات الترتيب الجزئي، لكن تطبيقها يتطلب من الوكلاء تبادل حالات المتجهات — وهي عملية بيانات تحكم خارج النطاق (out-of-band) لا تمر عبر استنتاج نماذج اللغة الكبيرة، وبالتالي لا تستهلك أي رمز (token). ولذلك كانت التوصيفات السابقة لعبء ساعات المتجهات على أنها «استهلاك رموز» سوء فهم جوهريًّا. أما العقبة الحقيقية فهي في مكان آخر: فساعات المتجهات تتطلب من كل وكيل أن يحتفظ بمتجه كامل ويسلسله، ما يفرض عبئًا بروتوكوليًّا على الوكلاء الخفيفة (مثل الخدمات المصغرة التي تعالج فقط تحويل التنسيق)، ويتعارض مع باراديغمات الأطر الحالية (مثل نموذج تمرير الحالة في LangGraph).

وبالتالي، يجب أن توازن الحلول العملية بين الصلاحية الدلالية والجدوى الهندسية: فعند نقاط اتخاذ القرار الحرجة (مثل تحويلات الأموال، وتوقيع العقود)، يجدر إدخال ساعات منطقية هجينة خفيفة (HLC) مقترنة بنقاط تدخل بشرية. وتدمج ساعة HLC بين الساعات الفيزيائية والعدادات المنطقية، ما يسمح بتقدّم أحادي الاتجاه أثناء انقطاع الشبكة، ويتجنب انجراف الساعات المنطقية البحتة؛ كما أن عبء تسلسلها أقل بكثير من عبء ساعات المتجهات، وتتكامل بسلاسة مع رؤوس HTTP أو بيانات gRPC الوصفية. ومع ذلك، فإن ساعة HLC وحدها لا تحل الغموض الدلالي — فهي تضمن أن «تعليمات التحويل» تحدث بعد «موافقة مراقبة المخاطر»، لكنها لا تضمن أن فهم وكيل مراقبة المخاطر لمصطلح «مخاطر عالية» يتماشى مع فهم وكيل التحويل لهذا المصطلح نفسه ضمن نفس نموذج العالم. وهنا، لا تخدم نقطة التدخل البشري كبديل للأتمتة، بل كمحفّز للمعايرة: فعندما تشير ساعة HLC إلى أن التحويل هو «حدث حرج عبر نطاقات الساعات»، يجمّد النظام تلقائيًّا الإجراءات اللاحقة ويعرض لوحة تحقق منظمة، تتطلب من المشغل مقارنة «النتيجة المتوقعة» (مثل: «ينخفض رصيد حساب العميل بمقدار ١٠٠٠٠ دولار أمريكي») مع «النتيجة الفعلية» (مثل: «ينخفض الرصيد بمقدار ١٠٠٠٠ دولار أمريكي، لكن الرسوم تبقى غير محصودة»)، وتوثيق سبب الانحراف إلزاميًّا (مثل: «فشل نموذج العالم في مزامنة أحدث جدول للرسوم»). وهذه العملية تحوّل مفهوم «عدم إمكانية تتبع السببية» المجرد إلى «تسجيل انحراف نموذج العالم» الملموس.

ويكشف هذا الأسلوب عن رؤية أعمق وقابلة للنقل: إن إعادة بناء الترتيب الزمني يجب أن تتم بالتوازي مع معايرة الترتيب الدلالي. فتركز أنظمة التوزيع التقليدية على سؤال «متى حدث الحدث؟»؛ أما أنظمة وكلاء الذكاء الاصطناعي فيجب أن تسأل «كيف فُسِّر الحدث ضمن أي نموذج عالم؟». فساعة HLC تحل السؤال الأول؛ أما نقطة التدخل البشري فتفرض السؤال الثاني في حلقة مغلقة. وأي محاولة لتحسين دقة الطوابع الزمنية بمعزل عن مقارنة نموذج العالم (مثل نشر خوادم وقت بروتوكول التزامن الدقيق PTP) ستنتهي حتمًا إلى «خطأ دقيق» — أي أن النظام يعيد بناء خط زمني للعطل بدقة تامة، لكنه لا يستطيع تفسير سبب خطأ جميع الوكلاء الجماعي في تقدير سعر الصرف في اللحظة نفسها. فالقابلية الحقيقية لتتبع السببية هي معايرة ذات مسارين — للخطوط الزمنية والخطوط الدلالية — ولا يكفي أحدهما بدون الآخر.

يجب ألا يتبع التنسيق الطبقي مكدسات التكنولوجيا المُعدة مسبقًا، بل يجب أن يلتزم صراحةً بمبادئ التصنيف حسب مستوى المخاطر — التي تكمن في رسم حدود المسؤولية بين الإنسان والآلة وربطها بمقاييس ملموسة قابلة للمراقبة. وقد يُسمح للسلاسل القصيرة منخفضة المخاطر (≤٣ قفزات، ولا تتضمّن معالجة معلومات شخصية أو مالية) باعتماد نموذج النشر والاشتراك مع قابلية المراقبة — ولكن فقط إذا كانت قابلية المراقبة تتيح المعايرة الفورية: فيجب تهيئة StateGraph في LangGraph لوظيفة المقارنة التلقائية (auto-diff)، بحيث تُفعّل تنبيهات المعايرة كلما سقطت التغيرات في حالة العقد المجاورة تحت عتبة دلالية محددة مسبقًا (مثل: تقلّب «درجة مشاعر المستخدم» <٠٫٣)؛ ويجب أن تدعم مسارات LangSmith التصدير بنقرة واحدة لـ«لقطات نموذج العالم» — التي تتضمّن مجموعة القواعد الحالية لكل عقدة، وإصدار مصدر البيانات، والإعلانات المتعلقة بالثقة — وليس مجرد عرض تسلسل الاستدعاءات. فبدون هذه الإمكانيات، فإن مصطلح «منخفض المخاطر» لا يكون سوى حظٍّ محض، لأن الارتباط المرن في نموذج النشر والاشتراك يضخّم الانحرافات الصغيرة بصمت إلى فشل يشمل السلسلة بأكملها.

أما السلاسل الطويلة متوسطة المخاطر (التي تتضمّن استدعاءات عبر الأنظمة، وتتطلب مزامنة الحالة) فيجب أن تتضمّن منسقين صريحين — لكن نوع المنسق يجب أن يتطابق مع احتياجات المعايرة. فسير عمل Temporal ممتاز في الحفاظ على الحالة المستمرة واستراتيجيات إعادة المحاولة الصريحة، ما يجعله مناسبًا للسياقات التي تتطلب تحكمًا دقيقًا في الآثار الجانبية لكل خطوة (مثل تلبية الطلبات)؛ أما التسجيل بالأحداث (event sourcing) فيتفوّق في قابلية عكس نموذج العالم — فعندما يثبت خطأ نتيجة مراجعة الامتثال، يمكن التراجع إلى حدث معيّن وإعادة تشغيل السلسلة، ما يجبر جميع الوكلاء على إعادة الحساب استنادًا إلى نموذج العالم المصحّح. وقد تم تفنيد الاقتراح الأصلي لـ«تجميع السجلات مع خصوصية تفاضلية»: فخصوصية التفاضل تهدف إلى إخفاء الأفراد في المخرجات الإحصائية، ما يؤدي إلى تدمير إعادة بناء الحالة بدقة لسلاسل الطلبات الفردية — وهو ما يتعارض مباشرةً مع هدف «مزامنة الحالة». أما النهج الصحيح فهو «تطهير البيانات/إخفاءها» أو «التشفير على مستوى الحقول»، ما يضمن بقاء الحقول التي تحتوي معلومات شخصية غير قابلة للقراءة في السجلات، مع الحفاظ على الحالة التجارية الكاملة للتدقيق والمعايرة.

أما الحد الأدنى للمواقف عالية المخاطر والخاضعة للتنظيم الصارم (مثل GDPR/CCPA، واللوائح المالية) فهو واضح لا لبس فيه: يجب أن تمر جميع تفاعلات الوكلاء عبر طبقة RPC مُصادَق عليها وفق المخطط (gRPC/Protobuf)، ويجب أن تعلن كل واجهة عن عقود دلالية قابلة للتفنيد. فعلى سبيل المثال، يجب أن تتضمّن طريقة VerifyIdentity الخاصة بمدقق الامتثال في بروتوكول الاستجابة حقولًا مثل confidence_score (عدد عشري)، وsource_version (سلسلة نصية)، وexpiration_timestamp (طابع زمني) — وأي حقل مفقود يشكّل انتهاكًا للعقد. أما قيمة زر «التجميد بنقرة واحدة + الاستيلاء البشري» فهي لا تكمن في فعل التجميد ذاته، بل في قدرته التلقائية على التقاط وتأمين جميع لقطات نموذج العالم الخاصة بالوكلاء، والحالات الحالية، وثلاث جولات سابقة من المدخلات والمخرجات، وسجلات الانحراف لحظة التجميد — ما يرفع التدخل البشري من كونه حكمًا تجريبيًّا إلى قرارات معايرة قائمة على الأدلة. والمنطق المشترك عبر جميع المستويات الثلاثة هو: إن اختيار التكنولوجيا يخدم كفاءة المعايرة — وليس الأداء أو المرونة؛ والمُوثوقية تتجسّد في النهاية كـ«سرعة تحديد الانحراف» و«يقين تنفيذ المعايرة»، وليس كـ«نسبة تسليم الرسائل».