بناء ضوابط حتمية (Deterministic Guardrails) لأنظمة Multi-Agent المعتمدة على الحالة (Stateful)

إذا كان نظام الـ multi-agent الخاص بك يعتمد بالكامل على موجّهات النظام (system prompts) لتوجيه سير العمل، فهو معرض بشدة للدخول في حلقة لانهائية (infinite loop)، مما يستهلك ميزانية الـ API الخاصة بك دون تقديم أي نتيجة. الحل لبناء ضوابط (guardrails) لأنظمة multi-agent لا يكمن في كتابة تعليمات أكثر صرامة للنموذج اللغوي، بل في نقل تدفق التحكم (control flow) خارج النموذج تماماً وتحويله إلى كود حتمي (deterministic code).

على مستوى الصناعة، كشف الانتقال من التفاعلات القائمة على موجّه واحد إلى مخططات سير العمل المعتمدة على الحالة (stateful multi-agent workflows) عن خلل حرج: انحراف الحالة (state drift). عندما يتبادل ثلاثة أو أربعة وكلاء (agents) البيانات ذهاباً وإياباً — من استرجاع المستندات وتنسيق البيانات إلى استدعاء واجهات برمجة التطبيقات (APIs) الخارجية — فإن متغيراً واحداً مهلوساً (hallucinated variable) يمكن أن يخرج السلسلة بأكملها عن مسارها. نرى شركات تراكم ديوناً تقنية في الذكاء الاصطناعي (AI debt) بمحاولة إصلاح هذه الإخفاقات الهيكلية عبر كتابة موجّهات أطول وأكثر تعقيداً. بالنسبة لمشتري المؤسسات ومؤسسي الشركات الناشئة (SaaS) في الولايات المتحدة ومنطقة الخليج العربي، حيث الكفاءة التشغيلية وقابلية التوسع هما الأساس، فإن هذا ليس مجرد إزعاج هندسي بسيط — بل هو تهديد مباشر لاقتصاديات الوحدة (unit economics)، وثقة العملاء، واستقرار النظام. تتطلب هندسة الذكاء الاصطناعي الجاهزة للتشغيل الفعلي (production-grade) التعامل مع الوكلاء كدوال غير موثوقة (untrusted functions) تحكمها آلات حالة (state machines) مبرمجة مسبقاً ومقيدة رياضياً.

التكلفة المالية والتشغيلية للوكلاء غير الحتميين (Non-Deterministic Agents)

يعمل نظام الـ multi-agent عادةً عن طريق السماح لنموذج منسق (orchestrator model) بتحديد الوكيل الفرعي (sub-agent) الذي يجب استدعاؤه بناءً على الحالة الحالية للمهمة. في التطبيقات البسيطة (naive implementation)، يكون قرار التوجيه هذا احتمالياً بالكامل؛ حيث يتوقع النموذج اللغوي الخطوة التالية الأفضل بناءً على أوزان تدريبه والسياق المتاح.

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

تخيل وكيلاً (agent) مكلفاً بتأهيل عميل محتمل، والاستعلام من نظام إدارة علاقات العملاء (CRM)، وصياغة بريد إلكتروني. إذا أرجعت واجهة CRM API رمز خطأ غير متوقع، فقد يحاول الوكيل غير المقيد بشكل جيد الاستعلام من الـ CRM مرة أخرى، ثم مرة أخرى. ونظراً لأن النموذج اللغوي ليس لديه مفهوم متأصل للوقت أو التكلفة، فإنه سيستمر في التكرار حتى يصل إلى الحد الأقصى للوقت (timeout) أو يستنفد نافذة السياق (context window) بالكامل.

