إدارة الحالة عبر الواجهة والخادم في تطبيقات الذكاء الاصطناعي

ماذا يعني "الحالة" في تطبيق مبني على الذكاء الاصطناعي

"الحالة" هي كل ما يحتاج تطبيقك لتذكره ليعمل بشكل صحيح من لحظة لأخرى.

إذا ضغط المستخدم على إرسال في واجهة دردشة، فلا يجب أن ينسى التطبيق ما كتبه المستخدم، أو ما رد به المساعد بالفعل، أو ما إذا كانت هناك عملية طلب جارية، أو الإعدادات المفعّلة (نغمة، نموذج، أدوات). كل ذلك هو حالة.

الحالة، بعبارات بسيطة

طريقة مفيدة للتفكير في الحالة هي: الحقيقة الحالية للتطبيق — القيم التي تؤثر على ما يراه المستخدم وما يفعله النظام لاحقًا. هذا يشمل أشياء واضحة مثل حقول النماذج، لكنه يشمل أيضًا حقائق "غير مرئية" مثل:

• أي محادثة يتواجد فيها المستخدم
• ما إذا كان الرد الأخير يتم بثه تدريجيًا أم انتهى
• قائمة الرسائل وترتيبها
• استدعاءات الأدوات ونتائجها (نتائج البحث، استعلامات قاعدة البيانات، استخراج من ملفات)
• الأخطاء، المحاولات المتكررة، وتراجع بسبب حدود المعدل

لماذا لتطبيقات الذكاء الاصطناعي أجزاء متحركة أكثر

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

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

هذه الحركة الإضافية هي سبب أن إدارة الحالة غالبًا ما تكون التعقيد الخفي في تطبيقات الذكاء الاصطناعي.

ما ستغطيه هذه الدليل

في الأقسام التالية سنقسّم الحالة إلى فئات عملية (حالة الواجهة، حالة الجلسة، البيانات الدائمة، وحالة النموذج/وقت التشغيل)، ونوضّح أين يجب أن يعيش كل منها (الواجهة أم الخادم). سنغطي أيضًا المزامنة، التخزين المؤقت، المهام الطويلة، تحديثات البث، والأمان — لأن الحالة مفيدة فقط إن كانت صحيحة ومحمية.

مثال سريع

تخيل تطبيق دردشة يسأل المستخدم فيه: “لخّص فواتير الشهر الماضي وعلّم على أي شيء غير اعتيادي.” قد يقوم الخادم بـ(1) جلب الفواتير، (2) تشغيل أداة تحليل، (3) بث ملخص إلى الواجهة، و(4) حفظ التقرير النهائي.

لكي يبدو ذلك سلسًا، يجب أن يحتفظ التطبيق بسجل الرسائل، نتائج الأدوات، التقدم، والمخرجات المحفوظة — دون خلط المحادثات أو تسريب بيانات بين المستخدمين.

الطبقات الأربع للحالة: الواجهة، الجلسة، البيانات، والنموذج

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

1) حالة الواجهة (ما يفعله المستخدم الآن)

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

تطبيقات الذكاء الاصطناعي تضيف بضعة تفاصيل مخصّصة للواجهة:

• مؤشرات التحميل وحالات "يفكر"
• توكنات متدفقة (نص جزئي يظهر أثناء توليده)
• مسودات محلية للرسائل (قبل إرسالها)

حالة الواجهة يجب أن تكون سهلة إعادة التعيين وآمنة أن تُفقد. إذا حدّث المستخدم الصفحة، قد تفقدها — وهذا عادةً مقبول.

2) حالة الجلسة / المحادثة (السياق المشترك لتدفق المستخدم)

حالة الجلسة تربط المستخدم بتفاعل جاري: هوية المستخدم، معرّف المحادثة، ونظرة متسقة لتاريخ الرسائل.

في تطبيقات الذكاء الاصطناعي، يتضمن هذا غالبًا:

• تاريخ الرسائل (أو مراجع إليه)
• أثر استدعاءات الأدوات (ما الأدوات/الدوال التي نُفذت وبأي نتائج)
• خيارات مجموعة العمل مثل المشروع/المستند الحالي، النموذج المحدد، أو مساحة العمل

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

3) حالة البيانات (سجلات دائمة في التخزين)

حالة البيانات هي ما تخزّنه عمدًا في قاعدة بيانات: مشاريع، مستندات، تمثيلات تضمينية (embeddings)، تفضيلات، سجلات التدقيق، أحداث الفوترة، ونُسخ المحادثات المحفوظة.

