وكيل الدعم في الإنتاج: Temporal والساغا وcircuit breaker تحمي المبالغ المستردة من الأعطال
وكيل الدعم في ملف واحد يعمل في العرض التجريبي، لكنه ينهار في بيئة الإنتاج: إعادة التشغيل تمحو المحادثات، وأي عطل بين الاسترداد والرد يترك سؤالاً عمّا إذا كانت الأموال قد خرجت. يبني كاتب Habr النظام خطوة بخطوة: واجهة API وقاعدة بيانات، وTemporal للعمليات الطويلة، وبوابة LLM مع circuit breaker، وساغا للاسترداد، ومشغّل بشري للمبالغ الكبيرة. ولا يُضاف أي مكوّن إلا عند ظهور مشكلة محددة.
معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
يكتب العميل: «لم تصل الطرد، أعيدوا لي أموالي». يمكن كتابة الوكيل الذي سيجيب على ذلك في أمسية واحدة: حلقة وثلاث أدوات، وفي العرض التجريبي يعمل كل شيء. ثم تُعاد العملية في منتصف الاسترداد، ويتعطل مزوّد النموذج نصف ساعة، ويضغط العميل «إرسال» مرتين. يتضح أن الوكيل ليس سوى جزء صغير من النظام. الجزء الأخير من السلسلة على Habr يجمع هذا النظام خطوة بخطوة، وقيمته الأساسية أن كل مكوّن يظهر استجابةً لعطل محدد.
من ملف واحد إلى API وworker وTemporal
النسخة الأولية تحتفظ بسجل المحادثة في ذاكرة العملية. إعادة التشغيل تمحو جميع المحادثات، ويُخدَّم العملاء واحداً تلو الآخر، وإذا سقطت العملية بين استدعاء refund_payment والرد فلا أحد يعرف هل عادت الأموال أم لا.
الخطوة الأولى: فصل السكربت إلى API وworker. تستقبل الـAPI الرسالة وتكتبها في قاعدة البيانات وتردّ على الدردشة فوراً. هي لا تستدعي النموذج، لذا تردّ في أجزاء من الثانية. أما حلقة الوكيل فتعيش في workers منفصلة يمكن إضافتها حسب الحمل. صار السجل في قاعدة البيانات وينجو من إعادة التشغيل.
لكن الـworker قد يسقط مع ذلك في منتصف المعالجة. إعادة الاسترداد خطرة: قد تدفع مرتين. وعدم إعادته سيئ أيضاً: قد لا تدفع إطلاقاً. هنا يأتي دور Temporal: فهو يكتب كل خطوة في سجل، ويتابع worker آخر من النقطة نفسها دون إعادة تنفيذ الخطوات المنجزة. حلقة الوكيل تعيش في workflow، وتتحول استدعاءات النموذج والأدوات إلى activities.
توضيحان مهمان. لدى Temporal قاعدة بياناته الخاصة، ولا تُخزَّن فيها بيانات العملاء التجارية: سجل التنفيذ الواحد محدود بـ 51200 حدث أو 50 ميغابايت. أما الـworkers التي تشغّل شيفرتكم فتطلقونها أنتم، وخدمة Temporal لا تنفّذها. وWorkflow ID تحدّدونه أنتم: خذوا معرّف المحادثة، ولن ينشئ الإرسال المتكرر نسخة مكررة. فقط لا تضعوا بيانات شخصية في المعرّف، فهو ظاهر في الواجهة وفي السجلات.
إعادة المحاولة ليست circuit breaker
عندما يتعطل مزوّد النموذج نصف ساعة، يعيد Temporal محاولة الـactivity بأمانة. مئة worker وألف طلب مفتوح تطرق معاً على الـAPI المتعطلة، وعندما تعود تنهال عليها الطابور بأكمله.
إعادة المحاولة مصممة لعطل يزول في ثوانٍ. أما الفشل الطويل فيحتاج إلى circuit breaker. فهو يعدّ الأعطال، وبعد بلوغ العتبة ينفتح ويعيد خطأً فوراً دون التوجه إلى الخدمة، وبعد فترة يسمح بمرور استدعاء تجريبي. يجب أن تكون حالة القاطع مشتركة بين جميع الـworkers، وإلا سيكتشف كل منها من جديد أن المزوّد متوقف. لذلك مكانه في بوابة LLM بين الـworkers والمزوّدين. فمثلاً يُخرج LiteLLM النموذج من التناوب بعد سلسلة أعطال، ويحوّل إلى نموذج احتياطي، ويخزّن الحالة في Redis.
نصيحة عملية من الكاتب: دعوا الـactivity تميّز بين نوعين من الأخطاء. الخطأ المؤقت تعيده سياسة Temporal. أما خطأ «القاطع مفتوح» فلا يجوز إعادة محاولته: يقرر الـworkflow بنفسه هل ينتقل إلى نموذج احتياطي أم ينتظر أم يحيل الطلب إلى مشغّل. وتوضع القواطع نفسها أمام خدمة التوصيل وبوابة الدفع.
الساغا والمشغّل والموجّه
يمسّ الاسترداد ثلاثة أنظمة بلا معاملة مشتركة: الملصق لدى خدمة التوصيل، والأموال في بوابة الدفع، وإشعار العميل وتحديث الطلب. هذه ساغا: لكل خطوة تعويض. المفهوم الأساسي هو نقطة اللاعودة (pivot transaction). قبل إعادة الأموال يمكن إلغاء الخطوات، وبعدها يجب إتمام رسالة العميل وتحديث الطلب مهما تطلّب ذلك من محاولات. يحصل كل إجراء على مفتاح idempotency، مثل معرّف القرار، فلا تخصم بوابة الدفع الأموال مرة ثانية.
يجب ألا يُجري النموذج المبالغ الكبيرة. يعرض الـworkflow القرار في لوحة المشغّل وينتظر إشارة. الانتظار مسجّل في السجل ولا يشغل worker، لذا يمكن للمشغّل أن يردّ بعد ساعة.
تتعلق الخطوة الأخيرة بالتكلفة. ليس كل طلب يحتاج حلقة وكيل كاملة. موجّه على نموذج صغير يرسل الأسئلة الشائعة إلى استدعاء واحد، وسؤال «أين طلبي» إلى سلسلة مكتوبة مسبقاً، ولا يصل إلى الوكيل إلا الاسترداد المتنازع عليه. المبدأ بسيط: اختيار أدنى مستوى تعقيد يحل المهمة بموثوقية.
ماذا نفعل بهذا
لا ينبغي بناء المخطط كله دفعة واحدة. ينصح الكاتب صراحةً بإضافة المكوّن عندما تظهر المشكلة التي يعالجها. إن كان لديكم عميل واحد في كل مرة ولا أموال متداولة، فتكفي قاعدة البيانات. وما إن تظهر آثار جانبية كالمدفوعات، تلزم idempotency وdurable execution. وما إن تظهر تبعية لمزوّد خارجي، يلزم قاطع مشترك.
وهناك قيود أيضاً. الشيفرة في المقال شيفرة زائفة. أما الادعاء بأن وكيل الويب Codex يعمل على Temporal فمصدره الشركة المطوِّرة نفسها، ولم يجد الكاتب تأكيداً مستقلاً. لكن كخريطة للأعطال النموذجية في النظام الوكيلي، فالنص مفيد لكل من يطلق وكيلاً في الإنتاج. ابدؤوا بسؤال: ماذا سيحدث لو سقطت العملية بعد أخطر استدعاء؟
- 16 يونيو 2026تسعة وكلاء ذكاء اصطناعي وحصة API واحدة: كيف يمنع Rate Governor الأعطال المتتالية
- 12 نوفمبر 2026AWS في أكتوبر: Haiku 5.5 أرخص بنسبة 75%، وبدائل احتياطية للنماذج، وصندوق عزل للوكلاء
- 28 أكتوبر 2026Keystone تُخرج اسم النموذج من الشيفرة: بوابة LLM مفتوحة المصدر تضيف 0.64 مللي ثانية فقط
- 12 نوفمبر 2026وكيل من 30 خطوة مع 1% من الإخفاقات يفشل في مهمة من كل أربع: كيف تجهّزه للإنتاج
أسئلة وأجوبة حول الخبر
ما أبرز التفاصيل حول من ملف واحد إلى API وworker وTemporal؟
النسخة الأولية تحتفظ بسجل المحادثة في ذاكرة العملية. إعادة التشغيل تمحو جميع المحادثات، ويُخدَّم العملاء واحداً تلو الآخر، وإذا سقطت العملية بين استدعاء refund_payment والرد فلا أحد يعرف هل عادت الأموال أم لا. الخطوة الأولى: فصل السكربت إلى API وworker. تستقبل الـAPI الرسالة وتكتبها في قاعدة البيانات وتردّ على الدردشة فوراً. هي لا تستدعي النموذج، لذا تردّ في أجزاء من الثانية. أما حلقة الوكيل فتعيش في workers منفصلة يمكن إضافتها حسب الحمل. صار السجل في قاعدة البيانات وينجو من إعادة التشغيل.
ما أبرز التفاصيل حول إعادة المحاولة ليست circuit breaker؟
عندما يتعطل مزوّد النموذج نصف ساعة، يعيد Temporal محاولة الـactivity بأمانة. مئة worker وألف طلب مفتوح تطرق معاً على الـAPI المتعطلة، وعندما تعود تنهال عليها الطابور بأكمله. إعادة المحاولة مصممة لعطل يزول في ثوانٍ. أما الفشل الطويل فيحتاج إلى circuit breaker. فهو يعدّ الأعطال، وبعد بلوغ العتبة ينفتح ويعيد خطأً فوراً دون التوجه إلى الخدمة، وبعد فترة يسمح بمرور استدعاء تجريبي. يجب أن تكون حالة القاطع مشتركة بين جميع الـworkers، وإلا سيكتشف كل منها من جديد أن المزوّد متوقف.
ما أبرز التفاصيل حول الساغا والمشغّل والموجّه؟
يمسّ الاسترداد ثلاثة أنظمة بلا معاملة مشتركة: الملصق لدى خدمة التوصيل، والأموال في بوابة الدفع، وإشعار العميل وتحديث الطلب. هذه ساغا: لكل خطوة تعويض. المفهوم الأساسي هو نقطة اللاعودة (pivot transaction). قبل إعادة الأموال يمكن إلغاء الخطوات، وبعدها يجب إتمام رسالة العميل وتحديث الطلب مهما تطلّب ذلك من محاولات. يحصل كل إجراء على مفتاح idempotency، مثل معرّف القرار، فلا تخصم بوابة الدفع الأموال مرة ثانية. يجب ألا يُجري النموذج المبالغ الكبيرة. يعرض الـworkflow القرار في لوحة المشغّل وينتظر إشارة.
Delegate Deep Research, Coding & Multi-Step Workflows to Nomad Agent
Deploy autonomous task execution with Nomad Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and MCP tool orchestration.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.