تتزايد التكلفة المالية لهذه الحلقات التكرارية طردياً مع حجم السياق. إذا دخل وكيل لديه تاريخ سياق يبلغ 10,000 رمز (token) في حلقة مفرغة، فإن كل محاولة إعادة ستعالج تلك الرموز مجدداً. بافتراض حمولة ثابتة تبلغ 10,000 token لكل محاولة، وبمعدل أسعار الـ API القياسي للمؤسسات البالغ حوالي 5.00 دولارات لكل مليون token مدخل (باستخدام النماذج الحالية من عائلات GPT-4o أو Claude 3.5)، فإن الوكيل العالق في حلقة من 50 خطوة سيعالج 500,000 token، مما يكلف 2.50 دولار لاستعلام فاشل واحد. اضرب ذلك في 100 مهمة خلفية مؤتمتة تعمل بالتوازي، وسيتحول خطأ توجيه بسيط إلى 250 دولاراً من الحوسبة المهدرة في دقائق معدودة، إلى جانب الفشل التام في تحقيق هدف العمل.

على مدار شهر من التشغيل الفعلي دون مراقبة، يمكن لهذه الإخفاقات الصامتة أن تضخم فواتير الـ API بآلاف الدولارات، مع تعريض عملك في الوقت نفسه لانتهاكات اتفاقية مستوى الخدمة (SLA) وخسارة العملاء (churn). لهذا السبب، يعد الاعتماد على موجّهات مثل "لا تكرر نفس الإجراء مرتين" فشلاً هندسياً. النماذج اللغوية هي مولدات نصوص احتمالية، ولا يمكنها ضمان الالتزام بالقيود السلبية. تتطلب الأنظمة الفعلية ضوابط حتمية (deterministic guardrails) تمنع فيها البنية الهيكلية نفسها حدوث مثل هذه الأخطاء.

الحدود الرياضية القصوى: إيقاف الحلقة اللانهائية

لمنع الوكلاء المستقلين من الخروج عن السيطرة، يجب أن تفصل بنية النظام بين "التفكير" (النموذج اللغوي LLM) و"التنفيذ" (مسار التشغيل). ويتم تحقيق ذلك من خلال بنيات مخططات الحالة (state-graph architectures)، والتي يتم تنفيذها باستخدام أطر عمل مثل LangGraph.

في إعداد مخطط الحالة (state-graph)، يتم تعريف سير عمل الـ multi-agent كمخطط موجه (directed graph). تمثل العقد (nodes) الوكلاء أو الأدوات، بينما تمثل الحواف (edges) الانتقالات الممكنة بينهم. لا يقوم النموذج اللغوي بتنفيذ الانتقال بنفسه، بل يقتصر دوره على تقديم تحديث للحالة (state update). بعد ذلك، يقرأ محرك المخطط (graph engine) هذه الحالة وينتقل إلى العقدة التالية وفقاً لقواعد صارمة ومبرمجة مسبقاً.

يوفر هذا الفصل بين المسؤوليات صمام أمان حاسم: تضع بنيات state-graph حداً أقصى لخطوات الانتقال لمنع الحلقات اللانهائية لنماذج LLM رياضياً. من خلال وضع حد تكرار صارم (recursion limit) على مستوى المخطط — على سبيل المثال، حد أقصى يبلغ 15 انتقالاً بين العقد لكل عملية تشغيل — يضمن النظام عدم تجاوز أي مهمة للميزانية الحوسبية المحددة لها. إذا فشل الوكيل في حل المهمة خلال 15 خطوة، يوقف المخطط التنفيذ قسرياً، ويسجل خطأ انتهاء الوقت، ويوجه الفشل إلى مشرف بشري أو نظام بديل (fallback).

بالنسبة لمتخذي القرار في الأعمال، يعني هذا إمكانية التنبؤ (predictability). يمكنك حساب التكلفة القصوى المطلقة لأي سير عمل محدد. إذا كان سياق الوكيل مقيداً بـ 20,000 token لكل خطوة وكان المخطط مقيداً بـ 10 خطوات، فإن أقصى تكلفة تشغيلية لكل جولة تقتصر رياضياً على معالجة 200,000 token. لن تضطر بعد الآن إلى كتابة شيكات على بياض لمزودي الـ API على أمل أن ينجح النموذج في حل المهمة في النهاية.

زمن الاستجابة وقابلية المراقبة في الأنظمة المعتمدة على الحالة (Stateful Systems)