بعكس حالة الواجهة والجلسة، حالة البيانات يجب أن تكون:

• دائمة (تبقى بعد إعادة التشغيل)
• قابلة للاستعلام (يمكن البحث/الفلترة)
• قابلة للتدقيق (يمكن فهم ما حدث لاحقًا)

4) حالة النموذج / وقت التشغيل (كيف تم تكوين الذكاء الآن)

حالة النموذج/وقت التشغيل هي الإعداد التشغيلي المستخدم لإنتاج إجابة: رسائل النظام، الأدوات المفعّلة، temperature/max tokens، إعدادات السلامة، حدود المعدل، وذاكرات مؤقتة.

بعضها تكوين (إفتراضات ثابتة)؛ وبعضها عابر (ذاكرات قصيرة العمر أو ميزانية توكن لكل طلب). معظم هذا ينتمي للخادم كي يُتحكم فيه بانتظام ولا يُكشف بلا داعٍ.

لماذا الفصل يقلّل الأخطاء

عندما تختلط هذه الطبقات، تحصل على إخفاقات كلاسيكية: الواجهة تعرض نصًا لم يُحفظ، الخادم يستخدم إعدادات مختلفة للـ prompt مما يتوقعه الواجهة، أو ذاكرة المحادثة "تتسرب" بين المستخدمين. الحدود الواضحة تخلق مصادر حقيقة أوضح — وتجعل من السهل معرفة ما يجب المحافظة عليه، وما يمكن إعادة حسابه، وما يجب حمايته.

ما الذي يعيش في الواجهة مقابل الخادم (ولماذا)

طريقة موثوقة لتقليل الأخطاء في تطبيقات الذكاء الاصطناعي هي تقرير، لكل جزء من الحالة، أين يجب أن يعيش: في المتصفح (الواجهة)، على الخادم، أو كليهما. هذا القرار يؤثر على الموثوقية، الأمان، ومدى "المفاجأة" عند تحديث الصفحة أو فتح تبويب جديد أو فقدان الشبكة.

حالة الواجهة: سريعة، مؤقتة، يقودها المستخدم

حالة الواجهة مناسبة للأشياء التي تتغير بسرعة ولا تحتاج للبقاء بعد التحديث. إبقاؤها محليًا يجعل الواجهة سريعة ويتجنب استدعاءات API غير ضرورية.

أمثلة شائعة فقط في الواجهة:

• نص المسودة الذي يكتبه المستخدم
• عوامل تصفية محلية وترتيب في جدول
• حالة النوافذ المنبثقة المفتوحة/المغلقة، التبويب المحدد، حالات hover

إن فقدت هذه الحالة عند التحديث، فعادةً مقبول.

حالة الخادم: موثوقة، حساسة، ومشتركة

حالة الخادم يجب أن تحمل أي شيء يجب الوثوق به، تدقيقه، أو فرضه باستمرار. هذا يشمل حالة تحتاج أجهزة/تبويبات أخرى لرؤيتها، أو التي يجب أن تبقى صحيحة حتى لو تم تعديل العميل.

أمثلة شائعة فقط في الخادم:

• الأذونات والأدوار
• حالة الفوترة/الاشتراك وحدود الاستخدام
• المهام طويلة الأمد (فهرسة مستندات، صادرات كبيرة، تدريبات دقيقة) وحالتها

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

حالة مشتركة: منسقة، لكن بمصدر حقيقة واحد

بعض الحالات طبيعتها مشتركة:

• عنوان المحادثة
• مصادر المعرفة المحددة للدردشة
• حقول ملف المستخدم المستخدمة عبر الأجهزة

حتى عندما تكون مشتركة، اختر "مصدر الحقيقة". عادةً ما يكون الخادم هو المرجع والواجهة تخزن نسخة مخبأة للسرعة.

قاعدة إبهام ونمط مضاد شائع

احتفظ بالحالة أقرب ما تكون إلى مكان الحاجة، لكن أحفظ ما يجب أن يبقى بعد التحديث أو تغيّر الجهاز أو الانقطاعات.

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

دورة حياة طلب AI النموذجية: من نقرة إلى اكتمال

ميزة ذكاء اصطناعي قد تبدو "إجراء واحد"، لكنها في الواقع سلسلة من انتقالات الحالة المشتركة بين المتصفح والخادم. فهم دورة الحياة يجعل من السهل تجنب واجهة غير متطابقة، سياق مفقود، أو رسوم مكررة.

1) إجراء المستخدم → الواجهة تُعد النية

يضغط المستخدم إرسال. الواجهة تحدث فورًا الحالة المحلية: قد تضيف فقاعة رسالة "قيد الانتظار"، تعطل زر الإرسال، وتلتقط المدخلات الحالية (نص، مرفقات، أدوات مختارة).

في هذه النقطة يجب على الواجهة توليد أو إرفاق معرفات ترابطية:

• conversation_id: أي سلسة ينتمي هذا
• message_id: معرف العميل للرسالة الجديدة
• request_id: فريد لكل محاولة (مفيد لإعادة المحاولة)

تسمح هذه المعرفات للطرفين بالحديث عن نفس الحدث حتى لو وصلت الردود متأخرة أو مرتين.

2) استدعاء API → الخادم يتحقق ويخزّن

ترسل الواجهة طلب API مع رسالة المستخدم والمعرفات. يتحقق الخادم من الأذونات، حدود المعدل، وشكل الحمولة، ثم يخزن رسالة المستخدم (أو على الأقل سجلًا ثابتًا غير قابل للتعديل) مفهرسة بـ conversation_id و message_id.

تمنع هذه الخطوة ظاهرة "التاريخ الوهمي" عندما يحدث تحديث للصفحة أثناء الطلب.

3) الخادم يعيد بناء السياق

للاستدعاء النموذجي، يعيد الخادم بناء السياق من مصدر الحقيقة:

• جلب الرسائل الأخيرة لـ conversation_id
• سحب السجلات المرتبطة (مستندات، تفضيلات، مخرجات أدوات)
• تطبيق سياسات المحادثة (رسائل النظام، قواعد الذاكرة، تقليم السياق)

الفكرة الأساسية: لا تعتمد على العميل لتزويد التاريخ الكامل. العميل قد يكون غير محدث.

4) تنفيذ النموذج/الأدوات → حالة وسيطة

قد يستدعي الخادم أدوات (بحث، استعلام DB) قبل أو أثناء توليد النموذج. كل استدعاء أداة يولّد حالة وسيطة يجب تتبعها مقابل request_id لكي يمكن تدقيقها وإعادة تشغيلها بأمان.

5) الرد (متدفق أو لا) → اكتمال الواجهة

مع البث، يرسل الخادم توكنات/أحداث جزئية. الواجهة تحدّث فقرة المساعد المؤقتة تدريجيًا، لكنها تعاملها كـ "قيد التنفيذ" حتى يحدد حدث نهائي اكتمالها.

6) نقاط الفشل التي يجب التخطيط لها

إعادة المحاولات، الإرسال المزدوج، والردود غير المرتبة تحدث. استخدم request_id لإزالة التكرار على الخادم، و message_id للتوفيق في الواجهة (تجاهل أجزاء متأخرة لا تطابق الطلب النشط). اعرض دائمًا حالة "فشلت" واضحة مع محاولة آمنة لا تُنشئ رسائل مكررة.

الجلسات وذاكرة المحادثة: الحفاظ على السياق دون فوضى

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

أهداف حالة الجلسة

استهدف: (1) الاستمرارية (المستخدم يمكنه المغادرة والعودة)، (2) الصحة (الذكاء يستخدم السياق الصحيح للمحادثة الصحيحة)، و(3) العزل (جلسة لا تتسرب إلى أخرى). إذا دعمت أجهزة متعددة، عامل الجلسات كـ scoped للمستخدم + scoped للجهاز: "نفس الحساب" لا يعني دائمًا "نفس الجلسة المفتوحة".

الكوكيز مقابل التوكنات مقابل جلسات الخادم

عادة تختار واحدًا من هذه الطرق لتحديد الجلسة:

• الكوكيز: الأبسط لتطبيقات الويب لأن المتصفح يرسلها تلقائيًا. ممتاز للجلسات التقليدية، لكن يجب ضبط أعلام الأمان (HttpOnly, Secure, SameSite) والتعامل مع CSRF.
• التوكنات (مثل JWT): جيدة للـ APIs والتطبيقات المحمولة لأن العميل يرفقها صراحة. تتوسع جيدًا، لكن إلغاء الصلاحية وتدويرها يتطلب تصميمًا إضافيًا (ولا تُخزن الحالة الحساسة داخل التوكن).
• جلسات الخادم: الخادم يخزن بيانات الجلسة (غالبًا في Redis)، والعميل يحمل فقط معرف جلسة غامض. أسهل للإبطال والتحديث، لكن يجب تشغيل وتوسيع محل تخزين الجلسات.

استراتيجيات ذاكرة المحادثة

"الذاكرة" هي فقط الحالة التي تختار إرسالها مرة أخرى إلى النموذج.