عندما يفشل نظام multi-agent، يكون تشخيص السبب الجذري أكثر تعقيداً بكثير من تصحيح أخطاء البرمجيات التقليدية. قد لا يكون الفشل عبارة عن تعطل في الكود، بل قد يتمثل في قيام الوكيل (A) بتمرير سياق غامض قليلاً إلى الوكيل (B)، مما يدفع الوكيل (B) إلى استخدام معايير بحث خاطئة عند استدعاء أداة قاعدة البيانات.

بالنسبة لمنصات SaaS سريعة النمو وعمليات المؤسسات، يعد زمن الاستجابة (latency) مقياساً أساسياً للأعمال؛ فكل ميلي ثانية تضاف إلى سير العمل تهدد بمغادرة المستخدمين وخسارة التحويلات. علاوة على ذلك، في الأسواق الخاضعة للتنظيم الصارم في الولايات المتحدة ومنطقة الخليج، فإن غياب تدقيق واضح لعمليات اتخاذ القرار يفرض مخاطر امتثال جسيمة. للحد من هذه المخاطر دون التأثير على الأداء، يجب على الشركات تطبيق أطر عمل للمراقبة غير معطلة للتشغيل (non-blocking observability) لتتبع قرارات الوكلاء في الوقت الفعلي.

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

مع تفعيل التتبع غير المتزامن، تكتسب فرق العمليات القدرة على تصور المسار الدقيق لسير عمل الـ multi-agent. يمكنك رؤية اللحظة الدقيقة التي هلوس فيها الوكيل بمعامل ما، والوقت الذي استغرقته أداة API معينة للاستجابة، وعدد الـ tokens المستهلكة بدقة في كل خطوة. هذه البيانات هي حجر الأساس للذكاء الاصطناعي الجاهز للتشغيل الفعلي. بدونها، ستعمل بلا رؤية، وستكون أي محاولة لتحسين موثوقية النظام مجرد تخمين.

تقييم تحديثات الوكلاء قبل النشر في بيئة التشغيل الفعلي

اليوم الأكثر خطورة على نظام الـ multi-agent هو يوم تحديثه. قد يؤدي تغيير الموجّه لوكيل استخراج البيانات إلى تحسين مهمته المحددة، ولكنه قد يغير دون قصد تنسيق البيانات التي يمررها إلى وكيل التلخيص التالي في خط المعالجة، مما يتسبب في تعطل النظام بأكمله.

بالنسبة لقادة المنتجات والهندسة، تمثل التقييمات اليدوية السريعة (vibe checks) عقبة تشغيلية مكلفة، حيث تؤدي إلى إبطاء سرعة النشر والمخاطرة بحدوث تراجعات صامتة (silent regressions) في بيئة التشغيل الفعلي. إن الاعتماد على المطورين لاختبار بضعة استعلامات يدوياً هو السبب الرئيسي وراء فشل المشاريع التجريبية للذكاء الاصطناعي عند توسيع نطاقها. للحفاظ على المرونة التنافسية، تحتاج الشركات إلى خطوط اختبار مؤتمتة (automated testing pipelines) للتحقق من سلوك الوكيل في ثوانٍ معدودة، مما يحمي ساعات العمل الهندسية وتجربة العملاء على حد سواء.

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

عندما يقترح مهندس تغييراً في منطق عمل الوكيل، يقوم خط معالجة التطوير والنشر المستمر (CI/CD pipeline) تلقائياً بتشغيل الوكيل المحدث مقابل مجموعة بيانات تحتوي على مئات التفاعلات التاريخية المعتمدة. بعد ذلك، يقوم إطار التقييم بتسجيل درجات المخرجات الجديدة. إذا انخفض مقياس answer_relevancy عن حد معين — على سبيل المثال، 0.85 من 1.0 — يفشل البناء (build) ويتم حظر وصول التحديث إلى بيئة التشغيل الفعلي.

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

مقارنة بين بنيات الضوابط (Guardrail Architectures)

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