• السجل الكامل: الأكثر دقة، لكنه مكلف وقد يعيد نصوصًا حساسة قديمة.
• الملخص: احتفظ بملخّص متجدد بالإضافة إلى بعض اللفّات الأخيرة؛ أرخص وعادةً "كافٍ".
• سياق نافذة: الرسائل الأخيرة فقط؛ الأبسط، لكنه قد يفقد قرارات سابقة مهمة.

نمط عملي هو الملخص + النافذة: متوقّع ويساعد على تجنّب سلوك مفاجئ من النموذج.

استدعاءات الأدوات: قابلة للإعادة وقابلة للتدقيق

إذا استخدم الذكاء أدوات (بحث، استعلام قاعدة بيانات، قراءة ملفات)، خزن كل استدعاء أداة مع: المدخلات، الطوابع الزمنية، نسخة الأداة، والإخراج المعاد (أو مرجع إليه). هذا يتيح شرح "لماذا قال الذكاء ذلك"، وإعادة تشغيل تنفيذات للتصحيح، والكشف عندما تتغير النتائج لأن الأداة أو مجموعة البيانات تغيرت.

ضوابط الخصوصية

لا تخزن الذاكرة طويلة الأمد بشكل افتراضي. احتفظ بما تحتاجه فقط للاستمرارية (معرّفات المحادثة، الملخصات، سجلات الأدوات)، ضع حدود احتفاظ، وتجنّب حفظ نص المستخدم الخام إلا إذا كان هناك سبب منتج واضح وموافقة المستخدم.

مزامنة الحالة بأمان: مصادر الحقيقة والتعامل مع التعارضات

الحالة تصبح خطرة عندما يمكن تعديل نفس "الشيء" في أكثر من مكان — واجهتك، تبويب ثانٍ، أو مهمة خلفية تحدّث محادثة. الحل أقل عن الشيفرة الذكية وأكثر عن الملكية الواضحة.

عرّف مصادر الحقيقة

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

قاعدة عملية: إن كنت ستغضب لفقدانه عند التحديث، فمن المحتمل أنه ينتمي للخادم.

تحديثات واجهة المستخدم المتفائلة (استخدمها بحذر)

التحديثات المتفائلة تجعل التطبيق يبدو فوريًا: قم بتبديل إعداد، حدّث الواجهة فورًا، ثم أكد مع الخادم. تعمل جيدًا للأفعال منخفضة المخاطر وقابلة للعكس (مثل تمييز محادثة بنجمة).

تسبب ارتباكًا عندما قد يرفض الخادم أو يحوّل التغيير (فحوصات أذونات، حدود الحصة، التحقق، أو إعدادات الخادم الافتراضية). في تلك الحالات، أعرض حالة "جاري الحفظ..." وحدث الواجهة بعد التأكيد.

التعامل مع التعارضات (تبويبان، محادثة واحدة)

التعارضات تحدث عندما يحدث عميلان تحديثًا لنفس السجل اعتمادًا على إصدارات بداية مختلفة. مثال شائع: تبويب A وتبويب B يغيّران درجة حرارة النموذج.

استخدم ترقيم خفيف للإصدارات بحيث يكتشف الخادم الكتابات القديمة:

• طوابع updated_at (بسيطة وقابلة للتصحيح من الإنسان)
• ETags / رؤوس If-Match (مدمجة في HTTP)
• أرقام مراجعة متزايدة (كشف صريح عن التعارض)

إذا لم تتطابق النسخة، أعد استجابة تعارض (غالبًا HTTP 409) وأعد إرسال الكائن الأحدث من الخادم.

صمّم واجهات برمجة تطبيقات لتقليل عدم المطابقة

بعد أي كتابة، اجعل الـ API يعيد الكائن المحفوظ كما خُزن (بما في ذلك افتراضات الخادم، الحقول المطبّعة، والنسخة الجديدة). هذا يسمح للواجهة باستبدال نسختها المخبأة فورًا — تحديث مصدر الحقيقة مرة واحدة بدل التخمين مما تغيّر.

التخزين المؤقت والأداء: التسريع بدون حالة قديمة

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

ما الذي تخزّنه في العميل

التخزين المؤقت على جانب العميل يجب أن يركز على التجربة، لا السلطة. مرشّحون جيدون:

• معاينات المحادثات الأخيرة (عناوين، مقطع الرسالة الأخير)
• تفضيلات الواجهة (الثيم، النموذج المحدد، حالة الشريط الجانبي)
• حالة الواجهة المتفائلة (رسائل "جارٍ الإرسال")

ابقِ ذاكرة العميل صغيرة وقابلة للإتلاف: إذا اُمحيت، يجب أن يعمل التطبيق بإعادة جلب من الخادم.

ما الذي تخزّنه على الخادم

التخزين المؤقت على الخادم يجب أن يركز على العمل المكلف أو المتكرر:

• نتائج الأدوات الآمنة لإعادة الاستخدام (مثلاً: نتيجة طقس لمدينة نفسها خلال 5 دقائق)
• عمليات بحث التضمين ونتائج البحث المتجهي للاستعلامات المتكررة (غالبًا بـ TTLs قصيرة)
• حالة حدود المعدل وأعداد التحجيم (لحماية API والتكاليف)

وهنا أيضًا يمكنك تخزين الحالة المشتقة مثل عدادات التوكن، قرارات المراجعة، أو مخرجات تحليل المستند — أي شيء حتمي ومكلف.

أساسيات إبطال الكاش (دون تعقيد زائد)

ثلاث قواعد عملية:

1. استخدم مفاتيح كاش واضحة تُشفّر المدخلات (user_id, النموذج، باراميترات الأداة، نسخة المستند).
2. عيّن TTLs بحسب سرعة تغيّر البيانات. TTL قصيرة أفضل من منطق ذكي معقد.
3. تجاوز الكاش عندما تكون الصحة أكثر أهمية من السرعة: بعد تحديث مستخدم للمستند، تغيّر الأذونات، أو طلب تحديث صريح.

إذا لم تستطع شرح متى يصبح مدخل الكاش خاطئًا، لا تخزّنه.

لا تُخزن الأسرار أو البيانات الشخصية في كاش مشترك

تجنّب وضع مفاتيح API، توكنات المصادقة، النصوص الأولية التي تحتوي على نص حساس، أو محتوى المستخدم في طبقات مشتركة مثل CDN. إذا اضطررت لتخزين بيانات المستخدم، عزّلها بحسب المستخدم وشفّرها أثناء الراحة — أو احتفظ بها في قاعدة البيانات الرئيسية بدلاً من ذلك.

قياس التأثير: السرعة مقابل واجهة قديمة

يجب إثبات التخزين المؤقت، لا افتراضه. راقب زمن الاستجابة p95 قبل/بعد، معدل نجاح الكاش، وأخطاء مرئية للمستخدم مثل "تحدّثت الرسالة بعد العرض". استجابة سريعة تتناقض لاحقًا مع الواجهة غالبًا أسوأ من استجابة أبطأ لكنها متسقة.

الاستمرارية والمهام طويلة الأمد: الوظائف الخلفية، القوائم، وحالة الوظائف

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

ما الذي تحفظه (ولماذا)

احفظ فقط ما يفتح قيمة منتج حقيقية.

سجل المحادثات هو واضح: الرسائل، الطوابع الزمنية، هوية المستخدم، وغالبًا أي نموذج/أدوات مستخدمة. هذا يمكّن "الاستئناف لاحقًا"، آثار التدقيق، ودعم أفضل.

إعدادات المستخدم ومساحة العمل يجب أن تكون في قاعدة البيانات: النموذج المفضل، افتراضات temperature، مفاتيح تفعيل الميزة، رسائل النظام، وتفضيلات الواجهة التي تتبع المستخدم عبر الأجهزة.

الملفات والآثار (التحميلات، النص المستخرج، التقارير المولّدة) عادة تُخزن في تخزين كائنات مع سجلات قاعدة بيانات تشير إليها. قاعدة البيانات تحمل البيانات الوصفية (المالك، الحجم، نوع المحتوى، حالة المعالجة)، بينما مخزن الـ blob يحمل البايتات.

المهام الخلفية للعمليات الطويلة

إذا كان الطلب لا يمكن أن ينتهي ضمن مهلة HTTP عادية، انقل العمل إلى قائمة انتظار.

نمط نموذجي:

• الواجهة تستدعي API مثل POST /jobs مع المدخلات (معرف الملف، معرف المحادثة، الباراميترات).
• الخادم يضع مهمة في الطابور (استخراج، فهرسة، تشغيل أدوات مجمعة) ويُعيد فورًا job_id.
• العمال يعالجون الوظائف بشكل غير متزامن ويكتبون النتائج إلى التخزين الدائم.

هذا يجعل الواجهة متجاوبة ويجعل إعادة المحاولة أكثر أمانًا.

حالة الحالة التي يمكن للواجهة الوثوق بها