يتطلب الانتقال من القيود القائمة على الموجّهات إلى إدارة مخطط الحالة (state-graph orchestration) استثماراً أولياً في البنية الهندسية. ومع ذلك، يتم تعويض هذه التكلفة المسبقة سريعاً من خلال التخلص من فواتير الـ API المتضخمة والتقليل الكبير في ساعات الصيانة المطلوبة لحل مشكلات سير عمل الوكلاء العالقة.

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

تطبيق إدارة الحالة الحتمية (Deterministic State Management)

لبناء هذه الأنظمة بفعالية، يجب على الفرق الهندسية اعتماد مخطط (schema) صارم لإدارة الحالة. في بنية مخطط الحالة (state-graph)، تكون "الحالة" عبارة عن كائن بيانات (data object) محدد يتم تمريره من عقدة إلى أخرى.

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

إذا تم تكليف وكيل بصياغة مقترح بناءً على ملاحظات العميل، يجب أن يحدد كائن الحالة صراحةً حقولاً لـ client_notes و missing_information و draft_status و error_count.

عند تشغيل الوكيل، يُسمح له فقط بتحديث حقول معينة داخل هذه الحالة. إذا قرر الوكيل أن هناك معلومات مفقودة، فإنه يقوم بتحديث حقل missing_information ويضبط draft_status على "blocked". يقرأ محرك المخطط هذا التغيير في الحالة ويوجه سير العمل بشكل حتمي إلى عقدة موافقة بشرية (human-in-the-loop)، بدلاً من السماح للوكيل بهلوسة التفاصيل المفقودة.

يغير هذا الأسلوب جذرياً نظرتنا لنماذج اللغة في البنية التقنية للمؤسسات. لم تعد هذه النماذج موظفين مستقلين يُمنحون حرية التصرف لحل المشكلات، بل هي محركات تفكير قوية مقيدة داخل خطوط برمجية صارمة وقابلة للتتبع والتحقق. تنقل Verel Systems الذكاء الاصطناعي من العشوائية إلى التشغيل الفعلي المنظم من خلال فرض هذه الحدود، مما يضمن تنفيذ الوكيل بشكل متوقع في كل مرة يتم فيها نشره.

الأسئلة الشائعة

هل يؤدي تقييد الوكلاء بمخططات الحالة (state graphs) إلى تقليل قدرتهم على حل المشكلات المعقدة؟ لا، بل يركز قدراتهم التفكيرية. من خلال نقل عبء إدارة سير العمل إلى بنية المخطط، يمكن للنموذج اللغوي تخصيص نافذة السياق وقدرة المعالجة بالكامل لحل المهمة الفرعية المحددة المعروضة عليه، بدلاً من محاولة تذكر مكانه الحالي في عملية تتكون من 20 خطوة.

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

هل بنية مخطط الحالة (state-graph) مطلوبة لنظام الوكيل الواحد (single-agent)؟ إذا كان الوكيل الواحد يمتلك صلاحية الوصول إلى أدوات خارجية (مثل البحث على الويب أو الاستعلام من قاعدة بيانات) ويمكنه استدعاؤها بشكل تكراري، فنعم. أي نظام يتحكم فيه نموذج LLM في حلقة تكرارية يتطلب حدوداً حتمية لمنع التشغيل اللانهائي الخارج عن السيطرة. أما عمليات تحويل النصوص الخطية تماماً وأحادية الخطوة فلا تتطلب هذا المستوى من البنية الهيكلية.

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

ما هو العائد المتوقع على الاستثمار (ROI) من الانتقال من الإعدادات القائمة على الموجّهات إلى بنيات مخططات الحالة (state-graph)؟ على الرغم من أن بنيات state-graph تتطلب استثماراً هندسياً أعلى في البداية، إلا أنها عادةً ما تعوض تكلفتها في غضون 3 إلى 6 أشهر. من خلال القضاء على حلقات الـ API اللانهائية (التي قد تكلف مئات الدولارات لكل حادثة)، وتقليل وقت اختبار الجودة اليدوي بنسبة تصل إلى 80%، ومنع خسارة العملاء الناتجة عن الإخفاقات الصامتة، يحول هذا الانتقال الذكاء الاصطناعي من مركز تكلفة متقلب إلى أصل متوقع وعالي الهامش الربحي.