اجعل حالة الوظيفة صريحة وقابلة للاستعلام: queued → running → succeeded/failed (اختياريًا canceled). خزّن هذه الانتقالات على جانب الخادم مع طوابع زمنية وتفاصيل الأخطاء.

على الواجهة، اعكس الحالة بوضوح:

• Queued/running: اعرض مؤشر تحميل وعطّل الأفعال المكررة.
• Failed: اعرض خطأ موجزًا، وزر إعادة المحاولة.
• Succeeded: حمّل الآثار الناتجة أو حدّث المحادثة.

اكشف عن GET /jobs/{id} (استطلاع) أو بث التحديثات (SSE/WebSocket) حتى لا تضطر الواجهة للتخمين.

مفاتيح عدم التكرار: إعادة المحاولات بدون كتابات مكررة

انقطاعات الشبكة تحدث. إذا أعاد العميل محاولة POST /jobs، لا تريد وظيفتين متطابقتين (وفواتيرتين).

اطلب Idempotency-Key لكل فعل منطقي. يخزن الخادم المفتاح مع job_id/الاستجابة ويعيد نفس النتيجة للطلبات المكررة.

سياسات التنظيف والانتهاء

تطبيقات الذكاء الاصطناعي طويلة الأمد تراكم بيانات بسرعة. حدّد قواعد الاحتفاظ مبكرًا:

• احذف المحادثات القديمة بعد N يومًا (أو أتاح للمستخدم التخصيص).
• احذف الآثار المشتقة عندما يُحذف المصدر.
• قم دوريًا بتنظيف الوظائف الفاشلة والملفات الوسيطة.

عامل التنظيف كجزء من إدارة الحالة: يقلّل المخاطر، التكلفة، والارتباك.

الردود المتدفقة والتحديثات في الزمن الحقيقي: إدارة الحالة الجزئية

البث يجعل الحالة أكثر تعقيدًا لأن "الإجابة" لم تعد قطعة واحدة. تتعامل مع توكنات جزئية (نص يصل كلمة بكلمة) وأحيانًا عملات أدوات جزئية (بدأت عملية بحث ثم انتهت لاحقًا). هذا يعني أن واجهتك وخادمك يجب أن يتفقا على ما يُعتبر حالة مؤقتة وما يُعتبر نهائية.

الخادم: بث أحداث مُصنّفة، لا نص فقط

نمط نظيف هو بث سلسلة من الأحداث الصغيرة، كلٍ بنوع وحمولة. على سبيل المثال:

• token: نص تدريجي (أو قطعة صغيرة)
• tool_start: بداية استدعاء أداة (مثلاً "جارٍ البحث..." مع معرف)
• tool_result: نتيجة الأداة جاهزة (نفس المعرف)
• done: رسالة المساعد مكتملة
• error: حدث فشل (ضمن رسالة آمنة للمستخدم ومعرف تصحيح)

سلسلة الأحداث هذه أسهل في الإصدار وتصحيح الأخطاء من بث النص الخام، لأن الواجهة يمكنها عرض التقدّم بدقة (وتظهر حالة الأداة) دون تخمين.

الواجهة: تحديثات قابلة للإلحاق فقط، ثم التثبيت النهائي

على العميل، عامل البث كإلحاق فقط: أنشئ رسالة مساعد "مسودة" واستمر في تمديدها مع وصول أحداث token. عند استلام done، قم بعملية تثبيت: علّم الرسالة كنهائية، احتفظ بها (إن خزنت محليًا)، وافتح الأفعال مثل النسخ، التقييم، أو التوليد مرة أخرى.

هذا يتجنّب إعادة كتابة التاريخ أثناء البث ويحافظ على واجهة متوقعة.

التعامل مع الانقطاعات (إلغاء، انقطاع، مهلات)

البث يزيد احتمال العمل نصف المكتمل:

• إلغاء المستخدم: أرسل إشارة إلغاء؛ أوقف عرض التوكنات؛ احتفظ بالمسودة ظاهرة كملغاة.
• انقطاع الشبكة: أوقف البث؛ اعرض "إعادة الاتصال..." ولا تفترض الإكمال.
• مهلات/أخطاء الخادم: أنهِ المسودة كفاشلة، ووفّر إعادة محاولة تبدأ طلبًا جديدًا (لا تُلصق التدفقات بصمت).

إعادة التحميل: إعادة البناء وإعادة تهيئة الحالة المستقرة

إذا أعيد تحميل الصفحة أثناء البث، أعِد البناء من الحالة المستقرة الأخيرة: الرسائل المثبتة الأخيرة بالإضافة إلى أي بيانات مسودة مخزّنة (message id، النص المتراكم حتى الآن، حالات الأدوات). إذا لم تستطع استئناف البث، اعرض المسودة كمنقطعة ودع المستخدم يعيد المحاولة، بدل التظاهر بأنها اكتملت.

الأمان والخصوصية: حماية الحالة من الطرف إلى الطرف

الحالة ليست فقط "البيانات التي تخزنها" — إنها مطالبات المستخدم، رفعاته، تفضيلاته، المخرجات المولّدة، والميتا التي تربط كل شيء. في تطبيقات الذكاء الاصطناعي، تلك الحالة قد تكون حساسة بشكل غير اعتيادي (معلومات شخصية، مستندات مملوكة، قرارات داخلية)، لذا يجب تصميم الأمان في كل طبقة.

احتفظ بالأسرار على الخادم

أي شيء قد يسمح للعميل بانتحال تطبيقك يجب أن يبقى على الخادم: مفاتيح API، موصلات خاصة (Slack/Drive/DB credentials)، ورسائل النظام أو منطق التوجيه الداخلي. يمكن للواجهة طلب فعل ("لخص هذا الملف"), لكن الخادم يجب أن يقرّر كيف ينفّذ ومع أية بيانات اعتماد.

فَوّض كل كتابة (ومعظم القراءات)

عامل كل تعديل للحالة كعملية مميزة تتطلب صلاحية. عندما يحاول العميل إنشاء رسالة، إعادة تسمية محادثة، أو إرفاق ملف، يجب على الخادم التحقق:

• المستخدم مُصَدّق.
• المستخدم يملك المورد (المحادثة، مساحة العمل، المشروع).
• للمستخدم الحق في إجراء ذلك (دور، حدود الخطة، سياسة المنشأة).

هذا يمنع هجمات "تخمين المعرف" حيث يبدّل أحدهم conversation_id ويصل إلى تاريخ مستخدم آخر.

لا تثق بالمتصفح: تحقق ونقّح

افترض أن أي حالة يزوّدها العميل إدخال غير موثوق. تحقق من الشكل والقيود (الأنواع، الأطوال، القيم المسموحة)، ونقّح للوجهة (SQL/NoSQL، السجلات، العرض HTML). إذا قبلت "تحديثات حالة" (مثلاً: إعدادات، باراميترات أدوات)، قوّم الحقول المسموح بها بدل دمج JSON عشوائي.

سجلات تدقيق للإجراءات الحرجة

للأفعال التي تغيّر الحالة الدائمة — المشاركة، التصدير، الحذف، وصول الموصل — سجّل من فعل ماذا ومتى. يساعد سجل تدقيق خفيف في الاستجابة للحوادث، دعم العملاء، والامتثال.

تقليل البيانات والتشفير

خزن فقط ما تحتاجه لتنفيذ الميزة. إن لم تكن بحاجة للنصوص الكاملة إلى الأبد، فكّر في نوافذ الاحتفاظ أو الحذف/التشويه. شفر الحالة الحساسة أثناء الراحة حيث يلزم (التوكنات، بيانات الاعتماد)، واستخدم TLS أثناء النقل. افصل الميتاداتا التشغيلية عن المحتوى حتى تستطيع تقييد الوصول بشكل أدق.

بنية مرجعية عملية وقائمة فحص للبناء

افتراضي مفيد لتطبيقات الذكاء الاصطناعي بسيط: الخادم هو مصدر الحقيقة، والواجهة تخزين مؤقت سريع وتفاؤلي. يمكن للواجهة أن تبدو فورية، لكن أي شيء ستنزعج لفقدانه (الرسائل، حالة الوظائف، مخرجات الأدوات، أحداث الفوترة) يجب تأكيده وتخزينه على الخادم.

إذا تبنّيت سير عمل "vibe-coding" — حيث تُنشأ الكثير من واجهات المنتج بسرعة — يصبح نموذج الحالة أكثر أهمية. منصات مثل Koder.ai يمكن أن تساعد الفرق في شحن تطبيقات ويب، خوادم، وتطبيقات محمولة من الدردشة، لكن نفس القاعدة تبقى: التكرار السريع يكون أكثر أمانًا عندما تُصمّم مصادر الحقيقة، المعرفات، وانتقالات الحالة مُسبقًا.

بنية مرجعية (قابلة للشحن)

الواجهة (متصفح/محمول)

• حالة الواجهة: اللوحات المفتوحة، نص المسودة، النموذج المحدد، مؤشرات "الكتابة" المؤقتة.
• حالة مخبأة من الخادم: المحادثات الأخيرة، حالة الوظيفة الأخيرة، مخزن البث الجزئي.
• خط أنابيب طلب واحد يرفق دائمًا: session_id, conversation_id, و request_id.

الخادم (API + عمال)

• خدمة الـ API: تتحقق من المدخلات، تنشئ سجلات، وتصدر ردود بثية.
• مخزن دائم (SQL/NoSQL): محادثات، رسائل، استدعاءات أدوات، حالة الوظائف.
• قائمة انتظار + عمال: المهام الطويلة (فهرسة RAG، تحليل ملفات، توليد صور).
• كاش (اختياري): قراءات ساخنة (ملخصات المحادثات، ميتاداتا التضمينات)، دائمًا مفهرسة بالإصدارات/الطوابع.

ملاحظة: طريقة عملية للحفاظ على الاتساق هي توحيد حزمة الخادم مبكرًا. على سبيل المثال، خلفيات مُولدة عبر Koder.ai غالبًا ما تستخدم Go مع PostgreSQL (وReact في الواجهة)، ما يجعل من السهل تركيز "مصدر الحقيقة" في SQL مع إبقاء كاش العميل قابلًا للإتلاف.

صمّم نموذج الحالة أولًا

قبل بناء الشاشات، عرّف الحقول التي ستعتمد عليها في كل طبقة:

• المعرّفات والملكية: user_id, org_id, conversation_id, message_id, request_id.
• الطوابع والترتيب: created_at, updated_at, وتسلسل صريح للرسائل.
• حقول الحالة: queued | running | streaming | succeeded | failed | canceled (للمهام واستدعاءات الأدوات).
• النسخ: etag أو version لعمليات تحديث آمنة من التعارض.

هذا يمنع الخطأ الكلاسيكي حيث تبدو الواجهة "صحيحة" لكنها لا تستطيع التوفيق بين المحاولات المتكررة، التحديثات، أو التعديلات المتزامنة.

اجعل أشكال الـ API متسقة

حافظ على نقاط النهاية متوقعة عبر الميزات:

• GET /conversations (قائمة)
• GET /conversations/{id} (جلب)
• POST /conversations (إنشاء)
• POST /conversations/{id}/messages (إلحاق)
• PATCH /jobs/{id} (تحديث الحالة)
• GET /streams/{request_id} أو POST .../stream (بث)

أعد دائمًا نفس شكل الغلاف في كل مكان (بما في ذلك الأخطاء) حتى تتمكن الواجهة من تحديث الحالة بشكل موحّد.

أضف قابلية الرصد حيث يمكن أن تنكسر الحالة

سجّل وارجع request_id لكل استدعاء ذكاء اصطناعي. سجّل استدعاءات الأدوات/مخرجاتها (مع تشويه)، الكمون، المحاولات، والحالة النهائية. اجعل من السهل الإجابة على: "ما الذي رآه النموذج، ما الأدوات التي عملت، وما الحالة التي حفظناها؟"

قائمة فحص للبناء (لتجنب أخطاء الحالة الشائعة)

• الخادم هو مصدر الحقيقة؛ تخزين واجهة العميل واضح وقابل للإتلاف.
• كل كتابة قابلة لإعادة المحاولة بأمان (آمنة لإعادة الإرسال) باستخدام request_id (و/أو Idempotency-Key).
• انتقالات الحالة صريحة ومحققة (لا قفزات صامتة من queued إلى succeeded).
• تحديثات البث تندمج بحسب المعرفات/التسلسل، لا بنهج "آخر رسالة تفوز".
• تُعالَج التعارضات عبر version/etag أو قواعد دمج على الخادم.
• لا تُخزن معلومات تعريف شخصية وبيانات حساسة في حالة العميل؛ شذّب السجلات افتراضيًا.
• توجد لوحة تحكم واحدة للتصحيح: الطلبات، استدعاءات الأدوات، حالة الوظائف، والأخطاء.

عند تبنّي دورات بناء أسرع (بما في ذلك التوليد المدعوم بالذكاء)، فكّر بإضافة ضوابط تُطبّق عناصر قائمة الفحص هذه تلقائيًا — تحقق الأشكال، عدم التكرار، والبث الحدثي — حتى لا يؤدي "التحرك السريع" إلى انحراف الحالة. في الممارسة العملية، هذا ما يجعل منصة شاملة مثل Koder.ai مفيدة: تُسرّع التسليم، مع السماح لك بتصدير الشيفرة المصدرية والحفاظ على أنماط التعامل مع الحالة متسقة عبر الويب، الخادم، وبنيات المحمول.